Before we get too far into details here, this is the real point I'm
trying to make.
The set of Perl 6 module authors will be much greater than the set of
Perl 6 core programmers (again, same in Perl 5). The more Perl 6
things we can shove out into modules, the less work we have to do on
the Perl 6 core. (This is true of Perl 5 as well). Less work we need
in the core, the faster we will see a working Perl 6.
I'm trying to cut/defer features. If you've got something that can be
98% done as a module, that's good enough. Leave it out of the core,
or work on it if we happen to have time. And in this case, we can
always put it into perl 6.0.1 (since there's no issue of breaking
perl5 compatibility).
Its the surest way to shorten a project's schedule. Cut features.
On Sun, Jul 01, 2001 at 01:00:09AM -0400, Dan Sugalski wrote:
> > > > "Any sufficiently encapsulated hack is no longer a hack."
>
> Well, you're wrong--it's still a hack. The encapsulation just makes it
> possible to remove the hack and replace it with something less hackish at
> some point later. (Yeah, I know--like that ever happens with software...)
Thank you, that's my point exactly. Its all about the relatively of
hackmanship. To take a recent example...
sub new {
my($class) = @_;
@{$class.'::ISA'} = $class.'::__multi';
@{$class.'::__mutli::ISA'} = qw(Employee Person);
return bless {}, $class.'::__multi';
}
That's a hack. But if we do this...
sub new {
my($class) = @_;
return multibless {}, qw(Employee Person);
}
Wow! The hack is gone! Its not gone, we just smeared a layer of
abstraction over it. But from the user's perspective, the hack is
gone.
But I digress.
> >They're NO SLOWER than normal objects, it uses all the normal OO
> >channels, it was very simple and small to implement and it WORKS!
> >Now, right this second, with perl 5.
>
> There are space costs involved here that aren't obvious.
(Of course, you're going to make stashes really light-weight in Perl
6, RIGHT?! ;)
There's a way around that. If you make every single object into its
own class its gets nasty and fat.
# $foo is a daughter of $obj.
my $foo = $obj->new;
If instead you make them siblings of each other...
# $foo is a sibling (ie. the same class) as $obj.
my $foo = $obj->new;
Things stay nice and trim, almost no memory difference (since we're
not constantly creating new classes and stashes). Then you have a
special constructor to create daughter objects...
my $daughter = $obj->new_daughter;
The problem with this approach is now siblings can effect each other,
it no longer works as if each object is in its own class.
my $sibling = $obj->new; # assuming new() creates siblings
$sibling->sub('foo', sub { return 42 });
print $obj->foo; # 42
Instead of only parents effecting their children
my $daughter = $obj->new; # assuming new() creates daughters
$obj->sub('foo', sub { return 23 });
print $obj->foo; # 23
print $daughter->foo; # 23
$daughter->sub('foo', sub { return 42 });
print $obj->foo; # 23
print $daughter->foo; # 42
I don't know if this is good or bad, not really knowing how this
technique is typically applied. I suppose I could just make two
versions/subclasses of Class::Object to try it out. If anyone has
used object inheritance in the past, let me know the ins and outs.
Anyhow, if you want Perl 6 objects to be able to act as if they're in
their own class (ie. have their own methods, inheritance, etc...) how
are you going to do this without having the moral equivalent of a
stash associated with it? And if you can do something that saves
memory on object inheritance, why not apply it to class inheritance?
> Having separate classes for the threaded and unthreaded versions of
> an object seem silly, as does the case where an object changes class
> merely because some of the methods behave slightly
> differently. (Should a disk-backed object look like a different
> class than a non-disk-backed object if they behave identically to
> the program?)
This is OO 101. Yes, the disk vs non-disk should be different
classes, but they should share a common parent class/interface. But
that's just internal details. They're *different* but they *look the
same*.
my $obj = Foo->new;
Is $obj really of class Foo? Could it be Foo::Disk or Foo::NonDisk?
It could be anything, but at least we know its a subclass of Foo that
will act like any other Foo object. This is your basic factory
pattern.
When you get into object inheritance you're doing exactly the same
thing, terminology just changes. Instead of having Foo::NonDisk and
Foo::Disk classes, you might have parental $foo_disk and $foo_nondisk
objects from which you derive sub-objects which then inherit their
overridden methods.
All these techniques start to blur together.
--
Michael G Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
