Object Systems 2018-11-14

By Max Woerner Chase

In this post:

I've got an urge to mess with object libraries again. I think I didn't write up the last time I did this, but the main challenges come around to design, again.

My goal this time is to set something up based around newtype wrappers and parametric types. The idea is that a given underlying representation of an object can have different behavior in different contexts, mostly within that object's own methods. The idea is that "inheritance" works very differently in this library, compared to most languages. I'll also try going for "everything is (boxed) objects" within the context of the library, and see how that works out. This requires a small collection of wrapper types. The hierarchy will have multiple roots, so there'll be a special constructor for root classes around optimized ("optimized") representation, but the initial set of roots will just be, like, table, function, number, string, coroutine maybe.

A boxed value can have its underlying representation looked up, and it has an associated type, which is a subtype of functions, or possibly tables, or maybe specialized shapes. Building this kind of self-referential hierarchy is fun. I get to pretend it's like assembling an airplane around myself in midair, but it's not really, I guess.

Anyway, the idea is that each box type exposes the functions on its associated table as rewritten methods, but here's the key: "inheritance" is only structural, so method names don't propagate, so they can't conflict. I'll maybe want some form of automated delegation, but that's an ergonomics concern, not a completeness concern.

A type is several fundamental things:

In other words, a function that creates the underlying data, plus a table to be used in metamethod lookup. It's not a metatable precisely, because I plan to have all objects use the same metatable, and just interact with the metamethod hooks.

Thinking about this, it seems problematic to wrap the table functions into table methods. I guess to deal with it, it'd need, like, get and set methods instead of forwarding __index. Which is fine.

Since I cannot figure out how to do that "optimized representation" idea, I'm going to have to scrap it.

One thing that I'd really like to try out around Lua-related experimentation is Pijul, a new version-control system based on patch algebra. It sounds really cool, but I wouldn't know, since the current release doesn't install, and I have no idea when the next release comes out. The specific application I'd like to try out is taking the tiny Lua modules I always end up writing in projects, like a function to make ephemeron tables, and just merge it into any Lua project I do that needs it.

Last-minute thought: as I think about this more, I might want some way to do "multiple inheritance", and I think I see a way to pull it off.

Next time, I'll sketch out some use cases and invocations