RE: Expunge implicit @_ passing
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 java code can load in extra classes later. 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 especially important when you can't see all the source. (Pretty much the case in all languages that compile down to object modules you link together later) If our intention is only for optimization, I prefer to use word inline instead of final. The word final already has been abused. It is very awkward to use it for this purpose. Hong
RE: Expunge implicit @_ passing
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 the compiler can make no such assumption because java code can load in extra classes later. 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 especially important when you can't see all the source. (Pretty much the case in all languages that compile down to object modules you link together later) If our intention is only for optimization, I prefer to use word inline instead of final. The word final already has been abused. It is very awkward to use it for this purpose. Fair enough. I don't much care what its called, as long as I know what it does. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Expunge implicit @_ passing
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 design reasons. You may think that your class is perfect or that, conceptually, your class should have no subclasses. The idea that a class is either 'perfect' or 'complete' has to be the silliest, most arrogant thing I've ever heard! 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 java code can load in extra classes later. 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 especially important when you can't see all the source. (Pretty much the case in all languages that compile down to object modules you link together later) You can, with sufficiently aggressive analysis, determine whether a class is subclassed if you have a language that doesn't allow you to change the rules at runtime, if all the source is available. Perl, alas, doesn't fall into this class of languages, so we're going to have to do something clever. (Probably some form of conditional branch--Branch if not changed since time X--that checks to see if the inlined version's safe to use) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Expunge implicit @_ passing
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? Are you seriously suggesting that the Array class should be designed such that it cannot be inherited? -- Eric J. Roode[EMAIL PROTECTED] Senior Software Engineer, Myxa Corporation
Re: Expunge implicit @_ passing
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;
}
:)
It's nice to see that someone looked at the import method in
Pollute::Persistent
At some point I came up with a list of Ways Life Would Improve
If Perl Had Tail-Recursion, or something like that. It largely
hinged on being able to access the calling context more aggressively
than returning a value back into it, was a side-effect of something
else, or required something else which had other beneficial effects.
Sorry about the vagueness
--
David Nicol 816.235.1187
A government of the p8a, by the p8a, and for the p8a.
Re: Expunge implicit @_ passing
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 non-Perl people. This is not a bad thing, it just means they have to stop expecting the language designer to dictate their whole universe. They can only see hordes of malicious hackers and irresponsible junior programmers blowing away their classes at run-time. As the pendulum swings in the other direction you get mind-bogglingly silly things like finalize which I just learned of today. I'm going to be giving a talk about just this sort of thing at JAOO to a room full of Java people. Should be interesting. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Your average appeasement engineer is about as clued-up on computers as the average computer hacker is about B.O. -- BOFH
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 -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! Wow. I'm reading the Sun tutorial on the subject. Interesting reading. http://java.sun.com/docs/books/tutorial/java/javaOO/final.html 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 perfect or that, conceptually, your class should have no subclasses. The idea that a class is either 'perfect' or 'complete' has to be the silliest, most arrogant thing I've ever heard! Anyhow, just don't anyone suggest putting this in Perl 6. I know where you live. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Good tidings, my native American Indian friend! America will soon again be yours! Please accept 5th Avenue as an initial return!
RE: Expunge implicit @_ passing
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-variable-typed language, such as Java. If the variable is not strongly-typed, people can always use delegation or has-a scheme to subvert the class, even the class itself is declared as final. For a truly well designed class, which has no public/protected fields, nor protected methods, it really does not matter whether it is final or not, since the subclass can not do anything beyond the class' public interface. Unless we want Perl to be strongly typed everywhere, I doubt the usefulness of final except documentation purpose. Hong
RE: Expunge implicit @_ passing
# -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 -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! 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! (It was private inheritance, so you couldn't tell this from the outside.) This was one of the biggest kludges I've ever seen, and a good example of a bad use of is-a. It also meant that the class was nearly impossible to modify for different storage--it was far easier to just write a new class with the same interface. Stupid, stupid, stupid. --Brent Dax [EMAIL PROTECTED]
Re: Expunge implicit @_ passing
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 over-ride
class methods. The basic idea is
sub foo {
my $method = $_[0]{_foo} || $_[0]-can(_foo);
{$method};
}
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.
- Ken
Re: Expunge implicit @_ passing
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 a frame system that allows instances to over-ride
class methods. The basic idea is
sub foo {
my $method = $_[0]{_foo} || $_[0]-can(_foo);
{$method};
}
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.
Given that I'd *really* like to see information about 'whether this
subroutine was called in an OO fashion', I'd prefer to see:
sub foo {
my $self = shift;
my $method = $self-{'_foo'} || $self-can('_foo');
$self-$method(@_);
}
used. But I take your general point about 'goto $method'.
--
Piers Cawley
www.iterative-software.com
Re: Expunge implicit @_ passing
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/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One It sure is fun masturbating. http://www.unamerican.com/
Re: Expunge implicit @_ passing
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. (Although with re-directors
we want to minimize cost so the 10% penalty should be eliminated.)
Larry Wall has a quote about goto somewhere...
It would be possible to optimize some forms of goto, but I haven't
bothered.
-- Larry Wall in [EMAIL PROTECTED]
but I think he was refering to goto LABEL.
Anyhow, with a redirector it's more important for caller() to be
untouched than a little microptmization, so goto is the way to go.
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;
}
in the first call to foo(), the redirector will replace itself with
the real method. Thereafter, it's a normal method call. That's the
real savings.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Death follows me like a wee followey thing.
-- Quakeman
Re: Expunge implicit @_ passing
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*
That's what 'or' means.
sub foo { { $_[0]-{_foo} || $_[0]-can(_foo) } }
works just as well as
sub foo { goto { $_[0]-{_foo} || $_[0]-can(_foo) } }
and doesn't mess up code which relies on caller...
A good redirector should be totally transparent. When _foo() asks for
it's caller() it should get foo()'s caller, not foo() itself.
So in this case, goto does the right thing.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
You see, in this world there's two kinds of people. Those with loaded
guns, and those who dig. Dig.
-- Blonde, The Good, The Bad And The Ugly
Re: Expunge implicit @_ passing
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 Perl 6, the expression Cfoo returns a reference to the Cfoo subroutine. Damian
