[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: upvalues and polymorphism
- From: David Jeske <jeske@...>
- Date: Fri, 15 May 1998 11:29:10 -0700
On Fri, May 15, 1998 at 01:10:49AM -0300, Dan Marks wrote:
> I hate to stray more toward the Python crowd, but
> I couldn't help noticing that upvalues seem like
> a way to introduce object-oriented like programming
> capability into lua. So the question is, why not
> then make it so one is able to define functions that
> are called differently depending on the tag of the
> first parameter.
Lua already has OO like programming capability which is very much like
what you are talking about here, in fact, better.
> For example, I could define
> myclass = newclass() -- really would be a "newtag"
> myclass = newclass(oldclass) -- same as newtag() except all
> -- methods would be copied from the old class.
> e = myclass(5,4,6) -- would call constructor method for myclass
> -- with parameters 5,4,6
> then I could define a function like
> function myclass:mymethod(a,b,c)
> local x,y,z
> To be invoked as e.mymethod(5,6,7)
If you look through some of the online papers about Lua, there is already
a prototype based behavior inheritence system which acts just like this.
except the involking occurs as:
In fact, in lua that is just a shortcut for:
and "function myclass:mymethod(a,b,c)" is just a shortcut for:
myclass.mymethod = mymethod;
mymethod_temp = nil;
> You could even have constructors/destructors like
> function myclass
> local x,y,z
> or function ~myclass
> (called during garbage collection)
Is there a tag method for garbage collection? If so, you can already do
this. (i.e. setup the tag method for a table to call it's internal
> Perhaps I am missing the point on how upvalues should
> be used, but it seems to me that invoking methods by
> data type is a very common occurrence in most languages,
> and lua is an excellent candidate to have good polymorphism.
> Tags and classes are already almost analogous, and maybe
> there is a simple way to make this work. I guess
> "automatic upvalues" would be like inheritance, and would
> facilitate calling subclassed methods, etc.
I think the bigger question to ask is why table operations and tag methods
are different. Namely, why isn't syntax execution defined as a table
access, and thus all values would be tables.
For example, "foo(1,2,3)" would trigger the evaluator:
whereas "foo" would trigger the evaluator:
and "foo = bar" would trigger the evaluator:
Perhaps this isn't a good idea, or dosn't buy us much. However, if the
idea were to unify everything under some concept, I would far sooner think
the general concept of tables would unify everything, than the
> I don't want to turn lua in to a scripted C++ but lua
> would be a very powerful and compact object-oriented
> language. I think lua's strength is its simplicity so
> if these types of features could be added without language
> bloat that would be a great thing.
I'll just reiterate that I have a prototype based inheritence system in
use in a project right now. It works just like the "parent" inheritence
example in one of the Lua papers. You can construct objects, and they
inherit behavior. It works just like you are talking about here.
If I was going to add something to Lua, I'd spend my time trying to do
some sort of table lookup cache, as currently using multiple levels of
tables for orginization (either as classes, or just as heirarchy) costs.
In fact, for this specific reason, I'd like to see the "lookup" VM codes
dereference a complete table lookup, instead of just one slot. It would be
much more efficient to come up with a cache method for:
than it is to optimize:
Am I wrong in assuming that table lookup is somewhat costly in lua?
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + firstname.lastname@example.org