Separating a Hash type from Object

Garrett Smith dhtmlkitchen at gmail.com
Mon Jul 30 08:54:50 PDT 2007


On 7/25/07, Lars T Hansen <lth at acm.org> wrote:
> 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.
That's for ES3.

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

var stuff = new HashTable.<String, *>();

stuff.add( "one", 1 );

stuff.hasOwnProperty( "one" ); // false.
stuff.one;// undefined.
"one" in stuff; // false.

if( "one" in stuff.keys ) stuff.get( "one" ); // 1.

for( var key in stuff.keys ) {
  print( key + ": " + stuff[ key ] );
}
// one: 1.

Should all Collections have a toJSONString?

Collection
 |
 +HashTable, SortedSet TreeMap ?


> > > (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 ;-)
> > >
The current JS spec is camelCasing everything. I usually like it when
an API does one thing consistently. If it's underscores, then always
use underscore, et c. JavaScript (hey, that's camel'd, too!) alway
uses camelCase. The DOM stuff is consistent, too (textContent,
nodeValue, et c). Will adding an inconsistency add confusion?


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


-- 
http://dhtmlkitchen.com/



More information about the Es4-discuss mailing list