Re: RFC 244 (v1) Method calls should not suffer from the action on a distance
On Mon, Sep 25, 2000 at 09:10:49PM -0700, Nathan Wiger wrote:
if ( want-{count} 2 ) { return $one, $two }
Will that be interpreted as:
'want'-{count}
want()-{count}
To be consistent, it should mean the first one. That is, the infix
operator - should always autoquote the bareword to the left. Am I
correct in assuming that's what you meant?
Yes. Use want()-{count} instead. Or, better,
use want;
wantCount;
Ilya
Re: RFC 244 (v1) Method calls should not suffer from the action on a distance
Currently,
foo-bar($baz)
can be parsed either as C'foo'-bar($baz), or as Cfoo()-bar($baz)
depending on how the symbol Cfoo was used on other places. The proposal
is to always choose the first meaning: make C - autoquote the bareword
on the left.
Here is a question: How does this relate to getting hashrefs and
arrayrefs from functions?
if ( want-{count} 2 ) { return $one, $two }
Will that be interpreted as:
'want'-{count}
want()-{count}
To be consistent, it should mean the first one. That is, the infix
operator - should always autoquote the bareword to the left. Am I
correct in assuming that's what you meant?
-Nate
Re: RFC 244 (v1) Method calls should not suffer from the action on a distance
== Please show me how to write: print STDERR @stuff; without it, while keeping it a method of the STDERR filehandle, and without requiring -. == Why not use -? $IO::STDERR-print @stuff; print $IO::STDERR @stuff; == This would cause about 80% of Nathan's RFCs to die screaming, since they nearly all rely on indirect object syntax. == This is why I stole my time from other things to write this RFC. Additional remark: There is no conflict (I know of) in the method $var @args; syntax. Given that some people may consider this syntax to be cleaner than $var-method @args; (beats me why), it may be desirable to keep it. Ilya
Re: RFC 244 (v1) Method calls should not suffer from the action on a distance
Ilya Zakharevich wrote: Why not use -? $IO::STDERR-print @stuff; print $IO::STDERR @stuff; Ok, something here is extreme confused. Is not the second form an instance of indirect object syntax? == This would cause about 80% of Nathan's RFCs to die screaming, since they nearly all rely on indirect object syntax. == This is why I stole my time from other things to write this RFC. Please explain what you mean. -Nate
Re: RFC 244 (v1) Method calls should not suffer from the action on a distance
On Tue, Sep 19, 2000 at 04:26:47PM -0700, Nathan Wiger wrote: $IO::STDERR-print @stuff; print $IO::STDERR @stuff; Ok, something here is extreme confused. Is not the second form an instance of indirect object syntax? It is not with a bareword at the second place, so is not causing the action on the distance. (There are some other problems with this, such as having two frequently used constructs disambiguated by a hard-to-notice comma.) As I mentioned in the message you are answering to, there may be argument both pro and contra having IO syntax with variables stay, why IO syntax with barewords go. == This would cause about 80% of Nathan's RFCs to die screaming, since they nearly all rely on indirect object syntax. == This is why I stole my time from other things to write this RFC. Please explain what you mean. I browsed through the database, and saw that a lot of proposals rely on the syntax which should better go. Ilya
Re: RFC 244 (v1) Method calls should not suffer from the action on a distance
Ilya Zakharevich wrote: On Tue, Sep 19, 2000 at 04:26:47PM -0700, Nathan Wiger wrote: $IO::STDERR-print @stuff; print $IO::STDERR @stuff; Ok, something here is extreme confused. Is not the second form an instance of indirect object syntax? It is not with a bareword at the second place, so is not causing the action on the distance. (There are some other problems with this, such as having two frequently used constructs disambiguated by a hard-to-notice comma.) Ok, you should clarify this. You're not suggesting that indirect object syntax be removed. You're suggesting that it should not accept barewords. These are two separate things. Again, I think your RFC is far too terse and needs clarification. Make sure that you provide for telling people that this: $q = new CGI; needs to now be written as this: $q = CGI-new; in all cases. -Nate
Re: RFC 244 (v1) Method calls should not suffer from the action on a distance
On Tue, Sep 19, 2000 at 04:52:12PM -0700, Nathan Wiger wrote: Ok, you should clarify this. You're not suggesting that indirect object syntax be removed. You're suggesting that it should not accept barewords. These are two separate things. Agreed. I realized the ambiguity only after I posted it. Again, I think your RFC is far too terse and needs clarification. Make sure that you provide for telling people that this: $q = new CGI; needs to now be written as this: $q = CGI-new; in all cases. Thanks. Ilya
Re: RFC 244 (v1) Method calls should not suffer from the action on a distance
'foo'-bar($baz) looks visually clattered, but Cfoo()-bar($baz) looks as if it expresses its meaning. The default choice is done so that if you need other choice, your code does not look artificial. Hear, hear! foo-bar($baz, $coon) should be made synonymous with foo-bar $baz, $coon I can see no ambiguity in this call, but it not always works with Perl5. But [proposal:] Method calls should respect prototypes just like normal subs. So that if bar is prototyped as bar($$), then the call is parsed as foo-bar($baz), $coon -- John Porter We're building the house of the future together.
Re: RFC 244 (v1) Method calls should not suffer from the action on a distance
foo-bar($baz, $coon) should be made synonymous with foo-bar $baz, $coon I can see no ambiguity in this call, but it not always works with Perl5. Arrow invocation does not a listop make. Only indirect object invocation style does that. print STDOUT $foo, $bar, $glarch; is a list op. STDOUT-print $foo, $bar, $glarch; is not, and, in fact, is a syntax error. You *must* use parens for the arrow invocation's arguments. You *may* use them with I/O style. --tom
Re: RFC 244 (v1) Method calls should not suffer from the action on a distance
On Sat, Sep 16, 2000 at 08:08:06AM -, Perl6 RFC Librarian wrote: There only way to avoid the action at a distance is to prohibit one of these interpretations. Since the other way Cfoo-bar $baz to write this method call is as convenient as the indirect object syntax, the proposal is to prohibit the indirect object method calls altogether. This would cause about 80% of Nathan's RFCs to die screaming, since they nearly all rely on indirect object syntax. Not that I'd mind seeing it buried (indirect object syntax, not Nathan's RFCs) but you should enumerate the RFCs you're conflicting with. PS Shouldn't this be on perl6-language-objects? -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Cheating is often more efficient. - Seven of Nine
Re: RFC 244 (v1) Method calls should not suffer from the action on a distance
This RFC proposes to remove indirect object syntax Please show me how to write: print STDERR @stuff; without it, while keeping it a method of the STDERR filehandle, and without requiring -. -Nate
RFC 244 (v1) Method calls should not suffer from the action on a distance
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Method calls should not suffer from the action on a distance =head1 VERSION Maintainer: Ilya Zakharevich [EMAIL PROTECTED] Date: 15 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 244 Version: 1 Status: Developing =head1 ABSTRACT This RFC proposes to remove indirect object syntax, and modify the semantic of the C - operator. =head1 DESCRIPTION =head2 - Currently, foo-bar($baz) can be parsed either as C'foo'-bar($baz), or as Cfoo()-bar($baz) depending on how the symbol Cfoo was used on other places. The proposal is to always choose the first meaning: make C - autoquote the bareword on the left. This interpretation is more desirable on esthetical ground, since 'foo'-bar($baz) looks visually clattered, but Cfoo()-bar($baz) looks as if it expresses its meaning. The default choice is done so that if you need other choice, your code does not look artificial. =head2 Parentheses foo-bar($baz, $coon) should be made synonymous with foo-bar $baz, $coon I can see no ambiguity in this call, but it not always works with Perl5. =head2 Indirect object syntax Currently, bar foo $baz can be parsed either as C'foo'-bar($baz), or as Cbar(foo($baz)), depending on how the symbols Cfoo and Cbar were used on other places. There only way to avoid the action at a distance is to prohibit one of these interpretations. Since the other way Cfoo-bar $baz to write this method call is as convenient as the indirect object syntax, the proposal is to prohibit the indirect object method calls altogether. Make the above syntax be interpreted as Cbar(foo($baz)). =head1 MIGRATION ISSUES Translate Perl5 code as specified above. =head1 IMPLEMENTATION Remove the DWIM logic from the parser. =head1 REFERENCES None.
