[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