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
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
* Damian Conway <[EMAIL PROTECTED]> [06/25/2001 13:20]:
>
> But one could also imagine that Perl 6 might allow individual objects to
> have an C 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 ex
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
What follows is a long, detailed summary of an attempt to install JDK 1.2.2
on FreeBSD today. FreeBSD/JDK 1.2.2 is an unsupported configuration for Sun,
although patches exist to get the JDK to work under FreeBSD.
Skip to the last two paragraphs if you want to see how this installation
compares
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
David L. Nicol wrote:
> Yet another minor candidate for regularization.
(Hush, David, Don't say that. Perl should stay Perl! ;-)
--
John Porter
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:
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 langua
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
27 matches
Mail list logo
