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 > <[email protected]> wrote: >> The default argument should probably just be an iterable. >> >> On Feb 12, 2012 4:50 PM, "Oliver Hunt" <[email protected]> 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 [email protected] home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
