extends keyword instead of <superclass ... >
allen at wirfs-brock.com
Tue Mar 29 14:24:45 PDT 2011
On Mar 29, 2011, at 12:14 AM, Dmitry A. Soshnikov wrote:
> On 29.03.2011 2:51, Allen Wirfs-Brock wrote:
> Regarding classes in general I have the following table of "classes" kinds:
> | first-class | second-class (or "first-order")
> --------|------------------------------- |-----------------------------------
> dynamic | Ruby, Python, JS, Coffee | ?
> static | freeze(class) | C++, Java
> Thus, combination of "statics + second-class" can give us an immutable type with strong predefined behavior and set of properties.
FWIW, according to this model, Smalltalk has a static, first-class classes and I believe most of your points below also apply to such languages
> In dynamic classes first-class classes, a "type" as a set of predefined and immutable things is not so important. Moreover, for feature-testing, as a "type-tag" or better to say as a "classification-tag" can be used just a simple property of an object which helps to distinguish an object of yours classification from the object with the same state.
> foo.class == Foo; // true -- testing with a class-tag
> foo instanceof Foo; // true
> It's enough for dynamic first-class classes, and substitution principle may not be so important. Moreover, even here, e.g. the following substitution works fine:
> bar instanceof Bar; // true
> bar instanceof Foo; // true, assuming that Bar is a subclass of Foo
> And the set of methods and properties in the dynamic classes of course can vary over the time. And of course in such a system we cannot predict whether will be able to substitute an instance after some mutations (removing/addition methods, etc). But repeat, it's not so required hard in the dynamic system. But if you still want be sure, the just make them completely frozen (i.e. static classes) and then you can be sure.
There is much Smalltalk experience that shows that "class testing" leads to code that is less maintainable or less reusable. Smalltalk style guides (for example see http://stephane.ducasse.free.fr/FreeBooks/WithStyle/SmalltalkWithStyle.pdf ) invariably contained items like "don't test for a specific class" and "don't use isKindOf: or isMemberOf:" (tests for inherited/direct class membership). The reason is that you should care more about the behavioral contract of an object rather than which specific implementation class it is an instance of as there may be multiple classes whose instances are behaviorally interchangeable from some specific perspective. Behavior tests such as classification properties of the sort you mention are fine. Implementation class tests such as instanceof are not, even though as a practical matter they need to be available.
> So what is more important here (and exactly about it is your strawman as I understand, right?) is the syntactic sugar for exactly _convenient classified programming_. For the convinient classified generation of objects created by the specified (classified) _patterns_. And exactly from the _convenience of the usage_ of such a sugar I think we should start.
One of the things I was trying to say was that the most important thing about syntactic class definitions is their "modularity". They group all the elements that define the a set of objects with a common implementation into a single modular unit. The class declaration is the "module" that provides this grouping. The fact that you can use class membership for classification purposes is secondary and as mentioned above often undesirable.
>> One of the rules of object subtyping is that additional methods may be added by a subtype but methods may not be deleted. Thus in a subclassing==subtyping language it is easy to think about subclasses as generally "extending" superclasses with additional members. The use of "extends" in Java is no doubt a reflection of that perspective.
> Yes, that's true, but it seems a little bit as a nit-picking to exact syntax/terminology. Instead, we should concentrate on exactly the _convenient code reuse_ and _convenient classified generation_. Repeat, it doesn't matter much in dynamic system whether we'll remove some method (and therefore we shouldn't use keyword "extends"). If you just don't like exactly this keyword (assuming statics and only extension, not modification of descendant classes) then we may use any other word which you think fits better. E.g. `inherits` -- class B inherits A. Or symbols -- yours, proposed on Twitter (C++'s actually) colon : -- class B : A. Or Ruby's one -- class B < A (which is also logical -- "the class B is less than A").
I agree with you that the specific syntax for specifying the "superclass" is secondary and it wouldn't be the end of the word if we used the keyword "extends". But I did want point out that its familiarity may carry additional baggage. I also think there is some tension in this community between those who would prefer a "second-class static" subtyping based class model and those who are quite content with a "first class dynamic or static" inheritance based class model. If we are going to provide a class syntax we need to balance those perspectives or at least understand which we are favoring in our design decisions.
> What I want is to provide more convenient programming. What exactly you don't like in `@` as `this`? Isn't it convenient to describe class methods as just " (1) `this` evaluated in the class body -- is the class. (2) `this` evaluated inside instance method -- is an instance". And do you think the sugar I described is a good declarative form of classes sugar (or if not -- what did I do wrong?) ?
I think we already have "this" and it is too late to replace it with "@" in expressions.
> Writing every time "class method", "class method", "class method" not only too long (and therefore boring), but also will highlight this `class` keyword many times (which will annoy the users).
I think we can probably get rid of the "method". "class" doesn't bother me as being an excessively heavy weight of designate the relatively rare occurrences of constructor properties. Over all, I think this community tends to over use the need to minimize typing argument. Most lines of code are read many more times than they are written so there is a good case to be made for preferring readability or writability. Constructs that are used relatively infrequently should be more biased towards supporting readability while writability matters more for very frequently used constructs.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss