> Luke Palmer wrote:
>
> > Well, if you did that, it surely couldn't be polymorphic, which kind
> > of defeats most of the purpose of making it a method.
>
> I disagree. Consider the "template method" patten. This uses a
> non-polymorphic method in a base class to invoke a set of polymorphic
> methods in a standard sequence. I would consider my "macromethod" in a
> similar vain.
I'm not quite sure I follow you (I'm not familiar with that pattern).
But the macromethod I imagine is the non-polymorphic one, and the one
it expands to is the polymorphic one, if I'm guessing correctly. And
you certianly could do that. But the actual I<parsing> could not be
polymorphic. Thus, this wouldn't work:
my $db = new Database;
$db.select ...
Because the compiler [may] not know that $db is a Database until
runtime, after it's been parsed. However, this could work:
my Database $db = new Database;
$db.select ...
Which may just be the price you have to pay to use C<macromethod>.
But then, the only advantage that I'm seeing to macromethod, other
than the namespace pollution bit, is that it can handle arbitrarily
complex variable names, which macros ought to do anyway. Which means
you usually have to use a parse tree instead of simple string
substitution (I trust Larry to make it sufficiently easy to do that).
So, what I'm essentially saying is that C<macromethod> doesn't buy you
much save syntactic sugar. Perhaps you can give a concrete
counterexample?
Luke
