[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: RES: RES: RES: idea of vision of blueprint of ROADMAP of Lua core
- From: Chris Pressey <cpressey@...>
- Date: Sun, 16 Jan 2005 11:29:38 -0800
On Sun, 16 Jan 2005 14:07:17 -0300
André de Leiradella <firstname.lastname@example.org> wrote:
> > [Excuse me for jumping in - I'm still new to Lua and far from an
> > expert, but I just wanted to add my two cents here...]
> > The way I've been writing classes, using closures, lets you avoid
> > this.
> I saw it when you posted it to the list. I liked the idea of using
> only '.' to access methods and properties, but then I saw some
> messages about it not being efficient (don't remember the reasons
> though), and it does not solve the call for inherited methods.
Fair enough - efficiency is not one of the main goals of my current
project; clarity is more important.
> > 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.
When I saw the programming model it immediately struck me that something
pathological like that would be a lot more straightforward if the GUI
control just took a closure as one of the arguments to its constructor.
Alas, Java doesn't support function-valued variables, so they have to
resort to subclassing objects to do the equivalent work, AFAICT.
> >> The "blessed" way of doing it would come up from the community just
> >> like the packaging system. OOP in Lua would add very little to the
> >> core and make the language a great choice for many applications
> >that > require it. I'd like to stress this: there is no small
> >scripting > language with OOP, I've been looking to many options and
> >they're all > bloated with modules.
> > Well - I feel similarly, but I'd like to stress that I don't believe
> > there's any such thing as a "truly OO" language; I like the fact
> > that Lua doesn't force a one-size-fits-all OOP structuring on the
> > user, and lets them build their own solution. I would however
> > strongly approve of better mechanisms for writing OO programs in the
> > core language, if they are needed.
> The thing the bothers me most is how to call inherited methods. I
> don't if it would be feasible to make callbacks to operations like
> foo(...), new bar(...), inherited xyz(...) etc., so the OO part of Lua
> could be tuned for almost every taste. This of course will break
> compatibility between two packages that uses different implementations
> for those.
Well, merely from a sort of programmer's-usability standpoint, you ought
to be able to call inherited methods like you call any other method
(since, like, you inherited them, so they "belong to you" now?) The
question is, what gymnastics do you have to do go through when creating
a subclass to achieve this effect?
I don't know. It's quite interesting to play with though :)
> Andre de Leiradella