On Wed, Feb 08, 2006 at 08:49:54PM +0100, Leopold Toetsch wrote:
> I'm still having troubles, when thinking about namespace PMCs and
> implementation thereof. Especially the relationship of class namespaces
> and the store_global opcode.
As well you might. :-, There's a chicken/egg problem in there.
The summary of my response is that, though there is a namespace named 'Foo',
and there is a class named 'Foo', they are not the same object, and the
implied 1:1 relationship is not guaranteed to hold in all cases.
The summary of the summary is: class has-a namespace.
Here's the longer version:
1. The default implementation of find_method should use the typed namespace
interface on the associated namespace, since that will be the most common
case (counting by PMC types). In pseudo-C++:
class PMC {
public:
...
virtual PMC *namespace()
{ return _namespace; }
virtual PMC *find_method(STRING meth)
{ return this->namespace()->find_sub(meth); }
private:
PMC *_namespace;
}
2. Some PMCs may not have have namespaces, even if they have methods.
I expect that some PMCs (including 'namespace' itself, though that's not
a critical point) will not use full namespace PMCs to store and look up
their methods. Such PMCs will return null when queried for their
namespace, but can still respond properly to find_method and, in some
cases, even to add_method and delete_method.
(I say "in some cases" because may not even use hashes for method lookup.
For example, I can imagine a "find_method" implementation that checks for
a few hard-coded names and returns corresponding subroutine addresses.
It's a bit of a hack, but it's permissible. On the other hand, if it's
not permissible in the long term, I won't cry. It is an ugly hack.)
3. Some namespaces may be used by multiple PMCs. Maybe.
I'm a little vague on this point, but I can imagine that sometimes there
will be a need to create new classes that have no unique characteristics
except their type. Empty derivations, essentially. In such cases, it
would be advantageous not to have to create a new namespace for the
derived class unless/until the derived class actually makes a change to
the namespace with add_method/delete_method. Think of it as COW for
derived class namespaces.
Now, having said all this, I know I haven't given you an implementation.
But I have, I hoped, clarified what the implemementation must/should do.
So, what implementation you can imagine would meet these needs?
--
Chip Salzenberg <[EMAIL PROTECTED]>
