Re: Stupid Newbie Question
John == John Rudd [EMAIL PROTECTED] writes: John 1) Methods are always public John 2) Variables are always private (and in this case that means that other John instances may not view the instance variables of an object; I don't John recall whether the class can see the ivars of its instances but I'm John pretty sure it can't). No, an instance owns its ivars, so nobody touches it. However, the class for an instance can define a new method which of course acts within the instance. And there's always the system primitives used by the debugger (and for other reflection), with names like instVarAt: and instVarAt:put:. Anybody can send them! -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Stupid Newbie Question
From: Michael G Schwern [EMAIL PROTECTED]
On Thu, Nov 15, 2001 at 05:49:34PM -0800, John Rudd wrote:
That way you could choose to impliment Smalltalk or C++ style
protections (public, private, protected, etc)
Last I checked Smalltalk had no privacy protection.
So, for Smalltalk type semantics, if $foo != $bar, the
request will throw some sort of exeption indicating that $foo isn't
allowed to see $bar's instance variables. But, if $foo == $bar, then
the actual value will be found and returned.
... Smalltalk? not allowed? You sure about that? Or is this
something you hacked together with doesNotExist?
Smalltalk doesn't give you any privacy options, but it does dictate a
certain degree of privacy. Smalltalk is big on information hiding as
part of the whole OOP is an extension of Abstract Data Typing concept.
1) Methods are always public
2) Variables are always private (and in this case that means that other
instances may not view the instance variables of an object; I don't
recall whether the class can see the ivars of its instances but I'm
pretty sure it can't).
So, the only way for an outside entity see an object's ivar is if you
define an accessor method for it. If you don't define that method,
then outside entities can't see it at all.
(this is completely contrary to the mindset expressed in one of the perl
books about if you didn't want people to directly access the ivar via
$obj-{stuff}, then you should have given them an accessor method for
getting at the data ... this contradicts anything I've ever come across
wrt OOP, where information hiding is the norm and where if you aren't
given an accessor method, then you have no business with (and hopefully no
ability for) direct access to the ivar. In Smalltalk, the rampant creation
of accessor methods without reguard to whether the information ought to
be available to the public, or an attempt to violate the abstract data
typing of the object by an outside programmer, would be considered bad
programming style. Yet, the statement from the perl book in question
seems to embrace this bad programmign style so strongly as to blame the
class implimentor for not catering to the violating outside programmer.)
(note: I'm not meaning to say perl got it wrong or the mindset of
that author was wrong, just that it's directly the opposite of any
OO mindset I had seen before I learned perl OO-isms ... and I'm merely
musing about whether or not auto(vivify|glob) will allow me to build
up such a stronger sense of information hiding.)
Re: caller()
As I said in my previous message, knowing the package isn't really enough.
In order to support strong information hiding, you need to know not just
the package of the calling object, but the actual identity of the calling
object. Consider:
package A;
sub foo {
my $self = shift;
my $bar = shift;
$bar-blah();
}
package B;
sub blah {
my $self = shift;
my ($z);
$z = caller();
if ($z == $self) { # not technically correct, but semantically what
# I'm talking about
# same object, let it do stuff
}
else {
# not the same object, complain
}
}
sub blarg {
my $self = shift;
my $target = shift;
$target-blah();
}
package main;
$a = A-new();
$b = B-new();
$c = A-new();
# and, we have some $d, and we don't know if it was created via:
# $d = B-new();
# or
# $d = $b;
$a-foo($b); # statement 1
$c-foo($b); # statement 2
$d-blarg($b); # statement 3
Ok, in the 3 statements you've got 3 different things that eventually get
to B::blah(). $z wont be any different for statement 1 or statement 2
because caller() only tells us the package, not the identity. Even if you
were to depend upon the fact that $z wont be equal to B, this only helps
you in the first 2 statements. In statement 3, this doesn't help you at
all, because all caller() tells you is that they're of the same package,
not whether they were the same object.
All perl actually allows me to do for the incorrect if-confidtion above is:
if ($self-isa($z)) {
which isn't good enough for what I'm talking about. If $d and $b are
seperate instances, then the corrected if-condition wont differentiate
between them. This wont help you with strong information hiding.
For what I was asking, caller would have to return something equal to $a
for statement 1, $c for statement 2, and $d for statement 3. Then my
original if-condidition works and allows you to build up something for
strong information hiding.
Re: Stupid Newbie Question
Damian Conway wrote:
Schwern explained:
Going away? No way, it's SPREADING! We might wind up with AUTOGLOB, too.
http://dev.perl.org/rfc/324.pod
Though it won't be called AUTOGLOB (globs *are* going away),
and its semantics might be closer to those portrayed in:
http://www.yetanother.org/damian/Perl5+i/autovivify.html
Damian
I've been turning these two items over in my head for the last few days,
and wondering about the feasability of adding something to their
arguments:
some indication of who invoked the request.
So, for example, lets say I have an object $foo, which is an instance of
Class A. In one method, foo tries to access an instance variable of
$bar, an instance of Class B (not inherited from Class A). If $bar's
instance variables are somehow hidden, I could then have the Class B
auto(vivify|glob) routine perform checks on the identity and heritage of
$foo, and then decide what to do about the request.
That way you could choose to impliment Smalltalk or C++ style
protections (public, private, protected, etc) in the same way that I'm
using AUTOLOAD to impliment Smalltalk/Objective-C style instance/class
seperations. So, for Smalltalk type semantics, if $foo != $bar, the
request will throw some sort of exeption indicating that $foo isn't
allowed to see $bar's instance variables. But, if $foo == $bar, then
the actual value will be found and returned.
The question in my brain, since I don't know perl's internals in very
much detail, is how hard is it to figure out who the caller was? It's
not just a matter of knowing what package the invoking subroutine
belonged to, because instances of the same class might have have access
to eachother's instance variables (ala Smalltalk). It further
complicates things if you want to extend it to include C++ style
friend functions (I don't, but others might).
Oh, and, how does autovivify work wrt to class/package variables? I
mean, with an instance, you access instance variables via $foo-{blah}
and this will look for some scalar value, so I assume that the first
argument will be a reference to a scalar, and the second value will be
something like $foo-{blah}. What if, instead, I did
Class-{blah}? With AUTOLOAD I can tell the difference between class
and instance methods by asking if the first argument was a reference or
not. If it was, then it was an instance, if not, then it's a
class/package. How will that be handled here?
(yes, I know you can emulate class variables via package globals like
$Class::blah, but I'm trying to look at it in a more uniform point of
view so that you can fully treat Classes themselves as being objects)
--
John kzin Rudd http://people.ucsc.edu/~jrudd
Truth decays into beauty, while beauty soon becomes merely charm. Charm
ends up as strangeness, and even that doesn't last. (Physics of Quarks)
-= Kein Mitleid Fu:r MicroSoft (www.kmfms.com) ==-
Re: Stupid Newbie Question
On Thu, Nov 15, 2001 at 05:49:34PM -0800, John Rudd wrote:
So, for example, lets say I have an object $foo, which is an instance of
Class A. In one method, foo tries to access an instance variable of
$bar, an instance of Class B (not inherited from Class A).
This is a naughty thing to do. $bar should have a set of accessor
methods if you're really worried. Read on.
If $bar's instance variables are somehow hidden
Looks like the whole an object is just a hash reference paradigm
might be mutating some to allow better data hiding. There was a big
thread on perl6-language about this just recently.
I could then have the Class B auto(vivify|glob) routine perform
checks on the identity and heritage of $foo, and then decide what to
do about the request.
There's a whole host of modules that make writing accessors cheap,
Class::Accessor and Class::Struct for example. Once you're inside an
accessor method you can do whatever access checking you like.
If I'm reading the tea leaves correctly, Perl 6 will address this sort
of thing with some variation on slots. So you can declare for *this*
list of instance variables, make me some simple accessors. So
C$foo-bar = 'this' == C$foo-{bar} = 'this'. So rather than
using AUTOVIVIFIY you'd use slots and accessor methods.
In theory, these slots should be closer to the speed of a regular
hash than accessor methods currently are in perl5.
That way you could choose to impliment Smalltalk or C++ style
protections (public, private, protected, etc)
Last I checked Smalltalk had no privacy protection.
So, for Smalltalk type semantics, if $foo != $bar, the
request will throw some sort of exeption indicating that $foo isn't
allowed to see $bar's instance variables. But, if $foo == $bar, then
the actual value will be found and returned.
Smalltalk? not allowed? You sure about that? Or is this
something you hacked together with doesNotExist?
The question in my brain, since I don't know perl's internals in very
much detail, is how hard is it to figure out who the caller was?
caller(). Or is something more involved?
It's not just a matter of knowing what package the invoking
subroutine belonged to, because instances of the same class might
have have access to eachother's instance variables (ala Smalltalk).
It further complicates things if you want to extend it to include
C++ style friend functions (I don't, but others might).
die Sorry, private method unless caller eq ref $self;
die Sorry, protected method unless caller-isa(ref $self);
die Sorry, you're not my friend
unless exists $self-{_my_friends}{caller()};
That about covers basic method privacy.
(yes, I know you can emulate class variables via package globals like
$Class::blah, but I'm trying to look at it in a more uniform point of
view so that you can fully treat Classes themselves as being objects)
Class::Data::Inheritable anyone? :)
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
You killed my fish?
Why does that pickle you?
http://sluggy.com/d/010204.html
Re: Stupid Newbie Question
Dan Sugalski [EMAIL PROTECTED] writes:
At 04:21 PM 11/8/2001 -0800, John Rudd wrote:
So, does this mean my other heart's desire of operator overloading might
be coming forth? (I know, I know, here I am, a smalltalker, asking for
operator overloading ... but, what are the smalltalkers gonna do, take
away my membership card?)
What, you mean being able to override the + function for a variable,
complete with method dispatch depending on the types of the variables
on both sides of the +?
Yup ;)
Um, you do realise you don't need multi dispatch to do operator
overloading don't you?
package Foo;
use overload
'+' = my_add,
...
;
sub my_add {
my $self = shift;
my $target = shift;
$target-add_Foo($self);
}
...
And we can do that today. 'cept it's something of a PITA because
'real' numbers don't respond to object methods.
Every so often I find myself thinking 'I should implement something
that automagically turns all numbers and strings into objects', but
there's always something more important to do.
--
Piers
It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
-- Jane Austen?
Re: Stupid Newbie Question
At 06:48 AM 11/9/2001 +, Piers Cawley wrote: Dan Sugalski [EMAIL PROTECTED] writes: At 04:21 PM 11/8/2001 -0800, John Rudd wrote: So, does this mean my other heart's desire of operator overloading might be coming forth? (I know, I know, here I am, a smalltalker, asking for operator overloading ... but, what are the smalltalkers gonna do, take away my membership card?) What, you mean being able to override the + function for a variable, complete with method dispatch depending on the types of the variables on both sides of the +? Yup ;) Um, you do realise you don't need multi dispatch to do operator overloading don't you? Of course. You don't *need* it, but it does make things nicer. Every so often I find myself thinking 'I should implement something that automagically turns all numbers and strings into objects', but there's always something more important to do. The multimethod dispatch'll take care of that, I think. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Stupid Newbie Question
On Thu, Nov 08, 2001 at 03:56:59PM -0800, John Rudd wrote: So, I'm reading various things about lots of changes for perl6, and some arcane things going away, and stuff like that.. and I suddenly wondered if one of my favorite features of Perl Objects (the one that keeps me from migrating to tcl or python, cuz I can never find clear information about whether such an analog exists in those languages) is going away: AUTOLOAD. Going away? No way, it's SPREADING! We might wind up with AUTOGLOB, too. http://dev.perl.org/rfc/324.pod -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One List context isn't dangerous. Misquoting Gibson is dangerous. -- Ziggy
Re: Stupid Newbie Question
Michael G Schwern wrote: On Thu, Nov 08, 2001 at 03:56:59PM -0800, John Rudd wrote: So, I'm reading various things about lots of changes for perl6, and some arcane things going away, and stuff like that.. and I suddenly wondered if one of my favorite features of Perl Objects (the one that keeps me from migrating to tcl or python, cuz I can never find clear information about whether such an analog exists in those languages) is going away: AUTOLOAD. Going away? No way, it's SPREADING! We might wind up with AUTOGLOB, too. http://dev.perl.org/rfc/324.pod Oh, now, quit that ... you're making me drool all over my keyboard! (though, I sorta kinda do prefer the AUTOHASH, AUTOARRAY, AUTOSCALAR ... approach mentioned there to one unified AUTOGLOB ... but it's really just a matter of druthers and style, isn't it?) So, does this mean my other heart's desire of operator overloading might be coming forth? (I know, I know, here I am, a smalltalker, asking for operator overloading ... but, what are the smalltalkers gonna do, take away my membership card?) It would, on some levels, seem to be required that you'll have the ability to have operator methods for objects if you go down the all things returned are objects path, in order to support mathematical objects like numerical scalars. And, that sort of implies some amount of ability to overload them. Though, not necessarily, as smalltalk would imply the same thing and none of the versions I've used allow it. (though, there were some older versions ... ) But, still ... I'd kinda like to see it. -- John kzin Rudd http://people.ucsc.edu/~jrudd Truth decays into beauty, while beauty soon becomes merely charm. Charm ends up as strangeness, and even that doesn't last. (Physics of Quarks) -= Kein Mitleid Fu:r MicroSoft (www.kmfms.com) ==-
Re: Stupid Newbie Question
At 04:21 PM 11/8/2001 -0800, John Rudd wrote: So, does this mean my other heart's desire of operator overloading might be coming forth? (I know, I know, here I am, a smalltalker, asking for operator overloading ... but, what are the smalltalkers gonna do, take away my membership card?) What, you mean being able to override the + function for a variable, complete with method dispatch depending on the types of the variables on both sides of the +? Yup ;) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Stupid Newbie Question
On Thu, Nov 08, 2001 at 04:21:57PM -0800, John Rudd wrote: So, does this mean my other heart's desire of operator overloading might be coming forth? Yeah, that was mentioned in Apoc and Exewhatever 3. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One We're talkin' to you, weaselnuts. http://www.goats.com/archive/000831.html
