At 05:22 PM 6/28/2001 -0500, David L. Nicol wrote:
>Garrett Goebel wrote:
>
> > > So every class has a vtable, which is a copy of its parents except for
> > > what is overridden within it, and a instance that wishes to
> > > deviate could make a local copy of its vtable and twiddle it.
>
> > Why n
At 06:07 PM 6/28/2001 -0700, Brent Dax wrote:
>I'd think that @ISA would be copied to .ISA on object instantiation, and
>after that the two wouldn't have anything to do with each other. We could
>set up one of those cool copy-on-write locks everyone's been talking about
>to save memory too.
Yep,
28, 2001 17:59
To: [EMAIL PROTECTED]
Subject: Re: Multiple classifications of an object
On Wed, 27 Jun 2001 13:48:38 -0400, Dan Sugalski wrote:
>And the current @ISA stuff is MI,
>albeit on a per-class basis rather than on a per-object one.
>
>Anyway, as Damian mentioned, set
On Wed, 27 Jun 2001 13:48:38 -0400, Dan Sugalski wrote:
>And the current @ISA stuff is MI,
>albeit on a per-class basis rather than on a per-object one.
>
>Anyway, as Damian mentioned, setting the .ISA property is a perfectly
>reasonable sort of thing to do if the language supports this.
Just
Garrett Goebel wrote:
> > So every class has a vtable, which is a copy of its parents except for
> > what is overridden within it, and a instance that wishes to
> > deviate could make a local copy of its vtable and twiddle it.
> Why not just fall back to the ancestor(s) unless it provides its o
At 09:51 AM 6/28/2001 -0500, Garrett Goebel wrote:
>From: David L. Nicol [mailto:[EMAIL PROTECTED]]
> > "Mark J. Reed" wrote:
> >
> > > But you're opening a big can of worms if you make such a
> > > change. The biggest impact would be in the way methods are defined.
> > > Instead of just being me
> > The downside is of course that I need to make a small stub for every
> > single function I want to delegate.
>
> Well, that's relatively simple to automate...
>
> Wasn't Damian working on something like this? I looked at his
> delegation stuff in perl5+i, but it didn't
From: David L. Nicol [mailto:[EMAIL PROTECTED]]
> "Mark J. Reed" wrote:
>
> > But you're opening a big can of worms if you make such a
> > change. The biggest impact would be in the way methods are defined.
> > Instead of just being members of a package, they would have to be
> > associated with
Oh yeah. Look at Class::Classless.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Maybe they hooked you up with one of those ass-making magazines.
-- brian d. foy as misheard by Mic
On Wed, Jun 27, 2001 at 01:00:40PM -0700, David Whipp wrote:
> For the distinction between methods vs members, I don't think
> we have to stray too far from perl-is-perl. Afterall, we already
> know that &foo is a function and $foo is a scalar. So from an
> implementation perspective there's no pr
On Mon, Jun 25, 2001 at 11:36:34PM +0200, Trond Michelsen wrote:
> The downside is of course that I need to make a small stub for every
> single function I want to delegate.
Well, that's relatively simple to automate...
%Delegations = ( foo=> '_This',
bar
On Mon, Jun 25, 2001 at 12:05:42PM -0700, Peter Scott wrote:
> >In Perl5 I am forced to create 4 new classes:
> >Employed_Male, Employed_Female, Unemployed_Male,
> >Unemployed_Female. The combinatorial explosion can,
> >well, explode!
>
> What's wrong with multiple inheritance?
You get a maze of
On Mon, Jun 25, 2001 at 11:44:06AM -0700, David Whipp wrote:
> When you blass an object in Perl, you give it exactly
> one type. The @ISA variable allows that type to refer
> to many other classes as the inheritance tree. @ISA
> is a list, but ref($obj) isn't. This means that you
> sometimes have
Dan Sugalski wrote:
>
> Basically my preference, if we're going with a per-object .ISA with no
> class ISA fallback, is for each object to be independent and not affect any
> other object when its properties are messed with.
I'm straining to understand the subtle distinction btwn per-object ISA
"Mark J. Reed" wrote:
> But you're opening a big can of worms if you make such a
> change. The biggest impact would be in the way methods are defined.
> Instead of just being members of a package, they would have to be
> associated with particular objects (classes or instances). A method
> may
John Porter wrote:
> without any kind of data aggregation, as in most other OO
> languages, what else is there to inheritance but late binding
> of methods?
Early checking of method name validity?
--
David Nicol 816.235.1187
ftp:
At 03:52 PM 6/27/2001 -0400, John Porter wrote:
>Dan Sugalski wrote:
> > Should it be the fallback *only* if an object doesn't have its own ISA, or
> > should we walk the class ISA if walking the object ISA fails? I can see it
> > being sensible either way.
>
>Oh. Good question. I'm not sure how
Mark J. Reed wrote:
> Okay, but now we're getting into the fundamental O-O model for
> Perl. I guess that's fair game? You can certainly make the case
> that prototype-based inheritance makes at least as much sense
> as class-based inheritance for a dynamic language like Perl.
> But that's a maj
Mark J. Reed wrote:
> John Porter wrote:
> > Mark J. Reed wrote:
> > > ... be sure that "Perl stays Perl".
> > Eh, puke.
> I'm sorry?
"Keep Perl Perl" is a non-argument. And if you haven't heard me
rail against it yet, you haven't been around very long.
I think someone hits this tripwire at le
Dan Sugalski wrote:
> Should it be the fallback *only* if an object doesn't have its own ISA, or
> should we walk the class ISA if walking the object ISA fails? I can see it
> being sensible either way.
Oh. Good question. I'm not sure how it's done in prototype-OO langs.
I would think that if
At 03:07 PM 6/27/2001 -0400, John Porter wrote:
>Anyway, as long as the class-level @ISA (or Class.ISA, hopefully)
>is the fall-back default for any instance that doesn't have its
>own .ISA set, then current semantics are retained.
Should it be the fallback *only* if an object doesn't have its ow
On Wed, Jun 27, 2001 at 03:07:36PM -0400, John Porter wrote:
> Mark J. Reed wrote:
> > ... be sure that "Perl stays Perl".
>
> Eh, puke.
I'm sorry? If you don't like Perl as it is, why do you care what happens
to it in the future? But the RFC on Perl remaining Perl has been accepted,
so let's m
Mark J. Reed wrote:
> ... be sure that "Perl stays Perl".
Eh, puke.
Anyway, as long as the class-level @ISA (or Class.ISA, hopefully)
is the fall-back default for any instance that doesn't have its
own .ISA set, then current semantics are retained.
--
John Porter
Dan Sugalski wrote:
> Basically my preference, if we're going with a per-object .ISA with no
> class ISA fallback, is for each object to be independent and not affect any
> other object when its properties are messed with.
Good; that's the norm in prototype-based OO, and I believe,
in Frame sys
Okay, but now we're getting into the fundamental O-O model for
Perl. I guess that's fair game? You can certainly make the case
that prototype-based inheritance makes at least as much sense
as class-based inheritance for a dynamic language like Perl.
But that's a major implementation change and y
At 11:45 AM 6/27/2001 -0700, Mark Koopman wrote:
>>* Objects are bigger since they all need an .ISA property, if we toss the
>>per-class @ISA
>
>
>with an accessible .ISA property, are previous instaniated objects
>'brought-up-to-speed' with this new behaviour or not?
Depends on what you mean
>
> * Objects are bigger since they all need an .ISA property, if we toss the
> per-class @ISA
>
with an accessible .ISA property, are previous instaniated objects
'brought-up-to-speed' with this new behaviour or not?
--
Mark Koopman
Software Engineer
WebSideStory
10182
At 02:25 PM 6/27/2001 -0400, John Porter wrote:
>Dan Sugalski wrote:
> > * Objects are bigger since they all need an .ISA property, if we toss the
> > per-class @ISA
>
>I certainly like the idea of instance-level inheritance (since
>it's the only way to go in prototype-based OO), but I hope we
>wo
Dan Sugalski wrote:
> * Objects are bigger since they all need an .ISA property, if we toss the
> per-class @ISA
I certainly like the idea of instance-level inheritance (since
it's the only way to go in prototype-based OO), but I hope we
wouldn't sacrifice class-level inheritance for it.
We coul
At 09:57 AM 6/27/2001 -0700, David Whipp wrote:
>When I started this thread, I knew everyone would tell me that
>delegation is the answer: I included the note that I knew about
>that, but I guess the bias against MI is just too strong.
Well, not *everyone* is against it. :) And the current @ISA s
David L. Nicol wrote:
>
> > The other standard solution is to
> > add a "Person has-a Employment_Status" relationship,
> > but that doesn't feel much better.
>
> It feels fine to me. Person has-a gender, person has-a job,
> it's more politically correct, even, than pigeonholing. You
> can even
David Whipp wrote:
> The other standard solution is to
> add a "Person has-a Employment_Status" relationship,
> but that doesn't feel much better.
It feels fine to me. Person has-a gender, person has-a job,
it's more politically correct, even, than pigeonholing. You
can even do dynamic multipl
Hmm... very much like a module I wrote (but never released to CPAN),
called Class::Multi. It was indended as my answer to multimethods,
although it doesn't resemble multimethods at all.
It delegates to both classes and instances.
--
John Porter
On Mon, Jun 25, 2001 at 12:47:41PM -0700, David Whipp wrote:
>> What's wrong with multiple inheritance?
> You have to create a whole load of extra classes whose only
> purpose is to define a list of superclasses. Compare:
This sounds a lot like the case I had with a
content-syndication system I'm
On Mon, Jun 25, 2001 at 11:44:06AM -0700, David Whipp quoth:
> We might want some magic to ensure 'ref($foo) eq "bar"'
> still works as expected.
ref($foo) could be any(@ISA)
.g
--
Writing code on one line is like playing the trumpet without breathing!
-Adam Pisoni
> >What's wrong with multiple inheritance?
>
> Nothing, but he wants MI on a per-object basis, rather than a per-class
> basis, presumably to avoid having to create a zillion classes who's sole
> purpose in life is to have an @ISA array.
>
> Sounds sensible, and worth send
At 12:05 PM 6/25/2001 -0700, Peter Scott wrote:
>At 11:44 AM 6/25/01 -0700, David Whipp wrote:
>>Can anyone see any problems with making C and
>>C work with lists? C is not effected. We
>>might want some magic to ensure 'ref($foo) eq "bar"'
>>still works as expected.
>
>What's wrong with multiple
Peter Scott wrote:
> What's wrong with multiple inheritance?
You have to create a whole load of extra classes whose only
purpose is to define a list of superclasses. Compare:
bless $self, qw(Employed Male);
with
package Employed_Male;
@ISA=qw(Employed Male); # multiple inheritance
...
At 11:44 AM 6/25/01 -0700, David Whipp wrote:
>When you blass an object in Perl, you give it exactly
>one type. The @ISA variable allows that type to refer
>to many other classes as the inheritance tree. @ISA
>is a list, but ref($obj) isn't. This means that you
>sometimes have to create a lot of u
39 matches
Mail list logo
