Binary data (ByteArray/ByteVector) proposal on public-script-coord
charles at sproutit.com
Fri Nov 6 09:57:53 PST 2009
> I think the disadvantage of this design is that it puts all the
> mutation methods on immutable instances, where they are serve no
> purpose other than to throw when called. I think it is cleaner
> design for the immutable interface to lack mutation methods, rather
> than have mutation methods that always fail. I think designs where
> part of the normal workflow puts an object in a state where some
> methods always throw is poor OO design.
Well, let me argue this for a second...
Well designed systems often have objects with an internal state.
Features become available or unavailable on that object based on the
state. If you try to use a feature while the object is in the wrong
state, the object should throw an error. This is good API. It makes
it clear to the developer when they try to use the object in the wrong
The API I'm arguing for envisions the Data object having some internal
state [i.e. isEditable] and a part of the API is available or not
depending on that state.
ignore the "inheritance" of an object and just check its capabilities
before acting on it]. This pattern vastly simplifies JS code as you
don't have to shuffle references around so often and can reduce memory
That said, I will acknowledge there are many cases where methods that
throw are often indicative of bad OO design. I see this mostly in C++
and Java where devs define abstract base classes with lots of methods
that do nothing but throw. This is the opposite of what we want.
It's ugly and leads to code bloat.
In this case though, I would argue that a few if() statements at the
front of a primitive or two would actually reduce the amount of code
in regular running applications and means you only need to implement
> It's true that ECMAScript has not historically had mutable/immutable
> pairs of types, but this is a common pattern in other languages,
> such as Objective-C (NSString vs. NSMutableString), Java (String vs.
> StringBuilder), various recent Lisp dialects (where there are often
> both mutable and immutable lists) and arguably event C++ (const
> string and string expose different sets of method).
Most of the examples you give here, are statically-types [to various
degrees] class-based languages where inheritance chains are integral
The two-class pattern is more important in those cases than it is here.
> That being said, I can see how there is some value to aligning with
> the evolving ECMAScript pattern. Personally I think of Object.freeze
> as a tool for building new types that are meant to be immutable, or
> for exporting partially restricted facade interfaces, not as
> something one should be doing to random objects in the course of
> normal programming.
Allow me to withdraw my previous suggestion of freeze(). It's not the
right tool for this job. The general pattern though is well
established for freeze(), seal() and extensible. I think it would
work well here too.
PS. I'm happy to have data object support at all; this isn't really
critical to the feature IMO just an argument about which API would be
most useful to developers. I think both proposed models would be
More information about the es-discuss