On Wed, Jul 13, 2005 at 12:51:49PM -0400, Stevan Little wrote:
: Hello,
:
: More questions for the metamodel. I am trying to add proper submethod
: and private method handling and I have a question about method
: resolution order as a whole. I asked a similar question last week, but
: this time I have more details :)
:
: Given this class:
:
: class Foo {
: submethod bar { ... }
: method bar { ... }
: }
:
: and given this code:
:
: Foo.new().bar()
:
: What should happen?
:
: The Syn/Apoc seem to indicate that methods and submethods of the same
: name can coexist. So the class definition itself is legal. However, it
: brings up an issue when it comes time to call bar().
If the Syn/Apoc is giving that impression, it's giving the wrong impression.
Subs, methods, and anything in between all live in the same namespace.
The class above is illegal because you're trying to give two things
the name &bar in the absence of a "multi".
: Should submethod bar() be called first, then method bar() after it?
: Should method bar() be called first, then submethod bar() after it?
Question doesn't arise.
: Can submethods only be called from within the class (like private
: methods)?
No, they can be called from anywhere. They're just constrained to
work only when a dispatcher's idea of "current class" matches the
actual class, where "current class" usually means the actual class
of the object in question, but can also mean an ancestral class when
we're doing BUILDALL, for instance. There's some kind of "yes I mean
you" notion in the dispatcher. It comes out in user-visible terms
in .*foo calls but not ordinary .foo calls, which call a submethod
only when the object is actually that type, and otherwise look for an
ancestral method of that name.
: And if submethods can only be called from within the class, then how do
: I handle this:
:
: class Foo {
: submethod bar { ... }
: method bar { ... }
: method baz {
: $?SELF.bar()
: }
: }
:
: Foo.new().baz()
Again, illegal class.
: Thanks,
:
: Stevan
:
