RFC - weird stuff I had to do (for fun or profit)
Yuval Kogman
In light of the Perl 6 community's increasing interest in API level
design, I'd like people to share old war stories about things they
had to do once, but had to jump through hoops to pull off.
The point of this excercise is the edge cases of the existing perl
builtin functions and core modules can be revisited and maybe better
designed.
Please reply to this thread with your tales of glory (or failures,
and the reason they failed).
--
() Yuval Kogman <nothi...@woobling.org> 0xEBD27418 perl hacker &
/\ kung foo master: /me climbs a brick wall with his fingers: neeyah!
Yuval Kogman
I wanted to write a Test::Harness wrapper that would monitor all the
files/directories that the .t files of my test suite opened, and
when they change to rerun only the affected tests.
I am still planning on hacking this unportably using fs_usage on OSX
and strace on linux, using FAM or whatever as the monitoring
backend, but i would much rather have a mechanism like LD_PRELOAD
for perl, with which i could add fancy hooks for IO operations
without resorting to deep magic.
The second story is abou Devel::FIXME. Devel::FIXME installs a
subreference in @INC, that is always triggerred first. Then it
recursively re-requires the file that was asked for, and this time
when the callback is triggerred it pretends to fail.
When it finds the file using the "normal" require, it will then read
the file line by line, and report all FIXMEs using a cool api to
filter unwanted ones.
It then has additional boilerplate code to fake the "success" of an
included module. Luckily all require return values are passed in
scalar context so I didn't have to worry about *that* ;-)
Audrey subsequently told me about the (undocumented) feature that
lets you *return* a subroutine ref from a subroutine ref in @INC,
that lets you get the source of the file that was normally found
line by line for filtering. THat's what
Acme::use::strict::with::pride, but I didn't know of it at the
time. It's still pretty brutal ;-)
Conclusions:
I would have been happier if I could have a nice hook interface with
which i could trap both module includes, and all IO operations and
insert my own magic into the mess to aid me in my *DEVELOPMENT*
process (not production related at all =)
--
() Yuval Kogman <nothi...@woobling.org> 0xEBD27418 perl hacker &
/\ kung foo master: /me sneaks up from another MIME part: neeyah!!!!!
Larry Wall
have a generic .wrap mechanism in addition to the MMD mechanism, then
the only remaining technical question is whether you can actually
name the function or method (or set of multimethods) to which the
surface code is being desugared. Layered over that question is the
cultural issue of whether the underlying function is blessed into an
official API. (Which, if you squint, is just the same question writ
large: "Does this thing have a Name?").
I think we've pretty much solved the naming of sets of multimethods by
allowing types in the reference-taking syntax, but we do probably have
to think through whether that just calculates a set of multies when
you take the reference, or lazily just remembers the types so that it
can see new multis added after the reference is taken. The optimizer
would probably prefer the former, while semantic transparency would
probably argue for the latter. Basically, can we .wrap a multi that
doesn't entirely exist yet? The default answer should probably be yes,
with the option to tell the optimizer otherwise. Not sure if that
should just be a pragma or something you put on the actual reference
taking syntax... And if the latter, which syntax?
Larry
Larry Wall
: The default answer should probably be yes,
Or maybe not... After all, the main point of taking a reference is
to nail down particulars so you can bypass the identification phase
next time and deal directly with your object (or proxy object).
And there's always closures when you want to finesse partial results
one way or the other...
Larry
Larry Wall
So basically, with respect to the original question, it means that
where our sugar desugars to premature reference-taking, we're limited
to .wrap and .assuming solutions--but those are probably powerful
enough to reintroduce MMD and delegation where needed. Seems like
we're still covered...
Larry