http://qs321.pair.com?node_id=777873


in reply to How to write a Mixin without Exporter mess?

I could call frobnerize($self, ...) instead, but I'd like to use the object syntax for various reasons.

Paraphrasing the next paragraph: And you'd like to make object syntax not work for "everyone else".

It isn't particularly hard to come up with ways to make object syntax for a specific method to only work for some callers (I hope that restating your goals to make how they conflict with each other much clearer also makes the potential solutions much easier to see). And all of those ways suck.

Most of them don't even fix the real problem with breaking encapsulation. That is, you don't want your mix-in to break if it is used by a class that has its own frobnerize() method. So the real conflict in your goals boils down to:

For various reasons, you want $self->frobnerize(...) when written in your code to call your frobnerize(). But, for sound design reasons, you want other instances of $self->frobnerize(...) to call some other method or fail if no such other method exists.

Meanwhile, frobnerize($self,...) solves all of the important problems except the ones that you couldn't bring yourself to admit in public. (:

Just FYI, I'd like to get a pony for various reasons. And I don't want anybody else to be able to get a pony. ;)

BTW, if $self->Mixin::frobnerize(...) is too unwieldy for you (especially since the name of your mix-in is surely much longer than "Mixin"), you could use a code ref and $self->$frobnerize(...) with a simple my $frobnerize= \&frobnerize;. I also suspect that this may violate some of your "various reasons".

Note that I rejected my $frobnerize= sub { ... }; as then stack traces would report calls to such as being to __ANON__ instead of being to Mixin::frobnerize, and I consider that difference important since troubleshooting is too time-consuming compared to coding already.

- tye