On Thu, Aug 29, 2013 at 2:21 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

> Of the two cases I refer to, one is a function (the trademarking stamp())
> which takes a list of objects as a parameter and needs to ensure that
> successive stages of processing operate on exactly the same set of objects
> and do not trigger any side effects in the list's implementation. Here,
> realm is irrelevant but the list's implementation must be relied on, so in
> practice we want an Array from stamp()'s own realm.
>
> The other case is one where it is a cross-frame protocol and we
> specifically want an object which belongs to 'our own' realm because its
> prototypes are frozen and specially extended, whereas the calling realm's
> prototypes notably are not frozen (it's outside of the shiny happy sandbox)
> and therefore constitute a risk to least-authority programming which we
> want to stop at the boundaries. (Note for MarkM: It's actually a little bit
> more complicated than this, but the details are irrelevant to the
> principle.)
>
> for both cases, are you using Array.isArray to determine that you are
> operating upon an array?
>

In both cases, all we want is the user-specified set of values, to store or
operate on. So, in accordance with JavaScript idiom, we expect it to be
array-like, but (since we are multi-frame code) not necessarily an Array
from this frame.

Given this, there is no particular reason to perform an isArray test,
unless we wanted to do type checks for linting purposes ("you passed a Foo,
not an array of Foos; you probably made a mistake"), and we don't.

what would be the appropriate thing to happen (all things considered) in a
> world where subclasses of Array exist?


I don't have any examples to work from; I would think there is value in *
permitting* them to be used to carry the intended set-of-values if the code
calling our code uses them, but I do not see how any subclass could have a
custom behavior which would be *appropriate or useful* to preserve rather
than discarding in these two cases, or any other case where the array being
passed is used in 'functional' fashion (immediately reading as opposed to
either retaining it to look at later or mutating it).

(I admit I favor composition/delegation over inheritance, for public
interfaces, and therefore dislike the notion of working with subclasses of
concrete built-ins. But one could also consider, for example, the reasons
why java.lang.String is final.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130829/504914d8/attachment.html>

On Thu, Aug 29, 2013 at 2:21 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:

> for both cases, are you using `Array.isArray` to determine that you are
> operating upon an array?

In both cases, all we want is the user-specified set of values, to store or
operate on. So, in accordance with JavaScript idiom, we expect it to be
array-like, but (since we are multi-frame code) not necessarily an `Array`
from this frame.

Given this, there is no particular reason to perform an `isArray` test,
unless we wanted to do type checks for linting purposes ("you passed a `Foo`,
not an array of `Foo`s; you probably made a mistake"), and we don't.

> what would be the appropriate thing to happen (all things considered) in a world where subclasses of `Array` exist?


I don't have any examples to work from; I would think there is value in *permitting* them to be used to carry the intended set-of-values if the code
calling our code uses them, but I do not see how any subclass could have a
custom behavior which would be *appropriate or useful* to preserve rather
than discarding in these two cases, or any other case where the array being
passed is used in 'functional' fashion (immediately reading as opposed to
either retaining it to look at later or mutating it).

(I admit I favor composition/delegation over inheritance, for public
interfaces, and therefore dislike the notion of working with subclasses of
concrete built-ins. But one could also consider, for example, the reasons
why `java.lang.String` is final.)