On 7/25/07, Lars T Hansen [EMAIL PROTECTED] wrote:
On 7/25/07, Garrett [EMAIL PROTECTED] wrote:
Lars T Hansen-2 wrote:
On 7/25/07, Garrett [EMAIL PROTECTED] 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
