On Monday 02 April 2001 17:05, Steve Dekorte wrote:
> > Jecel Assumpcao Jr wrote:
> > 1) base level: objects look like menus, morphs, strings, etc...
> > 2) reflective level: objects look like hash tables (or
> > collections of slots)
> > 3) implementation level: you have the actual memory format of
> > objects with tricks such as "maps" to help make cloned objects
> > smaller
> > What I am investigating here is the possibility of bringing levels
> > 2 and 3 closer together (ideally level 2 would be a slightly "sugar
> > coated" version of level 3).
> I'm not sure what you mean here.
> If you mean:
> 1) method invocation
> 2) reflection
> 3) object model
Well, I mean the object model as seen by the implementor.
> Then scripting languages like python and lua unite the first 2:
> 1) table.slotName() = call the returned function
> 2) a = table.slotName (get slot value, be it a function or data)
> table.slotName = b (set slot value to data or function)
That is exactly it. But I don't like how this unification made 1 feel
less object-like than it does in Smalltalk or Self. But it is
reasonable for people used to C++.
> And Lua brings 3 (the implementation of the object model) up to the
> level of 1&2 (the language itself) by providing "hooks" that let you
> define what happens when a table lookup fails:
> function index(table, slotName)
> local parent = rawgettable(table, "_parent")
> if parent then return parent[slotName] end
> error("object "..tostring(table).." has no slot
> You can likewise define the clone method, so you're free to do things
> like NewtonScript style slot creation on write if you like, to
> conserve memory and instantiating time at the expense of slot lookup
> It doesn't get much more "light-weight" than this.
Well, this is all at what I would call level 2. I still have no idea of
what a hash table looks like in the computer's memory. I would have to
look at Lua's C source code to find that out.