How much sugar do classes need?

Peter Michaux petermichaux at gmail.com
Sun Nov 23 10:17:00 PST 2008


On Sun, Nov 23, 2008 at 7:24 AM, Mark S. Miller <erights at google.com> wrote:
> On Sat, Nov 22, 2008 at 8:54 PM, Peter Michaux <petermichaux at gmail.com>
> wrote:
>>
>> 2008/11/22 Mark S. Miller <erights at google.com>:
>>
>> >         Point.pubClassConst = -3;
>>
>> Why not the following?
>>
>>  public pubClassConst = -3
>
>
> I'm glad you raised this first. This example is a good microcosm of the
> issues distinguishing the two sugar proposal. My reasons for preferring the
> first:
>
> * The second form desugars to the first, but is no more convenient than the
> first. So introducing sugar here is not justified on convenience grounds.

At the very least, using the name of a class inside the class is a
problem for refactoring. If the code is moved to another class or the
class is renamed then all the names need to be changed.

If classes were to inherit class methods from parent classes (not
implying single inheritance) then your syntax would/may make it seem
that the property must be accessed through the Public object and
couldn't be accessed through a subclass object.

> * The second form obscures the difference between variables and properties,
> which does the ES programmer no favors.

I don't agree that it would be confusing to the ES programmer.

> In ES, "instance private" means
> lexically captured variable. ES has no other encapsulation mechanism, and
> the essence of the classes-as-sugar proposal is to employ that mechanism to
> create encapsulated instances.

Indeed. I thought that hiding that mechanism is part of the sugar's objective.

> "Public" means exactly string-named property.
> (A third category, class-private instance variables, depends on the
> introduction of Name objects, which both Cormac and I have left out of our
> first examples.)

I understand your point. I don't think this sugar is the sugar for
which people are hoping. If making a public method means explicitly
adding a property to an object then your proposed sugar is only
nutrasweet ;-) I mean that jokingly. I understand you are trying to
make a minimal proposal to see how minimal it can be.

I think part of the appeal of writing the following is it is declarative.

  public pubClassConst = -3

Writing the following is imperative.

  Public.pubClassConst = -3

I think your idea of adding properties to mean "public" is also the
reason for the "return self" in your example which I saw and didn't
understand. Why did you use "self" and not "this" which is a
constructor's automatic return value? If "look ma, no "this"' is
possible only because "self" is used in it's place then that seems
quite a superficial claim.

Why did you use the "public" keyword at all in the following line

  public self implements Point {

For consistency with this properties idea, should/could that section be

  var self = {
    to toString() {
      return '<' + self.getX() + ',' + self.getY() + '>';
    },
    to getX() { return x; },
    to getY() { return y; }
    let pubInstVar: 4,
    const pubInstConst: -4
  };
  return self;

I've removed the implements because that is related to type checking
and not this properties vs "public" issue. I'm guessing the "to" is a
typo and there is a missing comma. I don't understand the need for the
"let".

If there is to be inheritance (not necessarily single inheritance),
and something like Java's "protected" modifier for subclass-only
access, then how would that fit into your system?

> As for "familiarity to Java programmers", more people learn ES as their
> first language that Java.

Is that true?

> Java programmers have already learned to program.
> Making things easier for Java programmers to learn, at the price of making
> it harder for new programmers and for ES3 programmers (as well as functional
> programmers) seems like a bad tradeoff.

I think functional programmers would be more interested in having
multi-methods. Moving to an exclusive multi-method system is not
really possible given the entire DOM API is message passing.

> ES already won where Java lost.
> There's no reason for us to imitate its mistakes.

I wasn't advocating anything because it is familiar to Java
programmers. If ever I do mention doing something like Java does, it
will be both because Java does a few things well and it will be rare.
When talking about classes, Java is bound to be discussed.

> It probably makes sense to argue through this one example first, as most of
> the rest of the differences between the sugar proposals have these same
> motivations.

Peter


More information about the Es-discuss mailing list