I am lost.
Can you provide me a precise bug report?
cheers, AA
On 13 Oct 2008, at 11:01 , Simon Denier wrote:
On 12 oct. 08, at 12:12, Tudor Girba wrote:
No, you had it right :).
The only problem is that we cannot specify these derived options in Fame. In this case it is easy because it's just a negation, but in other cases it can be more complicated.
Sorry for the cross-post, but since I guess it can be of interest for eberybody.
So I understand the rationale, but the squeak code generator and the Java code generator are not consistent.
- in Java some code is generated, more specifically in Famix3:
- above<->below is a one-to-one relationship and the update code
can be generated (as is the case in Fame Java)
- isRead is implemented as a normal attribute complete with an
instance variable, without any update code - but it should be a derived attribute
- in squeak both are left as 'shouldBeImplemented'
Actually I think that both are 50% right/50% wrong. Fame Java does it right when generating the update code for one-one relationship, but is wrong when it implements isRead - the derived property is lost and this is something which is easily overlooked - as you say it should be left as is.
Cheers, Doru
On Oct 10, 2008, at 4:40 PM, Simon Denier wrote:
Thanks for your clarification, it helps!
Now I can compare the generated code under VW with Squeak (as well as with Fame4Java but it's another story)
The code seems fine except for Association>>below as well as Access>>isRead Both are implemented with 'self shoudBeImplemented' Both are derived attributes Association>>below is the opposite attribute of Association>>above It seems obvious that isRead is derived from isWrite.
there should be some code at least to update the one-to-one relationship between above<->below.
did I miss something?