Set constructor arguments

[Axel Rauschmayer]

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

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120213/931f44d4/attachment-0001.html>