Larry Wall <[EMAIL PROTECTED]> writes: > Mark-Jason Dominus writes: > : It may turn out that the new notation really does have exactly the > : same ambiguities, but that's not clear to me now. All I said was that > : I would like to see some discussion of it. > > Operator vs term processing would presumably treat any initial / as it > does now (in the absence of mandatory m//), so that's not a problem as > far as I can see. But for linguistic reasons I don't think putting the > regex in front of the variable is a good idea. I already regret putting > the class as the second argument of bless. But 'bless $obj => Class' reads very nicely as 'bless $obj into Class'. -- Piers
- Re: RFC 138 (v1) Eliminate =~ operator. Steve Fink
- Re: RFC 138 (v1) Eliminate =~ operator. Nathan Wiger
- Re: RFC 138 (v1) Eliminate =~ operator. Nathan Torkington
- Re: RFC 138 (v1) Eliminate =~ operator. Nathan Wiger
- Re: RFC 138 (v1) Eliminate =~ operator... Nathan Torkington
- Re: RFC 138 (v1) Eliminate =~ ope... Tom Christiansen
- Re: RFC 138 (v1) Eliminate =~ ope... Nathan Torkington
- Re: RFC 138 (v1) Eliminate =~ ope... Nathan Wiger
- Re: RFC 138 (v1) Eliminate =~ operator. Mark-Jason Dominus
- Re: RFC 138 (v1) Eliminate =~ operator. Larry Wall
- Re: RFC 138 (v1) Eliminate =~ operator. Piers Cawley
- Re: RFC 138 (v1) Eliminate =~ operator. Tom Christiansen
- working mnemonic for =~ David L. Nicol