# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #108670]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=108670 >
<masak> nom: class A { has @.a = 2,3; has $.a = 1 }; say "alive", A.new.a
<p6eval> nom 029140: OUTPUT«alive2 3»
<masak> anyone submit this rakudobug?
<masak> or maybe it was submitted long ago?
* masak submits rakudobug, Justin Case
<masak> niecza: class A { has @.a = 2,3; has $.a = 1 }; say "alive", A.new.a
<p6eval> niecza v13-313-ge748acd: OUTPUT«===SORRY!===Two definitions
of method a (see line 1) [...]
I expect Niecza's behavior here.
<moritz> masak: did you see jnthn++'s explanation in the backlog?
<masak> no. looking.
<moritz> masak: he says it's intentional, and it makes sense to me
Here, for reference, is jnthn's explanation:
<jnthn> Rakudo isn't silently overriding it at all
<jnthn> It checks if such a method was already defined.
<jnthn> And if it was, then doesn't generate an accessor
<jnthn> Since the user may be supplied their own.
<jnthn> Of course, that means that the first accessor is generated,
and the second is not.
<jnthn> perl6: class A { has $.a; method a() { } }
<p6eval> niecza v13-313-ge748acd: OUTPUT«===SORRY!===Two definitions
of method a (see line 1) [...]
<p6eval> ..pugs b927740, rakudo 7006f7: ( no output )
<jnthn> Niecza is wrong on this, given previous discussions.
Yup, agree on that specific point.
<moritz> but if the user wants to supply his own accessor, shouldn't
he use $!a instead?
<jnthn> moritz: No, because then .has_accessor will be false in
attribute introspection
<jnthn> And that'd in turn mean you couldn't set it in .new()
Back to the present.
<masak> now I see jnthn's explanation. it may make sense to you -- I
think the above should be an error.
<masak> because it indicates that the user is confused.
<geekosaur> see my later response to jnthn about it
Oh, ok! Back in time again!
<geekosaur> so really both are partly wrong. seeing that one has been
declared by the user, fine; but double implicits with no manual
declaration should generate at least a warning and probably an error
And again back in the present. Well, it used to be the present, when
this ticket was submitted.
* masak sees it
<moritz> geekosaur: if we want it that way, we have to spec it
<masak> I agree with geekosaur.
<masak> and I say error.
<masak> two different-sigiled public attrs, one in parent and one in
child, are of course fine.
<moritz> should has $!x; has @!x; also error out?
<masak> no.
<moritz> should has $.x; method x() { $!x } error out?
<masak> no.
<TimToady> not according to current spec, but the other way is arguable
<masak> I like the fact that $.x; method x doesn't error out.
<moritz> so, it's ok to not generate one accessor, but it's not ok to
not generate two accessors?
<masak> moritz: yes.
<moritz> that is... confusing.
<masak> moritz: I have a rationale, too.
<geekosaur> no, which was jnthn's case, and my response was that that
is acceptable and correct, it's specifically the case of multiple
implicitly generated accessors that should somehow indicate that there
is a conflict
<geekosaur> (also note that the case of { has $.x; has @.x; method x()
} is also fine)
<masak> hm. yes, that case should be fine, but "don't do that" :)
<masak> moritz: if I add another public attribute with a different
sigil but the same name, I *want to know* that I did, at the earliest
possible moment.
<masak> moritz: not thought a silent logical bug when I run the wrong accessor.
<masak> moritz: if I add a method that overrides an auto-generated
attribute, I'm only happy if I don't have to go in and change the
attribute's twigil from dot to bang, because both I and the compiler
know what I just did.
< masak> that's why it's two different behaviors.
< geekosaur> yes, that, exactly
* masak appends all this to the ticket so that jnthn knows what to fix :)
<moritz> masak: fwiw I think that's something you could fix yourself
if you wanted
<moritz> the attribute generation code is all Perl 6, and quite accessible
<masak> oh right, I'm an implementor!
<masak> (dang!)
* masak includes this in the ticket too so that jnthn can nag him
