Kevin,
Thanks for taking the time to write up your thoughts[1] in this area. I won't
try to make a point by point response because I think others on this list are
already doing a good job at this. However, I do what do clarify a few points
about the intent and likely usage patterns of of various object literal
extension proposal that I have been involved with.
First I'm not exactly clear on you position WRT including syntactic class
declarations as a feature of the ECMAScript language. Are you in favor of
that or do you think that library provided class abstractions such as your
describe are preferable for defining abstractions over objects. If you think
that adding syntactic class declarations are a good idea, then what specific
class semantics do you require. You seem to have some pretty specific ideas (as
exemplified in your library) about the semantics of classes. What if syntactic
classes become "built-in", but they do not support all the features of your
class model? For example, what if they only support single inheritance? Would
you use them? Or would you continue to use your on library provide class
abstraction?
The reason the above questions are important, is because many people think
"classes" should be added to ECMAScript but there are many different things
that they mean by "class". The biggest impediment to adding classes to
ECMAScript out inability, up to this point, to find a class model that is
satisfactory to all of the class proponents. Our experience so far, is that
the more "full featured" a class model becomes, the more likely that it will
include some feature that is considered essential by some parts of the
community but is totally unacceptable to other members of the community. Yes,
if a class model is minimized to the avoid such controversial features, nobody
finds it to be worth having.
The object literal class pattern[2], is an attempt to provide an "80%" percent
solution for defining class like abstractions that can be used in the absence
of a full featured declarative class definition. It does indeed assert (and
demonstrate) that extended object literals can be used to define "class-like
abstractions". However, it does not say, as you content, that "class syntax is
not necessary". What it says is:
"This pattern seems to capture pretty much everything that the classes proposal
accomplish without introducing a new hardwired syntactic forms. With this
pattern available do we really need class declarations (at least for now).
Rather than rushing syntactic class declarations into ES.next perhaps we should
first get experience with this pattern and later, based upon that experience
reconsider whether we need syntactic class declarations."[3]
Note the above is a reference to a single specific classes proposal and it is
offering this pattern as a potentially less intrusive alternative for what was
(and still is) a controversial proposal.
In your review you state: "It has been suggested that in ES.next extended
object literal can be used to create class-like abstractions" and then
investigate a more specific assertion "Can I get rid of my class library now,
and use this built-in feature to define classes?". First note that the first
sentence of [2] states that my proposed pattern "can be used to define
class-like abstractions that have all of the characteristics of the built-in
abstractions in Chapter 15 of the ECMAScript specification". It is claiming
that it suffices for supporting one specific class-like abstraction model, the
one that is implicit in Chapter 15. In fact, it is quite a bit more general
than the chapter 15 class model, as is demonstrated (not just suggested) by [4]
which uses the pattern to implement a well-known and fairly complex single
inheritance class library.
But [2] does not assert that its pattern is suitable for supporting all
class-like abstractions and in particular it makes no claims relating to your
library classed class abstraction. It if fine for you to contrast the the
features of the Chapter 15 class model (as support by my pattern) with your
class model. But since supporting your pattern was not a goal of my pattern,
its failure to do so doesn't really have much relevance to my stated goals.
More generally, you dig into whether the various object literal extensions that
I use for this pattern would be useful for library developers who are defining
class definition libraries. This is an interesting investigation, but
supporting such library developers was also not one of the goals of my specific
proposal. The patterns in [2] were intended to be used directly by ES
programmers who wanted to express Chapter 15 type class-like abstractions
directly in ES code without using a library. But supporting library writes is
one of the Harmony goals, so I'd be quite interested in hearing from you about
what new compositional features you think would be useful to such library
developers.
Just one other points before I wrap up.
You criticize the pattern for not being declarative, "not in nature, not in
form". I have to disagree with you on that point. Do you believe that your
library Class abstraction is is declarative in either nature or form? When I
compare your code in [5] with my code in [4] I don't see that much of a
difference in their "declarativeness". On this point, I probably should
define what I mean by "declarative". I consider code to be declarative, if a
human (or an appropriately programmed machine) can understand its meaning
without actually (or symbolically ) executing the code in its runtime
environment. In other words, its meaning is apparent from inspection rather
than from evaluation. My pattern uses a very small number of imperative
operators (<| , .prototype , .{ .constructor this.( , etc. ) to define its
class-like abstractions. While these are "imperative" when executed by the JS
engine it is also possible to assign declarative meaning to them. You could
build a front-end that recognized these declarative patterns and general the
runtime structures to represent these "classes" without have to imperative
execute the imperative definitions patterns. The same may well be true for
your library pattern.
Again, thanks for taking the time to write this all up. Even if I don't agree
with all of your conclusions the input is valuable. I'd like to seem more
feedback like this from the community.
Allen
[1]: http://blog.khs4473.com/2012/03/using-object-literals-as-classes.html
[2]:
http://wiki.ecmascript.org/doku.php?id=harmony:object_extension_literal_class_pattern
[3]:
http://wiki.ecmascript.org/doku.php?id=harmony:object_extension_literal_class_pattern#is_a_class_declaration_really_needed
[4]:
https://github.com/allenwb/ESnext-experiments/blob/master/ST80collections-exp1.js
[5]: https://gist.github.com/2050188
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
