OOBit

[Nilson <nilson.brazil@...>]

Hi everyone,

I'm thinking about a Lua patch and before spend much time working on
it, I would appreciate any comments about the ideas involved.
Thanks in advance for your attention.

Motivation

Lua, like other languages, uses the colon character to offer a
syntactic sugar to simulate the way that pure OO languages usually
makes call method, i.e.,  make automatically inserting the self
parameter in function calls.

tab:fname(param-list)  =>  tab.fname(tab, param-list)

This is a good idea. The syntactic sugar really helps. But, it could
be better?

a) Well, the mix of colon usage (call functions with ) and dot usage
(field methods) introduces a certain dissonance in the language´s
elegant harmony.  See, to simulate a method call, which improves the
perception of an pure OO language like java, you must use a special
feature (the colon) that damages/lowers the OO abstraction.

b) Although the hidden parameter is a function requirement and the
function itself could vary between calls, all the responsability to
make a correct call is left on programmer's shoulders. Lua does not
help. The programmer must decide (think) whether use a dot or a colon
each time it writes a member access or make a function call. Depending
on the context, this may require a annoying effort.

c) Besides that, the colon syntactic sugar solution is a static
solution. Does not vary with function requirements. Ok, ok. In
practice this is not use to be a real problem but it is a latent
problem.

d) The permanent necessity to choose between colon and dot may bother
occasional (Lua?) programmers and may affect their programming
language's choice.

Main goal
Always use only dots to access fields or make calls and divide the
responsability to add or not the hidden self parameter between Lua and
the programmer.
This must be done without any notable degradation in Lua's performance.

How
The programmer must inform the OO requirements during the function or
table creation (or just after that), so Lua can decide if it must add
or not the self parameter at each function call.

Steps/Tasks (very preliminary):

1. Reserve one bit (called OOBit) in the type field (int tt) of the
Lua's Value structure. Lua´s type uses only 4 bits to store type info.

2. Make the OOBit invisible/undetectable using a mask in all macros
that handles types in Lua. In this way, no new type will be created or
changed by Lua's code point of view. The OOBit will be detectable only
by new specific macros or functions.

3. Create a mechanism that sets the OOBit on table and function
values, like an ooset() function. Alternatively implement a syntax
change to indicate that the element must have the OOBit true, like
:{} or function :( ) and use the function table:name ( ) syntax to set
the OOBit.

4. Create a C function oocall(luastate,function,table). The oocall
function verifies the function and the table (eventually) OOBit and

a) if OOBit is true on both, the function will make the call adding
the table value as the self parameter.

b) if OOBit is false on both, the function will make a normal call.

c) In other cases the function could return or generate errors like
"calling a non method" or "requires an ootable". The actual behavior
could be defined set by the OO layer or could be a language design
decision.

5. The  oocall must be called on default implementation of __call
event and can be called on user's implementation of __call event if
the programmer is implementing a OO extension.

6. Create additional  functions, like ooget() to retreive OOBit state
of a value. I think it´s better not create a ooreset().

7. Optionally, Lua could generate an error if detects a attempt to
make a direct call (not a object call)  to a function with OOBit
enabled: 'You cannot direct call a method'.


Notes:

* As I´m newbie in Lua implementation I'm still investigating the
lowest cost strategy to implement the steps 4 and 5. I may change the
whole strategy.

* As a collateral effect, two "virtual/invisible" types are created:
OOTABLE (table with OOBit) and METHOD (a function with OOBit).

* In strict sense, it´s not necessary to have OOBit enabled on tables
to correct usage of oocall(), but it seems nice to have a low level
OOTABLE mark.

* The legacy usage of colon should be maintained. This will require a
special attention of programmer to don´t mix OOBit objects with legacy
colon. A mechanism to avoid double self could be developed, if
possible.

* Another indirect effect is the implementation of a infrastructure to
handle unused bits in type field. These bits could be use to store
other runtime data.


That´s the idea.

-- 
Nilson