RES: RES: RES: RES: idea of vision of blueprint of ROADMAP of Lua core

[André de Leiradella <leiradella@...>]

>>> Up to now I've accepted this drawback, since I'm not too fond of
>>> inheritance (Java, for example, uses inheritance for many things
>>> which can be done in a much simpler way using closures,) but as I
>>> see
>> 
>> This is new to me, care to give an example?
> 
> ActionListeners, in the GUI model, (it's been a few months so maybe
> I'm misrembering the name.)  They're objects with basically one
> method which reacts to an input event.  The default reaction is
> uninteresting, so they are inevitably subclassed, with that one
> method overridden with what you really want it to do.    
> 

That's not true. ActionListener is an interface that you must implement
in your class when instances of it must respond to button
presses/releases. *If* you want to process those actions, you implement
the interface and by doing that you must write the code of the method
actionPerformed (the only method declared in the interface) that will
handle the events.

The Java GUI model is similar to the Windows API (with it's ugly
WindowProc) and Turbo Pascal 7 (with it's HandleEvent) as it's
event-based, but instead of throwing every event that arrives in the
event queue of the application into one function of your program to
handle, Java separates them in interfaces. Instead of one huge
WindowProc or HandleEvent, many smaller and simpler methods to capture
specific types of events.

Remember that interfaces don't have code, they only declare methods, and
aren't subclassed by your application, but implemented.

I know an interface can be subclassed to construct another interface,
but that's not the point here.

Regards,

Andre de Leiradella