Es4-discuss Digest, Vol 3, Issue 2

[Kris Zyp]

I for one would love to see the ability to set DontEnum on properties. This
is a very logical thing do with some properties and is very useful in code
interopibility even when you are not trying to achieve a pure "Hash". It
doesn't seem like a very big addition either (vs sharps).
Also, having function/methods as slots that can be swapped with values seems
like a fundamental concept of ES and its simplicity and consistency. It
would seem bizarre to me to set toString to a primitive and expect anything
but an error when coercion tried to convert the object to string. ES3 throws
an error, and it seems totally logical that it should.
Also, it seems weird that we use the term "Hash", isn't Map or Dictionary
more correct? Isn't a Hash just the most natural and efficient
implementation of a Map or Dictionary? Maybe I am just used to Java
terminology. Of course we know what each other is talking about, so it is
not really a big deal.
Kris


On 5/2/07, es4-discuss-request at mozilla.org <es4-discuss-request at mozilla.org>
wrote:
>
> Send Es4-discuss mailing list submissions to
>        es4-discuss at mozilla.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://mail.mozilla.org/listinfo/es4-discuss
> or, via email, send a message with subject or body 'help' to
>        es4-discuss-request at mozilla.org
>
> You can reach the person managing the list at
>        es4-discuss-owner at mozilla.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Es4-discuss digest..."
>
> Today's Topics:
>
>   1. Re: Separating a Hash type from Object (Brendan Eich)
>   2. Re: Separating a Hash type from Object (Andrew Dupont)
>   3. Re: Separating a Hash type from Object (Brendan Eich)
>   4. Re: Separating a Hash type from Object (Andrew Dupont)
>   5. Re: Separating a Hash type from Object (Brendan Eich)
>   6. Re: Separating a Hash type from Object (Yuh-Ruey Chen)
>   7. Re: Separating a Hash type from Object (Brendan Eich)
>   8. Re: Separating a Hash type from Object (Peter Hall)
>   9. Re: Separating a Hash type from Object (zwetan)
>
>
> ---------- Forwarded message ----------
> From: Brendan Eich <brendan at mozilla.org>
> To: Andrew Dupont <andrew at andrewdupont.net>
> Date: Tue, 1 May 2007 18:36:44 -0700
> Subject: Re: Separating a Hash type from Object
> On Apr 30, 2007, at 2:43 PM, Andrew Dupont wrote:
>
> > However, it doesn't fix the lack of key safety.
> >
> > var foo = {};
> > foo + ""; //-> "[object Object]"
> >
> > foo.toString = "bar";
> > foo + ""; //-> Error: Can't convert foo to primitive type
> >
> > This bothers me.  The original "toString" property can still be
> > accessed with an intrinsic:call, but that doesn't help with the
> > automatic string coercion in the example above.
>
> use namespace intrinsic;
>
> does help there.
>
> > I think this has been discussed before on this ML, but nobody has
> > come up with an easy answer here.  Ideally, speaking from a narrow
> > perspective, I'd like to be able to distinguish dot notation from
> > bracket notation...
> >
> > foo["toString"]; //-> "bar";
> > foo.toString;     //-> function() {}
> >
> > ... but I fear that's too large a can of worms to open.
>
> How about a magic namespace:
>
> foo.direct::["toString"]
>
> or some such? Then 'use namespace direct' would result in foo.toString
> () or an implicit conversion failing if there were a foo.direct::
> ["toString"]. So a magic namespace may be the wrong UI. How about
> special syntax?
>
> foo#.toString
> foo#["toString"]
>
> and of course
>
> let dict = #{a:1, b:2, c:3};
>
> ?
>
> /be
>
>
>
>
> ---------- Forwarded message ----------
> From: Andrew Dupont <andrew at andrewdupont.net>
> To: Brendan Eich <brendan at mozilla.org>
> Date: Tue, 01 May 2007 23:41:28 -0500
> Subject: Re: Separating a Hash type from Object
> Brendan Eich wrote:
> > How about a magic namespace:
> >
> > foo.direct::["toString"]
> >
> > or some such? Then 'use namespace direct' would result in
> > foo.toString() or an implicit conversion failing if there were a
> > foo.direct::["toString"]. So a magic namespace may be the wrong UI.
> > How about special syntax?
> >
> > foo#.toString
> > foo#["toString"]
> >
> > and of course
> >
> > let dict = #{a:1, b:2, c:3};
> >
> > ?
> >
> > /be
> I like it. Let me think out loud...
>
> var foo = {};
> foo.toString; //-> function() {}
> foo#.toString; //-> undefined
>
> foo.toString = "bar";
> foo + "" //-> Error
> foo#.["toString"]; //-> undefined
>
> foo#.toString = "bar";
> foo#.toString; //-> "bar";
> delete foo.toString; //-> true
> foo#.toString; //-> "bar";
>
> delete foo#.toString;
> foo#.toString; //-> undefined
>
>
> If I'm correct in all these assumptions, then this seems like a good
> solution. I also like PT's "for..in own" syntax for discovering which
> keys are defined this way.
>
> Cheers,
> Andrew
>
>
>
> ---------- Forwarded message ----------
> From: Brendan Eich <brendan at mozilla.org>
> To: Andrew Dupont <andrew at andrewdupont.net>
> Date: Tue, 1 May 2007 21:50:02 -0700
> Subject: Re: Separating a Hash type from Object
> On May 1, 2007, at 9:41 PM, Andrew Dupont wrote:
>
> > Brendan Eich wrote:
> >> How about a magic namespace:
> >>
> >> foo.direct::["toString"]
> >>
> >> or some such? Then 'use namespace direct' would result in
> >> foo.toString() or an implicit conversion failing if there were a
> >> foo.direct::["toString"]. So a magic namespace may be the wrong UI.
> >> How about special syntax?
> >>
> >> foo#.toString
> >> foo#["toString"]
> >>
> >> and of course
> >>
> >> let dict = #{a:1, b:2, c:3};
> >>
> >> ?
> >>
> >> /be
> > I like it. Let me think out loud...
> >
> > var foo = {};
> > foo.toString; //-> function() {}
> > foo#.toString; //-> undefined
>
> So far so good.
>
> > foo.toString = "bar";
>
> This must create a direct property in the object referenced by foo,
> which shadows Object.prototype.toString. So:
>
> > foo + "" //-> Error
>
> agreed...
>
> > foo#.["toString"]; //-> undefined
>
> This isn't right, given the shadowing rule of JS/ES.
>
> > foo#.toString = "bar";
> > foo#.toString; //-> "bar";
> > delete foo.toString; //-> true
> > foo#.toString; //-> "bar";
>
> I'm confused -- do you intend that foo#.toString name a property in
> no namespace with identifier 'toString' in some object, or a property
> in a hidden namespace with local name 'toString'?
>
> > delete foo#.toString;
> > foo#.toString; //-> undefined
>
> This seems consistent no matter what.
>
> > If I'm correct in all these assumptions, then this seems like a good
> > solution. I also like PT's "for..in own" syntax for discovering which
> > keys are defined this way.
>
> That thought has occurred, but it doesn't match the |in| operator. A
> custom iterator factory might be better; there are lots of ways to
> iterate.
>
> /be
>
>
>
>
> ---------- Forwarded message ----------
> From: Andrew Dupont <andrew at andrewdupont.net>
> To: Brendan Eich <brendan at mozilla.org>
> Date: Wed, 02 May 2007 00:14:49 -0500
> Subject: Re: Separating a Hash type from Object
> Brendan Eich wrote:
> > I'm confused -- do you intend that foo#.toString name a property in
> > no namespace with identifier 'toString' in some object, or a property
> > in a hidden namespace with local name 'toString'?
> >
> The latter was my interpretation. But you're saying that the #. operator
> would simply look at the subset of an object's properties that are
> defined on the instance?
>
> That's more reasonable than creating a whole new property namespace. It
> doesn't solve the string coercion problem, though. Combining the #.
> operator with "use namespace intrinsic;" would, but that means the
> developer would have to *opt into* key safety.
>
> I still think the idea is promising, though, and would be useful even
> with this drawback -- and far more practical than what I originally
> thought you meant.
>
> Cheers,
> Andrew
>
>
>
> ---------- Forwarded message ----------
> From: Brendan Eich <brendan at mozilla.org>
> To: Andrew Dupont <andrew at andrewdupont.net>
> Date: Tue, 1 May 2007 22:41:27 -0700
> Subject: Re: Separating a Hash type from Object
> On May 1, 2007, at 10:14 PM, Andrew Dupont wrote:
>
> > Brendan Eich wrote:
> >> I'm confused -- do you intend that foo#.toString name a property in
> >> no namespace with identifier 'toString' in some object, or a property
> >> in a hidden namespace with local name 'toString'?
> >>
> > The latter was my interpretation. But you're saying that the #.
> > operator
> > would simply look at the subset of an object's properties that are
> > defined on the instance?
>
> Yes -- hence the direct:: namespace conceit that lost to #. #[ #{.
>
> > That's more reasonable than creating a whole new property
> > namespace. It
> > doesn't solve the string coercion problem, though. Combining the #.
> > operator with "use namespace intrinsic;" would, but that means the
> > developer would have to *opt into* key safety.
>
> The key safety problems you cite are (a) matching toString or another
> indirect (prototype-owned) property; (b) setting toString in the
> directly referenced object to some value not a toString function.
> You're right, #. addresses only (a).
>
> To address (b) would seem to require opting in as you note, or
> changing the usual rules for hashes (objects created via #{...}) to
> look for methods in a special namespace (intrinsic, or perhaps
> function as in SpiderMonkey).
>
> This is a fair amount of magic for the Hash class, and some of it
> (the function namespace) might want to be abstracted over any class,
> since E4X's XML class in SpiderMonkey wants the ability to access XML
> methods via, e.g., function::elements.
>
> Leaving (b) unsolved without opt-in (use namespace intrinsic), we
> could avoid a Hash class with magic method lookup rules altogether,
> and add #. #[ #{ as shorthand, where obj#.ident, obj#[expr] ,
> obj#.ns::ident, and obj#.ns::[expr] would be variations on the
> corresponding unsharp (hash-free) operators, which would work on any
> kind of object by looking only in the directly referenced object, not
> any prototype.
>
> /be
>
>
>
> ---------- Forwarded message ----------
> From: Yuh-Ruey Chen <maian330 at gmail.com>
> To: Brendan Eich <brendan at mozilla.org>
> Date: Wed, 02 May 2007 01:28:52 -0500
> Subject: Re: Separating a Hash type from Object
> Brendan Eich wrote:
> > How about a magic namespace:
> >
> > foo.direct::["toString"]
> >
> > or some such? Then 'use namespace direct' would result in foo.toString
> > () or an implicit conversion failing if there were a foo.direct::
> > ["toString"]. So a magic namespace may be the wrong UI. How about
> > special syntax?
> >
> > foo#.toString
> > foo#["toString"]
> >
> > and of course
> >
> > let dict = #{a:1, b:2, c:3};
> >
> > ?
> >
> > /be
> >
>
> As elegant as it is to use # for hashes, I'm not sure if a special
> syntax is needed for it, since I imagine it's usage would be limited to
> only certain classes. It doesn't introduce any new functionality, since
> we already have hasOwnProperty(). Perhaps a better way would be to allow
> the author to override the "[]" and "." operator in some coherent way
> (the approach C++ and Python take).
>
> -Yuh-Ruey Chen
>
>
>
> ---------- Forwarded message ----------
> From: Brendan Eich <brendan at mozilla.org>
> To: Yuh-Ruey Chen <maian330 at gmail.com>
> Date: Tue, 1 May 2007 23:40:28 -0700
> Subject: Re: Separating a Hash type from Object
> On May 1, 2007, at 11:28 PM, Yuh-Ruey Chen wrote:
>
> > As elegant as it is to use # for hashes, I'm not sure if a special
> > syntax is needed for it, since I imagine it's usage would be
> > limited to
> > only certain classes. It doesn't introduce any new functionality,
> > since
> > we already have hasOwnProperty(). Perhaps a better way would be to
> > allow
> > the author to override the "[]" and "." operator in some coherent way
> > (the approach C++ and Python take).
>
> Indeed, #. etc. is just a thought experiment. But just providing the
> ability to override . and [] wouldn't help so much without a default
> implementation -- it would force everyone wanting a hash unpolluted
> by Object.prototype to reinvent the wheel.
>
> So let's say there's a standard Hash or Dictionary class, with
> operator static functions for . and []. Then the missing piece is
> initializer syntax. We've talked about the thin nature of any #{...}
> syntax, since
>
> let myDict : Dictionary = {...};
>
> could perhaps optimize to avoid constructing an Object instance, then
> converting it to the Dictionary type due to the type annotation on
> myDict (perhaps, because object initialiser evaluation in ES3 is
> observable if one wraps or overrides the Object constructor -- see
> the recent JSON security blog threads).
>
> None of this is yet compelling enough, or coherent/general enough, to
> add to ES4. But work with me here...
>
> /be
>
>
>
>
> ---------- Forwarded message ----------
> From: "Peter Hall" <peter.hall at memorphic.com>
> To: "Brendan Eich" <brendan at mozilla.org>
> Date: Wed, 2 May 2007 11:35:41 +0100
> Subject: Re: Separating a Hash type from Object
> > use namespace intrinsic;
> >
> > does help there.
> >
>
>
> I don't think this is an answer. It solves the problem, but I doubt
> most JS developers would think of doing that until after they actually
> encountered the problem with live data. A dedicated hash object would
> solve the problem simply by being the obvious tool to use.
>
> Peter
>
>
>
> ---------- Forwarded message ----------
> From: zwetan <zwetan at gmail.com>
> To: es4-discuss at mozilla.org
> Date: Wed, 2 May 2007 13:12:57 +0200
> Subject: Re: Separating a Hash type from Object
> for me I see that as duality between strict and non-strict mode
>
> in strict mode we have statement as internal/private/public/etc..
>
> but for non-strict mode we don't have such things
> so to handdle those object as hash
> I would prefer to have access to DontEnum() / ReadOnly() / DontDelete()
> kind of functions
>
> and maybe using something as ASSetPropflags from flash implementation
> could be more practical
> (see: http://osflash.org/flashcoders/undocumented/assetpropflags )
>
> for the record, one thing I hated a lot from the JScript.NETimplementation
> was to access such hash with [] and impossible to use .
>
> maybe I don't see all the implications, but on object Object
> we should keep the shadowing mecanism as it was in ES3
> and just use DontEnum() (or more powerfull functions)
> to hide what we don't want to be enumerable.
>
> If it may be of any use, in environments like AS1/AS2
> I use the ASSetPropflags to change the enumerability
> in JS, I just use hasOwnProperty to be sure the prop is defined
> on the instance and not inherited.
>
> zwetan
>
>
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20070502/8ee25995/attachment-0002.html