|
| Re: howto to do objects with serial numbers [message #422407 is a reply to message #422401] |
Thu, 04 September 2008 17:31  |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Gary,
Comments below.
gary s thompson wrote:
>
> Dear all
>
> I hope this is not too much of a ramble and is intelligible.
> I have a need to create some objects in emf which have serial numbers
> which are unique for each reference type within a container and have a
> fast lookup mechanism. Now I have written some classes that track
> serial numbers and can add those to the relevant parent classes.
> However I now needs a containment EList that looks for a new serial
> number from its container when objects are added to the the container.
>
> However there are a few areas where I am not sure what best to do
> I guess I need to hack into then the containment contract when the
> containment is set (and if it is reset/unset?) So I guess I need to
> hack a subclass of EObjectContainmentEList.java and override the
> methods that do the setting and removing of objects (however
> everything appears to lie in the subclasses and very little goes on in
> EObjectContainmentEList... which is a little strange am I right in
> thinking that most of the subclasses of BasicEList are to switch
> things on and off?)
Yes, the factoring is such that much of the logic is in BasicEList,
NotifyingEList, and EcoreEList.
>
> Also, the fast lookup by serial adds another requirement ie that the
> container should also be map like (i.e. internally i need to be able
> to lookup on serial numbers which I could make a key of the map) but i
> don't think there is anything like EObjectContainmentEMap.java ;-)
Nope.
>
> Finally the object that doles out serial numbers from the parent needs
> to an implementation artifact only (i.e not part of the public
> interface) so is it possible to have a field in a parent object that
> is only visible to the child (which may not be from the same package)
No. But you could have the parent's class implement some "Internal"
interface so that it's not visible in the public part of the API.
>
>
> as usually looking for any wise words
Probably I'm missing the big picture of what will be achieved by
this... Certainly hooks like EObjectImpl.eBasicSetContainer might be a
simple place to know the container and know to compute something based
on that container. The lists themselves have hooks like
didAdd/didRemove... It sounds like an EcoreEMap is almost exactly like
what you want, so that's a good example to consider.
> gary
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.03242 seconds
] 
Search
Help
Register
Login
Home
