New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
func Class->method should resolve to func( Class->method ) #8874
Comments
From @schwernCreated by @schwern sub foo { 23 } 'Can't locate object method "foo" via package "Foo"' Perl is trying to resolve that as Foo->foo->bar. However. sub foo { 23 } 'Can't locate object method "bar" via package "Foo"' Perl is trying to resolve that as foo( Foo->bar ). The resolution Perl can do a better job resolving that ambiguity. It could look Perl Info
|
From gerard@tty.nlOn Wed, Apr 18, 2007 at 09:34:22AM -0700, Michael G Schwern wrote:
What I remember from removing indirect object syntax for kurila, is that Your solution only solves the problem for the -> operator, but that I agree that the ambiguity is very bad. It can lead to very nasty bugs But giving a warning when doing 'foo Foo->bar' doesn't sound bad, on Gerard Goossen ps. indirect object syntax also depends on whether foo is already |
The RT System itself - Status changed from 'new' to 'open' |
From @maukeCreated by @maukeLet's create a dog and wash it: % perl -MO=Deparse -e '{package Dog} sub wash {}' -e 'wash Dog->new;' Wait, that's not what I meant! Maybe like this? % perl -MO=Deparse -e '{package Dog} sub wash {}' -e 'wash Dog::->new;' No, same problem. Hmm ... % perl -MO=Deparse -e '{package Dog} sub wash {}' -e 'wash ::Dog->new;' OK, that at least parses the sub call correctly. But: % perl -e '{package Dog} sub wash {}' -e 'wash ::Dog->new;' Looks like '::Dog' doesn't work as 'Dog'. Finally: % perl -MO=Deparse -e '{package Dog} sub wash {}' -e 'wash +Dog->new;' This is what I wanted all along. I think the indirect object heuristic is too trigger-happy and should be dialed In fact, I'd be glad to see indirect object syntax simply go away completely [1] Perl Info
|
From @epavia RT <l.mai <at> web.de> writes:
I think 'new' should be special-cased too. -- |
The RT System itself - Status changed from 'new' to 'open' |
From c.nehren/p5p@shadowcat.co.ukOn Tue, Aug 07, 2012 at 14:18:11 +0000 , Ed Avis wrote:
Please no. This only exacerbates the problem of indirect object syntax -- |
From @LeontOn Tue, Aug 7, 2012 at 4:47 PM, l.mai@web.de <perlbug-followup@perl.org> wrote:
You're forgetting this scenario: «new Foo->bar». I'd expect this to be
Everybody likes to hate indirect object syntax. I never use it, and Leon |
From @LeontOn Tue, Aug 7, 2012 at 5:21 PM, Chris Nehren
+1 |
From @epaI wanted to make the point that if you intend to get rid of dative syntax, If that's not an option, I would prefer to keep the indirect object syntax rather -- |
From c.nehren/p5p@shadowcat.co.ukOn Tue, Aug 07, 2012 at 15:10:14 +0000 , Ed Avis wrote:
I'm not sure I understand how adding a special case simplifies the -- |
From @xdgOn Tue, Aug 7, 2012 at 9:47 AM, l.mai@web.de <perlbug-followup@perl.org> wrote:
+1 My preference: indirect object syntax (except for built-in special -- David |
From @AbigailOn Tue, Aug 07, 2012 at 03:10:14PM +0000, Ed Avis wrote:
Perl already has a constructor, it's special cased (as in, it's a keyword), Abigail |
From @AbigailOn Tue, Aug 07, 2012 at 06:47:50AM -0700, l.mai@web.de wrote:
Is this indirect object heuristic, or bare word heuristics? $ perl -MO=Deparse -e '{package Dog} sub wash {} wash "Dog" -> new' If you don't want to get bitten by Perl having to guess what you mean, Abigail |
From zefram@fysh.orgTinkering with the rules for indirect object syntax would be foolish. Any change to the ambiguity resolution in the absence of new pragmata If we were to introduce a new pragma, that could invoke a different The only pragma here that would be worth introducing would be one that I think the new pragma should be a "feature" subpragma. I'm in two I'm also not sure whether "print {$fh} $stuff" should count as indirect If there are no objections, I'd like to go ahead with implementing some -zefram |
From @cpansproutOn Tue, 14 Nov 2017 05:47:21 -0800, zefram@fysh.org wrote:
Likewise, SUPER::foo{@_} is the only syntax that will produce the optree that it produces. That is a very useful feature, which I use frequently, despite the fact that its documentation was deleted when perlobj was rewritten. -- Father Chrysostomos |
From @schwernOn Tue, 14 Nov 2017 05:47:21 -0800, zefram@fysh.org wrote:
Yes. I concur. Wholeheartedly and with no reservations. Give us a pragma to turn off indirect object syntax.
There is already indirect.pm which is used as `no indirect`. I'd say make `indirect` a feature, on by default, and turn it off with `no feature "indirect"`. I'm sure I can think of a few more existing features I'd like to have pragmas to turn off.
My inclination is to deal with special cases like `print` and `open` separately. They're their own hairballs. But I haven't given it much thought. |
From @SmylersFather Chrysostomos via RT writes:
What's it do? I couldn't find any instances of it on Cpan: It looks like using braces to denote the invocant, so would be my $object = do { @_ }; but that sets $object to the number of elements in @_ ... so I can't be
Are you referring to 7168b25, ‘Lots of revisions from Damian for move {$obj->{FIELD}}; being equivalent to: $obj->{FIELD}->move(); Is there any reason not to restore mention of this syntax to the Smylers |
From zefram@fysh.orgSmylers wrote:
It puts the elements of @_ on the stack, uses the first of them as the -zefram |
Migrated from rt.perl.org#42603 (status was 'open')
Searchable as RT42603$
The text was updated successfully, but these errors were encountered: