This whole thing is actually a deep and complicated imbroglio--as I know
you, Damian, are aware. I don't know your ideas for untangling it.
To review for others, if one is to require
$fh->print("blah")
or
$STDOUT->print("blah")
or
STDOUT->print("blah")
then people will truly balk. But if one does not, then
one is hit with severely distressing syntactic ambiguity.
Is
print $x;
really
CORE::print($x)
or is it really
$x->print()
Moreover, *when* is this decision made? If it isn't made until
runtime, as with Python, then this seems slow. But it can't be
made at compile time in the general case, for in the general case,
you don't know (and provably cannot know) whether what $x will at
run contain will be a valid invocant for a print method. Or any
other method.
If we homogenize builtins with user-defineds, both on "methods" and
functions, then we may achieve a clean and simple approach that by
that simplicity yields significant power and flexibility. Look at
how Python's equivalent of a safe module works for how lovely this
can become.
However, it seems that to do this, a few things will have to change,
including the unary operator problem with functions and the intent
to compile-time resolve symbol lookups, which always happens with
non-indirect function calls. This does seem expensive.
It might suffice to change the syntax to *require* parens on all
function calls (much as use strict requires quotes on all strings),
which will/could clear up the problem of:
sub give {}
give $dog;
give $dog $chow;
But I fear people will freak if they have to parenthesize
absobloodylutely everything and their dog.
(The new Camel's OO chapter has some more details on this and related
annoyances. It turns out that even Classname->method() is unsafe,
for if there's a sub Classname in (package) scope, that becomes
Classname()->method(). That's why we have Classname::->method(),
but the galloping catenation of four successive nonalphabetics makes
even those of little taste go "Yuck".)
Then again, starting down that road might well hold other treasures:
I would bet that completely dispensing with precedence would solve
the incessant and infernally subtle problems virtually everyone
always has with Perl's multitudinous levels of precedence. :-)
--tom
