7 Dec
2007
7 Dec
'07
3:51 p.m.
Hi,
currently opposites are described as
opposite and opposite+derived. This can be one->one, one->many,
many->one and many->many. We
can easily generate code which handles all those different cases.
Secondly, when we are writing out instances of fm3-described classes; we
know when attributes
have an opposite. There the derived is quite unimportant; since it is
just a hint to the writer "which" of
the 2 opposites it should write and which it should derive. However,
since you can
generate code which takes all different cases into account, writing it
out (and reading it in) either way is
possible. The opposite can be filled in from either of the available
relationships. So which opposite you
file out could be chosen randomly. Coming to my point: do attributes
which have an opposite need a
derived statement? Isn't it more logical that only real algorithmic
"attributes" are derived? When choosing
automatically you will only have to take care that if an opposite is its
own opposite (the opposite of the
attribute "opposite" in fm3.Property is like this; that's probably the
only case :)), that it always gets written.
#(((
#This fact would again strengthen my case that the opposite of an
opposite should not necessarily be
#declared as an opposite in the MSE file. Nor should the type be in
either of them. If we find (prop (id: 2)
#(opposite (idref: 1))), then we should automatically do (objectAtId:
1).setOpposite(objectAtId: 2),
#which sets the owner of (objectAtId: 2) as it's type, sets the type of
the (objectAtId: 2) as the owner of
#(objectAtId: 1); and then sets (objectAtId: 2) as the opposite of
(objectAtId: 1)
#
#---->> if you use an opposite-declaration for an attribute; you have 1
statement instead of 5 for which 4 are
#redundant ----> less redundancy => better performance
#)))
any ideas / comments? Does this seem right / clean?
cheers,
Toon
7 Dec
7 Dec
7:07 p.m.
On 7 Dec 2007, at 15:51 , Toon Verwaest wrote:
currently opposites are described as
opposite and opposite+derived. This can be one->one, one->many,
many->one and many->many. We
can easily generate code which handles all those different cases.
Secondly, when we are writing out instances of fm3-described
classes; we
know when attributes
have an opposite. There the derived is quite unimportant; since it is
just a hint to the writer "which" of
the 2 opposites it should write and which it should derive. However,
since you can
generate code which takes all different cases into account, writing it
out (and reading it in) either way is
possible. The opposite can be filled in from either of the available
relationships. So which opposite you
file out could be chosen randomly. Coming to my point: do attributes
which have an opposite need a
derived statement? Isn't it more logical that only real algorithmic
"attributes" are derived? When choosing
automatically you will only have to take care that if an opposite
is its
own opposite (the opposite of the
attribute "opposite" in fm3.Property is like this; that's probably the
only case :)), that it always gets written.
You are right, the derived opposites are a mere hint. Some points why
this might nevertheless be a good idea to keep them, we are not the
only client of mse
- generated code is not the only use-case
- there is legacy code that does not update opposites automatically
- some people use hardcoded mse exporters
- some people use hardcoded mse importers
#(((#This fact would again strengthen my case that the
opposite of an
opposite should not necessarily be
#declared as an opposite in the MSE file. Nor should the type be in
either of them. If we find (prop (id: 2)
#(opposite (idref: 1))), then we should automatically do (objectAtId:
1).setOpposite(objectAtId: 2),
#which sets the owner of (objectAtId: 2) as it's type, sets the
type of
the (objectAtId: 2) as the owner of
#(objectAtId: 1); and then sets (objectAtId: 2) as the opposite of
(objectAtId: 1)
#
#---->> if you use an opposite-declaration for an attribute; you
have 1
statement instead of 5 for which 4 are
#redundant ----> less redundancy => better performance
#)))
Do you have a reference implementation?
any ideas / comments? Does this seem right / clean?
cheers,
Toon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:04 p.m.
Adrian Kuhn wrote:
Not yet, shouldn't be too difficult though...
What I -did- implement today in my python version is "onemany.py", which
is a implementation of a
One class and a Many class which are polymorphic "Opposite" descendants.
Which both have a
pointer to their owner instance. This allows me to use them as instance
variables of (their owner
instances), and instead of setting these instance variables and updating
the other side of a (one->one,
one->many or many->many relationship), these Opposite-descendants get a
new Opposite added.
This implements the 3 scenarios by using just 2 (polymorphic) classes.
Example of a use (this is generated code, I indicated the lines to read
with "%"):
class LocalVariable(StructuralEntity.StructuralEntity):
def __init__(self):
StructuralEntity.StructuralEntity.__init__(self)
% self.gen_parentBehaviouralEntity = onemany.One(self)
def getParentBehaviouralEntity(self):
# .value() returns the owner of the opposite Opposite descendant
% return self.gen_parentBehaviouralEntity.value()
def setParentBehaviouralEntity(self, gen_parentBehaviouralEntity):
import BehaviouralEntity
assert(isinstance(gen_parentBehaviouralEntity,
BehaviouralEntity.BehaviouralEntity))
%
self.gen_parentBehaviouralEntity.add(gen_parentBehaviouralEntity.gen_localVariables)
class BehaviouralEntity(ContainerEntity.ContainerEntity):
def __init__(self):
ContainerEntity.ContainerEntity.__init__(self)
self.gen_outgoingInvocations = onemany.Many(self)
% self.gen_localVariables = onemany.Many(self)
self.gen_parameters = onemany.Many(self)
self.gen_outgoingAccesses = onemany.Many(self)
self.gen_signature = None
% def getLocalVariables(self):
# values returns a [] of owners of the opposite Opposite descendants
% return self.gen_localVariables.values()
def setLocalVariables(self, gen_localVariables):
import LocalVariable
assert(isinstance(gen_localVariables, list))
for i in gen_localVariables:
assert(isinstance(i, LocalVariable.LocalVariable))
# On the setting of many-side you have to clear manually
since adding does not remove for Many
% self.gen_localVariables.clear()
% for i in gen_localVariables:
% self.gen_localVariables.add(i.gen_parentBehaviouralEntity)
((in the code I prepend gen_ to all instance variable names to avoid
conflicts with existing keywords))
if you want to run it yourself, do "python fm3codegenerator.py
FAMIX30.fm3.mse" (FAMIX30.fm3.mse not supplied
in that svn dir)
cheers,
Toon
- generated code is not the only use-case
- there is legacy code that does not update opposites automatically
- some people use hardcoded mse exporters
- some people use hardcoded mse importers
right .. backwards compatibility.... the horror of microsoft nightmares
all over again
#(((#This fact would again strengthen my case
that the opposite of an
opposite should not necessarily be
#declared as an opposite in the MSE file. Nor should the type be in
either of them. If we find (prop (id: 2)
#(opposite (idref: 1))), then we should automatically do (objectAtId:
1).setOpposite(objectAtId: 2),
#which sets the owner of (objectAtId: 2) as it's type, sets the
type of
the (objectAtId: 2) as the owner of
#(objectAtId: 1); and then sets (objectAtId: 2) as the opposite of
(objectAtId: 1)
#
#---->> if you use an opposite-declaration for an attribute; you
have 1
statement instead of 5 for which 4 are
#redundant ----> less redundancy => better performance
#)))
Do you have a reference implementation?
10:10 p.m.
Toon Verwaest wrote:
Adrian Kuhn wrote:
> - generated code is not the only use-case
>
Oh and right; what -IS- the other use-case which is not covered by what
I explained?
- there is
legacy code that does not update opposites automatically
- some people use hardcoded mse exporters
- some people use hardcoded mse importers
right .. backwards compatibility.... the horror of microsoft nightmares
all over again
10 Dec
10 Dec
11:29 a.m.
#(((#This fact would again strengthen my case that the
opposite of an
opposite should not necessarily be
#declared as an opposite in the MSE file. Nor should the type be in
either of them. If we find (prop (id: 2)
#(opposite (idref: 1))), then we should automatically do (objectAtId:
1).setOpposite(objectAtId: 2),
#which sets the owner of (objectAtId: 2) as it's type, sets the
type of
the (objectAtId: 2) as the owner of
#(objectAtId: 1); and then sets (objectAtId: 2) as the opposite of
(objectAtId: 1)
#
#---->> if you use an opposite-declaration for an attribute; you
have 1
statement instead of 5 for which 4 are
#redundant ----> less redundancy => better performance
#)))
Do you have a reference implementation?
12:01 p.m.
On 10 Dec 2007, at 11:29 , Toon Verwaest wrote:
I just had a look at this, and it actually already
automatically
works,
since opposites are defined as One instances of my implementation
of One
to One relations; since they have an opposite. When you write one
of the
opposites; the other one is automatically set. (I don't set the types
automatically yet; but that should only be two lines of code)
Cool!
Writing this out to an MSE file with only one opposite
also doesn't
work
[...snip...]
I dont know if writing is necessary, as I understood your usecase is
import of handwritten metamoels, right?
AA
1:29 p.m.
Adrian Kuhn wrote:
Right. However, I think that we should also try to reduce filesizes
where possible anyhow. This is quite straightforward and applies to all
situations so... why not?
So for those not getting it; I basically implemented the reduction from
5 attribute declarations of two opposite fm3.Property in mse-files to
one attribute in one of these opposite properties. Opposite+type+derived
and opposite+type to just one time opposite.
cheers
On 10 Dec 2007, at 11:29 , Toon Verwaest wrote:
Now the types also work. For this I just had to change the accessor
(getType) of property to:
if self.hasOpposite():
return self.getOpposite().getOwningClass()
else:
return self.type
Code generation uses these accessors instead of direct access anyway; so
it nicely generates correct type-asserts.
I just had a look at this, and it actually
already automatically
works,
since opposites are defined as One instances of my implementation
of One
to One relations; since they have an opposite. When you write one
of the
opposites; the other one is automatically set. (I don't set the types
automatically yet; but that should only be two lines of code)
Cool!
Writing this out to an MSE file with only one
opposite also doesn't
work
[...snip...]
I dont know if writing is necessary, as I understood your usecase is
import of handwritten metamoels, right?
5993
days inactive
5996
days old
6 comments
2 participants
participants (2)
-
Adrian Kuhn -
Toon Verwaest