Re: Safer OO inheritance

[Bart Lateur]

On 07 Aug 2000 13:57:14 +0200, Jean-Louis Leroy wrote:

>Bart Lateur <[EMAIL PROTECTED]> writes:
>
>> The problem is that you can't safely subclass a class, without examining
>> it's source, just to make sure that your instance fields don't clash
>> with any private fields of the mother class.
>
>Well...let's think twice. What has the reputatin of being a bug or a
>shortcoming in Perl is actually a feature in CLOS.

>Thus, regardless of the issue about field inheritance, I believe that
>"you can't safely subclass a class, without examining it's source" (or
>its documentation, which should spell out the existence and purpose of
>each field).

Until you want to have multiple inheritance, where the (private?) fields
of both mother classes share some common names. So you can't combine
them, no matter how well-informed you are.

What will you say then? "Sorry, it's impossible"?

-- 
Bart.

Re: Safer OO inheritance

[Bennett Todd]

2000-08-07-19:22:59 Michael Fowler:
> Is $CURRENT_PACKAGE any different, value-wise, than __PACKAGE__?

I'm guessing no, unless I've misunderstood something from the
preceeding discussion.

> Is there a reason to prefer it?

I suppose some folks who want to do a truly stunningly huge amount
of this stuff might want to get an variable they can slightly more
easily interpolate, and don't want to just

my $CURRENT_PACKAGE = __PACKAGE__;

right after the "package" declaration. But you'd really have to be
doing a _huge_ amount to pay for the extra
documentation/implementation complexity.

> I understand it can be interpolated, making it easier to use
> within a string, but weigh that against adding yet another special
> variable, for a value that's already available otherwise.

and if you don't want to do a gigantic amount of it, stuff like

bless { "@{[__PACKAGE__]}stuff" => 0, ... }, $self;

isn't too bad.

-Bennett

 PGP signature

Re: Safer OO inheritance

[Michael Fowler]

On Mon, Aug 07, 2000 at 01:57:14PM +0200, Jean-Louis Leroy wrote:
> package Foo;
> 
> sub new
> {
> bless { "${CURRENT_PACKAGE}name" => 'Simpson' ...
> }
> 
> ...where $CURRENT_PACKAGE is a special variable automatically set
> to...guess what? ;-)

Is $CURRENT_PACKAGE any different, value-wise, than __PACKAGE__?  Is there a
reason to prefer it?  I understand it can be interpolated, making it easier
to use within a string, but weigh that against adding yet another special
variable, for a value that's already available otherwise.


Michael
--
Administrator  www.shoebox.net
Programmer, System Administrator   www.gallanttech.com
--

Re: Safer OO inheritance

[Michael Fowler]

On Tue, Aug 08, 2000 at 06:22:03AM +1000, Damian Conway wrote:
>> I'm more in favor of a mechanism that makes it easy to build field
>> names from the package name, for those rare cases where you want
>> scoped fields.

[snip]

> See the Tie::Securehash module for a variation on this theme.
> Also note that I will be proposing something similar in my
> general revamp of Perl OO (RFCs galore, probably next week).

Which is exactly what I thought of when I saw the original message.  If
tying is sped up, Tie::SecureHash could become far more viable for
production code.


Michael
--
Administrator  www.shoebox.net
Programmer, System Administrator   www.gallanttech.com
--

Re: Safer OO inheritance

[Damian Conway]

   > I'm more in favor of a mechanism that makes it easy to build field
   > names from the package name, for those rare cases where you want
   > scoped fields. There were discussions about this a couple of years ago
   > on p5p. For example:
   > 
   > package Foo;
   > 
   > sub new { bless { "${CURRENT_PACKAGE}name" => 'Simpson' ... }
   > 
   > ...where $CURRENT_PACKAGE is a special variable automatically set
   > to...guess what? ;-)

See the Tie::Securehash module for a variation on this theme.
Also note that I will be proposing something similar in my
general revamp of Perl OO (RFCs galore, probably next week).

Damian

Re: Safer OO inheritance

[Jean-Louis Leroy]

Bart Lateur <[EMAIL PROTECTED]> writes:

> The problem is that you can't safely subclass a class, without examining
> it's source, just to make sure that your instance fields don't clash
> with any private fields of the mother class.

Well...let's think twice. What has the reputatin of being a bug or a
shortcoming in Perl is actually a feature in CLOS.

In the C++ View of the World you should be able to derive from a class
without examining the bases - especially the indirect bases. I thought
it made sense for years.

Until I realized that the 'miraculous reuse by accident' is a complete
lure. Which did a lot of harm to the reputation of OO. I now believe
that reuse is the consequence of ad-hoc design and cooperation between
the involved classes, that it has to be planned for and that it has a
cost - typically two or three times the cost of a non-reusable
design. Someone even said that the word 'reuse' made it look too
simple and suggested using the word 'polybloodyhardreuse' instead 

Thus, regardless of the issue about field inheritance, I believe that
"you can't safely subclass a class, without examining it's source" (or
its documentation, which should spell out the existence and purpose of
each field).

Also, consider what happens in presence of multiple inheritance,
particularly in the 'mixin' style. Typically you want to share a
single base sub-object even if a class is inherited more than once
(iow you want what C++ calls 'virtual inheritance'). Currently, in
Perl you get that by default. If you introduce scoped fields (by
default), you'll also have to introduce two kinds of inheritance:
shared and repeated.

I'm more in favor of a mechanism that makes it easy to build field
names from the package name, for those rare cases where you want
scoped fields. There were discussions about this a couple of years ago
on p5p. For example:

package Foo;

sub new
{
bless { "${CURRENT_PACKAGE}name" => 'Simpson' ...
}

...where $CURRENT_PACKAGE is a special variable automatically set
to...guess what? ;-)

-- 
Jean-Louis Leroy
http://users.skynet.be/jll

Safer OO inheritance

[Bart Lateur]

One of the major problems with Perl's OO, is something I haven't seen
mentioned in these lists, until now. So I'll bring it to your attention
here and now.

The problem is that you can't safely subclass a class, without examining
it's source, just to make sure that your instance fields don't clash
with any private fields of the mother class. We need some mechanism to
keep private fields private.

Just let me point you at a newsgroup post by Abigail who put it pretty
eloquently:

   


   Perl OO violates the basic reason OO exists: implementation hiding. 
  
   And yes, am I aware that after 5+ years we got hacks like %FIELDS,
   base.pm, pseudo-hashes, and Tom and Damian have collected assorted
   tricks in man pages and books. But tricks are nothing more than
   tricks. I still cannot take a random module from CPAN, study no more
   than its interface, subclass it, and be garanteed it works. I would
   still have to study the internals to make sure it works; and if it
   doesn't use a myriad of tricks, but just "normal OO" (that is,
   objects as a hashref), any update of the module could break my
   subclass, even if it isn't changing the interface. 
  
   Perl OO is nothing more than a mockup thrown together to make Perl
   look modern language. It's a facade, making Java look like an
   attractive language. Perl is a toy language, and as long as it has
   this form of OO, it'll remain a toy language.
 
And, in a follow-up post:

I detest Perl OO because it's neither OO, *NOR* Perl.

-- 
Bart.