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 do dynamic
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
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 could
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 by
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
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
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 move on
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 own
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
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 least once a
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 major
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 it's
David Whipp wrote:
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
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
David L. Nicol wrote:
Yet another minor candidate for regularization.
(Hush, David, Don't say that. Perl should stay Perl! ;-)
--
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.
I'm straining to understand the subtle distinction btwn per-object ISA and
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 to
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 twisty
* Damian Conway [EMAIL PROTECTED] [06/25/2001 13:20]:
But one could also imagine that Perl 6 might allow individual objects to
have an CISA property that pre-empted their class's C@ISA array.
At some point, it is probably worth talking about Perl's ALLCAPS subs
for special methods. For
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 Wed, Jun 27, 2001 at 05:30:02PM -0400, John Porter wrote:
David L. Nicol wrote:
Yet another minor candidate for regularization.
(Hush, David, Don't say that. Perl should stay Perl! ;-)
Okay, I clearly missed out on some heated discussion about the
``Perl bleibt Perl'' RFC. I'll dive
21 matches
Mail list logo
