This is probably because of the slot-objects which are generated by the codegenerator for properties with an opposite. This one clearly has an opposite so to get the actually value, in code where you use objects for slots, you have to call values on it. I guess that if you use a different strategy for handling opposites, you don't wont to have the "values" message sent.
Or was there something else?
Stéphane Ducasse wrote:
Ok what I did was to go over all the changes you did (as they show up in the refactoring window) and check the code and evaluate what was changed. I put back most of the famix2 code (but let the annotations that were introduced by your changes). I think that there should be one or two cases where I was confused and it would be good if you can have a look. \ The most intriguing one was incomingInvocations <MSEProperty: #incomingInvocations type: #FAMIXInvocation opposite: #candidates> <mulivalued> <derived> ^ incomingInvocations values
stef
On Sep 6, 2008, at 4:04 PM, Oscar Nierstrasz wrote:
In the FAMIX2 Meta -> Fame stuff, there is apparently a race condition that I did not realize.
So although we patch up the lazy initializers, this may be done in the wrong order.
I should sit together with Doru and have a look at it.
- on
On Sep 4, 2008, at 14:18, Stéphane Ducasse wrote:
The problem is that in Famix20 we have lazzy initializers and they got replaced by direct accessor. So signature was for example not lazzily computed anymore, and breaking the debugger. :(
So I do not know what is the contract stuff you are talking about but at the end it should be fixed.
Stef
On Sep 4, 2008, at 2:01 PM, Tudor Girba wrote:
The error I mentioned before is not due to the changes of Oscar and Toon. It's just that Fame has a different contract than Meta.
Doru
On Sep 4, 2008, at 1:54 PM, Stéphane Ducasse wrote:
Apparently when applying blindly the changes of oscar I broke FAMIX2 (argh) so I will take another image and check one by one the suggested changes and produce a new Famx20 package
Stef On Sep 4, 2008, at 11:40 AM, Tudor Girba wrote:
Hi Stef,
I know it breaks. The errors that you mention are due to the fact that some old classes from VW do not conform to Fame.
That is why I said that for the moment just put there FAMIX2ModelRoot and then I will take a look at the code in the afternoon.
Cheers, Doru
On Sep 4, 2008, at 11:26 AM, Stéphane Ducasse wrote:
> On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote: > > >> Hi, >> >> FAMIX2Class mooseDescription works only if the repository is >> correctly >> setup :). >> >> If you look in the code, then "MooseModel>>meta" is the one that >> returns the meta-model. >> > Ah > I thought that we could plug any metamodel under fame > > > Now I did > > MooseModel2 class>>metaTower > "self resetMetaDescriptions. self metaTower" > > | pp | > ^metaTower ifNil: [ > pp := FMPragmaProcessor new. > pp queue: MooseEntity withAllSubclasses. > pp run. > metaTower := pp asTower] > > and I got a wonderful error which is a bad smell to me. > > > Stef > > > > > > > > > >> It is lazily created and in the current >> implementation is starts the lookup from FAMIXEntity which does >> not >> include FAMIX2. >> >> I would suggest to make it FAMIX2ModelRoot for the moment just >> to >> make >> it work with your code. >> >> >> > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
www.tudorgirba.com www.tudorgirba.com/blog
"What we can governs what we wish."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com www.tudorgirba.com/blog
"Problem solving efficiency grows with the abstractness level of problem understanding."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev