marcoonroad / families

Concatenation-based prototypes implementation for Lua. :microscope: :crescent_moon: :family_man_woman_girl_boy: :house_with_garden:

Hi there 👋

Ghosts 👻 from the past 📚 are everywhere, hauting the only one left future ⌚ -- in which time is frozen 🥶 forever.

---

Stats 🧪

families's Issues

Links in the wiki are Broken.

Rather than providing filename as references into the links I must link the respective github wiki page. In this way, links redirect to rendered pages rather than raw Markdown files.

Provide support for Lua 5.1.

Despite the __gc metaevent existing only on userdata, it is really possible to implement the support of the cloning families algorithm within this library on the Lua 5.1 version as well. We just need to provide another layer of abstraction/indirection, that is, we must decouple the finalizer meta-method (in the case, __gc) from the current implementation on metatable.lua. Perhaps, another file/module called finalizer.lua could help us a lot. In this file, we could also detect the current Lua version, if it is 5.1 we just implement the finalizer with userdata/newproxy, otherwise, for the cases 5.2 and 5.3 we'll rather use a sole table. Such reference holding a finalizer must be unique and exclusively hold/pointed by the public object counterpart, whenever that public object is collected, that private reference will be collected as well and also will run the expected finalizer for our cloning families algorithm.

Documentation regarding initial version.

I must complete the documentation for that project. The wiki needs more things covering the API, examples and even tutorials, if possible, surely. Comparisons regarding other prototype-based languages such as JavaScript, Self and Io will be a huge plus.

Concatenative semantics are broken with nil values.

The addition of new fields on prototype-side are propagated into children due the current lookup semantics/rules.

Hence, it's needed to change the __index metamethod to take into account if the current selector is updated on clone-side. If it is indeed updated, even being nil, no further lookups on prototype-side could be performed.

Provide benchmarks & documentation for used concatenative clone-families algorithms.

In the experimental lua-51 branch I using a split & scan algorithm where the cloning procedure splits the current original prototype in two, the former part will be the new structure for the prototype and the latter, the structure/dictionary for clone object. With that approach, I have achieved support for Lua v5.1 while maintaining the Clone early, Clone often lemma. This kind of implementation is in some sense asynchronous, cause the evaluation order of super-structure scanning is unknown until runtime. The whole super/original structure/dictionary can be iterated entirely, or just a few (mostly due pairs function semantics). That implementation relies on coroutines rather than master branch's finalizers. The respective scanners hold strong references for such parent structure, but not the objects (the clone & prototype, they won't ever notice that super structure). The scanner copies lazily the fields from that parent structure, when the scan process finishes, it collects itself, thus, decreasing the pointer/counter for that super structure (which will be prone to GC).

Broken propagation semantics.

Further mutations on some prototype's selector don't notify children from previous selector's value. That is, such state propagation only occurs once due a certain conditional on metatable.lua file, inside the __newindex metamethod.

GC finalizer tries to index clones from inexistent prototypes.

When a topmost prototype object (from ex-nihilo creation, that is, an object containing nil as parent) is collected, its finalizer doesn't know whether it's a topmost prototype or not. Due that, the finalizer will try to add clones for such nil prototype, and thus errors are thrown mostly cause nil doesn't have clones in this library (there's no reason for that, nil won't eventually trigger and propagate changes anyways). The solution here is to patch the finalizer to detect if an object being collect is a topmost prototype.

Prototype mutation overrides existing children's properties.

After cloning, the passed structure (where the clone differs from prototype) must have greater precedence on lookup rules. I mean, it should "override" any existing property/selector from prototype. But in this library the inverse happens. IHMO, this is a quite awful and unsound bug on the implementation for concatenative OOP.

Move mirror/reflection API into a new experimental branch.

If a feature is undocumented, it's a bug. Nevertheless, reflection is quite a complex topic. It involves introspection and intercession as well. Besides, it can result in some delays in the release, so I must drop the support on the initial version and move that in another branch for further work.

NOTE: If possible, I must provide some kind of security to prevent malicious code tampering the production code using reflection. Still an open question. Perhaps the Object-Capability Model could help us.

Family introspection breaks 'Clone early, Clone often' lemma.

The clone object also could evolve in many distinct ways which don't resemble the prototype/parent object anymore. Therefore, I must figure out a structural approach to deal with the family resemblance API.

By now, move it away in another branch called resemblance.