Set constructor arguments
axel at rauschma.de
Mon Feb 13 01:01:59 PST 2012
My suspicion: All these features make sense for the full-blown collections API, but for sets I’m not sure at which point they wouldn’t be “simple”, any more.
Oliver Hunt makes a good case: “With the existence of the spread operator I think that there's a good
argument in favour of the multiple parameters approach.”
An additional option is to introduce a “static” factory method: Set.fromIterable().
On Feb 13, 2012, at 4:29 , Michael A. Smith wrote:
> …But we wouldn't want to require the arguments to the set constructor
> to require instantiation itself/themselves, right? If a set has to be
> constructed with an Iterable, and cannot (also) be constructed with
> individual atoms, then you'll end up with use cases like Set(['foo',
> 'bar', 'baz']), which requires two constructions, one of which is
> essentially a waste. If allowing both forms of the constructor is
> distasteful, then why not just go with the multiple parameters,
> approach, and implement toSet() as a method on appropriate Iterables?
> -Michael A. Smith
> On Sun, Feb 12, 2012 at 9:29 PM, Erik Arvidsson
> <erik.arvidsson at gmail.com> wrote:
>> The default argument should probably just be an iterable.
>> On Feb 12, 2012 4:50 PM, "Oliver Hunt" <oliver at apple.com> wrote:
>>> I saw a reference to it being modified to take an array(-like?) as a
>>> parameter. While I can see an argument in favour of a single array argument
>>> I can also see using a set of parameters that initially populate the set.
>>> We just shouldn't allow both (and introduce another version of the horror
>>> that is the Array constructor).
>>> With the existence of the spread operator I think that there's a good
>>> argument in favour of the multiple parameters approach.
Dr. Axel Rauschmayer
axel at rauschma.de
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss