Front page | perl.perl6.language |
Postings from June 2001
Embrace polymorphic builtins, for they are cool.
Thread Next
From:
David L. Nicol
Date:
June 11, 2001 19:22
Subject:
Embrace polymorphic builtins, for they are cool.
Message ID:
3B257BE6.A1F71D51@kasey.umkc.edu
Coming to Perl 5 from a C++ background, I was greatly
disappointed, while writing a persistent object base
class and consulting my new, flat-lying Blue Camel (Second
edition, this was 1996), that the following kind of thing
did not do what I wanted:
sub argle($){
print "One argle: $_[0]\n";
}
sub argle($$){
print "Two argles: <$_[0]>,<$_[1]>\n";
}
sub argle($$$@){
print join('>,<',
"Many argles: <$_[0]",
@_[1..($#_-1)],
"$_[$#_]>\n"
);
}
It turned out, on inspection, that the prototyping mechanism
was for syntactic ease -- leave out the occasional sigil -- and
occasional error checking -- rather than for multiple dispatch, as
it is in C++. If you want multiple dispatch, you need to either
write a prototype that will accept all possible valid arguments, then
select from them after the named function has been called, or
somehow wrap your data modeling around some sort of interface object
which can have the appropriate package methods associated with it,
which really doesn't gain you much:
{
#LoggingObjects automatically subclass based on argument number:
my $LoggingObject = new LoggingObject qw/argle bargle whoosh/;
$LoggingObject->Print();# Correct one/two/many distinction!
}
Therefore, last year, when the perl 6 community suggestion period was
announced, I made sure to write a RFC describing a type-based
multiple dispatch mechanism.
But I'm digressing. What I want to talk about is overloaded builtins.
I recently suggested that C<close> be overloaded to make its argument,
when its argument is not a filehandle, become read-only. An objection
was made to this, on the grounds that homonymous operators are confusing,
with eval block and eval string being given as an example of something
that is confusing.
This post is intended to be a response to that objection.
Natural language contains many homonyms. This is rarely, outside of
dramatic plots, a problem, as there are other indicators, up to and
including requests for clarification, but generally "context," to
guide us human beings as we apply our common sense to the great
questions of What Is Fair and What Is Right without taking wrong turns
or digressing into discussions of propagandistic trends in modern
journalism while dividing chocolate cake evenly among party guests.
Okay?
C<eval> (string/block) is but one. C<require> (file name / version number)
is
another. C<do> might be considered another. There is discussion of
overloading
C<length(@)> to do what beginners expect.
Those are the only ones we have right now. I am sure that the people
reading
this are about evenly divided between thinking "Basta, no mas!" and
agreeing
with what I am about to say.
Just as Websters has multiple entries for some words, with completely
different meanings, it is all right for a programming language to have
different meanings. Commonly used function names vary between different
programs, for instance.
I believe that multiple dispatch based on argument type is an important
feature of a general purpose programming language. With this in mind,
what better way to introduce the concept to the beginning programmer than
to have built-ins that do multiple dispatch based on argument type?
close (IO) # closes an open stream, returns
# true on success or false on failure,
# sets $! on failure
close (\$) # overwrites the ASSIGN method of the
# referenced object or container with
# a placeholder that inherits from
# C<warn>; returns a CODEREF that will
# cause, on run, the referent's ASSIGN
# method to be returned to the current
# method, or undef on failure. Sets
# $! on failure, to, for instance,
# "$_[0]->NAME already read-only"
Multiple dispatch based on argument type, gentlemen. C++ has it, and
C++ programmers miss it when writing in other languages. Few other
languages
dare to include argument types into the symbolic identifiers for their
code entry points.
In the land of More Than One Way, it is surprising that this important
way -- the mechanism behind, for example, the double-angle-bracket C++
streams library output syntax -- early-binding multiple dispatch based
on known argument type -- is missing.
--
David Nicol 816.235.1187
Signature closed for repaving
Thread Next
-
Embrace polymorphic builtins, for they are cool.
by David L. Nicol