On Jun 12, 2014, at 5:36 AM, Jason Orendorff wrote:
> On Wed, Jun 11, 2014 at 11:44 AM, Allen Wirfs-Brock
> <al...@wirfs-brock.com> wrote:
>> Array.from and Array.of have a non-throwing IsConstrutor test because they
>> are designed to allow things like this:
>>
>> let of = Array.of;
>> of(1,2,3,4,5); //Equivalent to: Array.of(1,2,3,4,5)
>>
>> I don't recall why we provided that functionality. It doesn't seem to me
>> like a pattern we should want to encourage.
>
> I think it was meant for functional programming; but FP is so poorly
> supported by the rest of the standard library that it's not useful by
> itself.
>
> Array.of could test 'if the this value is undefined' rather than using
> IsConstructor(). I like that. I can't put my finger on it, but I
> suspect people will try to treat Array.of as a standalone function and
> get the "undefined is not a constructor" error, and be baffled.
The problem with the undefined test is that it doesn't work if somebody tries
to attach such functions to a namespace object:
let arraybuilder = {of: Array.of, from: array:Array.from};
arraybuilder.of(1,2,3,4);
or consider, at the global level:
var of = Array.of;
of(1,2,3); //works
this.of(1,2,3) //breaks
That's essentially why we have the IsConstructor test. To distinguish between
this values that are actual constructors that will be used to create the new
collection and non-constructor objects that are just contains for the function.
>
> Back to the topic, it seems weird to go out of our way to expose
> @@isRegExp and @@isConcatSpreadable and also go out of our way to hide
> IsConstructor(). I don't like "does this object conform to this
> protocol" tests, but they are a fact of life in real JS code.
I think the @@is methods and isConstructor are different kinds of beasts.
isConstructor wold be a very general predicate that queries a fundamental
characteristic of the meta-object protocol. The @@is methods are local to the
implementation of a specific abstraction and nobody really needs to know about
them unless they are trying to extend that abstraction.
I'm not really opposed to an isConstructor predicate, I'm just pushing back to
see if it is something that really needs to be exposed. If we have it, I think
we probably should also have a isCallable predicate and I'd hand both of them
off of Function. IE:
Functiuon.isCallable(value)
Function.isConstructor(value) //or maybe it should be Function.isNewable ?
Allen
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
