zefram at fysh
May 20, 2012, 3:10 PM
Post #51 of 55
Father Chrysostomos via RT wrote:
Re: [perl #108286] Wishlist: Overridable keywords
[In reply to]
>On Sun May 20 05:09:10 2012, zefram [at] fysh wrote:
>> What does it mean to be a keyword?
>To use the built-in parser for that keyword.
This shouldn't be distinguishable from using an appropriate custom parser
that a user can attach to an arbitrary sub. Going to need more detail
if you're maintaining a distinction here.
>There is currently an ugly parser hack that makes "require" and
>"CORE::require" behave differently, in that the latter bypasses callbacks.
I think here you're talking about the difference that arises if a
sub CORE::GLOBAL::require is defined. This is not a problem to my
model. It's only a problem if you mistakenly suppose that require and
CORE::require must be the same thing, which, for exactly this reason,
they're patently not.
As it is, "CORE::require", used without sigil, always refers to the
baseline builtin behaviour. Its behaviour is not affected by any
CORE::GLOBAL::require. &CORE::require should exhibit the same behaviour.
So your later clearer question:
>What I was trying to ask was: Should an inlined CORE::require CV
>respect callbacks, the way the built-in function does?
(supposing that by "callbacks" you're referring to the CORE::GLOBAL::
mechanism) has a very simple answer: no, &CORE::require should not obey
This also immediately leads us to the blindingly obvious realisation
that unqualified "require" by default *does not* refer to CORE::require.
It refers to something else whose behaviour is derived from CORE::require
and CORE::GLOBAL::require, and in particular has compile-time magic that
looks at whether a CORE::GLOBAL::require has been defined. This something
else doesn't currently have a name. I've been privately thinking of it
as CORE::DEFAULT::require for some months, but I'm totally flexible on
what name we use to reify it. Anyway, the point is we *should* reify it,
we should explicitly distinguish between it and CORE::require, and we
should not get confused about having multiple entities with "require"
in their name.
Same goes for everything that's currently subject to CORE::GLOBAL::.
Is this the problem you were referring to? If you meant something else,
please explain further.