Re: Re[2]: Still cryptic OOP syntax

[David Olofson <david@...>]

On Monday 31 January 2005 03.44, skaller wrote:
> On Mon, 2005-01-31 at 13:20, David Olofson wrote:
> 
> > > This would simplify the core, slow down processing due
> > > to the indirection, and make things extensible,
> > > since you can replace the 'add' function.
> > 
> > Dunno if it would slow things down all that much, actually... 
Calls 
> > through function pointers are slightly slower, but switches and 
other 
> > conditionals aren't exactly free either. 
> 
> Sure but I actually meant the bytecode should call a *Lua* function
> not a C one.
> 
> I.e. it should treat
> 
>  a + b
> 
> just the same way it treads
> 
>  add (a,b)
> 
> right now. The standard library would predefine 'add'
> to work just the same as 'a + b' does right now..

Well, that would just be an implementation detail. At least, EEL calls 
C and EEL functions the same way, and that could be extended to work 
for operators as well. One would just have two pointers for each 
operator "hook"; one C function pointer that may point directly to a 
native implementation, and one pointer to a bytecode function object.

To install a bytecode operator, on would just set the bytecode 
function pointer to it, and then point the C function pointer to a 
function that performs a VM call instead of actually performing an 
operation. No performance penalty for native implementations!


> However since lookup in Lua is dynamic .. you could replace it
> at run time :)

That works with a raw array of function pointers as well. ;-)


//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
|  Free/Open Source audio engine for games and multimedia.  |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---