Carl Mäsak wrote:
To summarize, I consider myself having lost that debate. I even demonstrate the complete unviability of my views (that privacy has any kind of footing in Perl 6) with the below one-liner.<masak> rakudo: class X { has $!foo; has $!bar; has $!baz }; say eval(X.new( foo => 1, bar => 2, baz => 3).perl.subst("X.new(", "\{ ").subst(/\)$/, " }")).perl <p6eval> rakudo 8156be: OUTPUT«{"foo" => 1, "bar" => 2, "baz" => 3}» As long as C<.perl> works the way it does, there can be no real privacy. And thus C<.get_value> and C<.set_value> are just convenient access points for the same behaviour.
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.
It should be possible to provide all the information to construct said object with a single constructor/new() call, and such a new() call is what .perl should be producing.
Such as in this context, private attributes are about letting the class designer have arbitrary differences between the public possible representation and internal actual representation of an object and the class knows how to map them; moreover, it should have enough knowledge to make this a 2-way mapping. (Maybe the type system needs more metadata for that to be automatic? Maybe not?)
Also, some private attributes are redundant and don't need to be separately turned into source code, such as if they are a cache or something.
The .perl should just use a class' mechanism for producing a complete set of new() arguments and produce code for that.
Objects that you can't do that with don't make sense to be serialized and so .perl can reasonably refuse to work on them.
I don't think anyone can argue that every object of every class can reasonably be serialized with .perl and so it should only try where it makes sense. Now if .perl is also savvy enough to take a reference to a subroutine and can produce the source code for said subroutine, I'd have a bit less of a case.
Bottom line, if .perl isn't supposed to work on 100% of objects then we should fix .perl so it doesn't break encapsulation.
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.
Then Damian's position (which I support) is supported and so are monkeys. -- Darren Duncan
