On 30/09/2010 10:49, Damian Conway wrote:
As long as C<.perl>  works the way it does, there can be no real
Sigh. That is indeed badly broken. Surely it ought to default to C<die>,
and require class architects to override .perl explicitly if they wish to
break encapsulation.

I see/use .perl as a debugging aid. When debugging, I tend to want to see what is *really* there, including its private bits, since those may well hold the key to the bug. I'd say .perl is currently optimized for debugging, but of course anything that helps from that angle is open to being (ab)used for encapsulation breaking too. And maybe that's not what .perl should be optimized for.

And thus C<.get_value>  and C<.set_value>  are just convenient
access points for the same behaviour.
Yes. People are going to shoot themselves in the foot anyway,
so let's legalize semi-automatic weapons as well.

If we don't provide some way then I suspect folks will either start parsing the result from .perl (or whatever the debuggy-dumper is called), and/or pretty quickly a CPAN module (or several) will appear that do some low-level, per-implementation trickery to break the encapsulation.

I'd agree we don't want to make encapsulation breaking so convenient that folks just mindlessly, effortlessly do it. I'm all for finding ways to declare up front that evil is happening. But I think trying to make it outright impossible may backfire and lead to there being multiple different ways to behave badly rather than one standard, easy to spot one.

Plus, we probably do need *some* way for folks to write serializers in standard Perl 6.

I'm still undecided on whether or not I think C<use MONKEY_TYPING;>  is
the right way to enable this kind of privacy breakage. Maybe nothing
is needed, since the C<^>  in C<$obj.^attributes>  (or the C<HOW>)
already says "warning! meta!".
Except that, if the Attribute object is passed around, it may be saying
"warning! meta!" in a completely different scope, in a completely
different file.

Sounds like the encapsulation breaking thingy probably wants to be looking for some pragma to have been used in the lexical scope of the caller, maybe. I'd rather that we called it something other than MONKEY_TYPING though. Different evil, different pragma. :-)



Reply via email to