At 03:54 PM 9/4/2001 -0400, Michael G Schwern wrote:
>Ummm... there should be no *language* reason why we can't override
>inline methods. It's purely an internal distinction.
I'm not so much thinking about inline methods as inline subs.
>The unfortunate problem with saying "inline methods canno
On Tue, Sep 04, 2001 at 09:30:19AM -0700, Hong Zhang wrote:
> > This is the only real reason I've seen to allow final. (And it's not a bad
>
> > reason, honestly, though not necessarily one appropriate in all cases) It
> > does allow a fair amount of optimization to be done, which can be
> > es
At 09:30 AM 9/4/2001 -0700, Hong Zhang wrote:
> > >The only good justification I've heard for "final" is as a directive
> > >for optimization. If you declare a variable to be of a final type, then
> > >the compiler (JIT, or whatever) can resolve method dispatch at
> > >compile-time. If it is not
> >The only good justification I've heard for "final" is as a directive
> >for optimization. If you declare a variable to be of a final type, then
> >the compiler (JIT, or whatever) can resolve method dispatch at
> >compile-time. If it is not final, then the compiler can make no such
> >assumptio
At 05:23 PM 8/28/2001 -0700, David Whipp wrote:
> > They list two reasons to make your class final. One is security
> > (which might actually be valid, but I doubt it will hold up to
> > determined attack), the other though...
> >
> > You may also wish to declare a class as final for object-o
Michael G Schwern wrote:
> If you *really* wanted to write an optimized redirector, you'd
> have the redirector eliminate itself.
>
> sub foo {
> my $method = $_[0]->{"_foo"} || $_[0]->can("_foo");
> {
> no warnings 'redefine';
> *foo = $method;
> }
> goto &$meth
Brent Dax wrote:
>On the other hand, it could stop some of the really stupid uses for
>inheritance I've seen. The dumbest one was in high school Advanced
>Placement's C++ classes--the queue and stack classes inherited from the
>array class!
Oh? How could "final classes" prevent such a travest
On Tue, Aug 28, 2001 at 05:23:46PM -0700, David Whipp wrote:
> The only good justification I've heard for "final" is as a directive
> for optimization. If you declare a variable to be of a final type, then
> the compiler (JIT, or whatever) can resolve method dispatch at
> compile-time. If it is no
On Tue, Aug 28, 2001 at 05:22:01PM -0700, Brent Dax wrote:
> # Sorry, I ment "final". final classes and methods. The idea that you
> # can prevent someone from subclassing your class or overriding your
> # methods. I've seen things that hinder reuse, but this is the first
> # time I've seen one
> They list two reasons to make your class final. One is security
> (which might actually be valid, but I doubt it will hold up to
> determined attack), the other though...
>
> You may also wish to declare a class as final for object-oriented
> design reasons. You may think that your cla
# -Original Message-
# From: Michael G Schwern [mailto:[EMAIL PROTECTED]]
# Sent: Tuesday, August 28, 2001 4:35 PM
# To: [EMAIL PROTECTED]
# Subject: Re: Expunge implicit @_ passing
#
#
# On Tue, Aug 28, 2001 at 10:47:35AM -0700, Damien Neil wrote:
# > On Tue, Aug 28, 2001 at 09:13:2
> Sorry, I ment "final". final classes and methods. The idea that you
> can prevent someone from subclassing your class or overriding your
> methods. I've seen things that hinder reuse, but this is the first
> time I've seen one that violently blocks reuse!
"final" is only useful for strongly-
On Tue, Aug 28, 2001 at 10:47:35AM -0700, Damien Neil wrote:
> On Tue, Aug 28, 2001 at 09:13:25AM -0400, Michael G Schwern wrote:
> > As the pendulum swings in the other direction you get mind-bogglingly
> > silly things like finalize which I just learned of today.
>
> What's so silly about final
On Tue, Aug 28, 2001 at 09:13:25AM -0400, Michael G Schwern wrote:
> As the pendulum swings in the other direction you get mind-bogglingly
> silly things like finalize which I just learned of today.
What's so silly about finalize? It's pretty much identical to Perl's
DESTROY. (Except that Java'
Michael G Schwern wrote:
> On Mon, Aug 27, 2001 at 10:58:00AM -0400, John Porter wrote:
> > You can, with C< goto &$foo; >.
> > Problem is, it's *slower* (in p5 anyway) than the plain sub call.
>
> By only 10%. Let's keep things in proportion here.
O.k., thank you for supplying the proportion.
On Tue, Aug 28, 2001 at 09:10:40AM -0400, Ken Fox wrote:
> One of the cool things about Perl's OO system is that it lets
> us invent new type systems. This IMHO is its greatest strength.
> Perhaps this is also why some OO people hate Perl's OO?
Yes, this sort of thing FRIGHTENS THE HELL out of no
Michael G Schwern wrote:
> If you *really* wanted to write an optimized redirector, you'd
> have the redirector eliminate itself.
That's not always appropriate. In my frame system, an instance
can over-ride its class method. An instance can also remove the
over-ride and return to using the class
On Mon, Aug 27, 2001 at 06:02:50PM -0500, Garrett Goebel wrote:
> From: Ken Fox [mailto:[EMAIL PROTECTED]]
> > Michael G Schwern wrote:
> > > Any time you want to implicitly pass @_, you can just as easily
> > > *explicitly* pass it or use goto.
>
> goto does screw up caller... so I wouldn't say
On Mon, Aug 27, 2001 at 06:50:35PM -0400, Ken Fox wrote:
> Michael G Schwern wrote:
> > Any time you want to implicitly pass @_, you can just as easily
> > *explicitly* pass it or use goto.
>
> I never thought of using goto actually. "goto &$method;" actually
> looks clearer than the code I'm usi
From: Ken Fox [mailto:[EMAIL PROTECTED]]
> Michael G Schwern wrote:
> > Any time you want to implicitly pass @_, you can just as easily
> > *explicitly* pass it or use goto.
goto does screw up caller... so I wouldn't say *anytime*
> I never thought of using goto actually. "goto &$method;" actua
Michael G Schwern wrote:
> Any time you want to implicitly pass @_, you can just as easily
> *explicitly* pass it or use goto.
I never thought of using goto actually. "goto &$method;" actually
looks clearer than the code I'm using. (Although with re-directors
we want to minimize cost so the 10% p
On Mon, Aug 27, 2001 at 10:48:55AM -0400, Ken Fox wrote:
> Michael G Schwern wrote:
> > I can't think of any reason why this feature is useful anymore, and it
> > can be a really confusing behavior, so what say we kill it in Perl 6?
>
> I've always thought is was pretty useful for implementing ge
On Mon, Aug 27, 2001 at 10:58:00AM -0400, John Porter wrote:
> You can, with C< goto &$foo; >.
> Problem is, it's *slower* (in p5 anyway) than the plain sub call.
By only 10%. Let's keep things in proportion here.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
P
Ken Fox <[EMAIL PROTECTED]> writes:
> Michael G Schwern wrote:
> > I can't think of any reason why this feature is useful anymore, and it
> > can be a really confusing behavior, so what say we kill it in Perl 6?
>
> I've always thought is was pretty useful for implementing generic
> redirectors.
Ken Fox wrote:
> The only thing I'd like to change is to make &foo a tail call instead
> of a normal function call. But I guess that would *really* confuse
> people.
You can, with C< goto &$foo; >.
Problem is, it's *slower* (in p5 anyway) than the plain sub call.
--
John Porter
A word spoken i
Michael G Schwern wrote:
> I can't think of any reason why this feature is useful anymore, and it
> can be a really confusing behavior, so what say we kill it in Perl 6?
I've always thought is was pretty useful for implementing generic
redirectors. I wrote a frame system that allows instances to
> When foo() is called as &foo with no parens and no arguments, it
> inherits @_ from it's caller.
> I can't think of any reason why this feature is useful anymore, and it
> can be a really confusing behavior, so what say we kill it in Perl 6?
It's alreday scheduled for termination.
Odd feature of perl5:
sub bar { &foo }
sub foo { print @_ }
print bar("It's Magic!");
When foo() is called as &foo with no parens and no arguments, it
inherits @_ from it's caller.
This might have been originally introduced as an efficient way to pass
huge sets of arguments
28 matches
Mail list logo
