Re: Why is the predicate method not available for a MooseX::Privacy protected attribute?

It should fail. If the attribute is protected, then it can only be accessed from within the class it was defined in, and from subclasses. Whether to do the same with delegated methods was a design decision made by the MXP authors; there are arguments in both directions, but personally I think they made the right choice. That a method is implemented by delegation is really an implementation detail; code outside the class shouldn't care.

That said, MXP doesn't really give you proper private methods. To do that, you'd need to delve into the MRO, and MXP was not ambitious enough to do that.

use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name

Comment on Re: Why is the predicate method not available for a MooseX::Privacy protected attribute?

Replies are listed 'Best First'.
Re^2: Why is the predicate method not available for a MooseX::Privacy protected attribute? by paulymer (Novice) on Aug 31, 2013 at 22:44 UTC
Thanks for the reply. Everything you said makes sense, but... I say "but" because the user experience with this use case is less than desirable. The inconsistency between the failure of the predicate method and the success of the delegated method doesn't satisfy my left-brain needs. So, there's my two cents for what it's worth. Also, we could easily apply the same argument to the predicate method as was given for the delegated method, e.g. "That a method is implemented by delegation is really an implementation detail; code outside the class shouldn't care." Whether 'hasGameStarted' is implemented as a predicate or a sub shouldn't matter outside the class. If I'm still missing something, I apologize for belaboring the point. Thanks.	[reply]

Replies are listed 'Best First'.

Re^2: Why is the predicate method not available for a MooseX::Privacy protected attribute?
by paulymer (Novice) on Aug 31, 2013 at 22:44 UTC

Thanks for the reply. Everything you said makes sense, but...

I say "but" because the user experience with this use case is less than desirable. The inconsistency between the failure of the predicate method and the success of the delegated method doesn't satisfy my left-brain needs. So, there's my two cents for what it's worth.

Also, we could easily apply the same argument to the predicate method as was given for the delegated method, e.g. "That a method is implemented by delegation is really an implementation detail; code outside the class shouldn't care." Whether 'hasGameStarted' is implemented as a predicate or a sub shouldn't matter outside the class. If I'm still missing something, I apologize for belaboring the point. Thanks.

[reply]