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

[Eric Dillon <erdillon@xxxxxxxxx>]

Well... One more response (sorry for the spam).

I guess it doesn't have to be treated as a black box, as long as you can
"partially match" the key in the store based on whatever interface is
present on the synthetic object (in the example below "ITSElement"). The
assumption is still that within an "provider" the object constitutes an
unique key...

Ok. I'm done this time.

Eric


On 5/7/08 3:56 PM, "Eric Dillon" <erdillon@xxxxxxxxx> wrote:

> Well... As soon as I pressed the send button... Of course... I had a
> question for you.
> 
> So what if the annotation is created in an environment where
> ResourceProvider and TSProvider was present. Then the annotation file is
> installed in an environment where JavaProvider and TSProvider is present.
> 
> Each provider will be ok, but the resulting Synthetic object will be
> different and if you use it simply as a blackbox, you won't be able to find
> the annotations that had been defined?
> 
> What am I missing?
> Eric
> 
> 
> On 5/7/08 3:52 PM, "Eric Dillon" <erdillon@xxxxxxxxx> wrote:
> 
>> 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
>>> 
>>> 
>> 
>> _______________________________________________
>> tigerstripe-dev mailing list
>> tigerstripe-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/tigerstripe-dev
> 
> _______________________________________________
> tigerstripe-dev mailing list
> tigerstripe-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/tigerstripe-dev