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
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
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
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 m
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
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 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
>
> * 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 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
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 le
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
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
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
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
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
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 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
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 L. Nicol wrote:
> Yet another minor candidate for regularization.
(Hush, David, Don't say that. Perl should stay Perl! ;-)
--
John Porter
"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
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
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
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
* 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 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
27 matches
Mail list logo
