13 Oct
2008
13 Oct
'08
11:01 a.m.
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:
--
Simon Denier, PhD
Postdoc, Ptidej Team
DIRO, Université de Montréal
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?
On 9 oct. 08, at 14:53, Tudor Girba wrote:
--
www.tudorgirba.com
www.tudorgirba.com/blog
"Beauty is where we see it."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi,
Sorry for the trouble. FAMIX 3.0 is a construction site and the
information is not consistent.
The website shows the beta 14 version which is about half a year
old.
The current and running one can be found in the Famix-Specification
package in the http://www.squeaksource.com/Moose Squeak repository.
I will try to put a new image and the specification online in the
following days.
Cheers,
Doru
On Oct 9, 2008, at 12:10 PM, Simon Denier wrote:
--
Simon Denier, PhD
Postdoc, Ptidej Team
DIRO, Université de Montréal
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
I'm confused
Where is the reference implementation for Famix 3.0 right now?
Because when I look at those documents
http://moose.unibe.ch/docs/famix/famix3.0?_s=qCdqiYvltMRJXWPd&_k=KPeddY…
Famix 3.0 beta 14
it does not match with what I found in the Squeak package. Namely,
there is no incomingInvocations in the FAMIXEntity class. Also some
methods such as Access>>isRead are not implemented.
However, when I look at the generated code with Fame for Java and
the mse file included (FAMIX30.fm3.mse), the attribute
incomingInvocations is defined. However (another problem?), it is
declared as an opposite to Invocation>>candidates, but this one
declares BehaviouralEntity>>incomingInvocations as the opposite.
So, I'm really confused.
--
Simon Denier, PhD
Postdoc, Ptidej Team
DIRO, Université de Montréal
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
www.tudorgirba.com/blog
"To lead is not to demand things, it is to make them happen."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev