Re: Re[2]: Still cryptic OOP syntax

[skaller <skaller@...>]

On Mon, 2005-01-31 at 02:59, David Olofson wrote:
> On Sunday 30 January 2005 14.19, skaller wrote:
> [...]
> > It would actually be cleaner to get rid of operators
> > from the core completely. Functions are good enough.
> > Just call the 'add' function listed in the table
> > for operator '+'. Or operator '*' ... or any operator.
> 
> Well... I just reworked the operator subsystem of EEL (a language 
> rather similar to Lua in many ways; http://eel.olofson.net ) - and I 
> realized it's not quite that simple. :-)
> 
> In theory, you could just construct a multidimensional array of 
> operator calls; [all_types][all_operations][all_types]. 

Felix can do that (but it uses static typing and overload
resolution).

However the idea would not be to replace the existing
type dispatch mechanism, just encapulate it in a *single*
function eg: to add two things toegether call 'add' function.
Just one function for all types.

That function would have to do the 'try doubles, if not
try metamethods' that  the bytecode interpreter does right now.

This would simplify the core, slow down processing due
to the indirection, and make things extensible,
since you can replace the 'add' function.

The add function itself could also be designed to
be extensible, for example using a multi-dimensional
array as you suggest, would allow adding new
addition submethods without changing the actual add
function.

Anyhow the initial goal is not to change existing Lua semantics,
rather to leave any extensions/modifications up to the client.

> I did 
> something similar for the simple types (integer, reals, booleans; 
> anything that doesn't carry an object reference) in the form of a 
> large single level switch that decodes values combined from the 
> operator and the operand types. Fast and simple, and yet makes it 
> trivial to implement things like "Pascal style divison" (integer / 
> integer ==> real, rather than integer).
> 
> The problems gather when you get to operations on objects...

Of course. It's impossible. This is the covariance
problem I referred to in another post.

YOu need n^2 routines for n types, which doesn't fit
into the n methods OO allows... this kills OO as a
programming methodology with a one line argument.

Time to move on.. :)

> The second major problem with operations on objects is when doing 
> things like
> 
>  v = 1 / v;
> 
> Now what? 

You need a method

	div: float * vector -> vector

so look it up in the table, if you can't find it
give a runtime error, otherwise apply it.


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net