[prev in list] [next in list] [prev in thread] [next in thread]
List: groovy-dev
Subject: Re: [groovy-dev] Extension Modules used for evil?
From: Tim Yates <tim.yates () gmail ! com>
Date: 2012-10-23 9:25:18
Message-ID: CAFC8+YgNPeWC_r0WtjETs=4KwWZM8-utYniLV84K2a4xyznp0Q () mail ! gmail ! com
[Download RAW message or body]
Ahh, does the new modular Groovy us the Extension Module methodology?
I didn't realise
That does make it trickier...
Maybe logging when methods are hidden by an extension Module on the
classpath would make it explicit what is going on?
Then again, if this is done a lot, then the logging may prove useless as it
might be presenting so much information that it is hard to see when
unexpected things are happening?
Tim
On 22 October 2012 19:33, Jochen Theodorou <blackdrag@gmx.org> wrote:
> Am 22.10.2012 17:14, schrieb Tim Yates:
>
>> Obviously, this goes under the heading of "bleeding obvious", but as
>> they currently stand Extension Modules overwrite any existing methods
>> defined in the module... (and so can have hidden effects)
>>
>> [undesired BigDecimal#multiply reaplcement]
>>
>>
>> Without the source for the Evil Module, this sort of thing would be
>> completely hidden from the end user. And obviously, this is a simple
>> example... I guess I could have done anything... sent data to a server,
>> whatever. And I guess you could specially craft extensions to inject
>> into large well known apps to harvest internal information, etc...
>>
>
> what you scheme is the extreme, but imagine the less extreme case. I have
> to modules that both provide a method. Which of those is used would then
> depend on their occurance on the classpath.
>
>
> Is there a case for restricting the Extension Module mechanism somehow,
>> so that it (for instance) only allows the addition of new methods rather
>> than allowing the over-writing of anything Groovy?
>>
>
> I am thinking that we should maybe add something like that... not allowing
> one module overriding another module added method.
>
> The problem though is, that we indeed want to replace methods in some
> cases. We have to think about how to enable those. Such a case is for
> example Map#toString, which is done by the same mechanism that also adds
> the methods from modules. That means we need a distinction between the
> methods from a module and those not... and that we imho have..
>
> What do you think?
>
> bye blackdrag
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/**manage_email<http://xircles.codehaus.org/manage_email>
>
>
>
[Attachment #3 (text/html)]
Ahh, does the new modular Groovy us the Extension Module \
methodology?<div><br></div><div>I didn't realise</div><div><br></div><div>That \
does make it trickier...</div><div><br></div><div>Maybe logging when methods are \
hidden by an extension Module on the classpath would make it explicit what is going \
on?</div>
<div><br></div><div>Then again, if this is done a lot, then the logging may prove \
useless as it might be presenting so much information that it is hard to see when \
unexpected things are happening?</div><div><br></div><div>
Tim</div><div><br><div class="gmail_quote">On 22 October 2012 19:33, Jochen Theodorou \
<span dir="ltr"><<a href="mailto:blackdrag@gmx.org" \
target="_blank">blackdrag@gmx.org</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
Am 22.10.2012 17:14, schrieb Tim Yates:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div class="im"> Obviously, this goes under the heading of \
"bleeding obvious", but as<br> they currently stand Extension Modules \
overwrite any existing methods<br> defined in the module... (and so can have hidden \
effects)<br> <br></div>
[undesired BigDecimal#multiply reaplcement]<div class="im"><br>
<br>
Without the source for the Evil Module, this sort of thing would be<br>
completely hidden from the end user. And obviously, this is a simple<br>
example... I guess I could have done anything... sent data to a server,<br>
whatever. And I guess you could specially craft extensions to inject<br>
into large well known apps to harvest internal information, etc...<br>
</div></blockquote>
<br>
what you scheme is the extreme, but imagine the less extreme case. I have to modules \
that both provide a method. Which of those is used would then depend on their \
occurance on the classpath.<div class="im"><br> <br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> Is there a case for restricting the Extension Module \
mechanism somehow,<br> so that it (for instance) only allows the addition of new \
methods rather<br> than allowing the over-writing of anything Groovy?<br>
</blockquote>
<br></div>
I am thinking that we should maybe add something like that... not allowing one module \
overriding another module added method.<br> <br>
The problem though is, that we indeed want to replace methods in some cases. We have \
to think about how to enable those. Such a case is for example Map#toString, which is \
done by the same mechanism that also adds the methods from modules. That means we \
need a distinction between the methods from a module and those not... and that we \
imho have..<br>
<br>
What do you think?<br>
<br>
bye blackdrag<br>
<br>
<br>
------------------------------<u></u>------------------------------<u></u>---------<br>
To unsubscribe from this list, please visit:<br>
<br>
<a href="http://xircles.codehaus.org/manage_email" \
target="_blank">http://xircles.codehaus.org/<u></u>manage_email</a><br> <br>
<br>
</blockquote></div><br></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic