At 06:35 PM 8/1/00 -0400, John Tobey wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 05:55 PM 8/1/00 -0400, John Tobey wrote:
> > >Dan, you are completely missing my point. Okay, fine, non-inline may
> > >be a performance win in some cases. Inline may be a win in others. I
> > >am not proposing we mandate inlining in any case, I am proposing the
> > >exact opposite: that we let the caller decide in every case.
> >
> > Having thought about it a bunch more (because of this) I'm proposing we
> let
> > the compiler decide. The caller doesn't know enough to make that decision.
>
>Read carefully. I said we *let* the caller decide, not *make* the
>caller decide. What, specifically, disturbs you about my proposal?
First it means double the number of function names. This makes more work
for maintenance, and is bad.
Secondly, the programmer doesn't (and, in fact, can't) know whether the
inline function is appropriate. That's a decision that can only be made by
the compiler on the platform perl's being built on.
Whoever's working on the internals should just use the appropriate function
and leave it to the compiler to do the right thing. If we feel the need to
hint we can, but it should be optional and invisible to the person writing
the code.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
