Re: [ID 20000125.002] Problem in documentation of Fcntl constants

[Ilya Zakharevich <ilya@math.ohio-state.edu>]

Gurusamy Sarathy writes:
> >This in an enormous overhead.  Imagine loading a module with 6000
> >constants taking 6M just-for-nothing.
> >
> >Putting prototypes may be a better solution for largish modules:
> >prototypes takes circa 120bytes per a proto.
> 
> OK, h2xs should be able to generate those automatically too.  That lets
> us keep the AUTOLOAD based scheme.
> 
> Advance thanks to the person who's going to send me the patch.

I would not *deeply* thank anyone who implements such a botched
workaround.  The problem is that AUTOLOAD mechanism turned out to be a
hindrance, not an advantage.  *This* is the problem to solve.

"Real" autoload would provide a way to get a reference to the
autoloaded subroutine without executing it, and would allow a
compile-time hook (when the name of the subroutine is first seen).

Say, a compile-time hook could provide the prototype for the
subroutine, and the run-time hook would define the subroutine's body.
Or the compile-time hook could load the definition of the subroutine
itself, if preferable.

Given the current preference of no-new-magic-uppercase-names, what about

  use autoload proto => \&get_proto, body => \&get_body;

or some such?  BTW, return of undef from these subroutines could mean
"continue searching", which would help digest another can of worms...

Ilya

---

Follow-Ups from:

Marc Lehmann <marc@gimp.org>

References to:

Gurusamy Sarathy <gsar@ActiveState.com>

---

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

---