[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

Re: protected.pm (more Class::Fields)

Since %FIELDS and pseudohashes seem ill-known, I'll walk through
exactly what's going on here, in terms of the existing fields.pm and
base.pm in 5.005_03.  I'll flesh out the example into something
that'll actually run:

package Foo;

# This basically does:  
#	$Foo::FIELDS{_whatever} = 1;
#	$fields::attr{Foo}[1] = fields::_PRIVATE;
# fields::_PRIVATE is a flag indicating that the field is private.
use fields qw(_whatever);  # same as 'use private qw(_whatever)' in 
			   # Class::Fields
sub new {
	# This is the usual constructor stuff.
	my($proto) = shift;
	my($class) = ref $proto || $proto;

	# We bless a pseudohash with the %FIELDS hash set up by fields.pm.
	# Same as:  bless [{_whatever => 1}]
	bless [\%{$class.'::FIELDS'}], $class;

sub whatever {
	my($self) = shift;

	# Perl translates this to $self->[$self->[0]{_whatever}]
	# Which works out to $self->[1].  It does this at run-time.
	print $self->{_whatever};

package Bar;

# Along with the usual C<push @Bar::ISA, 'Foo';> it examines
# @{$fields::attr{Foo}} for any inheritable (public) fields.  If
# it finds any it will place them onto %Bar::FIELDS and @{$fields::attr{Bar}}
# In this example, Foo has no inheritable fields, so %Bar::FIELDS remains
# empty.
use base qw(Foo);

# Foo::new() is called and $bar = bless [\%Bar::FIELDS], 'Bar' which
# works out to just $bar = bless [{}], 'Bar'
$bar = Bar->new;

# Here's where things blow up.  Foo::whatever() attempts to access
# $bar->{_whatever}.  Since $bar is a pseudo-hash it works out to
# $bar->[$bar->[0]{_whatever}].  But $bar->[0]{_whatever} doesn't
# exist, which causes the program to abort.

This is all only relevent to pseudohashes.  If $bar is a regular hash
then everything works (for good or for ill).  Again, I don't know if
this is how privacy in traditional OO is supposed to work, but that's
how it currently works in Perl.

On Wed, Dec 29, 1999 at 06:51:16PM -0700, Tom Christiansen wrote:
> >Under the current system this does not work (assuming pseudohashes).
> Er, um, under your proposed system you mean.  I'm not sure whose
> bug you're pointing at.  This private.pm idea is from your dramatic
> overhaul of the fields.pm module.  I haven't looked it over extensively
> yet, but it seems pretty complicated, and I'm not big on complexity.
> It's especially bothersome when it's just there to imitate C++.
> Did this perl-qua-C++ class system really get rolled into core
> Perl sometime when I was away dreaming?  Or are you proposing
> that it be so added?

No, under the existing system as well as my proposed changes.  I
didn't make any fundemental changes.  (See above)

public.pm and private.pm are functionally equivalent to the existing
fields.pm, I just split the interface into two somewhat more intuitive

C<use public qw(foo);> and C<use fields qw(foo);> do exactly the same thing.
C<use private qw(_bar);> and C<use fields qw(_bar)> are also equivalent.

It must have slipped by you.  fields.pm has been in since at least
5.005_02 and base.pm has been around since 5.004_04 (although I think
it only started doing field inheritance in 5.005).

As it currently exists, fields.pm isn't really useful beyond
pseudo-hashes as objects, and even then its very clunky.  Far too
complicated to get anything done.  What I'm proposing is a rewrite of
the internals and the addition of some methods for field manipulation
and examination, but its still basically the same as the existing

Its all already in the core, fatal flaws and all.  I'm just trying to
make it servicable.

> Maybe we need a more rigorous OO model in Perl.  And maybe "need"
> is just way to spell "want".
> If there's going to be an annointed standard OO model introduced into
> Perl, one blessed by the p5peers and ordained by Larry, then I hope
> that there's some serious, constructive discussion on the matter.

All I know is that what we've currently got isn't quite enough, and
that Class::Fields is just intended as a band-aid on a stopgap.  I'm
certainly not intending this as an end-all be-all OO mechanism for


Michael G Schwern                                           schwern@pobox.com

Follow-Ups from:
Gurusamy Sarathy <gsar@ActiveState.com>

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]