Comment by chriswarbo | Hacker News Reader

Comment by chriswarbo | Hacker News Reader

Class hierarchies seem to me more and more like a shadow language[1]. I first realised this in Python, where:

- Classes can be called like functions

- Calling a class runs a function (the constructor, called __init__)

- The constructor is implicitly passed a fresh object as an argument (usually called "self"; this is like an implicit use of "new")

- The constructor implicitly returns an initialised object (a mutated "self")

In a language with first-class functions, it's also pretty arbitrary to define "attributes" inside the constructor and "methods" outside, since methods are functions which are values (modulo the implicit binding stuff).

Hence classes can be completely replaced by their constructors; or in other words, classes are a design pattern when writing functions. This is a realisation that's become mainstream due to Javascript, and that's the first thing I thought of when I saw the Ceylon code in this article.

The details at the end, about execution order, partial constructors, inheritance, etc. all screamed "shadow language" to me: if you've already got functions(/methods), can't you just re-use them instead of defining a new, semantically distinct category?

[1] http://gbracha.blogspot.co.uk/2014/09/a-domain-of-shadows.ht...

Sure. A class is certainly a kind of function: one which returns a closure over its own shared declarations. That's the way we conceptualize the notion of a class in Ceylon, and it's why the syntax for a class looks so much like the syntax for a function, and why there's no essential difference between a function defined inside a class (a "method") and a function declared toplevel, or inside another function, or whatever. Ditto for a value defined inside a class (an "attribute") and a value declared toplevel or inside another function. It's the same thing, as far as Ceylon is concerned.

One of the design goals in Ceylon was to treat all these things uniformly, so that a class is, as much as possible, just like any other function.

However, there is a big and surprisingly important difference between a class and a function that returns a record: with a class you get open recursion between members of the class. You don't get that with a function that assigns members to a record type - or, at least, if you do build the machinery you need to get that, you have essentially reinvented classes with a worse syntax.

Open recursion seems like a small thing. But in fact, in practice, if you try taking it away from me, I will have to do some convoluted and nasty things to emulate it. Sure, there are plenty of simple classes where you can do without it, but there are surprisingly many classes where it's necessary, or at least very useful.

It's not that's surprising.

To support open recursion, a lot of functional languages consider differently top level functions and functions inside functions. That's why in JavaScript you have a murky global object with some weird scope rules that makes top level functions globally available.

Wouldn't record literals with open recursion lead to a design with much less semantic duplication?

Well I guess it's not extremely clear to me how a "record literal with open recursion" isn't essentially the same thing as a "class".

A record literal is an expression that creates a value. A class would then be a function, as chriswarbo suggests.

I understand, but once you start taking into account other requirements, like the ability to functionally decompose construction of this record, you will wind up with something that looks painfully similar to a class in Ceylon.

Can you elaborate on that? Since in this model constructors are just functions you can of course define multiple constructors that may or may not call each other.

Well the issue in my mind is how to functionally decompose construction of a record. You have to come up with some way to express a "partial" record, and then "augment" it with new members. I'm trying to say this without using the word "inheritance" ;-)

Yes, sure, you need a construct to extend a record. All but the simplest record systems have this though.

Right, so at that point, as I say, there's really not much daylight between "class" and "record". The difference being that a class protects its initialization logic (favoring modularity), whereas a record opens it up (favoring flexibility).

Ultimately I see them as much more similar than they are different.

The difference is that a class combines several things into one construct (initialization, type definition, naming) that are separate with records. This is also what causes you to need such an elaborate design for constructors.

What I'm trying to say is that I don't think that the total complexity or total expressiveness is ultimately much different. You trade class types + interface types for record types + named structural types. You trade class inheritance for record extension. You gain a tiny little bit of flexibility via structural typing - but in my opinion much less than is often claimed, since in all these languages so-called structural types are only partially structural - and you lose some power at the tooling level (refactorings are no longer guaranteed to work). You gain a bit of flexibility by decoupling initialization into a function, but you also gain a bit of verbosity and lose a little bit of modularity.

Ultimately it's a bit of a wash and honestly I would probably be almost as happy with OCaml or Rust or something like that as I am with Ceylon. I think both systems work well and are intellectually consistent. I don't think either is clearly superior to the other.

It's highly dependent on coding style. If you program in a mostly ML-like style then I think that design has its advantages because only only need record of functions + open recursion + named + always constructed via some constructor in 1% of cases. In such a style you view that combination as just one combination in a whole spectrum of data types that you can express. However if you want to make a language for object oriented programming it makes sense to build that combination into the language rather than supplying each part as a separate building block that you compose in exactly the same way all the time.

Yeah, I think that's probably right.

> One of the design goals in Ceylon was to treat all these things uniformly, so that a class is, as much as possible, just like any other function.

That's reassuring to know, thanks :)

> However, there is a big and surprisingly important difference between a class and a function that returns a record: with a class you get open recursion between members of the class.

Record members are certainly bound too early to get open recursion, which is why I claimed that classes == functions rather than objects == records ;)

In my example of Python, "objects" are abstract: created implicitly, passed into the constructor, then (implicitly) returned.

> You don't get that with a function that assigns members to a record type - or, at least, if you do build the machinery you need to get that, you have essentially reinvented classes with a worse syntax.

I think there are a few distinctions to be made here:

- Records vs. objects; which I've addressed above.

- Syntax vs. semantics: I'm fine with special-purpose syntax, I just don't like arbitrary semantic distinctions. It sounds like Ceylon is better than most in this regard :)

- Built-in vs. library code: reinventing classes using functions is only a bad idea if they're already built into the language in some other way. If there's no built-in alternative, then doing this in a library is legitimate. Likewise, using the language's existing support for functions to build-in a class implementation is also legitimate, and it sounds like that's what Ceylon's done :)

Yes, I think that's certainly what we've tried to achieve. It sounds like you and I have the same mental model, at least.

Indeed, the Ceylon constructors even read like a regular old static factory method in any other OO language, another pointer to the functional underpinnings of objects.

Totally this!

Reply on news.ycombinator.com