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").
>
> But I think exact keyword isn't so important in this case. `extends` keyword
> is just familiar -- yes, from Java's syntax (actually JavaScript uses Java's
> syntax). And it doesn't matter and a Java programmer doesn't know that a
> class in JS can be dynamic and that after the extension there can be other
> modifications.
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.
...
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
