Prev: Do not assign undefined to window event handlers in IE/MSHTML
Next: Komodo Edit: Editor settings?
From: Ry Nohryb on 29 Apr 2010 09:53
On Apr 29, 3:36 pm, Ry Nohryb <jo...(a)jorgechamorro.com> wrote:
> (...) It was provided by some
> implementations, and it's still being provided by these
> implementations. (...)

s/these/those/ (I guess)
--
Jorge.
From: Dmitry A. Soshnikov on 29 Apr 2010 14:31
On Apr 29, 5:36 pm, Ry Nohryb <jo...(a)jorgechamorro.com> wrote:

> "And unfortunately, in contrast with __proto__ extension of some ES3
> implementation, ES5 does not provide ability for setting an object’s
> prototype."
>
> I find this phrase a bit nonsensical. The __proto__ wasn't part of ES
> before (ES3) and still isn't (ES5). It was provided by some
> implementations, and it's still being provided by these
> implementations. AFAIK.

Actually I meant the same. That for the word "extension" is - which
means it isn't standard, but an own extension of _some_
implementations.

Yes, it's still available in some implementations which already has
almost complete implementation of ES5 features.

So, I added "non-standard" word, maybe so it will be more clear:

"in contrast with non-standard __proto__ extension of some ES3
implementations"

Dmitry.
From: Dmitry A. Soshnikov on 29 Apr 2010 14:50
On Apr 29, 5:46 pm, Ry Nohryb <jo...(a)jorgechamorro.com> wrote:
> On Apr 29, 2:08 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com>
> wrote:
>
> > On Apr 29, 3:33 pm, Ry Nohryb <jo...(a)jorgechamorro.com> wrote:
> > (... ) And forgot about that only objects with
> > "Array" [[Class]] has overloaded internal methods related to arrays
> > stuff (15.4.5.1 in ES5).
>
> Yeah. Object.create() returns an {}. To subclass [] we'd need an
> Array.create(). I told this once to Brendan Eich @ es-discus, but
> unfortunately I couldn't understand his too-complicated-for-me
> response... :-)
>
> https://mail.mozilla.org/pipermail/es-discuss/2009-December/010425.html

Yep, I see.

And Brendan suggested [[Put]] to be delegable, but not determinate
only by some invariants (as it is now, and will), e.g. by [[Class]].
If [[Put]] would be delegable, then: own a.[[Put]] -> not found -> a.
[[Prototype]].[[Put]] - found and set "length" property accordingly.

In addition (as a variant) could be ability only to specify a
[[Class]] (it could be named as "type" e.g.) of the created object:

Object.created({
prototype: Array.prototype,
type: "Array",
// other properties
});

But it will be "too hard" (because require to be "prototype" and
"type" in this case a special properties, but not just normal). Also,
as I heard recently committee doesn't like (and won't standardize)
double-side-double-underscored __special__ properties, borrowed to ES
from Python. As actually __proto__, which is direct analogy of the
Python's __class__ and is for the same purpose.

Also, as was recently discussed @es-discuss list, all that new methods
which is now directly in "Object" constructor, but not in
"Object.prototype" led to that now we have three (!) syntactically
different approaches for the _same_ semantically entity - using
methods related with objects. The only reasonable thing is
stratification methods on "Meta" and "App" levels. But it is also very
debatable what should be treated as a "meta" and what is not (and
should ES do this the way as Java does). If will be interesting,
here's the complete discussion: <URL:
https://mail.mozilla.org/pipermail/es-discuss/2010-April/010908.html>

I already mentioned:

var o = Object.freeze(
Object.seel(
Object.defineProperties(
Object.create(proto),
properties
)
)
);

And:

var o = Object.create(proto)
.defineProperties(properties)
.seel()
.freeze();

that it is obvious that the first source even harder to read. And this
forced indention and repetition of Object.-Object.-Object. is just
ugly.

The same could be for:

var o = Object.create(SomePrototypeObject, {
...
});

And:

var o = {
__proto__: SomePrototypeObject,
...
};

The second source seems lighter, but, repeat, the committee doesn't
like __special__ properties. But, everything can be changed.

Dmitry.
From: Ry Nohryb on 29 Apr 2010 15:45
On Apr 29, 8:31 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com>
wrote:
> On Apr 29, 5:36 pm, Ry Nohryb <jo...(a)jorgechamorro.com> wrote:
>
> > "And unfortunately, in contrast with __proto__ extension of some ES3
> > implementation, ES5 does not provide ability for setting an object’s
> > prototype."
>
> > I find this phrase a bit nonsensical. The __proto__ wasn't part of ES
> > before (ES3) and still isn't (ES5). It was provided by some
> > implementations, and it's still being provided by these
> > implementations. AFAIK.
>
> Actually I meant the same. That for the word "extension" is - which
> means it isn't standard, but an own extension of _some_
> implementations.
>
> Yes, it's still available in some implementations which already has
> almost complete implementation of ES5 features.
>
> So, I added "non-standard" word, maybe so it will be more clear:
>
> "in contrast with non-standard __proto__ extension of some ES3
> implementations"

If it's non-standard it's not "in contrast" with ES5...
--
Jorge.
From: Ry Nohryb on 29 Apr 2010 16:19
On Apr 29, 8:50 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com>
wrote:
> On Apr 29, 5:46 pm, Ry Nohryb <jo...(a)jorgechamorro.com> wrote:
>
> > On Apr 29, 2:08 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com>
> > wrote:
>
> > > On Apr 29, 3:33 pm, Ry Nohryb <jo...(a)jorgechamorro.com> wrote:
> > > (... ) And forgot about that only objects with
> > > "Array" [[Class]] has overloaded internal methods related to arrays
> > > stuff (15.4.5.1 in ES5).
>
> > Yeah. Object.create() returns an {}. To subclass [] we'd need an
> > Array.create(). I told this once to Brendan Eich @ es-discus, but
> > unfortunately I couldn't understand his too-complicated-for-me
> > response... :-)
>
> >https://mail.mozilla.org/pipermail/es-discuss/2009-December/010425.html
>
> Yep, I see.
>
> And Brendan suggested [[Put]] to be delegable, but not determinate
> only by some invariants (as it is now, and will), e.g. by [[Class]].
> If [[Put]] would be delegable, then: own a.[[Put]] -> not found -> a.
> [[Prototype]].[[Put]] - found and set "length" property accordingly.
>
> In addition (as a variant) could be ability only to specify a
> [[Class]] (it could be named as "type" e.g.) of the created object:
>
> Object.created({
>   prototype: Array.prototype,
>   type: "Array",
>   // other properties
>
> });
>
> But it will be "too hard" (because require to be "prototype" and
> "type" in this case a special properties, but not just normal). Also,
> as I heard recently committee doesn't like (and won't standardize)
> double-side-double-underscored __special__ properties, borrowed to ES
> from Python. As actually __proto__, which is direct analogy of the
> Python's __class__ and is for the same purpose.
>
> Also, as was recently discussed @es-discuss list, all that new methods
> which is now directly in "Object" constructor, but not in
> "Object.prototype" led to that now we have three (!) syntactically
> different approaches for the _same_ semantically entity - using
> methods related with objects. The only reasonable thing is
> stratification methods on "Meta" and "App" levels. But it is also very
> debatable what should be treated as a "meta" and what is not (and
> should ES do this the way as Java does). If will be interesting,
> here's the complete discussion: <URL:https://mail.mozilla.org/pipermail/es-discuss/2010-April/010908.html>

Yeah. I had seen that already.

> I already mentioned:
>
> var o = Object.freeze(
>    Object.seel(
>      Object.defineProperties(
>        Object.create(proto),
>        properties
>      )
>    )
> );
>
> And:
>
> var o = Object.create(proto)
>    .defineProperties(properties)
>    .seel()
>    .freeze();
>
> that it is obvious that the first source even harder to read. And this
> forced indention and repetition of Object.-Object.-Object. is just
> ugly.


But that's a no-problem. They way they've done it you can build that
syntax yourself, if you wish:

(function (op) {
op.create= function (proto, p) {
return Object.create(proto, p ? p : undefined); };
op.defineProperties= function (p) {
Object.defineProperties(this, p); return this; };
op.seal= function () { Object.seal(this); return this; };
op.freeze= function () { Object.freeze(this); return this; };
})(Object.prototype);

var o=
({}).create(proto).defineProperties(properties).seal().freeze();


> The same could be for:
>
> var o = Object.create(SomePrototypeObject, {
>   ...
>
> });
>
> And:
>
> var o = {
>   __proto__: SomePrototypeObject,
>   ...
>
> };
>
> The second source seems lighter, but, repeat, the committee doesn't
> like __special__ properties. But, everything can be changed.

I don't think so. __proto__ is not a Good Thing™ due to some obscure
security reasons, and many of the seemingly odd-looking decisions wrt.
the new API, too, I heard.
--
Jorge.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Do not assign undefined to window event handlers in IE/MSHTML
Next: Komodo Edit: Editor settings?