Re: [tigerstripe-dev] Re: Unique annotations?

[Eric Dillon <erdillon@xxxxxxxxx>]

Hi Andrey,

So, first of all, yes, let's do a "quick" change to support the "unique"
annotation.

Now, I do like adapting annotable objects to Eobject instead of Iannotable.
It seems we've outgrown Iannotable already, so we would probably just keep
changing it. So an early move now makes a lot of sense.

I am not quite sure how much work this would actually trigger though... So a
bit of prototyping is definitely a good idea. Maybe see what this does with
one of the providers? (Iresource?).

I am not sure I'm following you on your comment on how this would help solve
current conflicts with Java Provider and Tigerstripe provider though :-)?
Could you elaborate a bit on that?

Thanks,
Eric


On 5/5/08 2:31 AM, "Andrey Platov" <andrey@xxxxxxxxx> wrote:

> Hi Eric,
> 
> Sounds like a good addition to set of managing EMF annotations. Also I'd like
> to point that this looks like a special case of more general constraints
> mechanism we need to work out for specifying which types of annotations can be
> bounded to which objects (e.g. stereotype can be applied to class only), etc
> 
> So in simplest case (if we're not going to employ OCL or other generic
> mechanism for constraints at the moment), I'd like to propose to enrich
> "unique" EMF annotation with target type specification. Something like "bind =
> tigerstripe/Entity; unique = false" to allow to specify cardinality on
> per-type basis.
> 
> The problem I see here is Annotation concept lacks of Annotable object type
> information, and I'm afraid we may need it in near future... From first look
> there are following possibilities to add typeinfo:
> 
> 1) Annotable namespace providers (Java, TS, Resource) may enforce type
> information in the URI encoding, so clients will be able to use it if needed,
> for example "java:method:/Foo/..."
> 
> 2) Extend IAnnotable interface with String getType method. Semantic of the
> type will be target-domain specific. So for example objects from Java
> namespace may specify type of Java element here ("Java Class", "Java Method",
> etc). 
> 
> Both 1-2 is nearly the same. What I do not like for this approach is poorness
> of such trivial "type system". At least lack of generalization would result in
> inablilty to attach annotations to base types (e.g. JavaElement) and so on...
> 
> 3) (1) & (2) triggered elegant (I think :)) change to current annotable model:
> what if we'll adapt annotable objects to EObject instead of IAnnotable. As a
> result we will have URI (from EMF), 'annotable object'-related information as
> a part of EObject (if needed), and Type information...
> 
> At the moment I'm not sure about amount of complexity this will add to the
> framework and some providers (Resource/Java Element), but for objects which
> are already stored in EMF resources (hopefully future Tigerstripe models after
> switched from POJOs) this approach may even simplify provider implementation:
> adapters will return EMF objects as is.
> 
> Evolving this idea further and with dynamic features of EMF we may try to use
> multiple inheritance and expose Compilation Unit as an object of type derived
> both from Resource and CompilationUnit -> Java Element. This looks as one of
> possible approaches to resolve ambiguous situation we have now with multiple
> providers (and turning Java provider off not to expose object as Java
> annotable object).
> 
> Please share your thoughts. In the meantime Yuri is going to provide simple
> "unique" annotation as suggested. I'd be happy to play with approach (3) and
> share PoC if succeed.
> 
> Kind Regards,
> Andrey
> 
> 
> ----- Forwarded Message -----
> From: Eric Dillon <erdillon@xxxxxxxxx>
> To: Yuri Strot <yuri@xxxxxxxxx>
> Cc: Tigerstripe Developers <tigerstripe-dev@xxxxxxxxxxx>
> Sent: Fri, 2 May 2008 22:52:36 +0700 (NOVST)
> Subject: Unique annotations?
> 
> HI Yuri,
> 
> As we consider the use of EMF annotations in the definition of the
> Annotation¹s .ecore files, we should consider allowing for annotations to be
> unique per URI.
> 
> Typically, Stereotypes in UML and Annotations in Java are uniquely applied
> (i.e. You cannot have 2 annotations of the same type on a single URI).
> 
> I think we should make this the default behavior (³unique=true²) but allow
> users to bypass it by using an annotation (unique=false).
> 
> What do you think?
> Eric
> 
> 
> _______________________________________________
> tigerstripe-dev mailing list
> tigerstripe-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/tigerstripe-dev