[prev in list] [next in list] [prev in thread] [next in thread]
List: groovy-dev
Subject: Re: [groovy-dev] Contract for createXXXFromClass (was Re:
From: Guillaume Laforge <glaforge () codehaus ! org>
Date: 2009-01-29 14:05:37
Message-ID: 197b18fc0901290605w6821c88au583bfe316ad6cf48 () mail ! gmail ! com
[Download RAW message or body]
On Thu, Jan 29, 2009 at 2:58 PM, Jochen Theodorou <blackdrag@gmx.org> wrote:
> Jim White schrieb:
>
>> Graeme Rocher wrote:
>>
>> ...
>>> I've created a JIRA for this:
>>>
>>> http://jira.codehaus.org/browse/GROOVY-3316
>>> ...
>>>
>>
>> I've committed a proposed fix to the trunk. If you could try it on
>> Hibernate and let us know if it works, that would be great.
>>
>> If this works and there is no objection, I'll commit to the 1.6 branch.
>> In that eventuality, we'll have to discuss whether this can make it into
>> 1.6.0 (I agree with Graeme that it should - even if it means another RC).
>>
>> In fact I'll go ahead and attach a 1.6 patch to the JIRA so folks can try
>> it that way themselves.
>>
>
> I think the idea Rene had looks promising. testing for AbstractList and
> such is a good idea too, but do they define a contract that allows us to
> make new instances of the implementation classes and add elements to that? I
> think it does not. On the other hand implementing Set, but not extending
> AbstractSet, does not mean it is dangerous to use that. So I would prefer a
> different solution... Rene had the idea to give the class to findAll. I
> think if it is the instance, then it is a good one.
>
> A problem with TreeSet for example is, that it can use a default Comperator
> or a custom one. Doing findAll on a TreeSet with a custom Comperator that
> produces a TreeSet with the default Comperator will not help. Doing a
> findAll(new TreeSet(myComperator)) is much longer, but you can specify
> exactly what data structure should be used.
>
But the default findAll (and related methods) would act as before, ie. use
the default list and set, right?
Only when we explicitely want a different collection (like this good example
of TreeSet with comparator), we'd use the findAll variant taking a
collection as first parameter.
Right?
--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one
[Attachment #3 (text/html)]
<br><div class="gmail_quote">On Thu, Jan 29, 2009 at 2:58 PM, Jochen Theodorou <span \
dir="ltr"><<a href="mailto:blackdrag@gmx.org">blackdrag@gmx.org</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, \
204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Jim White schrieb:<div \
class="Ih2E3d"><br> <blockquote class="gmail_quote" style="border-left: 1px solid \
rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Graeme Rocher \
wrote:<br> <br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); \
margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
...<br>
I've created a JIRA for this:<br>
<br>
<a href="http://jira.codehaus.org/browse/GROOVY-3316" \
target="_blank">http://jira.codehaus.org/browse/GROOVY-3316</a><br>
...<br>
</blockquote>
<br>
I've committed a proposed fix to the trunk. If you could try it on \
Hibernate and let us know if it works, that would be great.<br> <br>
If this works and there is no objection, I'll commit to the 1.6 branch. In \
that eventuality, we'll have to discuss whether this can make it into 1.6.0 (I \
agree with Graeme that it should - even if it means another RC).<br>
<br>
In fact I'll go ahead and attach a 1.6 patch to the JIRA so folks can try it that \
way themselves.<br> </blockquote>
<br></div>
I think the idea Rene had looks promising. testing for AbstractList and such is a \
good idea too, but do they define a contract that allows us to make new instances of \
the implementation classes and add elements to that? I think it does not. On the \
other hand implementing Set, but not extending AbstractSet, does not mean it is \
dangerous to use that. So I would prefer a different solution... Rene had the idea to \
give the class to findAll. I think if it is the instance, then it is a good \
one.<br>
<br>
A problem with TreeSet for example is, that it can use a default Comperator or a \
custom one. Doing findAll on a TreeSet with a custom Comperator that produces a \
TreeSet with the default Comperator will not help. Doing a findAll(new \
TreeSet(myComperator)) is much longer, but you can specify exactly what data \
structure should be used.<div class="Ih2E3d"> </div></blockquote><div><br>But the \
default findAll (and related methods) would act as before, ie. use the default list \
and set, right?<br>Only when we explicitely want a different collection (like this \
good example of TreeSet with comparator), we'd use the findAll variant taking a \
collection as first parameter.<br> Right? <br></div></div><br clear="all"><br>-- \
<br>Guillaume Laforge<br>Groovy Project Manager<br>Head of Groovy Development at \
SpringSource<br><a href="http://www.springsource.com/g2one">http://www.springsource.com/g2one</a><br>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic