groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: Implementing a DSL using groovy.util.DelegatingScript
Date Wed, 17 Aug 2016 11:31:08 GMT
Hi Gerrit,

When you say that a newer DelegateScript class is a muc more elegant 
way, than doing with MissingMethodException... well that would be still 
how it is implemented in the end. So not more elegant, just hidden in my 
opinion.

Planed is nothing in this direction right now. I have a bit of a 
tendency to say "roll your own". It saves only very few lines, while 
being more special. On the other hand I do think some kind of 
DSL-Combinator could have use beyond DelegatingScript (the resulting 
combinator could then be used as delegate).

You are welcome to contribute something like this if you want

bye Jochen

On 16.08.2016 16:11, Gerrit Telkamp wrote:
> Jochen, thank you for your approach!
> It seems that question was a bit incomplete.
> I should have asked: Is it planned to include a list of Delegate Classes
> by groovy itself, or is the preferred way to "roll your own" on
> application level by the existing groovy.util.DelegatingScript?
> BTW, the "MissingMethodException" has been used by other DSLs like Spock
> etc., but in my opinion the newer DelegateScript class is a much more
> elegant way...
> Thank you,
> Gerrit.
>
> Am 16.08.2016 um 11:46 schrieb Jochen Theodorou:
>>
>>
>> On 16.08.2016 10:45, Gerrit Telkamp wrote:
>>> I'm using groovy.util.DelegatingScript to realize a simple DSL. It works
>>> quite well and the implementation was straight forward.
>>> Now I would like to extend my DSL by more words. Usually, this would be
>>> done by implementing each word as method in the delegate class.
>>> Instead I would like to split the code into several delegate classes.
>>> Having a look into the source, it seems to me that it would be easy to
>>> iterate a list of delegate classes and branching into a the first method
>>> that has been found first.
>>> What do the groovy developers say about this? Have I missed something,
>>> or is this something that is alrady planned? A future idea would be to
>>> re-use the DSL classes in an application-specific combination for other
>>> projects.
>>
>> actually the class you delegate to can do this logic. Like:
>>
>> class MyDelegate {
>>   def listOfDelegates = []
>>
>>   def invokeMethod(String name, Object args) {
>>     listOfDelegates.each {
>>       try {
>>         return it."$name"(*args)
>>       } catch (MissingMethodException mme) {
>>         // swallow the exception here?
>>       }
>>     }
>>     throw new MissingMethodException(..)
>>   }
>> }
>>
>> and then
>> new DelegatingScript(delegate: new MyDelegate(list:[delegate1,
>> delegate2,...]))
>>
>> You could also realize a chain of delegates:
>>
>> class EndPoint {}
>> class BasicDSL extends DelegatingScript {...}
>> class ExtendedDSL extends DelegatingScript {...}
>>
>> new DelegatingScript(delegate:new ExtendedDSL(delegate: new
>> BasicDSL(delegate:new EndPoint())))
>>
>> or combine the approaches... or even:
>>
>> class MyDelegate extends DelegatingScript{
>>   MyDelegate(listOfDelegates = []) {
>>     delegate = listOfDelegates.inject(new EndPoint()) { prev, it ->
>> it.newInstance(delegate: prev) }
>>   }
>> }
>> new DelegatingScript(delegate:new MyDelegate(BasicDSL, ExtendedDSL))
>>
>> bye Jochen
>>
>>
>>
>

Mime
View raw message