[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: RES: RES: RES: RES: idea of vision of blueprint of ROADMAP of Lua core
- From: Chris Pressey <cpressey@...>
- Date: Mon, 17 Jan 2005 18:42:31 -0800
On Mon, 17 Jan 2005 20:18:50 -0300
André de Leiradella <email@example.com> wrote:
> >>> 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.
Sorry - when I said "ActionListeners" I meant "classes that programmers
typically create to implement the ActionListener interface". I was
mistaken about there being a default method, yes (I may have been
confusing them with Adapters, as PA noted.)
At any rate, the class that one writes that implements ActionListener
doesn't have to implement anything besides actionPerformed, and for
conceptual integrity of the design, probably shouldn't. So it still
ends up being a "closure in object's clothing".
> Andre de Leiradella