[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: RES: RES: RES: idea of vision of blueprint of ROADMAP of Lua core
- From: André de Leiradella <leiradella@...>
- Date: Sun, 16 Jan 2005 14:07:17 -0300
> [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.
> 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?
>> 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.
Regards,
Andre de Leiradella