Separating a Hash type from Object

Lars T Hansen lth at acm.org
Wed Jul 25 08:41:02 PDT 2007


On 7/25/07, Garrett <dhtmlkitchen at gmail.com> wrote:
>
>
> Lars T Hansen-2 wrote:
> >
> > On 7/25/07, Garrett <dhtmlkitchen at gmail.com> wrote:
> >> I see this as two issues.
> >>
> >> 1) The need for Collections/Data Structures.
> >> 2) The desire for shorthand access to these.
> >
> > Indeed.  We've decided to support (1) but not (2), but to sweeten our
> > solution by providing constructions and conversions from arbitrary
> > objects, so you can say
> >
> >   new Dict.<Name,int>({a: 1, b: 2, c: 3})
> >
> What is Name? Is that a new type that I haven't seen yet? Looks like an
> Identifier.
> I don't see Name here:
> http://developer.mozilla.org/es4/spec/chapter_19_native_objects.html
> (That page could benefit from a TOC and alphabetization.)

Indeed it could.

The wiki is pretty much out of sync with reality at this point; we
need to republish the internal wiki but haven't for a while, for
various reasons having to do with manpower etc.  Hopefully soon.

A Name is a data structure that holds a namespace and an identifier as
separate entities.  I misspoke above, there is a more general type
called EnumerableId that covers all the valid cases for a property
name in an object (Name, uint, int, and string), so the type in
question is Dict.<EnumerableId,int> in the example.

> > We're discussing whether to accomodate a hashcode/equals protocol on
> > keys, but if so this is guaranteed not to be the only protocol, and
> > we're not putting these protocols into Object, which will likely
> > reduce their utility a little.
> >
> The reason for adding them to Object.prototype is to have a common interface
> for collections to compare objects with. The default behavior would be
> strict equality.

I understand the motivation, but I don't think we'll be adding new
names to Object -- it's far too easy to break existing content, even
if these are DontEnum.  The global object probably needs to be an
Object of some sort, and suddenly "equals" and "hashcode" will show up
in the global environment because of that.  Tests for "'equals' in
<anything>" will suddenly return true.  etc.  It's a tough sell.  What
I have *proposed* for Dict is that we make it possible for clients who
want to use this OOP-like protocol to use it, and since we define what
that protocol would be then at least there's a standard for it, but
there will necessarily be some facility for supplying hashcode and
equality functions to the Dict constructor as well (defaulting to
intrinsic::hashcode and intrinsic::===) in cases where the protocol is
impossible or undesirable.

> The case for HashMap: HashMap is that it is the most common type of
> collection that will be used. Dictionary is more flexible, but since the
> keys are not, by default, strings, it will require more work to serialize
> toJSONString. In most cases users will want Strings for keys.

I think you have an uphill battle in restricting the functionality of
Dict, esp since one can say

  type HashMap.<T> = Dict.<String,T>;

and be done with it.  Not hard for the user, really.  Although I
suppose it is an interesting idea to provide that type by default, in
addition to Dict.

It's a good point that Dict ought to have a reasonable toJSONString,
and it's true that for String keys it can do a particularly good job.
I'll be sure to add that to the proposal.

(It actually opens up interesting questions about JSON -- the current
JSON code from Doug Crockford relies on enumeration to get property
names, but then filters the enumerated properties through
hasOwnProperty.  So even when Dict provides an iterator, it would need
to provide an override for hasOwnProperty to work correctly with the
default JSON protocol, if it does not want to override toJSONString.)

> > (I don't much care for "Dict" as a name myself, but BiCaptialized
> > suggestions like HashMap and hashCode won't get you anywhere with this
> > committee ;-)
> >
> What about ByteArray, toString, toJSONString, valueOf, et c? If that's not
> camelCase, I'm confused.

I'm sorry, I was being flip.  We've been deriding Java's choice of
"hashCode" for a method name (vs "hashcode" in ES4), but the examples
you cite are just as awful.  The splinter in your brother's eye and
the beam in your own and all that.

> How does "Dictionary" sound?

I love it, but I lost an informal vote :-)

--lars



More information about the Es4-discuss mailing list