Autogenerated attribute accessor names

3 views
Skip to first unread message

Stevan Little

unread,
Jul 5, 2005, 5:26:31 PM7/5/05
to perl6-l...@perl.org
Hello,

As I am building the metamodel, I had a question, I did not find anything specifically in
the docs regarding this.

What should I do when I encounter two attributes which can peacefully co-exist as
attributes, but cause a class when we autogenerate the accessors for them. Here is a
quick example:

class Foo {
has @.bar;
has $.bar;
}

Should $.bar win out because it is defined last? Or would @.bar win because it would
create the accessor first, then when an attempt to create the accessor for $.bar is made,
it will see an entry for bar() already in the class, and so not generate one (as that is the
default behavior when a user-created bar() is made)?

Should we enforce something along the lines of method conflict in roles? So that any
conflicts for autogenerated accessor methods will result in neither of them being
generated and therefore force the user to disambiguate manually?

On some level this might be able to be handled with MMD, and call context detection,
but I think that might actually make things far more confusing than they actually need
to be, but that is just MHO. Especially since it would create difficulties when something
like this is encountered.

class Foo {
has @.bar;
has $.bar;

# the autogenerated mutli method accessors
# multi method bar(Array @value) returns Array;
# multi method bar(Scalar $value) returns Scalar;

method bar () {...}
}

Unless of course we use Yuval's "everything is a MMD under the hood" idea. But that is
another thread entirely.

Thanks,

Stevan


Larry Wall

unread,
Jul 5, 2005, 9:08:32 PM7/5/05
to perl6-l...@perl.org
On Tue, Jul 05, 2005 at 05:26:31PM -0400, Stevan Little wrote:
: What should I do when I encounter two attributes which can peacefully co-exist as
: attributes, but cause a class when we autogenerate the accessors for them. Here is a
: quick example:
:
: class Foo {
: has @.bar;
: has $.bar;
: }

Probably for now we should do the conservative thing and carp as
soon as we notice it, much like for role method conflicts. We could
relax that later if we find a decent way to disambiguate, but I don't
think there will be great demand for it. In any event, as with role
conflicts, if they write their own method, it overrides both of them
anyway and they can figure it out them own selves. If we pretend
attribute declarations are anonymous role declarations, they might
turn out to be just that, especially if we decide it's a useful conceit.

Larry

Stevan Little

unread,
Jul 5, 2005, 9:56:41 PM7/5/05
to Larry Wall, perl6-l...@perl.org
Larry,

On Jul 5, 2005, at 9:08 PM, Larry Wall wrote:
> If we pretend attribute declarations are anonymous role declarations,
> they might
> turn out to be just that, especially if we decide it's a useful
> conceit.

This exact thing occurred to me as I was sitting in traffic on the way
back from $work. I think it probably makes the most sense to do it this
way. We can always change it later if it proves to be too restrictive.

Steve

Reply all
Reply to author
Forward
0 new messages