[prev in list] [next in list] [prev in thread] [next in thread] 

List:       groovy-dev
Subject:    Re: [groovy-dev] #flatten -- I don't get it
From:       Robert Fischer <robert.fischer () smokejumperit ! com>
Date:       2008-06-17 15:49:12
Message-ID: 4857DCF8.7050509 () smokejumperit ! com
[Download RAW message or body]

I suspect that there may be people relying on it who don't *realize* they are relying on it.  And
surprise breaks on point releases are REALLY annoying.

~~ Robert.

Paul King wrote:
> 
> Applied to 1.6. I also think this is the way to go for 1.5.7.
> I don't think the Map behavior is worth retaining but will
> keep the behavior if we think someone might be relying on it.
> 
> Paul.
> 
> Robert Fischer wrote:
>> +1 for Paul.
>>
>> There are a lot of methods on collection which aren't on array, so the
>> API for array doesn't need to
>> be induced to be the same as collection.  There is no #contains on
>> arrays, for instance, and
>> list#plus doesn't treat a list the same as an array:
>> groovy> def x = [ "A", "b", "c" ] as String[]
>> groovy> def y = [ "Z" ]
>> groovy> y + x
>> Result: ["Z", ["A", "b", "c"]]
>>
>> I'd fall back to "arrays aren't collections" and say that they should
>> be unadulterated by #flatten,
>> just like they aren't added by list#plus.   Converting from arrays to
>> lists isn't hard, and the
>> closure extension means that a user can override this behavior if
>> they'd like.
>>
>> ~~ Robert.
>>
>> Paul King wrote:
>>> Under what circumstances would that be used?
>>> In general an array is already a collection of like things
>>> so flattening isn't something that naturally springs to mind.
>>>
>>> Of course you could have Collection[] but that is probably
>>> a smell. And you could have custom classes, e.g. an Order class
>>> may have suborders but that would only make sense for the
>>> Closure provided case.
>>>
>>> Not trying to be difficult, we just have a tendency not to
>>> do things on Object for efficiency reasons because they slow
>>> down all objects. Not that efficiency should win over consistency
>>> but to me it feels like we are trying to force fake consistency.
>>>
>>> Paul.
>>>
>>>
>>> Jim White wrote:
>>>> This patch isn't quite correct.  Whatever you're going to do to the
>>>> children needs to be symmetric wrt to what you do at the top-level.
>>>>
>>>> If you're going to flatten arrays, then (<T>[]).flatten() needs to
>>>> work too.  If you're gonna do that you have to implement
>>>> DGM.flatten(Object) and DGM.flatten(Object, Closure).
>>>>
>>>> I've added this comment to the JIRA as well.
>>>>
>>>> http://jira.codehaus.org/browse/GROOVY-2904
>>>>
>>>> Jim
>>>>
>>>> Paul King wrote:
>>>>
>>>>> There is now a revised patch attached to the issue.
>>>>> Collection.flatten() now flattens arrays but not maps.
>>>>> Collection.flatten(Closure) allows a closure to be specified
>>>>> which describes how you want the flattening done which
>>>>> can be used for maps or other things.
>>>>>
>>>>> Paul.
>>>>>
>>>>> Jim White wrote:
>>>>>
>>>>>> Mike Dillon wrote:
>>>>>>
>>>>>>> begin Jim White quotation:
>>>>>>>
>>>>>>>> I think flatten should only be generalized to go as far as working
>>>>>>>> for Collection.  That means adding a DGM.flatten(Collection) and
>>>>>>>> removing the special treatment of Map for the children.
>>>>>>>
>>>>>>>
>>>>>>> What about arrays?
>>>>>>>
>>>>>>> -md
>>>>>>
>>>>>> flatten currently does nothing with arrays.
>>>>>>
>>>>>> If you want to apply flatten at the top-level you need to convert to
>>>>>> List or Set.  I do agree that generalizing that to Collection makes
>>>>>> sense.
>>>>>>
>>>>>> As for treatment of the children, that is exactly the sort of thing
>>>>>> you would do with my proposed Collection.flatten(Closure).
>>>>>>
>>>>>> Jim
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
> 
> 
> 

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

    http://xircles.codehaus.org/manage_email


[prev in list] [next in list] [prev in thread] [next in thread]