Object model

[yorickpeterse]

We need a chapter that outlines the object model the VM will use, what the trade-offs are, etc, etc.

[madmalik]

I'll try to sum up a few different models. Please correct me where i'm wrong ;)

• Prototype based: Used by Self, Javascript etc. An object is a hashtable with Strings as keys. In the common case, objects are created by cloning other objects. Code reuse is mostly done by runtime modification and methods are stored as values. Pro: It's easy to monkeypatch, easy to implement, easy to understand, flexible Contra: It's easy to monkeypatch ;), memory overhead (objects of the same kind don't share information about their structure), runtime overhead (every method call is a hashtable lookup), no type safety of any kind, since all objects have the same type (the flipside of the mentioned flexibility)
• The python approach: Basically the same, but with classes on top. (??? I'm not really sure how this actually works and what is specified and what is just CPython implementation). From what i understand: Objects behave like dictionaries, but have special attributes for type information and there are mechanisms for inheritance etc.
• Honorable mention: Lua. Dictionaries (named tables) are the only data structure in the language and there are different utilities for OO programming build on top as libs. A unique property is that every table can have a meta-table. If a lookup fails, the language tries to find the key in the metatable and so on. This lends itself to inheritance like mechanisms. Also the language dispatches operations like +, *, etc to special keys.
• Records, used by closure and i think in the common lisp object model CLOS (don't know that on very well): Structural information between objects are shared and methods are defined outside of the record. Pro: Allows multiple dispatch (if thats desired), decoupling of methods and data can be a solution for the expression problem.

All of these approaches are not big on information hiding.

Also:

• The Classic, a struct that contains a pointer to a Virtual Function Table. Used by C++, Java. Maybe not that interesting for a dynamic language.
• to be continued...

In general i'd like to see inheritance de-emphasised or completely left out. Another aspect that we can discuss is the addition of a trait system. There is a little bit of overlap with the described record approach that allows open method definition.

[yorickpeterse]

@madmalik

no type safety of any kind, since all objects have the same type (the flipside of the mentioned flexibility)

I disagree, type safety has little to do with prototype OO. See TypeScript for example, and Inko uses prototype OO and the language offers type safety (through gradual typing).

One of the big benefits of prototype OO is that it's super easy to model other object systems (class based OO for example) on top of it, while the inverse is not necessarily true. I personally also found it a bit easier to wrap my head around.

[madmalik]

@YorickPeterse

I disagree, type safety has little to do with prototype OO

Your are correct, i worded that wrong. What i meant is that the structure is more... amorphous? But I'll take a look into how typescript handles that (and of course Inko ;) ).

[yorickpeterse]

@madmalik Yeah, the underlying data structures are definitely less specialised. For example, for Inko it's (more or less) just this:

struct Object {
  prototype: *mut Object,
  attributes: Box<HashMap<*mut Object, *mut Object>>,
  value: ObjectValue
}

enum ObjectValue {
  Integer(i64),
  Float(f64),
  String(Box<String>),
  ...
}