Logbot (>):
> [S12] spec setting and getting values of attributes by means of introspection
>
> After lengthy IRC discussion, we concluded that it's a good idea to provide
> some form of introspection that doesn't bother about perceived privacy
> borders, provided that the implementation makes it feasible.
Below I summarize this email thread, the discussion on IRC, and my
thoughts so far.
I make no claims whatsoever to be objective; my aim is to help
understand enough about the issues to help build a good Perl 6.
== About introspection of attributes
I fully understand Damian's (and others') objections, especially since
I used to represent them.
Let me offer a metaphor. There's "normal OO" and "meta-level OO".
Normal OO can be likened to a labyrinth with walls higher than the
humans walking around in them. The walls are restrictions such as
"this attribute is private", offering reminders not to break the rules
of normal OO programming. They are good.
Meta-level OO is like going up in one of the towers conveniently
placed by a corner of the labyrinth. Going up one level eliminates the
walls. (Introspection does this, and serialization to a stream of
bytes does this. Probably other things as well.) From above, you can
see into objects, not through the walls but between them. The
normal-OO restrictions doesn't apply to you any more, because you've
made a *conscious choice* no longer to be restrained by them.
>From this point of view, we already have a word corresponding to
C<MONKEY_TYPING> but for getting through the restrictions put up by
the OO system. It's called C<.HOW>.
I thus find myself in favor of C<.get_value> and C<.set_value>. My
nagging doubts are gone; these two methods don't break any rules,
because they are located at a level where those rules don't apply.
== About C<.perl>
The choice here was between letting C<.perl> display only public
attributes, or keeping it the way it is, displaying public as well as
private attributes. The former is potentially a great help for
debugging; the latter respects the normal-OO level of privacy.
I don't have a horse in this race, and I see sensible arguments on both sides.
== About C<.new>
This method (along with .clone) is problematic because it allows
outsiders to set private attributes in objects. This may sound
innocent, but consider an object that works very hard to maintain an
invariant or other between its private attributes. The default C<.new>
and C<.clone> methods allow any outsider to completely rupture the
invariant in the new object.
I suppose the author of the class could override the constructor
methods to provide "safe" ones, but why should she have to?
The whole current situation seems problematic to me. But I also see
problems looming if we decide to "tighten up" C<.new> and C<.clone>
too much; for one thing because C<.new> and C<.clone> are currently
the only non-C<.HOW> way to set a readonly private attribute:
$ perl6 -e 'class A { has $!x is readonly; method x { $!x } }; say
A.new(x => 42).x'
42
In the end, I suppose it comes down to deciding how much we dislike
that C<.new> and C<.clone> break encapsulation. We like to champion
them as "just normal methods", but as long as they need to use C<.HOW>
introspection to do magic behind the scenes, they aren't really very
normal or innocent, IMO.
// Carl
