Separating a Hash type from Object

classic Classic list List threaded Threaded
77 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Separating a Hash type from Object

Brad Fults
As has been previously noted [1] and should be general knowledge, the
confusion and collision between Object-as-hash and
Object-as-inherited-from is sometimes painful in ES3.

I looked through the latest ES4 spec and proposals [2] but didn't see
anything about changing the way hashes are handled. Are there any
plans to derive a Hash type from Object which would handle what are
now object literals (as hash literals)? If not, can there be?

This would solve many of the contemporary problems with Object (like
extending Object.prototype to include methods like .keys(), .values(),
etc.). I'm interested to hear others' thoughts on this.

Thanks.

[1] - http://erik.eae.net/archives/2005/06/06/22.13.54
[2] - http://developer.mozilla.org/es4/

--
Brad Fults
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Separating a Hash type from Object

Alex Russell
On Monday 30 April 2007 11:59 am, Brad Fults wrote:
> As has been previously noted [1] and should be general knowledge, the
> confusion and collision between Object-as-hash and
> Object-as-inherited-from is sometimes painful in ES3.
>
> I looked through the latest ES4 spec and proposals [2] but didn't see
> anything about changing the way hashes are handled. Are there any
> plans to derive a Hash type from Object which would handle what are
> now object literals (as hash literals)? If not, can there be?

There has been a proposal regarding this:

        http://developer.mozilla.org/es4/proposals/enumerability.html

ISTM that exposing ES3's internal [DontEnum] to user-set properties
fixes the issue without removing the (useful) flexibility of the
object/hash duality.

> This would solve many of the contemporary problems with Object (like
> extending Object.prototype to include methods like .keys(),
> .values(), etc.). I'm interested to hear others' thoughts on this.

Idiomatic ES3 code uses the object/hash duality to good effect. It's one
of the things I miss most when returning to a language without it
(e.g., Python).

Regards

--
Alex Russell
[hidden email]     A99F 8785 F491 D5FD 04D7 ACD9 4158 FFDF 2894 6876
[hidden email] BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss

attachment0 (193 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Separating a Hash type from Object

Brad Fults
On 4/30/07, Alex Russell <[hidden email]> wrote:
> There has been a proposal regarding this:
>
>         http://developer.mozilla.org/es4/proposals/enumerability.html

Ah, yes, DontEnum seems to solve the immediate problem of extending
Object.prototype. Thanks.

> the (useful) flexibility of the
> object/hash duality.
> [...snip...]
> Idiomatic ES3 code uses the object/hash duality to good effect.

I'm (honestly) curious to see some examples of useful flexibility and
good effects of the object/hash duality. I think I'm looking at the
issue from a different perspective and would benefit from a different
and concrete viewpoint that supports the duality.

Thanks.

--
Brad Fults
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Separating a Hash type from Object

Andrew Dupont-2
In reply to this post by Alex Russell

On Apr 30, 2007, at 2:20 PM, Alex Russell wrote:

> There has been a proposal regarding this:
>
> http://developer.mozilla.org/es4/proposals/enumerability.html
>
> ISTM that exposing ES3's internal [DontEnum] to user-set properties
> fixes the issue without removing the (useful) flexibility of the
> object/hash duality.

This fixes for-in loops, more or less. I'd also like to see a Hash  
class with a custom iterator::get that yields only instance  
properties. Relying only on propertyIsEnumerable is not enough, I  
think, because naive script-writers won't necessarily know to mark  
their extensions to Object so as to keep their chocolate out of your  
peanut butter.

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.

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.

Cheers,
Andrew

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Separating a Hash type from Object

P T Withington
On 2007-04-30, at 17:43 EDT, Andrew Dupont wrote:

> On Apr 30, 2007, at 2:20 PM, Alex Russell wrote:
>
>> There has been a proposal regarding this:
>>
>> http://developer.mozilla.org/es4/proposals/enumerability.html
>>
>> ISTM that exposing ES3's internal [DontEnum] to user-set properties
>> fixes the issue without removing the (useful) flexibility of the
>> object/hash duality.

Alex, can you say more about how this duality is useful?  An example,  
perhaps?

> This fixes for-in loops, more or less. I'd also like to see a Hash
> class with a custom iterator::get that yields only instance
> properties. Relying only on propertyIsEnumerable is not enough, I
> think, because naive script-writers won't necessarily know to mark
> their extensions to Object so as to keep their chocolate out of your
> peanut butter.

Agreed.  This solution relies on everyone behaving.

Would another approach be to have a way to tell for to enumerate only  
`hasOwnProperty` properties?

  for (var k in own foo) ...
  foreach (var i in own foo) ...

?

[This has the drawback that you cannot create 'inherited' hashes  
using prototypes.]

> 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.
>
> 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.

Yow!  I have a better idea:  generic functions -- get methods out of  
instances altogether!

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Separating a Hash type from Object

Brendan Eich-2
In reply to this post by Andrew Dupont-2
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

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Separating a Hash type from Object

Andrew Dupont-2
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
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Separating a Hash type from Object

Brendan Eich-2
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

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Separating a Hash type from Object

Andrew Dupont-2
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
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Separating a Hash type from Object

Brendan Eich-2
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
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Separating a Hash type from Object

Yuh-Ruey Chen
In reply to this post by Brendan Eich-2
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
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Separating a Hash type from Object

Brendan Eich-2
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

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Separating a Hash type from Object

Peter Hall-4
In reply to this post by Brendan Eich-2
> 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
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Separating a Hash type from Object

zwetan-3
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.NET implementation
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
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Separating a Hash type from Object

P T Withington
In reply to this post by Brendan Eich-2
On 2007-05-02, at 02:40 EDT, Brendan Eich wrote:
  [...]
> Indeed, #. etc. is just a thought experiment.

I do think there needs to be a primitive Hash type.  Otherwise we  
doom users to trying to invent their own and hitting all the various  
pitfalls that have been enumerated on this thread.

The safety issue is that methods are visible as properties of an  
instance.  Putting the methods in a special namespace seems kludgey  
to me.  What is the benefit of methods being properties of an  
instance?  What if they were not?

Another thought experiment:

What if `foo.bar(...)` was syntactic sugar for `bar[typeof foo].apply
(foo, ...)`.  Oh, wait, that's not quite right.  Guess I have to  
invent generic functions.  Hm.


_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Separating a Hash type from Object

Andrew Dupont-2
In reply to this post by Brendan Eich-2

On May 2, 2007, at 1:40 AM, Brendan Eich wrote:
> 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.

And there's the rub: how do we make a default implementation without  
introducing too much magic? No matter how we do it, a Hash class  
would introduce a completely different relationship between an object  
and its properties.

Reinventing the wheel is less surprising to developers because it's  
their wheel and they know how it works. But I think the initial  
unpleasantness of special-casing Hash is better than the ongoing pain  
of each developer writing his own implementation of hashes.

I'm entirely in favor of a way to override "." and "[]", whether or  
not ES4 introduces a magic Hash class. That, at least, gives the  
developer a chance to solve the problem on her own.

Andrew


_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Separating a Hash type from Object

Brendan Eich-2
In reply to this post by P T Withington

On May 2, 2007, at 4:58 AM, P T Withington wrote:

> On 2007-05-02, at 02:40 EDT, Brendan Eich wrote:
>   [...]
>> Indeed, #. etc. is just a thought experiment.
>
> I do think there needs to be a primitive Hash type.  Otherwise we
> doom users to trying to invent their own and hitting all the various
> pitfalls that have been enumerated on this thread.

I've agreed repeatedly, but without a sufficiently winning proposal  
(which I'm explicitly seeking here with help from y'all), it's not  
going to happen for ES4.

> The safety issue is that methods are visible as properties of an
> instance.  Putting the methods in a special namespace seems kludgey
> to me.  What is the benefit of methods being properties of an
> instance?  What if they were not?

Backward incompatible, requiring opt-in versioning and doubling  
brainprint. Why is this important to change incompatibly? Note that  
it's not just methods that make for the safety issue. There may be  
properties with other than function value in a prototype object.

> Another thought experiment:
>
> What if `foo.bar(...)` was syntactic sugar for `bar[typeof foo].apply
> (foo, ...)`.  Oh, wait, that's not quite right.  Guess I have to
> invent generic functions.  Hm.

We have generic functions (Array.map, etc.). That's not the issue.

Compatibility with ES1-3, as well as with standard OOP dogma, says  
that methods are called via obj.foo(). You could argue that should be  
sugar for some different dispatch mechanism, but ES1-3 do not  
distinguish methods from other properties. It doesn't matter whether  
they're delegated to a prototype, or directly in the object at hand.

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Separating a Hash type from Object

Brendan Eich-2
In reply to this post by Peter Hall-4
On May 2, 2007, at 3:35 AM, Peter Hall wrote:

>> 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.

You're right.

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Separating a Hash type from Object

Peter Hall-4
In reply to this post by Brendan Eich-2
I'm wondering what is so wrong with Hash.set(key, value) and Hash.get(key)....


Peter



On 5/2/07, Brendan Eich <[hidden email]> wrote:

>
> On May 2, 2007, at 4:58 AM, P T Withington wrote:
>
> > On 2007-05-02, at 02:40 EDT, Brendan Eich wrote:
> >   [...]
> >> Indeed, #. etc. is just a thought experiment.
> >
> > I do think there needs to be a primitive Hash type.  Otherwise we
> > doom users to trying to invent their own and hitting all the various
> > pitfalls that have been enumerated on this thread.
>
> I've agreed repeatedly, but without a sufficiently winning proposal
> (which I'm explicitly seeking here with help from y'all), it's not
> going to happen for ES4.
>
> > The safety issue is that methods are visible as properties of an
> > instance.  Putting the methods in a special namespace seems kludgey
> > to me.  What is the benefit of methods being properties of an
> > instance?  What if they were not?
>
> Backward incompatible, requiring opt-in versioning and doubling
> brainprint. Why is this important to change incompatibly? Note that
> it's not just methods that make for the safety issue. There may be
> properties with other than function value in a prototype object.
>
> > Another thought experiment:
> >
> > What if `foo.bar(...)` was syntactic sugar for `bar[typeof foo].apply
> > (foo, ...)`.  Oh, wait, that's not quite right.  Guess I have to
> > invent generic functions.  Hm.
>
> We have generic functions (Array.map, etc.). That's not the issue.
>
> Compatibility with ES1-3, as well as with standard OOP dogma, says
> that methods are called via obj.foo(). You could argue that should be
> sugar for some different dispatch mechanism, but ES1-3 do not
> distinguish methods from other properties. It doesn't matter whether
> they're delegated to a prototype, or directly in the object at hand.
>
> /be
>
> _______________________________________________
> Es4-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es4-discuss
>
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Separating a Hash type from Object

Brendan Eich-2
On May 2, 2007, at 11:44 AM, Peter Hall wrote:

> I'm wondering what is so wrong with Hash.set(key, value) and  
> Hash.get(key)....

Nothing's wrong, but the "rightness" of object literals in  
particular, and . or [] for accessing values by key, will make  
anything like this less successful than you might hope. Syntax is the  
UI, it matters.

We actually started down this road at a recent meeting, and ran into  
another, non-syntactic issue: often one wants weak reference support  
for keys, and sometimes even for values. Flash's Dictionary class has  
a "weakKeys" flag parameter to its ctor. There's lots of prior art  
here -- Allen Wirfs-Brock cited Barry Hayes's Ephemerons (http://
portal.acm.org/citation.cfm?id=263733&coll=portal&dl=ACM), for example.

This complexity again made us shy away from any late-breaking  
significant feature. Adding GC requirements on all implementations  
needs to be done with care, and with enough time to implement and test.

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
1234