1. Re: None
Michael Nelson wrote:
> An example of my point is the function
> getMethodID() in classes.e (IF I understand
> your code correctly): this creates a method
> and makes it available to all classes.
Almost. It allocates a spot in every classes' method table for that method.
So if some class declares a method called "foo", a spot for a method called
"foo" is allocated in each class table at the same position.
Allocating space is not the same as declaring the method, however. If a
class tries to use a method without formally declaring it, you get a
"calling undefined method" error.
Why do this? It's actually a speed optimization. One of the reasons I've
been loath to work with a class system is the overhead associated with
resolving method and local names - tons and tons of calls to find() start
adding up.
By assigning the same slot in all the classes for a given method name -
whether or not the class actually declares that method - I can use the same
index to get the method, no matter what class I am dealing with. The only
place that this is really used is in wrappers.e. But once the library is
settled down, I plan on declaring *all* the method names as constants, and
replacing the strings with constants.
Llama lets you have it both ways - you can either use an index, or a string
in most method and local variable calls:
my( "color" )
my( color_ )
and
proc( self, "foo", {} )
proc( self, foo_, {} )
both have the same behavior, but there's more overhead with the string
lookup. I don't know how significant the overhead of the find is, but I'll
do some benchmarks at some point. If it turns out that it doesn't really add
that much overhead, then I'll get rid of getMethodID and deal with pure
strings.
-- David Cuny
