Skip to content
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

Opportunity to catch syntactically detectable calls to attribute-accessing methods on type objects in Rakudo #3768

Open
p6rt opened this issue Apr 1, 2015 · 3 comments
Labels

Comments

@p6rt
Copy link

p6rt commented Apr 1, 2015

Migrated from rt.perl.org#124226 (status was 'open')

Searchable as RT124226$

@p6rt
Copy link
Author

p6rt commented Apr 1, 2015

From @masak

<[Tux]> m​: class C { has Int $!x; method foo { ($!x, my $b) = (1,2);}};C.foo
19​:45 <+camelia> rakudo-moar 6caf1d​: OUTPUT«Cannot look up attributes
in a type object␤ in method foo [...]
<[Tux]> is that explainable?
<masak> you're calling C.foo, the .foo method on the type object C
<masak> the type object doesn't really properly have an $!x
<masak> m​: class C { has Int $!x; method foo { ($!x, my $b) =
(1,2);}}; C.new.foo
<camelia> rakudo-moar 6caf1d​: ( no output )
<masak> that works.
<TimToady> "Cannot look up attributes in a type object" is an
implementor-centric error message, not a user-centric one
<Juerd> TimToady​: "Instance attribute used in non-instance method call"? :)
<masak> TimToady​: actually, that error message could fail statically
in this case.
<masak> since C is already resolved at compile time.
<masak> no need to make it survive until runtime and then fail.
[...]
<masak> no-one else liked the idea of statically erroring out with
"call will never work" for the C.foo case where C is already
statically resolved?
<nine_> masak​: I do
<Juerd> masak​: Could work, but can't methods be marked as instance-only?
<nine_> masak​: the earlier errors are reported the better
<PerlJam> masak​: How does the compiler decide that it will never work? and when?
<Juerd> Because then, any use of $!foo could simply mark the method as
instance-only
<Juerd> And the error message could be simpler.
<Juerd> "Method foo can only be called on an instance of C, not on C itself."
<PerlJam> (compiler hints)++ if we can reasonably have them.
<PerlJam> I guess, if you declare the sig right, all the info is easy
to get at. But without that, it seems like a bit of guessing for the
compiler to do it.
<masak> PerlJam​: compiler sees the call C.foo, and has already set a
flag that the foo method in class C accesses an attribute. boom.
* masak submits rakudobug
<Juerd> "Method foo can only be called on an instance of C, not on C
itself, because C.foo accesses instance attribute $!x."
<masak> neat. +1
<PerlJam> masak​: flagging methods like that seems like quite a bit of
bookkeeping for marginal benefit.
<masak> really? seems worth it to me...
<masak> it's a small hash somewhere in the compiler.
<masak> %accattr<C.foo> = True;
<Juerd> It could be a boolean flag (instance-only) and an array of
further explanations
<[Coke]> masak​: I think you mean a compile-time static check, not a
static static check. ;)
<masak> [Coke]​: yes. thank you. I meant... that, what you said.

@p6rt
Copy link
Author

p6rt commented Dec 3, 2017

From @AlexDaniel

Still reproducible (2017.11,HEAD(e5b660e))

On 2015-04-01 13​:19​:33, masak wrote​:

<[Tux]> m​: class C { has Int $!x; method foo { ($!x, my $b) =
(1,2);}};C.foo
19​:45 <+camelia> rakudo-moar 6caf1d​: OUTPUT«Cannot look up attributes
in a type object␤ in method foo [...]
<[Tux]> is that explainable?
<masak> you're calling C.foo, the .foo method on the type object C
<masak> the type object doesn't really properly have an $!x
<masak> m​: class C { has Int $!x; method foo { ($!x, my $b) =
(1,2);}}; C.new.foo
<camelia> rakudo-moar 6caf1d​: ( no output )
<masak> that works.
<TimToady> "Cannot look up attributes in a type object" is an
implementor-centric error message, not a user-centric one
<Juerd> TimToady​: "Instance attribute used in non-instance method
call"? :)
<masak> TimToady​: actually, that error message could fail statically
in this case.
<masak> since C is already resolved at compile time.
<masak> no need to make it survive until runtime and then fail.
[...]
<masak> no-one else liked the idea of statically erroring out with
"call will never work" for the C.foo case where C is already
statically resolved?
<nine_> masak​: I do
<Juerd> masak​: Could work, but can't methods be marked as instance-
only?
<nine_> masak​: the earlier errors are reported the better
<PerlJam> masak​: How does the compiler decide that it will never work?
and when?
<Juerd> Because then, any use of $!foo could simply mark the method as
instance-only
<Juerd> And the error message could be simpler.
<Juerd> "Method foo can only be called on an instance of C, not on C
itself."
<PerlJam> (compiler hints)++ if we can reasonably have them.
<PerlJam> I guess, if you declare the sig right, all the info is easy
to get at. But without that, it seems like a bit of guessing for the
compiler to do it.
<masak> PerlJam​: compiler sees the call C.foo, and has already set a
flag that the foo method in class C accesses an attribute. boom.
* masak submits rakudobug
<Juerd> "Method foo can only be called on an instance of C, not on C
itself, because C.foo accesses instance attribute $!x."
<masak> neat. +1
<PerlJam> masak​: flagging methods like that seems like quite a bit of
bookkeeping for marginal benefit.
<masak> really? seems worth it to me...
<masak> it's a small hash somewhere in the compiler.
<masak> %accattr<C.foo> = True;
<Juerd> It could be a boolean flag (instance-only) and an array of
further explanations
<[Coke]> masak​: I think you mean a compile-time static check, not a
static static check. ;)
<masak> [Coke]​: yes. thank you. I meant... that, what you said.

@p6rt
Copy link
Author

p6rt commented Dec 3, 2017

The RT System itself - Status changed from 'new' to 'open'

@p6rt p6rt added the Bug label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant