Carl (>):
> == 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
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 f
On Thu, 30 Sep 2010 23:40:39 +0200, Jonathan Worthington wrote:
> Plus, we probably do need *some* way for folks to write serializers in
> standard Perl 6.
^ This.
I faced precisely this problem when trying to write persistent inside-out
classes with Class::Std. There was no way to break encaps
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/1/10 00:31 , Brandon S Allbery KF8NH wrote:
> As for serializeability, I think .perl is being used for two different
> things and we need to separate them. If it's there for debugging, you want
Addendum, since as I reread my message it looks a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/30/10 16:46 , Moritz Lenz wrote:
> 1) please don't abuse MONKEY_TYPING for anything that might look like
> dangerous
If Perl 6 is still Perl then in some sense it implies that "dangerous" is
accepted practice. :) That said...
> 2) I find .perl
On Thu, 30 Sep 2010, Damian Conway wrote:
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.
Well, of course! What are you, a soci
On Fri, 1 Oct 2010, Damian Conway wrote:
Jonathan wrote:
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 evi
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
Jonathan wrote:
> 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. :-)
As long as
On 30/09/2010 10:49, Damian Conway wrote:
As long as C<.perl> works the way it does, there can be no real
privacy.
Sigh. That is indeed badly broken. Surely it ought to default to C,
and require class architects to override .perl explicitly if they wish to
break encapsulation.
I see/use .perl
Moritz writes:
>> 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.
>
> method perl {
>die "Can't serialize objects of type $?CLASS, because ...";
> }
Sure. But now the cautious programmer has to add that to *every* cl
Darren Duncan wrote:
> 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.
>>
>> rakudo: class X { has $!foo; has $!bar; has $!baz };
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.
rakudo: class X { has $!foo; has $!bar; has $!baz }; say
eval(X.new( foo => 1, bar => 2,
Moritz wrote:
> To re-iterate, Perl 6 has no "real" privacy by default -- both the
> default .new and .perl methods give you access to private attributes,
> unless you explicitly override them.
At least you *can* explicitly override them (and perhaps factor that out
into a role that you could alw
Carl wrote:
> For what it's worth, we had exactly this discussion a couple of days
> ago on IRC. I represented your views above, Damian.
Thank-you for that.
> As long as C<.perl> works the way it does, there can be no real
> privacy.
Sigh. That is indeed badly broken. Surely it ought to defaul
Am 30.09.2010 10:32, schrieb Carl Mäsak:
Moritz in the spec (>>), Damian (>):
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.
Wow, tha
Moritz in the spec (>>), Damian (>):
>> 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.
>
> Wow, that's the first time I've ever been
On 30 September 2010 06:09, Moritz wrote:
> 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.
Wow, that's the first time I've ever bee
Branch: refs/heads/master
Home: http://github.com/perl6/specs
Commit: 58fe2d8c12892ab2cb661b4477fcd75f0bef67f4
http://github.com/perl6/specs/commit/58fe2d8c12892ab2cb661b4477fcd75f0bef67f4
Author: Moritz Lenz
Date: 2010-09-29 (Wed, 29 Sep 2010)
Changed paths:
M S12-objects.pod
Log Me
19 matches
Mail list logo
