[EMAIL PROTECTED] writes:
: On 4/15/02 5:16 PM, Damian Conway wrote:
: > if we don't support this, people will be forever having to create Perl 6
: > adapter classes just so that they can make use of legacy Perl 5 code. :-(
:
: Okay, how about making it a pragma that's not enabled by default? So all
: those Perl 5 porters can do their mechanical transformation of ->{} to .{}
: and then add a "no strict hashmethods;" (or something) to the top of the
: file? Leaving auto-method-call-on-{} in Perl 6 enabled by default seems
: like a tacit endorsement of that style (albeit a purely visual distinction
: in Perl 6, but why even endorse that?)
:
: (stage 2: bargaining ;)
Heh. Well. The main point of doing this isn't really the migration
from Perl 5, but a basic underlying philosophy of linguistics known as
tagmemics. The grammars of natural language are a convenient cultural
fiction, but within a particular context, you can often violate the
official grammatical and lexical rules in order to communicate. A
common manifestation of this in English is the "verbing" of nouns.
Just because something is officially a noun in English doesn't mean it
can't *function* as a verb. (In computer science this concept tends to
show up more under the term "polymorphism", but it's a similar idea.)
More violent examples are easy to come up with. For instance, you can
use an entire sentence as an adjective:
I don't like your I-can-use-anything-as-an-adjective attitude.
The point is, natural languages aren't terribly picky about what you
poke into a particular grammatical slot as long as it makes sense.
So the main reason that objects can function as hashes is so that the
user can poke an object into an interface expecting a hash and have it
"make sense", to the extent that the object is willing to be viewed like
that. And the default operator:{} method will let the user access the
existing accessors as if they were keys in a hash. And maybe even use
keys() on the object to get a list of available accessor method names.
If you don't want your objects used this way, it'd be trivial to
override the operator:{} method.
As for avoiding it via a pragma, I'd consider that error prone.
Suppose you call an interface that is defined to return a hash. The
module writer could decide to upgrade the interface to return an object
pretending to be a hash, and your code would break if it had already
decided on its own that only hashes can behave like hashes.
Larry
