Re: Expunge implicit @_ passing
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 be >overriden" is people are not going to realize this, slap 'inline' on >their methods (cuz it's faster, you see) and screw their subclassers. >Or they will realize it and slap it on anyway, either because they >think the speed is more important than subclassing, or because they >really want 'final'. > >Trying to optimize methods so they are "inline" in a dynamic language >like perl is going to have all sorts of weird side-effects. Object >method calls are currently only about 15% slower than function calls. >I expect that gap to close in Perl 6 just with the introduction of >proper vtables. It's not method calls as such that'll be faster or not with methods marked as definitive. There's also the potential to inline the sub code and then put the inlined code through the optimizer. Some code can get a pretty significant speedup that way. (And, then again, some code can't...) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Expunge implicit @_ passing
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 > > 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. Ummm... there should be no *language* reason why we can't override inline methods. It's purely an internal distinction. The unfortunate problem with saying "inline methods cannot be overriden" is people are not going to realize this, slap 'inline' on their methods (cuz it's faster, you see) and screw their subclassers. Or they will realize it and slap it on anyway, either because they think the speed is more important than subclassing, or because they really want 'final'. Trying to optimize methods so they are "inline" in a dynamic language like perl is going to have all sorts of weird side-effects. Object method calls are currently only about 15% slower than function calls. I expect that gap to close in Perl 6 just with the introduction of proper vtables. Preventing subclassing is not worth 10%. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One This is my sig file. Is it not nify? Worship the sig file. http://www.sluggy.com
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
> >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 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
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
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
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 final, then the compiler can make no such > assumption because java code can load in extra classes later. And a very good reason it is, too. While an optimizing JIT can play tricks to achieve similar results, this won't work for something like gcj which compiles directly to native code. The fact that C++ is usually compiled to native code, while Java is not, may explain why C++ methods are (in Java parlance) final unless explicitly declared "virtual". - Damien
Re: Expunge implicit @_ passing
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 violently blocks reuse! > > On the other hand, it could stop some of the really stupid uses for > inheritance I've seen. Problem is, it stops the smart ones, too. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One I have no choice but be brave and face the danger and laughter! So please don't email me insults. If I don't deserve your belief, at least I deserve your respect. --Alex Chiu, Immortality Guy
RE: Expunge implicit @_ passing
> 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. However, there are probably some advanced techniques that allow optimization even when there is no "final". Remembering where optimizations were done, and undoing them if necessary, is one possibility. Perl would find this more difficult (there are many more ways to mess with the type system), so a "final" property may actually be useful. > Anyhow, just don't anyone suggest putting this in Perl 6. I know > where you live. Uh Oh :) Dave -- Dave Whipp, Senior Verification Engineer, Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086 tel: 408 523 8071; http://www.fast-chip.com Opinions my own; statements of fact may be in error.
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
> 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
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
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 non-refcounting GC doesn't provide the same guarantees on when an object whill be finalized.) (And the problem that all too many JVMs have had buggy implementations of finalizers... that's an implementation issue, not a language one, though.) - Damien
Re: Expunge implicit @_ passing
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 still a bad proportion. goto &$foo should be *faster*. And I mean this as a -language person, not as an -internals person. Tail recursion elimination -- even if it must be explicit, as in perl5 -- should be faster than a recursive call. -- John Porter A word spoken in the mind will reach its own level in the objective truth.
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
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 method. If my redirector eliminated itself, none of this would be possible. 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? - Ken
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
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
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
> looks clearer than the code I'm using. (Although with re-directors
> we want to minimize cost so the 10% penalty should be eliminated.)
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...
Re: Expunge implicit @_ passing
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.) > Why am I beating this dead horse? I dunno. You asked. I just answered. ;) - Ken
Re: Expunge implicit @_ passing
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
> 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};
> }
Why not just $method->(@_); or &{$method}(@_); or goto $method?
Any time you want to implicitly pass @_, you can just as easily
*explicitly* pass it or use goto. As we're not doing pass-throughs
all over the place, it's not the sort of thing you want implicit, as
opposed to, say $_.
OH! Right, $_. Consider this.
sub foo {
my $arg = shift || $_;
print $arg;
}
sub bar {
$_ = 'from default';
&foo();
}
bar("from args");
What does that program do? Change &foo to foo() or &foo() and the
behavior changes. Ahh yes! Confusing, isn't it?
Why am I beating this dead horse?
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
ScHWeRnsChweRNsChWErN SchweRN SCHWErNSChwERnsCHwERN
sChWErn ScHWeRn schweRn sCHWErN schWeRnscHWeRN
SchWeRN scHWErn SchwErn scHWErn ScHweRN sChwern
scHWerNscHWeRn scHWerNScHwerN SChWeRN scHWeRn
SchwERNschwERnSCHwern sCHWErN SCHWErN sChWeRn
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
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
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 mind will reach its own level in the objective truth.
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
> 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 C<&foo> returns a reference to the C subroutine. Damian
Expunge implicit @_ passing
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 without copying before references were
introduced, but that's not a problem anymore. foo(@_) or goto &foo
works just fine.
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?
--
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"
