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 final, then
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 cannot
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
assumption because
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-oriented
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 travesty?
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 $method;
}
:)
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 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's
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
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.
But it's
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 class is
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 that
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 not
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 finalize?
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
# -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:25AM
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
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 in the
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. I wrote
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 using.
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 *anytime*
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 generic
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%
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; actually
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.
In
25 matches
Mail list logo
