Grasping for metaphors, I think it more of an object-system dissection.

Believe me when I say nobody's more sympathetic to the concerns of going-around-in-circles than myself. I've been going around in these circles for years and years. But object systems were an area I had more technical-familiarity with the variants of, than opinions on the correct formulation of. I tend to dislike OO and habitually write very close-to-the-data-structure procedural and functional code. So I chose an object system that was too conservative and conflated too much.

This is ironic since I felt much of the virtue of the obj system you and I worked on was that it didn't conflate as much as classes tend to (say, in C++). Yet it still conflated too much:

Non-integration with type parameter system (no interface-bounding)
Mandatory boxed representation
Mandatory vtbl dispatch
Mandatory representation hiding
Only context for destructors

This conservatism was based on my own areas of interest and style, and an assumption that objects would be something we "didn't lean on much", and that most objects would be "big" and "long-lived" so the conservatism wouldn't hurt too much. This was a mistake. There are too many small-to-medium cases that benefit from object-like treatments, where one or more aspects of the conservatism would bite. People wound up avoiding the object system for its costs, and getting irate. We lost contributors and users over the apparent willingness to impose systemic costs; the obj system was one of those cost centers. Costs really matter. Take a look through http://www.cs.virginia.edu/kim/publicity/pldi09tutorials/memory-efficient-java-tutorial.pdf and reflect on the numbers. Common collections -- 80% overhead!

We've since split off all these conflated facets into orthogonal concepts, each of which can be used in its most-efficient form independent of the others.

A destructor -- and a destructor alone -- is a resource now, and can exist absent an object. No vtbl, no heap allocation. The compiler can inline the dtor into its point-of-destruction.
Representation hiding only happens when you access things via interfaces; the owner of a type may "look inside" the representation.
Vtbl dispatch only happens when passing an interface-bound type parameter or boxed interface value; impl dispatch can be and often is resolved statically.
Boxing only happens in heterogeneous boxed interface value cases, which are more rare than one might assume: lots of the time a vector of foo really does consist of 10,000 concrete foo values packed into a homogeneous array.
Making ifaces into concepts that can apply to any type meant we could start using them as interface bounds on type-parametric functions, which makes a huge expressiveness difference. It also means we'll get inlined, specialized variants of such functions "for free" as part of the work on monomorphizing.

So please try not to look at this as a "rip it out and put it right back in" exercise. It's nothing of the sort. The pieces being put-back-in have very different characteristics: they're orthogonal to one another, more universal, and tend to perform much better. The parts that remain to be supplied in the "new" system are:

A sugar form class for declaring a nominal record plus methods that have self.foo based access to the record fields. I'm not entirely convinced this matters, since it is pretty much pure sugar and we can do all the components in isolation already. Possibly including a subtype relation on extensions thereof. But I really don't like the sound of that, as it breaks representation uniqueness (what's the element size of an array of T if T has larger subtypes?) and makes type inference much uglier too.
A mechanism for additive combination / mixing-in of implementation suites, for some degree of code-reuse. This is likely to be accomplished through iface-parameterized traits.

I'm much more interested in trait than class, but we'll see which of these is most likely. Minimalism is worth striving for here: every new orthogonal concept, while potentially powerful, is cognitively costly.

Much of the material written in Patrick's email above is redundant or not applicable anymore, in the presence of the iface/impl work. Which is a good thing. We have ifaces that can apply to numbers and tuples and tags now. That's great.

Uh oh!

Implement classes as per pcwalton's proposal #1726

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions