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
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.
Oops,
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
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 been
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 sorry not
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,
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 default to
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 always
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 =
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.
masak rakudo: class X { has $!foo; has $!bar; has $!baz }; say
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* class
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 Cdie,
and require class architects to override .perl explicitly if they wish to
break encapsulation.
I see/use
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
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
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
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
-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
-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
18 matches
Mail list logo
