Enumeration and Object Oriented JavaScript

AnimTree

Tabs

GlideMenus

DragLib

Conclusion

Enumeration might seem simple on the outside. Scratching beneath the surface, it's obviously not as simple as it seems.

All of the major libraries attempt to deal with the complications of enumeration, and the related browser bugs. The result is heavy, inefficient code whose meaning is obscured by it's workarounds for language deficiencies and browser bugs.

Enumerability in JavaScript creates a serious problem.

The language should be amended to support a practical and relevant set of collections to provide a useful alternative to Object as a hash table.

If the language defines this well, and browsers support the language perfectly, library code can be much smaller. Programs use more appropriate collection types, and code can be more meaningful.

My ES4 Recommendations

Public APIs are forever. Good code is modular code. Keep flexible and expect change.

Keep the spec in HTML format, interlinked, and provide examples throughout.
Easier for QA, studying, reference.
Fix the broken constructor property.
The constructor property is currently not on an object instance, but instead on the prototype. When creating a subclass, the constructor property is usually lost and can only be resolved to the superclass. This violates the principle of least astonishment. Programmers are forced to understand and patch the problem by maintaining the correct constructor property.
- Set the constructor Property of Each Function Object's prototype to Object
- Add the constructor property to the new object in [[Construct]] The value of the Object's constructor should be the function that created it. Keeping a warped API for performance reasons is a poor excuse for the current problematic design. Fix the problem. Implementations can and will fix the underlying performance issues.
Deprecate global properties, such as parseInt, isNaN, INFINITY and put them on the appropriate class. Global URI methods (encodeURI and friends) can go on a URI class.

The one exception would be the global property undefined. That should stay.
Fix propertyIsEnumerable and rename it to isPropertyEnumerable (link)
Make a DateFormatter class (link).
Keep JSON off Object.prototype.

Data Structures, Collections

typed Arrays
Enum
(typesafe, compact, reduces RuntimeErrors)
Generics
Map<T,T>
SortedSet<T>
ListIterator<T>
(the already proposed iterators are just a slight improvement from for in)
The Iterators and Generators proposals are all bad.
They are bad because they continue down the path of object-as-a-hashtable. They do not seem to fulfill any use cases.

There are a number of problems with each individual proposal, such as forcing the user to use exception handling for normal termination of the loop.

Each of the above Collection types (not ListIterator) could support most of the Array Generics.

Glossary

borrow: add properties of a supplier object as properties to receiver object This is usually done using a for in loop. It's kind of like doing a merge on a checkin.
enumerate: Using the for in statement to expose object properties (§12.6.4)
iterate: Using the for statement (§12.6.3)
override: shadow or replace a property value
prototype chain: linkage of the internal [[Prototype]] objects.
replace: give a new value to a object's own property
shadow: hide a property in the prototype chain by declaring it sooner in the object's prototype chain
white-box testing: Using an internal perspective of the system to test

Enumeration and Object Oriented JavaScript

Tags

Archived Scripts

Conclusion

My ES4 Recommendations

Data Structures, Collections

Glossary