Home » Modeling » EMF » HowTo model initializers
|
| Re: HowTo model initializers [message #428354 is a reply to message #428350] |
Tue, 17 March 2009 18:32   |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Michael,
Comments below.
Michael Mühlberg wrote:
> Hello,
>
> EMF supports attribute defaults, that has also to be constant.
Yes.
> If an
> attribute has a value that is equal to its default, it isn't persisted.
For feature with unsettable false, that's right.
> If
> the default changes after a model has been persisted and the model gets read
> from the persistence the attribute gets the new default.
>
Yes, that's the idea.
> So far so good for defaults.
>
> What I need is an initializer, also not constant, e.g. a GUID.
Think about when an object is created in order to deserialize. You'd
not need it then. Similarly when you do EcoreUtil.copy. It's expensive
to create a UUID only to have it replaced.
> An
> initializer is only set when an object is created, i.e. it isn't set during
> model load. This is typically done in a constructor.
>
XMIResourceImpl is also able to assign a UUID when the object is first
attached to the resource. This UUID remains associated with the object
even if it's moved to a different resource.
> Is there anyone out there who can tell me how I can "model" an initializer?
>
For the reason you describe, I think you should use extrinsic IDs.
> I want to avoid a manual change of the generated constructor. This because I
> also want sub classes of my class to have the initial value set which is not
> possible when the sub class has multiple inheritance and my class is not its
> first super class :)
>
If you really needed an initializer, it would likely to do it lazily,
i.e., initialize when you first get the value and there is no value
yet. But I don't think that's what you should do here.
Keep in mind too that UUIDs have a big footprint impact. Just count the
number of bytes in there and think carefully about how much their nice
properties are worth...
> Ciao, Michael
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
| Re: HowTo model initializers [message #429429 is a reply to message #429401] |
Thu, 23 April 2009 07:28 |
Michael Mühlberg
Messages: 33
Registered: July 2009 |
Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_000B_01C9C3F5.D5A1E2D0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Ed,
thanks for the idea with the unsettability, I think we can do it like =
that.
But wouldn't we achieve the same if we would override eIsSet, i.e. =
without making the attribute unsettable? We would use the pattern of =
renaming eIsSet to eIsSetGen and then our eIsSet would only react for =
the ID attribute and call eIsSetGen for all other attributes.
The only case then is that methods like eUnSet(attr) or unset<attr>() =
would have no effect wrt. eIsSet, ok, so what :)
Please allow me to make a few general statements about the =
responsibility of the setting of the ID-like attribute we are discussing =
here.
We want to provide a basic metamodel for our "applications" inhouse. =
Most of the attributes are indeed in the responsibility of that =
application, BUT, there are also "internal" attributes, that are in our =
responsibility.
The application doesn't care about them. We don't want it to set the ID =
attribute for example because the ID is an internal thing. The ID has =
also to be a UUID, so letting it set by the application would mean to =
establish an additional part of programming governance for them which =
should be avoided. It should only be allowed to read the attribute, =
nothing else.
Ciao, Michael
"Ed Merks" <Ed.Merks@gmail.com> wrote in message =
news:gsn4kj$8lk$1@build.eclipse.org...
Michael,
Comments below.
Michael M=FChlberg wrote:=20
Hello Ed,
I evaluated your proposals.
1. Using extrinsic IDs is not possible because the application that uses =
my=20
metamodel would then to be forced to first generate the extrinsic ID =
before=20
it can read it out, e.g. if it wants to store it somewhere in its own =
data.
I don't follow. How is this different from getting the model to =
generate it internally? In the end, you do consistently need an ID to =
be associated with an object...
2. Using the lazy initialization in the getter is also not possible =
because=20
then I don't get the attribute value persisted!
I'm not sure how that follows either. You could always make it =
unsettable and make it appear to be set and hence serialized.
Take the following simple use case. I create an instance of my class =
(which=20
has this famous GUID attribute) and do nothing else than to store it=20
afterwards. A common case that's well supported...
In this case the XMI Serializer does not serialize it because it=20
calls first eIsSet which returns false, so it doesn't call the getter=20
afterwards.
Make it unsettable and specialize isSetFoo to return true.
What now?
In the end, how is this problem any different from say ENamedElement =
where the name must be set? The client creating the element is =
responsible for setting the name and if they don't the instance is =
invalid. Similarly you can have the ID be a required attribute...
Ciao, Michael
"Ed Merks" <Ed.Merks@gmail.com> wrote in message=20
news:gpoqbk$vo3$1@build.eclipse.org...
Michael,
Comments below.
Michael M=FChlberg wrote:
Hello,
EMF supports attribute defaults, that has also to be constant.
Yes.
If an attribute has a value that is equal to its default, it isn't=20
persisted.
For feature with unsettable false, that's right.
If the default changes after a model has been persisted and the =
model=20
gets read from the persistence the attribute gets the new default.
Yes, that's the idea.
So far so good for defaults.
What I need is an initializer, also not constant, e.g. a GUID.
Think about when an object is created in order to deserialize. =
You'd not=20
need it then. Similarly when you do EcoreUtil.copy. It's expensive to=20
create a UUID only to have it replaced.
An initializer is only set when an object is created, i.e. it isn't =
set=20
during model load. This is typically done in a constructor.
XMIResourceImpl is also able to assign a UUID when the object is =
first=20
attached to the resource. This UUID remains associated with the object=20
even if it's moved to a different resource.
Is there anyone out there who can tell me how I can "model" an=20
initializer?
For the reason you describe, I think you should use extrinsic IDs.
I want to avoid a manual change of the generated constructor. This=20
because I also want sub classes of my class to have the initial value =
set=20
which is not possible when the sub class has multiple inheritance and my =
class is not its first super class :)
If you really needed an initializer, it would likely to do it =
lazily,=20
i.e., initialize when you first get the value and there is no value yet. =
But I don't think that's what you should do here.
Keep in mind too that UUIDs have a big footprint impact. Just count the =
number of bytes in there and think carefully about how much their nice=20
properties are worth...
Ciao, Michael
=20
------=_NextPart_000_000B_01C9C3F5.D5A1E2D0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3Dtext/html;charset=3DISO-8859-1 =
http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18702">
<STYLE></STYLE>
</HEAD>
<BODY dir=3Dltr bgColor=3D#ffffff text=3D#000000>
<DIV><FONT size=3D2 face=3DArial>Hello Ed,</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<DIV><FONT size=3D2 face=3DArial>thanks for the idea with the =
unsettability, I think=20
we can do it like that.</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<DIV><FONT size=3D2 face=3DArial>But wouldn't we achieve the same if we =
would=20
override eIsSet, i.e. without making the attribute unsettable? We would =
use the=20
pattern of renaming eIsSet to eIsSetGen and then our eIsSet would only =
react for=20
the ID attribute and call eIsSetGen for all other =
attributes.</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<DIV><FONT size=3D2 face=3DArial>The only case then is that methods like =
eUnSet(attr) or unset<attr>() would have no effect wrt. eIsSet, =
ok, so=20
what :)</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<DIV><FONT size=3D2 face=3DArial>Please allow me to make a few general =
statements=20
about the responsibility of the setting of the ID-like attribute we are=20
discussing here.</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<DIV><FONT size=3D2 face=3DArial>We want to provide a basic metamodel =
for our=20
"applications" inhouse. </FONT><FONT size=3D2 face=3DArial>Most of the =
attributes=20
are indeed in the responsibility of that application, BUT, there are =
also=20
"internal" attributes, that are in our responsibility.</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<DIV><FONT size=3D2 face=3DArial>The application doesn't care about =
them. We don't=20
want it to set the ID attribute for example because the ID is an =
internal thing.=20
The ID has also to be a UUID, so letting it set by the application would =
mean to=20
establish an additional part of programming governance for them which =
should be=20
avoided. It should only be allowed to read the attribute, nothing=20
else.</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<DIV><FONT size=3D2 face=3DArial>Ciao, Michael</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; =
PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px"=20
dir=3Dltr>
<DIV>"Ed Merks" <<A=20
href=3D"mailto:Ed.Merks@gmail.com">Ed.Merks@gmail.com</A>> wrote in =
message=20
<A=20
=
href=3D"news:gsn4kj$8lk$1@build.eclipse.org">news:gsn4kj$8lk$1@build.ecli=
pse.org</A>...</DIV>Michael,<BR><BR>Comments=20
below.<BR><BR>Michael M=FChlberg wrote:=20
<BLOCKQUOTE cite=3Dmid:gsn1g6$rc4$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Hello Ed,
I evaluated your proposals.
1. Using extrinsic IDs is not possible because the application that uses =
my=20
metamodel would then to be forced to first generate the extrinsic ID =
before=20
it can read it out, e.g. if it wants to store it somewhere in its own =
data.
</PRE></BLOCKQUOTE>I don't follow. How is this different =
from=20
getting the model to generate it internally? In the end, you do=20
consistently need an ID to be associated with an object...<BR>
<BLOCKQUOTE cite=3Dmid:gsn1g6$rc4$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">2. Using the lazy initialization in the =
getter is also not possible because=20
then I don't get the attribute value persisted!
</PRE></BLOCKQUOTE>I'm not sure how that follows either. You =
could=20
always make it unsettable and make it appear to be set and hence=20
serialized.<BR>
<BLOCKQUOTE cite=3Dmid:gsn1g6$rc4$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Take the following simple use case. I =
create an instance of my class (which=20
has this famous GUID attribute) and do nothing else than to store it=20
afterwards. </PRE></BLOCKQUOTE>A common case that's well =
supported...<BR>
<BLOCKQUOTE cite=3Dmid:gsn1g6$rc4$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">In this case the XMI Serializer does not =
serialize it because it=20
calls first eIsSet which returns false, so it doesn't call the getter=20
afterwards.
</PRE></BLOCKQUOTE>Make it unsettable and specialize isSetFoo to =
return=20
true.<BR>
<BLOCKQUOTE cite=3Dmid:gsn1g6$rc4$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">What now?
</PRE></BLOCKQUOTE>In the end, how is this problem any different from =
say=20
ENamedElement where the name must be set? The client creating =
the=20
element is responsible for setting the name and if they don't the =
instance is=20
invalid. Similarly you can have the ID be a required =
attribute...<BR>
<BLOCKQUOTE cite=3Dmid:gsn1g6$rc4$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Ciao, Michael
"Ed Merks" <A class=3Dmoz-txt-link-rfc2396E =
href=3D"mailto:Ed.Merks@gmail.com"><Ed.Merks@gmail.com></A> wrote =
in message=20
<A class=3Dmoz-txt-link-freetext =
href=3D"news:gpoqbk$vo3$1@build.eclipse.org">news:gpoqbk$vo3$1@build.ecli=
pse.org</A>...
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Michael,
Comments below.
Michael M=FChlberg wrote:
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hello,
EMF supports attribute defaults, that has also to be constant.
</PRE></BLOCKQUOTE><PRE wrap=3D"">Yes.
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">If an attribute has a =
value that is equal to its default, it isn't=20
persisted.
</PRE></BLOCKQUOTE><PRE wrap=3D"">For feature with unsettable =
false, that's right.
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D""> If the default changes =
after a model has been persisted and the model=20
gets read from the persistence the attribute gets the new default.
</PRE></BLOCKQUOTE><PRE wrap=3D"">Yes, that's the idea.
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">So far so good for =
defaults.
What I need is an initializer, also not constant, e.g. a GUID.
</PRE></BLOCKQUOTE><PRE wrap=3D"">Think about when an object is =
created in order to deserialize. You'd not=20
need it then. Similarly when you do EcoreUtil.copy. It's expensive to=20
create a UUID only to have it replaced.
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D""> An initializer is only =
set when an object is created, i.e. it isn't set=20
during model load. This is typically done in a constructor.
</PRE></BLOCKQUOTE><PRE wrap=3D"">XMIResourceImpl is also able to =
assign a UUID when the object is first=20
attached to the resource. This UUID remains associated with the object=20
even if it's moved to a different resource.
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Is there anyone out there =
who can tell me how I can "model" an=20
initializer?
</PRE></BLOCKQUOTE><PRE wrap=3D"">For the reason you describe, I =
think you should use extrinsic IDs.
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">I want to avoid a manual =
change of the generated constructor. This=20
because I also want sub classes of my class to have the initial value =
set=20
which is not possible when the sub class has multiple inheritance and my =
class is not its first super class :)
</PRE></BLOCKQUOTE><PRE wrap=3D"">If you really needed an =
initializer, it would likely to do it lazily,=20
i.e., initialize when you first get the value and there is no value yet. =
But I don't think that's what you should do here.
Keep in mind too that UUIDs have a big footprint impact. Just count the =
number of bytes in there and think carefully about how much their nice=20
properties are worth...
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Ciao, Michael
</PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=3D""><!---->
</PRE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_000B_01C9C3F5.D5A1E2D0--
|
|
| |
Goto Forum:
Current Time: Thu Apr 25 14:21:59 GMT 2024
Powered by FUDForum. Page generated in 0.03089 seconds |
] 
Search
Help
Register
Login
Home
