(no subject)

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

(no subject)

Neil Mix
I was just reading through the hashcodes proposal, I see that the  
proposal allows for the (remote) possibility of collisions between keys.

What jumps out at me is the potential for developers to assume that a  
hashcode is the same as a unique ID (especially if some  
implementations enforce uniqueness while others don't), thus leading  
to subtle bugs.  For that reason, I'd like to weigh in with the  
opinion that requiring uniqueness for hashcodes would be really  
nice.  (Alternatively a separate mechanism for generating unique  
object IDs would be nice.)

(I'm sure there are good reasons why enforcing uniqueness amongst  
keys is a burden on implementers, although I'm unaware of what those  
restrictions are.  Just a layman's perspective.)

   -Neil

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

Re: (no subject)

Lars T Hansen-2
On 3/15/07, Neil Mix <[hidden email]> wrote:

> I was just reading through the hashcodes proposal, I see that the
> proposal allows for the (remote) possibility of collisions between keys.
>
> What jumps out at me is the potential for developers to assume that a
> hashcode is the same as a unique ID (especially if some
> implementations enforce uniqueness while others don't), thus leading
> to subtle bugs.  For that reason, I'd like to weigh in with the
> opinion that requiring uniqueness for hashcodes would be really
> nice.  (Alternatively a separate mechanism for generating unique
> object IDs would be nice.)
>
> (I'm sure there are good reasons why enforcing uniqueness amongst
> keys is a burden on implementers, although I'm unaware of what those
> restrictions are.  Just a layman's perspective.)

The Java spec explicitly states that Object.hashCode does not return
unique values:

"It is not required that if two objects are unequal according to the
equals(java.lang.Object) method, then calling the hashCode method on
each of the two objects must produce distinct integer results."

The ES4 draft implies the same behavior, but couches it in more
difficult language (it tries to legislate what implementations ought
do without having the right to do so).

If an implementation is going to guarantee uniqueness then it probably
needs to maintain a global table of all live objects whose hash codes
have been obtained, to avoid generating duplicate codes when the
global hash code counter wraps around (intrinsic::hashcode returns a
uint).  True object IDs also preclude using a popular technique in the
presence of a moving collector, taking the address of the object at
the time the hash code was obtained and recording that in the object
if it survives a garbage collection.

IMO we'd be better off following Java here and just spell out (more)
clearly that you can't use the hash code as an object ID.  The purpose
of intrinsic::hashcode is after all to allow fast object-identity
hashing.  The use case for object IDs seems less clear.

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

Re: Object ID's

P T Withington
On 2007-03-16, at 05:23 EDT, Lars T Hansen wrote:

> The use case for object IDs seems less clear.

To visually distinguish otherwise similar objects in a debugger, for  
one.

If the language does not support object ID's internally, say in the  
introspection interface, you have a choice of maintaining a table  
(which the GC may already be doing), or annotating (but also  
polluting) the object (which the GC also may already be doing, but in  
a pollution-free manner).  So, while you can simulate object ID's, it  
should be cleaner and more efficient to provide an introspection  
interface to them.  (I'm not suggesting that hashcode should be the  
object ID, just that you might want to support object ID's.)

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

Re: Object ID's

Lars T Hansen-2
On 3/16/07, P T Withington <[hidden email]> wrote:
> On 2007-03-16, at 05:23 EDT, Lars T Hansen wrote:
>
> > The use case for object IDs seems less clear.
>
> To visually distinguish otherwise similar objects in a debugger, for
> one.

Granted...

> If the language does not support object ID's internally, say in the
> introspection interface, you have a choice of maintaining a table
> (which the GC may already be doing), or annotating (but also
> polluting) the object (which the GC also may already be doing, but in
> a pollution-free manner).  So, while you can simulate object ID's, it
> should be cleaner and more efficient to provide an introspection
> interface to them.  (I'm not suggesting that hashcode should be the
> object ID, just that you might want to support object ID's.)

I actually thought the meta-object proposal was flagged "optional",
but it's now mandated, otherwise I'd propose adding object IDs there.
Still, that'd be the best place for the functionality, as you suggest.

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

Re: Object ID's

Neil Mix
In reply to this post by Lars T Hansen-2

On Mar 16, 2007, at 4:23 AM, Lars T Hansen wrote:

> IMO we'd be better off following Java here and just spell out (more)
> clearly that you can't use the hash code as an object ID.  The purpose
> of intrinsic::hashcode is after all to allow fast object-identity
> hashing.  The use case for object IDs seems less clear.

Here's my problem: if one doesn't understanding the context behind  
intrinsic::hashcode, it looks like a bug:

   var key = new Widget();      // our unique lookup "key"
   var val = new Acme();        // value to reference
   var hash = {};               // our "hash table"
   var keycode = hashcode(key); // our hash table key
   hash[keycode] = val;         // UNSAFE

I see from the discussion page that this may be tied into some sort  
of dictionary datatype?  I'm having trouble understanding the use  
case for this otherwise.  Sorry if I'm missing the point of this  
feature, the context available in the docs is either missing or over  
my head.  :(

The use case that brought me to wondering about this was some vague  
brainstorming about a generic data binding architecture.  Given that  
es4 has sealed objects, the only way to safely reference a dependent  
object from its "data source" is to a) create a wrapper object (which  
could get expensive) or b) use a lookup table.

But, there's no way in the current spec to use a sealed object as the  
key in a table, unless you implement your own lookup mechanism that  
accounts for collisions, but then again it seems a bit silly to  
implement a hash table in JavaScript, doesn't it?

It's not a particularly strong use case, but my point is that if you  
start from the position of wanting object A to reference object B,  
but object A could be sealed, then there's no stupid-simple way to  
set up the reference.  (OTOH, for unsealed objects it's safe to  
simply add B as a member of A, provided you DontEnum it, which is  
awfully handy and simple.)

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

Re: Object ID's

Lars T Hansen-2
On 3/16/07, Neil Mix <[hidden email]> wrote:

>
> On Mar 16, 2007, at 4:23 AM, Lars T Hansen wrote:
>
> > IMO we'd be better off following Java here and just spell out (more)
> > clearly that you can't use the hash code as an object ID.  The purpose
> > of intrinsic::hashcode is after all to allow fast object-identity
> > hashing.  The use case for object IDs seems less clear.
>
> Here's my problem: if one doesn't understanding the context behind
> intrinsic::hashcode, it looks like a bug:
>
>    var key = new Widget();      // our unique lookup "key"
>    var val = new Acme();        // value to reference
>    var hash = {};               // our "hash table"
>    var keycode = hashcode(key); // our hash table key
>    hash[keycode] = val;         // UNSAFE

Sure, but the most I can do is write a clear spec.  If a programmer
reads guarantees into the spec that are not there (or indeed does not
understand the non-guarantees spelled out) then there's not much I can
do.

> I see from the discussion page that this may be tied into some sort
> of dictionary datatype?

So far we've failed to put a Dict type into the language; the utility
is understood but there's not been a critical push.  At this point it
may have been back-burnered long enough to be postponed until 5th
Edition.

> I'm having trouble understanding the use
> case for this otherwise.  Sorry if I'm missing the point of this
> feature, the context available in the docs is either missing or over
> my head.  :(

It's useful for building good hash tables that can use any object for a key.

> The use case that brought me to wondering about this was some vague
> brainstorming about a generic data binding architecture.  Given that
> es4 has sealed objects, the only way to safely reference a dependent
> object from its "data source" is to a) create a wrapper object (which
> could get expensive) or b) use a lookup table.
>
> But, there's no way in the current spec to use a sealed object as the
> key in a table, unless you implement your own lookup mechanism that
> accounts for collisions, but then again it seems a bit silly to
> implement a hash table in JavaScript, doesn't it?

Not particularly.  Objects are nice and clean, they map strings to
values.  Mapping arbitrary values to values is useful sometimes but
less rarely needed in my experience.  The language could provide a
built-in library (or even syntax support) for it, but ECMAScript is
not Java and the language probably should only provide libraries that
have substantial utility across the user base (just my opinion).

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

Re: Object ID's

Peter Hall-4
> So far we've failed to put a Dict type into the language; the utility
> is understood but there's not been a critical push.  At this point it
> may have been back-burnered long enough to be postponed until 5th
> Edition.
>

It *feels* more critical than the lambda syntax that is getting so
much attention in the other current thread. What is needed in order to
push this? I use AS3's Dictionary quite regularly for its weak keys,
and I imagine there would be growing need in JS as the number and
complexity of ajax apps increases.

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

Re: Object ID's

Lars T Hansen-2
On 3/20/07, Peter Hall <[hidden email]> wrote:
> > So far we've failed to put a Dict type into the language; the utility
> > is understood but there's not been a critical push.  At this point it
> > may have been back-burnered long enough to be postponed until 5th
> > Edition.
> >
>
> It *feels* more critical than the lambda syntax that is getting so
> much attention in the other current thread.

Amen to that, though there are several kinds of dictionary types one
could discuss, from the simple property-less object type (more
primitive than Object) to elaborate dictionary classes.

> What is needed in order to
> push this? I use AS3's Dictionary quite regularly for its weak keys,
> and I imagine there would be growing need in JS as the number and
> complexity of ajax apps increases.

We're technically way beyond the deadline for adding something like
weak tables (not something one implements on the user level) so I
don't know what it would take, really.  ByteArray made it in late but
it's a very simple proposal.

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

Re: Object ID's

P T Withington
On 2007-03-20, at 21:09 EDT, Lars T Hansen wrote:

>>
>> It *feels* more critical than the lambda syntax that is getting so
>> much attention in the other current thread.
>
> Amen to that, though there are several kinds of dictionary types one
> could discuss, from the simple property-less object type (more
> primitive than Object) to elaborate dictionary classes.

The last time this came up, I said:

> On 2007-01-05, at 20:14 EST, Brendan Eich wrote:
>> Another item falling out of the ES4 spec: hashes mapping string to  
>> value where the mapping is not polluted by Object.prototype.  A  
>> late "save" may be possible, if anyone can suggest syntax.  E.g.,  
>> var hash = #{'foo':1, 'bar':2, 'baz':3}; alert('toString' in hash)  
>> => false.  Eek, yet another attempt to use #.
>
> Since you can't build a pure hash in Javascript, this would be a  
> _highly_ desirable addition.  Naive use of Object for hash has been  
> the source of a number of subtle bugs in our code.  One might even  
> be so bold as to make Hash the primitive and Object inherit from it?
>
> We would have many uses for Hash in our code base.  I have defined  
> a dictionary class that I use for some cases, but often have had to  
> trade correctness for performance.
>
> A literal syntax would not be that important if you could have a  
> constructor with named arguments.  (Because the constructor's  
> `arguments` property would be a Hash?)  It would also be useful to  
> have a constructor that constructed a new hash from an existing one.
>
>> (Should these map value to value, rather than string to value?  
>> E4X (ECMA 357) already introduced QName objects as identifiers, so  
>> one can't pretend all properties are named by strings, if one  
>> believes in E4X.)
>
> value -> value would be a bonus that I would greatly appreciate,  
> but then won't you need to define a protocol for extending hash-
> code computation and `===`?

I think having a pollution-free dictionary type would be much more  
important that the `=>` syntax shortcut.  Having a dictionary that  
can map values to values would be a bonus, but also important.  You  
can't do either of these things efficiently in the language, which is  
a good reason to make them built in.

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

Re: Object ID's

Erik Arvidsson
Yes, The lambda discussion pales in comparison.

On 3/20/07, P T Withington <[hidden email]> wrote:

> On 2007-03-20, at 21:09 EDT, Lars T Hansen wrote:
>
> >>
> >> It *feels* more critical than the lambda syntax that is getting so
> >> much attention in the other current thread.
> >
> > Amen to that, though there are several kinds of dictionary types one
> > could discuss, from the simple property-less object type (more
> > primitive than Object) to elaborate dictionary classes.
>
> The last time this came up, I said:
>
> > On 2007-01-05, at 20:14 EST, Brendan Eich wrote:
> >> Another item falling out of the ES4 spec: hashes mapping string to
> >> value where the mapping is not polluted by Object.prototype.  A
> >> late "save" may be possible, if anyone can suggest syntax.  E.g.,
> >> var hash = #{'foo':1, 'bar':2, 'baz':3}; alert('toString' in hash)
> >> => false.  Eek, yet another attempt to use #.
> >
> > Since you can't build a pure hash in Javascript, this would be a
> > _highly_ desirable addition.  Naive use of Object for hash has been
> > the source of a number of subtle bugs in our code.  One might even
> > be so bold as to make Hash the primitive and Object inherit from it?
> >
> > We would have many uses for Hash in our code base.  I have defined
> > a dictionary class that I use for some cases, but often have had to
> > trade correctness for performance.
> >
> > A literal syntax would not be that important if you could have a
> > constructor with named arguments.  (Because the constructor's
> > `arguments` property would be a Hash?)  It would also be useful to
> > have a constructor that constructed a new hash from an existing one.
> >
> >> (Should these map value to value, rather than string to value?
> >> E4X (ECMA 357) already introduced QName objects as identifiers, so
> >> one can't pretend all properties are named by strings, if one
> >> believes in E4X.)
> >
> > value -> value would be a bonus that I would greatly appreciate,
> > but then won't you need to define a protocol for extending hash-
> > code computation and `===`?
>
> I think having a pollution-free dictionary type would be much more
> important that the `=>` syntax shortcut.  Having a dictionary that
> can map values to values would be a bonus, but also important.  You
> can't do either of these things efficiently in the language, which is
> a good reason to make them built in.
>
> _______________________________________________
> Es4-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es4-discuss
>


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

Re: Object ID's

Brendan Eich-2
In reply to this post by P T Withington
On Mar 20, 2007, at 6:34 PM, P T Withington wrote:

> I think having a pollution-free dictionary type would be much more
> important that the `=>` syntax shortcut.  Having a dictionary that
> can map values to values would be a bonus, but also important.  You
> can't do either of these things efficiently in the language, which is
> a good reason to make them built in.

You're right. I thought so when I brought this up a couple of months  
ago, and got "no new features" as the auto-reply. As Lars notes, that  
is very likely to be the answer again, but I'm willing to try one  
more time.

I would like a value -> value map unpolluted by prototype delegation.  
The string -> value map without pollution can be implemented by  
converting arbitrary keys to string and using the value -> value map.

As noted previously, objects in ES4 (which introduces Name objects to  
represent namespace-qualified property names) and ES3 with E4X (which  
calls Name QName) map not just string -> value, but (string, Name) ->  
value. o.q::n is not the same as o['q::n'].

The http://developer.mozilla.org/es4/proposals/catchalls.html 
proposal leaves ident untyped, but it can't be of type *. Practical  
implementations that I know of would type it (int, string, Name) or  
something similar (int might be constrained to fewer than 32 bits in  
a tagged word). Catchalls therefore look tempting for building value -
 > value maps, but without changing the inside of every ES3  
implementation to treat property names as arbitrary values instead of  
interned strings and tagged ints, or possibly qualified-name objects,  
the key type will be constrained.

So a value -> value map looks like a very special object, not  
something accessed via o.p or o[i] or o.q::n or o.q::[i]. This brings  
us back to the Flash Dictionary class (http://livedocs.adobe.com/flex/ 
2/langref/flash/utils/Dictionary.html#methodSummary) from AS3. Note  
the weakKeys constructor parameter. This class does suffer prototype-
delegated pollution, but does not intern its identifiers, instead  
using === to partition values into key equivalence classes (so -0 ===  
0 and NaN !== NaN).

Do we want a class that has magic (special-cased) property lookup  
rules, that does not delegate to Object.prototype, and that somehow  
can be operated upon without the standard methods from  
Object.prototype, or overrides for these (e.g., toString)?

I think not. The minimal solution, for which intrinsic::hashcode was  
devised, is a class with methods you have to call, say has, get, and  
put. No property lookup syntax for testing whether a word is in the  
dictionary, and no literal syntax for constructing instances by  
writing the key/value pairs in succession. But it could be part of  
the standard, so you could count on it everywhere. It could be  
written in ES4 if it were acceptable to hold only strong references  
to the keys.

Would this be enough? If so, I think TG1 ought to consider it. It  
would be a small addition to the standard library.

Flash Dictionary users who rely on weakKeys = true should pipe up for  
the use-cases that require this.

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

Re: Object ID's

Graydon Hoare-3
Brendan Eich wrote:

> Would this be enough? If so, I think TG1 ought to consider it. It  
> would be a small addition to the standard library.

This sort of thing -- either in app frameworks or the standard library
-- was certainly the purpose of adding intrinsic::hashcode. I hoped to
do a whole container library in the process of ES4, but it got shelved.

> Flash Dictionary users who rely on weakKeys = true should pipe up for  
> the use-cases that require this.

I admit to not having considered that scenario. Perhaps a general
Weak<T> type would do?

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

Re: Object ID's

Neil Mix
In reply to this post by Brendan Eich-2

> a class with methods you have to call, say has, get, and
> put. No property lookup syntax for testing whether a word is in the
> dictionary, and no literal syntax for constructing instances by
> writing the key/value pairs in succession. But it could be part of
> the standard, so you could count on it everywhere.

Moving intrinsic::hashcode into this proposed class would assuage any  
concerns I have about the hashcode proposal.
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Object ID's

Neil Mix
In reply to this post by Lars T Hansen-2

On Mar 20, 2007, at 6:30 PM, Lars T Hansen wrote:

> Sure, but the most I can do is write a clear spec.  If a programmer
> reads guarantees into the spec that are not there (or indeed does not
> understand the non-guarantees spelled out) then there's not much I can
> do.

Developers read documentation?  ;P  The spec is very clear (thank you  
Lars), anyone who reads it and jumps to the wrong conclusion has it  
coming to them.  I worry more about developers who see the method  
listed in reference docs that proliferate on the web (devguru.com,  
gotAPI.com, etc), the reliability of which may be questionable.  A  
globally scoped method named hashcode with a summary of "returns a  
hashcode for the given object"... well let's just say that I could  
see a younger version of me making an assumption I ought not.  ;)

I think the global scoping is my concern, it looks too all-purpose in  
that context.  Hence scoping to Brendan's proposed class suits me  
just fine.
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Object ID's

Bob Ippolito
On 3/20/07, Neil Mix <[hidden email]> wrote:

>
> On Mar 20, 2007, at 6:30 PM, Lars T Hansen wrote:
>
> > Sure, but the most I can do is write a clear spec.  If a programmer
> > reads guarantees into the spec that are not there (or indeed does not
> > understand the non-guarantees spelled out) then there's not much I can
> > do.
>
> Developers read documentation?  ;P  The spec is very clear (thank you
> Lars), anyone who reads it and jumps to the wrong conclusion has it
> coming to them.  I worry more about developers who see the method
> listed in reference docs that proliferate on the web (devguru.com,
> gotAPI.com, etc), the reliability of which may be questionable.  A
> globally scoped method named hashcode with a summary of "returns a
> hashcode for the given object"... well let's just say that I could
> see a younger version of me making an assumption I ought not.  ;)
>
> I think the global scoping is my concern, it looks too all-purpose in
> that context.  Hence scoping to Brendan's proposed class suits me
> just fine.

Do you really think that people will assume that hash means perfect
hash? I've never seen it taught or used that way. Maybe it's a common
programming mistake that I'm blissfully unaware of?

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

Re: Object ID's

Brendan Eich-2
In reply to this post by Graydon Hoare-3
On Mar 20, 2007, at 10:22 PM, Graydon Hoare wrote:

>> Flash Dictionary users who rely on weakKeys = true should pipe up for
>> the use-cases that require this.
>
> I admit to not having considered that scenario. Perhaps a general
> Weak<T> type would do?

In the spirit of intrinsic::hashcode, a WeakRef.<T> built-in type  
would give library authors the tools needed to make their own  
dictionary classes till the cows come home. But again I would hope  
that we could provide one simple, guaranteed-to-be-there, default  
implementation.

We still might want WeakRef.<T> for other use-cases.

/be

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

Re: Object ID's

Peter Hall-4
> We still might want WeakRef.<T> for other use-cases.
>

WeakRef.<T> could be derived from something like the AS3 Dictionary -
though not optimally. However, I think it's worth clarifying here that
the AS3 dictionary has weak keys, but not values. Weak values would be
nice-to-have, but can also be implemented on the back of a weak-key
dictionary.

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

Re: Object ID's

Peter Hall-4
In reply to this post by Brendan Eich-2
FWIW, The standard Flex Framework contains the string "new Dictionary"
19 times, of which 10 are weak keyed.

Peter


On 3/21/07, Brendan Eich <[hidden email]> wrote:

> On Mar 20, 2007, at 6:34 PM, P T Withington wrote:
>
> > I think having a pollution-free dictionary type would be much more
> > important that the `=>` syntax shortcut.  Having a dictionary that
> > can map values to values would be a bonus, but also important.  You
> > can't do either of these things efficiently in the language, which is
> > a good reason to make them built in.
>
> You're right. I thought so when I brought this up a couple of months
> ago, and got "no new features" as the auto-reply. As Lars notes, that
> is very likely to be the answer again, but I'm willing to try one
> more time.
>
> I would like a value -> value map unpolluted by prototype delegation.
> The string -> value map without pollution can be implemented by
> converting arbitrary keys to string and using the value -> value map.
>
> As noted previously, objects in ES4 (which introduces Name objects to
> represent namespace-qualified property names) and ES3 with E4X (which
> calls Name QName) map not just string -> value, but (string, Name) ->
> value. o.q::n is not the same as o['q::n'].
>
> The http://developer.mozilla.org/es4/proposals/catchalls.html
> proposal leaves ident untyped, but it can't be of type *. Practical
> implementations that I know of would type it (int, string, Name) or
> something similar (int might be constrained to fewer than 32 bits in
> a tagged word). Catchalls therefore look tempting for building value -
>  > value maps, but without changing the inside of every ES3
> implementation to treat property names as arbitrary values instead of
> interned strings and tagged ints, or possibly qualified-name objects,
> the key type will be constrained.
>
> So a value -> value map looks like a very special object, not
> something accessed via o.p or o[i] or o.q::n or o.q::[i]. This brings
> us back to the Flash Dictionary class (http://livedocs.adobe.com/flex/
> 2/langref/flash/utils/Dictionary.html#methodSummary) from AS3. Note
> the weakKeys constructor parameter. This class does suffer prototype-
> delegated pollution, but does not intern its identifiers, instead
> using === to partition values into key equivalence classes (so -0 ===
> 0 and NaN !== NaN).
>
> Do we want a class that has magic (special-cased) property lookup
> rules, that does not delegate to Object.prototype, and that somehow
> can be operated upon without the standard methods from
> Object.prototype, or overrides for these (e.g., toString)?
>
> I think not. The minimal solution, for which intrinsic::hashcode was
> devised, is a class with methods you have to call, say has, get, and
> put. No property lookup syntax for testing whether a word is in the
> dictionary, and no literal syntax for constructing instances by
> writing the key/value pairs in succession. But it could be part of
> the standard, so you could count on it everywhere. It could be
> written in ES4 if it were acceptable to hold only strong references
> to the keys.
>
> Would this be enough? If so, I think TG1 ought to consider it. It
> would be a small addition to the standard library.
>
> Flash Dictionary users who rely on weakKeys = true should pipe up for
> the use-cases that require this.
>
> /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: Object ID's

Igor Bukanov-2
In reply to this post by Brendan Eich-2
On 21/03/07, Brendan Eich <[hidden email]> wrote:
>  Catchalls therefore look tempting for building value -
>  > value maps,

It looks like the proposal misses function intrinsic::delete(ident)
and perhaps intrinsic::has(ident). The latter is necessary to allow to
use objects with catchalls under with() {}.

> but without changing the inside of every ES3
> implementation to treat property names as arbitrary values instead of
> interned strings and tagged ints, or possibly qualified-name objects,
> the key type will be constrained.

Rhino does not threat property names as interned strings and do the
full string equality  test if necessary during the property search.

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

Re: Object ID's

Peter Hall-4
In reply to this post by Peter Hall-4
On 3/21/07, Peter Hall <[hidden email]> wrote:
> FWIW, The standard Flex Framework contains the string "new Dictionary"
> 19 times, of which 10 are weak keyed.
>

Here are some examples of those usages:


CSSStyleDeclaration uses it to keep track of clones of itself, so it
can update them after changes to itself. The clones are created to be
inserted into prototype chains of other CSSStyleDeclarations, which is
how styles are inherited to subclasses.

To cache the result of expensive operations (eg
HierarchicalCollectionView and DefaultDataDescriptor)

To implement unique ids. (uids are mainly used in list controls and
collections).

To implement a simple weak reference. (eg ModuleManager)


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