Moritz Lenz wrote:
Darren Duncan wrote:
I think then that .perl needs to be updated so it is more expressly limited and
only works on some objects rather than on all of them.
The way I see it, .perl is mainly about representing *value* objects in a
serialized form, and what it should produce is a value expression whose
execution results in an object which would eqv the original.
Are you using "value object" in the same sense as in the Perl 6
specification?
I'm essentially thinking in terms of the Perl 6 specified "value types" but I
was actually being a little more general so to also include container objects
whose current values could change over time; hence I used "eqv" rather than
"==="; I didn't want the .perl to be more restrictive than necessary.
<snip>
Bottom line, if .perl isn't supposed to work on 100% of objects then we should
fix .perl so it doesn't break encapsulation.
+1. The question is: how?
My proposal: the default .perl method should only spit out value for
public attributes, ie those that have accessors. Maybe .new should also
default to his behavior.
I agree with this proposal, and would be happy for it like Damian. It would
mean the langauge has a good, safe, default behavior, which does what people
expect most of the time or is otherwise simple for users to understand and
should be simple to implement. And individual classes can write their own
.perl/etc when their public API is different from the corresponding internals.
Or maybe so that we can have our cake and eat it too, there should be two .perl
where the first is more restricted like I say and the second just dumps the
private attributes, and the second can only be used with MONKEY PATCHING.
1) please don't abuse MONKEY_TYPING for anything that might look like
dangerous
Fair enough. In this case I was just echoing Damian's comment. The main idea
was that any language built-in which exposes the otherwise private internals of
an object should be only be accessible when the user explicitly enables access
in a way that states they know what they're doing, such as by enabling a pragma.
2) I find .perl very, very valuable in real world debugging; I don't
want to make it its usage any harder.
So I suggest we utilize a debugging pragma that enables dumping an object's
actual internals; people only get that by explicitly activating the pragma; this
pragma could also implicitly be enabled by someone using a debugger. The
dumping routine would not be called .perl but rather something else ...
internals_perl() perhaps?
-- Darren Duncan
