13 Oct
2008
13 Oct
'08
5:31 p.m.
On 13 oct. 08, at 11:23, Adrian Kuhn wrote:
I am lost.
Can you provide me a precise bug report?
Actually there is two, one for Squeak/Fame and the other for Java/
Fame. Should I post them on:
http://code.google.com/p/moose-technology/issues/list
Anyway, here is the first for Squeak/Fame (I will post the second on
the Fame ML only, as it only concerns Fame 4 Java)
Ttitle: one-to-one relationship are not implemented
Description:
when two properties are declared as opposite but not multivalued, and
one is derived, this implies a one-to-one relationship between the two
classes (or at least this is my working hypothesis :)).
In particular the setter method for each of these attributes should
update the opposite attribute.
However, the code for the derived attribute is not generated (see
example below)
Note:
this case is handled in Fame 4 Java but with a double recursion schema.
Alternate solution: create a FMOnevalueLink which would take care of
the update logic.
Example:
From Famix3 current specification, attributes above and below are
opposite, both defined in Association, below is derived from above.
Current generated code:
below
<MSEProperty: #below type: #FAMIXAssociation opposite: #above>
<derived>
^self shoudBeImplemented
below: anAssociation
below set: anAssociation
initialize
super initialize.
above := nil.
(below is not initialized)
cheers,
AA
On 13 Oct 2008, at 11:01 , Simon Denier wrote:
--
Simon Denier, PhD
Postdoc, Ptidej Team
DIRO, Université de Montréal
On 12 oct. 08, at 12:12, Tudor Girba wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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?
>>