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

[Eric Dillon <erdillon@xxxxxxxxx>]

Hi Andrey,

Ok, I think I am starting to follow you:-)

So, basically the synthetic object that will be created on the fly, will
allow all providers to see what they want to see, and set whatever attribute
they need/want, and the framework will use that as a black-box instead of
the URI (used as a blackbox anyway too).

If I got that right, I do like it. It makes it a lot more "java" friendly as
opposed to making up a URI (which should be more of an implementation
detail).

Let me know how the prototyping goes ;-).

Eric



On 5/6/08 7:28 AM, "Andrey Platov" <andrey@xxxxxxxxx> wrote:

> Hi Eric,
> 
> Yes I'm going to try to expose IResource as an EObject as you suggested.
> 
> As for resolving provider conflicts my thoughts like following:
> 
> * Problem description (as I understand it)
> 
> Consider we have some POJO implemening IAdaptable interface, which we want to
> adapt to IAnnotable. Right now only one "provider" wins, so in case
> JavaElementProvider wins over TigerstripeElementProvider it will manage URI
> and other stuff without any Tigerstripe knowledge. This do not looks good,
> since we shall give a chance to all the providers to participate in this
> process. (Right now the process is about mapping URIs to POJOs and vice-versa,
> but in future it may involve other things).
> 
> Another bad thing is we're loosing actual object identity, for example let's
> consider some Java Type (JDT), which is TigerstripeElement. At the same time
> *this* object is also JavaElement. Each existing provider will use own schema
> to identify the object, which is not bad. Bad thing that in current model both
> URIs "points" to different objects, which is not true. So query for all
> object's annotations using Tigerstripe scheme will not return annotations
> provided with Java scheme because we think that objects are different in
> current model.
> 
> * Proposed solution
> 
> This is only thoughts extending "adapting to EObject" idea. I'm not sure how
> correct, realistic, and/or useful it may be:
> 
> Let's look at some POJO, which implements IAdaptable. Let's assume this POJO
> can be adapted to IResource, IJavaElement, and ITSElement. Tigerstripe
> Annotations Framework is responsible for adapting IAdaptable to EObject (or a
> class derived from EObject like EAnnotableObject). Adaptation process is like
> following:
> 
> 1) Framework ask providers about types they're responsible for. For our case
> this will be IResource, IJavaElement, and ITSElement.
> 2) Framework check is POJO (IAdaptable) adapts to types returned in step (1)
> 3) Framework construct synthetic EMF class, which is derived from
> EAnnotableResource, EAnnoitableJavaElement, and EAnnotableTSElement (multiple
> inheritance, assuming we found that POJO can be adapted to IResource,
> IJavaElement, and ITSElement in step 2).
> 4) Framework instantiate object of the class (3), and pass it to each of
> providers found in step (2) to initialize object content with
> provider-specific data.
> 
> Framework clients will work with EAnnotableObjects instead of URIs and all
> provider stuff will be hidden from clients, so Framework can be very flexible
> with managing object identity and understand which annotations actually bound
> to "this" object.
> 
> That's some draft idea, please share your thoughts.
> 
> Kind Regards,
> Andrey
> 
> ----- Original Message -----
> From: "Eric Dillon" <erdillon@xxxxxxxxx>
> To: "Tigerstripe developers list" <tigerstripe-dev@xxxxxxxxxxx>, "Andrey
> Platov" <andrey@xxxxxxxxx>
> Sent: Tuesday, May 6, 2008 1:50:02 AM GMT +06:00 Almaty, Novosibirsk
> Subject: Re: [tigerstripe-dev] Re: Unique annotations?
> 
> 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
> 
>