Problem with generics parsing in DSLD

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem with generics parsing in DSLD

me2stk
Hello,

I am using Eclipse 3.7 with plugin version 3.5.1 and I have a DSLD script that calculates stuff based on generics:

currentType(subType(MESSAGE_ADAPTER)  | subType(GROUP_ADAPTER) | subType(SEGMENT_ADAPTER)).accept {
    def gen = currentType?.genericsTypes
    if (gen && (gen.length == 1)) {
        def genericsType = gen[0]
        currentType.setRedirect(genericsType.getType())
    }
}


I observed strange behavior:
class A {
    MessageAdapter<ORU_R01> member

    void test(){
           MessageAdapter<ORU_R01> local

           local. // variable gen in the script has ORU_R01 value
           member.  // variable gen has value null and my script does not get further
     }

}

If I access member in the method, in the DSLD script the debugger shows that variable gen has value null 

Does anyone has idea what is the reason for this behavior?

Thanks in advance,
Mitko
Reply | Threaded
Open this post in threaded view
|

Re: Problem with generics parsing in DSLD

Andrew Eisenberg
Probably a bug.  :)

Let me explore a bit.

On Thu, Sep 8, 2011 at 6:09 AM, Mitko Kolev <[hidden email]> wrote:

> Hello,
>
> I am using Eclipse 3.7 with plugin version 3.5.1 and I have a DSLD script
> that calculates stuff based on generics:
>
> currentType(subType(MESSAGE_ADAPTER)  | subType(GROUP_ADAPTER) |
> subType(SEGMENT_ADAPTER)).accept {
>     def gen = currentType?.genericsTypes
>     if (gen && (gen.length == 1)) {
>         def genericsType = gen[0]
>         currentType.setRedirect(genericsType.getType())
>     }
> }
>
>
> I observed strange behavior:
> class A {
>     MessageAdapter<ORU_R01> member
>
>     void test(){
>            MessageAdapter<ORU_R01> local
>
>            local. // variable gen in the script has ORU_R01 value
>            member.  // variable gen has value null and my script does not
> get further
>      }
>
> }
>
> If I access member in the method, in the DSLD script the debugger shows that
> variable gen has value null
>
> Does anyone has idea what is the reason for this behavior?
>
> Thanks in advance,
> Mitko
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Problem with generics parsing in DSLD

Andrew Eisenberg
In reply to this post by me2stk
> currentType(subType(MESSAGE_ADAPTER)  | subType(GROUP_ADAPTER) |
> subType(SEGMENT_ADAPTER)).accept {
>     def gen = currentType?.genericsTypes
>     if (gen && (gen.length == 1)) {
>         def genericsType = gen[0]
>         currentType.setRedirect(genericsType.getType())
>     }
> }

Uh oh....this is not good.  You should not be doing this in the
script.  currentType.setRedirect(...) is making changes to the actual
AST (which should be read-only inside of DSLDs).  The method
setRedirect essentially changes the declaration that a reference to a
class points to.  And so changing this value will have all sorts of
problems.

What exactly are you trying to do?

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Problem with generics parsing in DSLD

me2stk
Basically I have adapter pattern, the generics type of the adapter is the target. http://goo.gl/eAPxM (the target classes are about hundred - generated from a complex model)
 
My goal is  to provide auto completion support  on the adapters dynamically, based on their generics types.
This functionality is de facto implemented in the adapters with some Groovy magic. On the getters the adapters return other adapters (exmpl MessageAdapter returns GroupAdapter), with the same functionality.
 
Is there a better way to implement auto completion descriptor for this model?
 
 
 
 
On Thu, Sep 8, 2011 at 6:44 PM, Andrew Eisenberg <[hidden email]> wrote:
> currentType(subType(MESSAGE_ADAPTER)  | subType(GROUP_ADAPTER) |
> subType(SEGMENT_ADAPTER)).accept {
>     def gen = currentType?.genericsTypes
>     if (gen && (gen.length == 1)) {
>         def genericsType = gen[0]
>         currentType.setRedirect(genericsType.getType())
>     }
> }

Uh oh....this is not good.  You should not be doing this in the
script.  currentType.setRedirect(...) is making changes to the actual
AST (which should be read-only inside of DSLDs).  The method
setRedirect essentially changes the declaration that a reference to a
class points to.  And so changing this value will have all sorts of
problems.

What exactly are you trying to do?

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Problem with generics parsing in DSLD

Andrew Eisenberg
So, in your example, you want content assist at 'local.<xxx>' to
propose all the methods/properties of ORU_R01?

Would something like this work?

currentType(subType(MESSAGE_ADAPTER)  | subType(GROUP_ADAPTER) |
subType(SEGMENT_ADAPTER)).accept {
    def gen = currentType?.genericsTypes
    if (gen && (gen.length == 1)) {
        delegatesTo gen[0].type
    }
}




On Thu, Sep 8, 2011 at 3:48 PM, Mitko Kolev <[hidden email]> wrote:

> Basically I have adapter pattern, the generics type of the adapter is the
> target. http://goo.gl/eAPxM (the target classes are about hundred -
> generated from a complex model)
>
> My goal is  to provide auto completion support  on the adapters dynamically,
> based on their generics types.
> This functionality is de facto implemented in the adapters with some Groovy
> magic. On the getters the adapters return other adapters (exmpl
> MessageAdapter returns GroupAdapter), with the same functionality.
>
> Is there a better way to implement auto completion descriptor for this
> model?
>
>
>
>
> On Thu, Sep 8, 2011 at 6:44 PM, Andrew Eisenberg <[hidden email]>
> wrote:
>>
>> > currentType(subType(MESSAGE_ADAPTER)  | subType(GROUP_ADAPTER) |
>> > subType(SEGMENT_ADAPTER)).accept {
>> >     def gen = currentType?.genericsTypes
>> >     if (gen && (gen.length == 1)) {
>> >         def genericsType = gen[0]
>> >         currentType.setRedirect(genericsType.getType())
>> >     }
>> > }
>>
>> Uh oh....this is not good.  You should not be doing this in the
>> script.  currentType.setRedirect(...) is making changes to the actual
>> AST (which should be read-only inside of DSLDs).  The method
>> setRedirect essentially changes the declaration that a reference to a
>> class points to.  And so changing this value will have all sorts of
>> problems.
>>
>> What exactly are you trying to do?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Problem with generics parsing in DSLD

me2stk
Hi Andrew,

Thank you very much for the hint.
Yes, your suggestion works a lot better, and also the problem seems to be fixed :)
 
Best regards,
Mitko
 

 
On Fri, Sep 9, 2011 at 12:57 AM, Andrew Eisenberg <[hidden email]> wrote:
So, in your example, you want content assist at 'local.<xxx>' to
propose all the methods/properties of ORU_R01?

Would something like this work?

currentType(subType(MESSAGE_ADAPTER)  | subType(GROUP_ADAPTER) |
subType(SEGMENT_ADAPTER)).accept {
   def gen = currentType?.genericsTypes
   if (gen && (gen.length == 1)) {
       delegatesTo gen[0].type
   }
}




On Thu, Sep 8, 2011 at 3:48 PM, Mitko Kolev <[hidden email]> wrote:
> Basically I have adapter pattern, the generics type of the adapter is the
> target. http://goo.gl/eAPxM (the target classes are about hundred -
> generated from a complex model)
>
> My goal is  to provide auto completion support  on the adapters dynamically,
> based on their generics types.
> This functionality is de facto implemented in the adapters with some Groovy
> magic. On the getters the adapters return other adapters (exmpl
> MessageAdapter returns GroupAdapter), with the same functionality.
>
> Is there a better way to implement auto completion descriptor for this
> model?
>
>
>
>
> On Thu, Sep 8, 2011 at 6:44 PM, Andrew Eisenberg <[hidden email]>
> wrote:
>>
>> > currentType(subType(MESSAGE_ADAPTER)  | subType(GROUP_ADAPTER) |
>> > subType(SEGMENT_ADAPTER)).accept {
>> >     def gen = currentType?.genericsTypes
>> >     if (gen && (gen.length == 1)) {
>> >         def genericsType = gen[0]
>> >         currentType.setRedirect(genericsType.getType())
>> >     }
>> > }
>>
>> Uh oh....this is not good.  You should not be doing this in the
>> script.  currentType.setRedirect(...) is making changes to the actual
>> AST (which should be read-only inside of DSLDs).  The method
>> setRedirect essentially changes the declaration that a reference to a
>> class points to.  And so changing this value will have all sorts of
>> problems.
>>
>> What exactly are you trying to do?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Problem with generics parsing in DSLD

me2stk
Hi Andrew,

sorry for the wrong feedback, and that I am back on the topic for the third time. I had the impression that my descriptor works fine (maybe because I wished it were so), when I wrote my last message, but the is-state is not the state I would like to have.

I would be very happy if you could find time take a look at this, I already lost some days in trying with questionable success.

Let me try to describe the challenge I have:

The delegateTo element solves the generics problem on the first step, when I have the message Adapter defined with generics, however on the second DSL navigation element I loose the information that the de-facto returned type of the DSLD contribution is an Adapter (instead I get the adapter's target which is wrong).

In other words, consider the following example:

class ORU_R01 {
    ORU_R01_PATIENT_RESULT getPatient_Result(){ ... }
    ...
}

class MessageAdapter<ORU_R01> {
    ORU_R01 target;

    //DSL method contributed by the de-facto DSL, which needs a DSLD descriptror
    GroupAdapter PATIENT_RESULT {
        return new GroupAdapter(target.getPatient_Result())        
   }
   ...

}


MessageAdapter<ORU_R01> msg;

msg. ..

on the first DSLD suggestion I delegate to an ORU_R01 method (this is made by the code generic type, it calculates the target type based on the generics type). However, on the first suggestion the IDE shows a result type ORU_R01_PATIENT_RESULT,  which is the result type of the target method, but NOT the actual GroupAdapter. So using delegateTo actually I loose the information, that the ORU_R01_PATIENT_RESULT is-a target of GroupAdapter.

The desired result would be to have the IDE show GroupAdapter, BUT then delegate to the ORU_R01_PATIENT_RESULT methods (the delegation on this step is essential).  So I guess in this case there should be something like type property for delegateTo  that will do my job.
In this case my contribution would look like this (code copied from my initial mail on the topic):

currentType(subType(MESSAGE_
ADAPTER)  | subType(GROUP_ADAPTER) | subType(SEGMENT_ADAPTER)).accept {
    def gen = currentType?.genericsTypes
    if (gen && (gen.length == 1)) {
        def genericsType = gen[0]
         delegateTo genericsType.type type:ClassHelper.make('...GroupAdapter')
    }
}


Alternative to the type property for delegateTo, I was thinking that if there was an additional property, say contributionDelegatesTo  would also do the job. Thus in my case I could list the delegate methods by myself (not using delegateTo) and then write:

property name:PATIENT_RESULT , type:GroupAdapter, declaringType:MessageAdapter, contributionDelegatesTo: ORU_R01_PATIENT_RESULT


Would something like the
contributionDelegatesTo, or the property type to delegateTo be realizable?

Best Regards,
Mitko


On Fri, Sep 9, 2011 at 1:22 AM, Mitko Kolev <[hidden email]> wrote:
Hi Andrew,

Thank you very much for the hint.
Yes, your suggestion works a lot better, and also the problem seems to be fixed :)
 
Best regards,
Mitko
 

 
On Fri, Sep 9, 2011 at 12:57 AM, Andrew Eisenberg <[hidden email]> wrote:
So, in your example, you want content assist at 'local.<xxx>' to
propose all the methods/properties of ORU_R01?

Would something like this work?

currentType(subType(MESSAGE_ADAPTER)  | subType(GROUP_ADAPTER) |
subType(SEGMENT_ADAPTER)).accept {
   def gen = currentType?.genericsTypes
   if (gen && (gen.length == 1)) {
       delegatesTo gen[0].type
   }
}




On Thu, Sep 8, 2011 at 3:48 PM, Mitko Kolev <[hidden email]> wrote:
> Basically I have adapter pattern, the generics type of the adapter is the
> target. http://goo.gl/eAPxM (the target classes are about hundred -
> generated from a complex model)
>
> My goal is  to provide auto completion support  on the adapters dynamically,
> based on their generics types.
> This functionality is de facto implemented in the adapters with some Groovy
> magic. On the getters the adapters return other adapters (exmpl
> MessageAdapter returns GroupAdapter), with the same functionality.
>
> Is there a better way to implement auto completion descriptor for this
> model?
>
>
>
>
> On Thu, Sep 8, 2011 at 6:44 PM, Andrew Eisenberg <[hidden email]>
> wrote:
>>
>> > currentType(subType(MESSAGE_ADAPTER)  | subType(GROUP_ADAPTER) |
>> > subType(SEGMENT_ADAPTER)).accept {
>> >     def gen = currentType?.genericsTypes
>> >     if (gen && (gen.length == 1)) {
>> >         def genericsType = gen[0]
>> >         currentType.setRedirect(genericsType.getType())
>> >     }
>> > }
>>
>> Uh oh....this is not good.  You should not be doing this in the
>> script.  currentType.setRedirect(...) is making changes to the actual
>> AST (which should be read-only inside of DSLDs).  The method
>> setRedirect essentially changes the declaration that a reference to a
>> class points to.  And so changing this value will have all sorts of
>> problems.
>>
>> What exactly are you trying to do?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email




Reply | Threaded
Open this post in threaded view
|

Re: Problem with generics parsing in DSLD

Andrew Eisenberg
Hi,

I'm trying to understand exactly what you are trying to do, but I am
getting a little confused with your explanation.  Can you provide a
few classes, a simple script that uses those classes, and the DSLD
that you are using?  Describe what you would like to see, but are not.
 What particular types/declaring types/methods should be seen, but
aren't?

On Wed, Sep 14, 2011 at 7:31 AM, Mitko Kolev <[hidden email]> wrote:

> Hi Andrew,
>
> sorry for the wrong feedback, and that I am back on the topic for the third
> time. I had the impression that my descriptor works fine (maybe because I
> wished it were so), when I wrote my last message, but the is-state is not
> the state I would like to have.
>
> I would be very happy if you could find time take a look at this, I already
> lost some days in trying with questionable success.
>
> Let me try to describe the challenge I have:
>
> The delegateTo element solves the generics problem on the first step, when I
> have the message Adapter defined with generics, however on the second DSL
> navigation element I loose the information that the de-facto returned type
> of the DSLD contribution is an Adapter (instead I get the adapter's target
> which is wrong).
>
> In other words, consider the following example:
>
> class ORU_R01 {
>     ORU_R01_PATIENT_RESULT getPatient_Result(){ ... }
>     ...
> }
>
> class MessageAdapter<ORU_R01> {
>     ORU_R01 target;
>
>     //DSL method contributed by the de-facto DSL, which needs a DSLD
> descriptror
>     GroupAdapter PATIENT_RESULT {
>         return new GroupAdapter(target.getPatient_Result())
>    }
>    ...
>
> }
>
>
> MessageAdapter<ORU_R01> msg;
>
> msg. ..
>
> on the first DSLD suggestion I delegate to an ORU_R01 method (this is made
> by the code generic type, it calculates the target type based on the
> generics type). However, on the first suggestion the IDE shows a result type
> ORU_R01_PATIENT_RESULT,  which is the result type of the target method, but
> NOT the actual GroupAdapter. So using delegateTo actually I loose the
> information, that the ORU_R01_PATIENT_RESULT is-a target of GroupAdapter.
>
> The desired result would be to have the IDE show GroupAdapter, BUT then
> delegate to the ORU_R01_PATIENT_RESULT methods (the delegation on this step
> is essential).  So I guess in this case there should be something like type
> property for delegateTo  that will do my job.
> In this case my contribution would look like this (code copied from my
> initial mail on the topic):
>
> currentType(subType(MESSAGE_ADAPTER)  | subType(GROUP_ADAPTER) |
> subType(SEGMENT_ADAPTER)).accept {
>     def gen = currentType?.genericsTypes
>     if (gen && (gen.length == 1)) {
>         def genericsType = gen[0]
>          delegateTo genericsType.type
> type:ClassHelper.make('...GroupAdapter')
>     }
> }
>
>
> Alternative to the type property for delegateTo, I was thinking that if
> there was an additional property, say contributionDelegatesTo  would also do
> the job. Thus in my case I could list the delegate methods by myself (not
> using delegateTo) and then write:
>
> property name:PATIENT_RESULT , type:GroupAdapter,
> declaringType:MessageAdapter, contributionDelegatesTo:
> ORU_R01_PATIENT_RESULT
>
>
> Would something like the contributionDelegatesTo, or the property type to
> delegateTo be realizable?
>
> Best Regards,
> Mitko
>
>
> On Fri, Sep 9, 2011 at 1:22 AM, Mitko Kolev <[hidden email]> wrote:
>>
>> Hi Andrew,
>> Thank you very much for the hint.
>> Yes, your suggestion works a lot better, and also the problem seems to be
>> fixed :)
>>
>> Best regards,
>> Mitko
>>
>>
>> On Fri, Sep 9, 2011 at 12:57 AM, Andrew Eisenberg <[hidden email]>
>> wrote:
>>>
>>> So, in your example, you want content assist at 'local.<xxx>' to
>>> propose all the methods/properties of ORU_R01?
>>>
>>> Would something like this work?
>>>
>>> currentType(subType(MESSAGE_ADAPTER)  | subType(GROUP_ADAPTER) |
>>> subType(SEGMENT_ADAPTER)).accept {
>>>    def gen = currentType?.genericsTypes
>>>    if (gen && (gen.length == 1)) {
>>>        delegatesTo gen[0].type
>>>    }
>>> }
>>>
>>>
>>>
>>>
>>> On Thu, Sep 8, 2011 at 3:48 PM, Mitko Kolev <[hidden email]> wrote:
>>> > Basically I have adapter pattern, the generics type of the adapter is
>>> > the
>>> > target. http://goo.gl/eAPxM (the target classes are about hundred -
>>> > generated from a complex model)
>>> >
>>> > My goal is  to provide auto completion support  on the adapters
>>> > dynamically,
>>> > based on their generics types.
>>> > This functionality is de facto implemented in the adapters with some
>>> > Groovy
>>> > magic. On the getters the adapters return other adapters (exmpl
>>> > MessageAdapter returns GroupAdapter), with the same functionality.
>>> >
>>> > Is there a better way to implement auto completion descriptor for this
>>> > model?
>>> >
>>> >
>>> >
>>> >
>>> > On Thu, Sep 8, 2011 at 6:44 PM, Andrew Eisenberg <[hidden email]>
>>> > wrote:
>>> >>
>>> >> > currentType(subType(MESSAGE_ADAPTER)  | subType(GROUP_ADAPTER) |
>>> >> > subType(SEGMENT_ADAPTER)).accept {
>>> >> >     def gen = currentType?.genericsTypes
>>> >> >     if (gen && (gen.length == 1)) {
>>> >> >         def genericsType = gen[0]
>>> >> >         currentType.setRedirect(genericsType.getType())
>>> >> >     }
>>> >> > }
>>> >>
>>> >> Uh oh....this is not good.  You should not be doing this in the
>>> >> script.  currentType.setRedirect(...) is making changes to the actual
>>> >> AST (which should be read-only inside of DSLDs).  The method
>>> >> setRedirect essentially changes the declaration that a reference to a
>>> >> class points to.  And so changing this value will have all sorts of
>>> >> problems.
>>> >>
>>> >> What exactly are you trying to do?
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe from this list, please visit:
>>> >>
>>> >>    http://xircles.codehaus.org/manage_email
>>> >>
>>> >>
>>> >
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Problem with generics parsing in DSLD

me2stk
Hi
I just did a small project that isolates the problem I have currently. If it still does not get clear  please let me know

https://github.com/mkolev/dsld/blob/master/dsld-project.zip

Best Regards,
Mitko

 

On Wed, Sep 14, 2011 at 7:01 PM, Andrew Eisenberg <[hidden email]> wrote:
Hi,

I'm trying to understand exactly what you are trying to do, but I am
getting a little confused with your explanation.  Can you provide a
few classes, a simple script that uses those classes, and the DSLD
that you are using?  Describe what you would like to see, but are not.
 What particular types/declaring types/methods should be seen, but
aren't?

On Wed, Sep 14, 2011 at 7:31 AM, Mitko Kolev <[hidden email]> wrote:
> Hi Andrew,
>
> sorry for the wrong feedback, and that I am back on the topic for the third
> time. I had the impression that my descriptor works fine (maybe because I
> wished it were so), when I wrote my last message, but the is-state is not
> the state I would like to have.
>
> I would be very happy if you could find time take a look at this, I already
> lost some days in trying with questionable success.
>
> Let me try to describe the challenge I have:
>
> The delegateTo element solves the generics problem on the first step, when I
> have the message Adapter defined with generics, however on the second DSL
> navigation element I loose the information that the de-facto returned type
> of the DSLD contribution is an Adapter (instead I get the adapter's target
> which is wrong).
>
> In other words, consider the following example:
>
> class ORU_R01 {
>     ORU_R01_PATIENT_RESULT getPatient_Result(){ ... }
>     ...
> }
>
> class MessageAdapter<ORU_R01> {
>     ORU_R01 target;
>
>     //DSL method contributed by the de-facto DSL, which needs a DSLD
> descriptror
>     GroupAdapter PATIENT_RESULT {
>         return new GroupAdapter(target.getPatient_Result())
>    }
>    ...
>
> }
>
>
> MessageAdapter<ORU_R01> msg;
>
> msg. ..
>
> on the first DSLD suggestion I delegate to an ORU_R01 method (this is made
> by the code generic type, it calculates the target type based on the
> generics type). However, on the first suggestion the IDE shows a result type
> ORU_R01_PATIENT_RESULT,  which is the result type of the target method, but
> NOT the actual GroupAdapter. So using delegateTo actually I loose the
> information, that the ORU_R01_PATIENT_RESULT is-a target of GroupAdapter.
>
> The desired result would be to have the IDE show GroupAdapter, BUT then
> delegate to the ORU_R01_PATIENT_RESULT methods (the delegation on this step
> is essential).  So I guess in this case there should be something like type
> property for delegateTo  that will do my job.
> In this case my contribution would look like this (code copied from my
> initial mail on the topic):
>
> currentType(subType(MESSAGE_ADAPTER)  | subType(GROUP_ADAPTER) |
> subType(SEGMENT_ADAPTER)).accept {
>     def gen = currentType?.genericsTypes
>     if (gen && (gen.length == 1)) {
>         def genericsType = gen[0]
>          delegateTo genericsType.type
> type:ClassHelper.make('...GroupAdapter')
>     }
> }
>
>
> Alternative to the type property for delegateTo, I was thinking that if
> there was an additional property, say contributionDelegatesTo  would also do
> the job. Thus in my case I could list the delegate methods by myself (not
> using delegateTo) and then write:
>
> property name:PATIENT_RESULT , type:GroupAdapter,
> declaringType:MessageAdapter, contributionDelegatesTo:
> ORU_R01_PATIENT_RESULT
>
>
> Would something like the contributionDelegatesTo, or the property type to
> delegateTo be realizable?
>
> Best Regards,
> Mitko
>
>
> On Fri, Sep 9, 2011 at 1:22 AM, Mitko Kolev <[hidden email]> wrote:
>>
>> Hi Andrew,
>> Thank you very much for the hint.
>> Yes, your suggestion works a lot better, and also the problem seems to be
>> fixed :)
>>
>> Best regards,
>> Mitko
>>
>>
>> On Fri, Sep 9, 2011 at 12:57 AM, Andrew Eisenberg <[hidden email]>
>> wrote:
>>>
>>> So, in your example, you want content assist at 'local.<xxx>' to
>>> propose all the methods/properties of ORU_R01?
>>>
>>> Would something like this work?
>>>
>>> currentType(subType(MESSAGE_ADAPTER)  | subType(GROUP_ADAPTER) |
>>> subType(SEGMENT_ADAPTER)).accept {
>>>    def gen = currentType?.genericsTypes
>>>    if (gen && (gen.length == 1)) {
>>>        delegatesTo gen[0].type
>>>    }
>>> }
>>>
>>>
>>>
>>>
>>> On Thu, Sep 8, 2011 at 3:48 PM, Mitko Kolev <[hidden email]> wrote:
>>> > Basically I have adapter pattern, the generics type of the adapter is
>>> > the
>>> > target. http://goo.gl/eAPxM (the target classes are about hundred -
>>> > generated from a complex model)
>>> >
>>> > My goal is  to provide auto completion support  on the adapters
>>> > dynamically,
>>> > based on their generics types.
>>> > This functionality is de facto implemented in the adapters with some
>>> > Groovy
>>> > magic. On the getters the adapters return other adapters (exmpl
>>> > MessageAdapter returns GroupAdapter), with the same functionality.
>>> >
>>> > Is there a better way to implement auto completion descriptor for this
>>> > model?
>>> >
>>> >
>>> >
>>> >
>>> > On Thu, Sep 8, 2011 at 6:44 PM, Andrew Eisenberg <[hidden email]>
>>> > wrote:
>>> >>
>>> >> > currentType(subType(MESSAGE_ADAPTER)  | subType(GROUP_ADAPTER) |
>>> >> > subType(SEGMENT_ADAPTER)).accept {
>>> >> >     def gen = currentType?.genericsTypes
>>> >> >     if (gen && (gen.length == 1)) {
>>> >> >         def genericsType = gen[0]
>>> >> >         currentType.setRedirect(genericsType.getType())
>>> >> >     }
>>> >> > }
>>> >>
>>> >> Uh oh....this is not good.  You should not be doing this in the
>>> >> script.  currentType.setRedirect(...) is making changes to the actual
>>> >> AST (which should be read-only inside of DSLDs).  The method
>>> >> setRedirect essentially changes the declaration that a reference to a
>>> >> class points to.  And so changing this value will have all sorts of
>>> >> problems.
>>> >>
>>> >> What exactly are you trying to do?
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe from this list, please visit:
>>> >>
>>> >>    http://xircles.codehaus.org/manage_email
>>> >>
>>> >>
>>> >
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Problem with generics parsing in DSLD

Andrew Eisenberg
Thanks for the project.  I'll have a look and if there are any
questions, I'll get back to you.

On Thu, Sep 15, 2011 at 4:14 PM, Mitko Kolev <[hidden email]> wrote:

> Hi
> I just did a small project that isolates the problem I have currently. If it
> still does not get clear  please let me know
>
> https://github.com/mkolev/dsld/blob/master/dsld-project.zip
>
> Best Regards,
> Mitko
>
>
>
> On Wed, Sep 14, 2011 at 7:01 PM, Andrew Eisenberg <[hidden email]>
> wrote:
>>
>> Hi,
>>
>> I'm trying to understand exactly what you are trying to do, but I am
>> getting a little confused with your explanation.  Can you provide a
>> few classes, a simple script that uses those classes, and the DSLD
>> that you are using?  Describe what you would like to see, but are not.
>>  What particular types/declaring types/methods should be seen, but
>> aren't?
>>
>> On Wed, Sep 14, 2011 at 7:31 AM, Mitko Kolev <[hidden email]> wrote:
>> > Hi Andrew,
>> >
>> > sorry for the wrong feedback, and that I am back on the topic for the
>> > third
>> > time. I had the impression that my descriptor works fine (maybe because
>> > I
>> > wished it were so), when I wrote my last message, but the is-state is
>> > not
>> > the state I would like to have.
>> >
>> > I would be very happy if you could find time take a look at this, I
>> > already
>> > lost some days in trying with questionable success.
>> >
>> > Let me try to describe the challenge I have:
>> >
>> > The delegateTo element solves the generics problem on the first step,
>> > when I
>> > have the message Adapter defined with generics, however on the second
>> > DSL
>> > navigation element I loose the information that the de-facto returned
>> > type
>> > of the DSLD contribution is an Adapter (instead I get the adapter's
>> > target
>> > which is wrong).
>> >
>> > In other words, consider the following example:
>> >
>> > class ORU_R01 {
>> >     ORU_R01_PATIENT_RESULT getPatient_Result(){ ... }
>> >     ...
>> > }
>> >
>> > class MessageAdapter<ORU_R01> {
>> >     ORU_R01 target;
>> >
>> >     //DSL method contributed by the de-facto DSL, which needs a DSLD
>> > descriptror
>> >     GroupAdapter PATIENT_RESULT {
>> >         return new GroupAdapter(target.getPatient_Result())
>> >    }
>> >    ...
>> >
>> > }
>> >
>> >
>> > MessageAdapter<ORU_R01> msg;
>> >
>> > msg. ..
>> >
>> > on the first DSLD suggestion I delegate to an ORU_R01 method (this is
>> > made
>> > by the code generic type, it calculates the target type based on the
>> > generics type). However, on the first suggestion the IDE shows a result
>> > type
>> > ORU_R01_PATIENT_RESULT,  which is the result type of the target method,
>> > but
>> > NOT the actual GroupAdapter. So using delegateTo actually I loose the
>> > information, that the ORU_R01_PATIENT_RESULT is-a target of
>> > GroupAdapter.
>> >
>> > The desired result would be to have the IDE show GroupAdapter, BUT then
>> > delegate to the ORU_R01_PATIENT_RESULT methods (the delegation on this
>> > step
>> > is essential).  So I guess in this case there should be something like
>> > type
>> > property for delegateTo  that will do my job.
>> > In this case my contribution would look like this (code copied from my
>> > initial mail on the topic):
>> >
>> > currentType(subType(MESSAGE_ADAPTER)  | subType(GROUP_ADAPTER) |
>> > subType(SEGMENT_ADAPTER)).accept {
>> >     def gen = currentType?.genericsTypes
>> >     if (gen && (gen.length == 1)) {
>> >         def genericsType = gen[0]
>> >          delegateTo genericsType.type
>> > type:ClassHelper.make('...GroupAdapter')
>> >     }
>> > }
>> >
>> >
>> > Alternative to the type property for delegateTo, I was thinking that if
>> > there was an additional property, say contributionDelegatesTo  would
>> > also do
>> > the job. Thus in my case I could list the delegate methods by myself
>> > (not
>> > using delegateTo) and then write:
>> >
>> > property name:PATIENT_RESULT , type:GroupAdapter,
>> > declaringType:MessageAdapter, contributionDelegatesTo:
>> > ORU_R01_PATIENT_RESULT
>> >
>> >
>> > Would something like the contributionDelegatesTo, or the property type
>> > to
>> > delegateTo be realizable?
>> >
>> > Best Regards,
>> > Mitko
>> >
>> >
>> > On Fri, Sep 9, 2011 at 1:22 AM, Mitko Kolev <[hidden email]> wrote:
>> >>
>> >> Hi Andrew,
>> >> Thank you very much for the hint.
>> >> Yes, your suggestion works a lot better, and also the problem seems to
>> >> be
>> >> fixed :)
>> >>
>> >> Best regards,
>> >> Mitko
>> >>
>> >>
>> >> On Fri, Sep 9, 2011 at 12:57 AM, Andrew Eisenberg <[hidden email]>
>> >> wrote:
>> >>>
>> >>> So, in your example, you want content assist at 'local.<xxx>' to
>> >>> propose all the methods/properties of ORU_R01?
>> >>>
>> >>> Would something like this work?
>> >>>
>> >>> currentType(subType(MESSAGE_ADAPTER)  | subType(GROUP_ADAPTER) |
>> >>> subType(SEGMENT_ADAPTER)).accept {
>> >>>    def gen = currentType?.genericsTypes
>> >>>    if (gen && (gen.length == 1)) {
>> >>>        delegatesTo gen[0].type
>> >>>    }
>> >>> }
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Thu, Sep 8, 2011 at 3:48 PM, Mitko Kolev <[hidden email]> wrote:
>> >>> > Basically I have adapter pattern, the generics type of the adapter
>> >>> > is
>> >>> > the
>> >>> > target. http://goo.gl/eAPxM (the target classes are about hundred -
>> >>> > generated from a complex model)
>> >>> >
>> >>> > My goal is  to provide auto completion support  on the adapters
>> >>> > dynamically,
>> >>> > based on their generics types.
>> >>> > This functionality is de facto implemented in the adapters with some
>> >>> > Groovy
>> >>> > magic. On the getters the adapters return other adapters (exmpl
>> >>> > MessageAdapter returns GroupAdapter), with the same functionality.
>> >>> >
>> >>> > Is there a better way to implement auto completion descriptor for
>> >>> > this
>> >>> > model?
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> > On Thu, Sep 8, 2011 at 6:44 PM, Andrew Eisenberg
>> >>> > <[hidden email]>
>> >>> > wrote:
>> >>> >>
>> >>> >> > currentType(subType(MESSAGE_ADAPTER)  | subType(GROUP_ADAPTER) |
>> >>> >> > subType(SEGMENT_ADAPTER)).accept {
>> >>> >> >     def gen = currentType?.genericsTypes
>> >>> >> >     if (gen && (gen.length == 1)) {
>> >>> >> >         def genericsType = gen[0]
>> >>> >> >         currentType.setRedirect(genericsType.getType())
>> >>> >> >     }
>> >>> >> > }
>> >>> >>
>> >>> >> Uh oh....this is not good.  You should not be doing this in the
>> >>> >> script.  currentType.setRedirect(...) is making changes to the
>> >>> >> actual
>> >>> >> AST (which should be read-only inside of DSLDs).  The method
>> >>> >> setRedirect essentially changes the declaration that a reference to
>> >>> >> a
>> >>> >> class points to.  And so changing this value will have all sorts of
>> >>> >> problems.
>> >>> >>
>> >>> >> What exactly are you trying to do?
>> >>> >>
>> >>> >>
>> >>> >> ---------------------------------------------------------------------
>> >>> >> To unsubscribe from this list, please visit:
>> >>> >>
>> >>> >>    http://xircles.codehaus.org/manage_email
>> >>> >>
>> >>> >>
>> >>> >
>> >>> >
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe from this list, please visit:
>> >>>
>> >>>    http://xircles.codehaus.org/manage_email
>> >>>
>> >>>
>> >>
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Problem with generics parsing in DSLD

Andrew Eisenberg
Hi,

So, the main problem that you had was that you wanted to use DSLDs to
add extra type information to your contributor and adaptor types
through DSLD.  However, what you really need to do is parameterize a
few more of your types.

I'm attaching a version of your project that has some changes and
works in the way that I think you want it to.  The biggest change is
to parameterize the Contribution class (as well as add the proper type
parameters to all references of the class).  However, the method
contributions and property contributions accept strings for 'type',
'declaringType', and parameter types.  In fact, if you want to pass in
parameterized types, you can *only* do this through strings.

Then, in CurrentDSLD.dsld, I made a few more changes (some stylistic
and some bigger).  I see in several places that you take a groovy
ClassNode, convert it to a string and then convert back to a
ClassNode.

So, your adapter method was this:

def adapter = { ClassNode node ->
    ClassNode res = node;
    if (node.name == 'domain.Contribution'){
        res = ClassHelper.make('adapter.ContributionAdapter')
    }
    //Note that there are many price classes but a single PriceAdapter
    if (node.name.contains('Price')){
        res = ClassHelper.make('adapter.PriceAdapter')
    }
    if (node.name == 'domain.FirstDsldShop'){
        res = ClassHelper.make('adapter.ShopAdapter')
    }
    return res
}

And I changed it to this.  Note that ContributionAdapter is now
properly parameterized:

def adapter = { ClassNode node ->
    String res = node;
    def qualName = node.name
    if (qualName == 'domain.Contribution'){
        res = "adapter.ContributionAdapter<${node.genericsTypes[0].type}>"
    }
    //Note that there are many price classes but a single PriceAdapter
    if (qualName.contains('Price')){
        res = "adapter.PriceAdapter"
    }
    if (qualName == 'domain.FirstDsldShop'){
        res = "adapter.ShopAdapter>"
    }
    return res
}

There are a few more changes that I made to the dsld that are like
this.  See the attached zip for everything.

Hope this helps.


On Fri, Sep 16, 2011 at 8:33 AM, Andrew Eisenberg <[hidden email]> wrote:

> Thanks for the project.  I'll have a look and if there are any
> questions, I'll get back to you.
>
> On Thu, Sep 15, 2011 at 4:14 PM, Mitko Kolev <[hidden email]> wrote:
>> Hi
>> I just did a small project that isolates the problem I have currently. If it
>> still does not get clear  please let me know
>>
>> https://github.com/mkolev/dsld/blob/master/dsld-project.zip
>>
>> Best Regards,
>> Mitko
>>
>>
>>
>> On Wed, Sep 14, 2011 at 7:01 PM, Andrew Eisenberg <[hidden email]>
>> wrote:
>>>
>>> Hi,
>>>
>>> I'm trying to understand exactly what you are trying to do, but I am
>>> getting a little confused with your explanation.  Can you provide a
>>> few classes, a simple script that uses those classes, and the DSLD
>>> that you are using?  Describe what you would like to see, but are not.
>>>  What particular types/declaring types/methods should be seen, but
>>> aren't?
>>>
>>> On Wed, Sep 14, 2011 at 7:31 AM, Mitko Kolev <[hidden email]> wrote:
>>> > Hi Andrew,
>>> >
>>> > sorry for the wrong feedback, and that I am back on the topic for the
>>> > third
>>> > time. I had the impression that my descriptor works fine (maybe because
>>> > I
>>> > wished it were so), when I wrote my last message, but the is-state is
>>> > not
>>> > the state I would like to have.
>>> >
>>> > I would be very happy if you could find time take a look at this, I
>>> > already
>>> > lost some days in trying with questionable success.
>>> >
>>> > Let me try to describe the challenge I have:
>>> >
>>> > The delegateTo element solves the generics problem on the first step,
>>> > when I
>>> > have the message Adapter defined with generics, however on the second
>>> > DSL
>>> > navigation element I loose the information that the de-facto returned
>>> > type
>>> > of the DSLD contribution is an Adapter (instead I get the adapter's
>>> > target
>>> > which is wrong).
>>> >
>>> > In other words, consider the following example:
>>> >
>>> > class ORU_R01 {
>>> >     ORU_R01_PATIENT_RESULT getPatient_Result(){ ... }
>>> >     ...
>>> > }
>>> >
>>> > class MessageAdapter<ORU_R01> {
>>> >     ORU_R01 target;
>>> >
>>> >     //DSL method contributed by the de-facto DSL, which needs a DSLD
>>> > descriptror
>>> >     GroupAdapter PATIENT_RESULT {
>>> >         return new GroupAdapter(target.getPatient_Result())
>>> >    }
>>> >    ...
>>> >
>>> > }
>>> >
>>> >
>>> > MessageAdapter<ORU_R01> msg;
>>> >
>>> > msg. ..
>>> >
>>> > on the first DSLD suggestion I delegate to an ORU_R01 method (this is
>>> > made
>>> > by the code generic type, it calculates the target type based on the
>>> > generics type). However, on the first suggestion the IDE shows a result
>>> > type
>>> > ORU_R01_PATIENT_RESULT,  which is the result type of the target method,
>>> > but
>>> > NOT the actual GroupAdapter. So using delegateTo actually I loose the
>>> > information, that the ORU_R01_PATIENT_RESULT is-a target of
>>> > GroupAdapter.
>>> >
>>> > The desired result would be to have the IDE show GroupAdapter, BUT then
>>> > delegate to the ORU_R01_PATIENT_RESULT methods (the delegation on this
>>> > step
>>> > is essential).  So I guess in this case there should be something like
>>> > type
>>> > property for delegateTo  that will do my job.
>>> > In this case my contribution would look like this (code copied from my
>>> > initial mail on the topic):
>>> >
>>> > currentType(subType(MESSAGE_ADAPTER)  | subType(GROUP_ADAPTER) |
>>> > subType(SEGMENT_ADAPTER)).accept {
>>> >     def gen = currentType?.genericsTypes
>>> >     if (gen && (gen.length == 1)) {
>>> >         def genericsType = gen[0]
>>> >          delegateTo genericsType.type
>>> > type:ClassHelper.make('...GroupAdapter')
>>> >     }
>>> > }
>>> >
>>> >
>>> > Alternative to the type property for delegateTo, I was thinking that if
>>> > there was an additional property, say contributionDelegatesTo  would
>>> > also do
>>> > the job. Thus in my case I could list the delegate methods by myself
>>> > (not
>>> > using delegateTo) and then write:
>>> >
>>> > property name:PATIENT_RESULT , type:GroupAdapter,
>>> > declaringType:MessageAdapter, contributionDelegatesTo:
>>> > ORU_R01_PATIENT_RESULT
>>> >
>>> >
>>> > Would something like the contributionDelegatesTo, or the property type
>>> > to
>>> > delegateTo be realizable?
>>> >
>>> > Best Regards,
>>> > Mitko
>>> >
>>> >
>>> > On Fri, Sep 9, 2011 at 1:22 AM, Mitko Kolev <[hidden email]> wrote:
>>> >>
>>> >> Hi Andrew,
>>> >> Thank you very much for the hint.
>>> >> Yes, your suggestion works a lot better, and also the problem seems to
>>> >> be
>>> >> fixed :)
>>> >>
>>> >> Best regards,
>>> >> Mitko
>>> >>
>>> >>
>>> >> On Fri, Sep 9, 2011 at 12:57 AM, Andrew Eisenberg <[hidden email]>
>>> >> wrote:
>>> >>>
>>> >>> So, in your example, you want content assist at 'local.<xxx>' to
>>> >>> propose all the methods/properties of ORU_R01?
>>> >>>
>>> >>> Would something like this work?
>>> >>>
>>> >>> currentType(subType(MESSAGE_ADAPTER)  | subType(GROUP_ADAPTER) |
>>> >>> subType(SEGMENT_ADAPTER)).accept {
>>> >>>    def gen = currentType?.genericsTypes
>>> >>>    if (gen && (gen.length == 1)) {
>>> >>>        delegatesTo gen[0].type
>>> >>>    }
>>> >>> }
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Thu, Sep 8, 2011 at 3:48 PM, Mitko Kolev <[hidden email]> wrote:
>>> >>> > Basically I have adapter pattern, the generics type of the adapter
>>> >>> > is
>>> >>> > the
>>> >>> > target. http://goo.gl/eAPxM (the target classes are about hundred -
>>> >>> > generated from a complex model)
>>> >>> >
>>> >>> > My goal is  to provide auto completion support  on the adapters
>>> >>> > dynamically,
>>> >>> > based on their generics types.
>>> >>> > This functionality is de facto implemented in the adapters with some
>>> >>> > Groovy
>>> >>> > magic. On the getters the adapters return other adapters (exmpl
>>> >>> > MessageAdapter returns GroupAdapter), with the same functionality.
>>> >>> >
>>> >>> > Is there a better way to implement auto completion descriptor for
>>> >>> > this
>>> >>> > model?
>>> >>> >
>>> >>> >
>>> >>> >
>>> >>> >
>>> >>> > On Thu, Sep 8, 2011 at 6:44 PM, Andrew Eisenberg
>>> >>> > <[hidden email]>
>>> >>> > wrote:
>>> >>> >>
>>> >>> >> > currentType(subType(MESSAGE_ADAPTER)  | subType(GROUP_ADAPTER) |
>>> >>> >> > subType(SEGMENT_ADAPTER)).accept {
>>> >>> >> >     def gen = currentType?.genericsTypes
>>> >>> >> >     if (gen && (gen.length == 1)) {
>>> >>> >> >         def genericsType = gen[0]
>>> >>> >> >         currentType.setRedirect(genericsType.getType())
>>> >>> >> >     }
>>> >>> >> > }
>>> >>> >>
>>> >>> >> Uh oh....this is not good.  You should not be doing this in the
>>> >>> >> script.  currentType.setRedirect(...) is making changes to the
>>> >>> >> actual
>>> >>> >> AST (which should be read-only inside of DSLDs).  The method
>>> >>> >> setRedirect essentially changes the declaration that a reference to
>>> >>> >> a
>>> >>> >> class points to.  And so changing this value will have all sorts of
>>> >>> >> problems.
>>> >>> >>
>>> >>> >> What exactly are you trying to do?
>>> >>> >>
>>> >>> >>
>>> >>> >> ---------------------------------------------------------------------
>>> >>> >> To unsubscribe from this list, please visit:
>>> >>> >>
>>> >>> >>    http://xircles.codehaus.org/manage_email
>>> >>> >>
>>> >>> >>
>>> >>> >
>>> >>> >
>>> >>>
>>> >>> ---------------------------------------------------------------------
>>> >>> To unsubscribe from this list, please visit:
>>> >>>
>>> >>>    http://xircles.codehaus.org/manage_email
>>> >>>
>>> >>>
>>> >>
>>> >
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

mitko-dsld.zip (370K) Download Attachment