>I haven't (and won't) have time to go into this in detail :-(
>
>I feel that this proposal is solving the wrong problem. The issue is
>that the original Forest and Frog (or DBI and DBI::st) classes are not
>*designed* for user-definable Frogs (DBI::st's). If that functionality
>is widely needed, the Forest should be redesigned with *configurable*
>Frogs.
This seems to me a very precarious argument. What I understand as
your argument would lead every class (which dealt with HASA
relationships) that /didn't/ wish to be non-extensible to implement
some method similar to this:
sub get_hasa_class { 'Some::Class' }
which could be changed through sub-classing. While such a thing
would work, it would incur an extra level of indirection on every
static method call,
$class->get_hasa_class->method()
and would assuredly cost both perl (in run-time) and the programmer
(in understanding) in dealing with such classes.
>But even if you can't redesign the forest, Perl still makes it easy to
>impose a Japanese accent on Frogs wherever you need to:
>
> my $forest = Forest->new();
>
> if (can_see_Mt_Fuji()) {
> local *Frog::speak = sub { "kerokero" };
> # or:
> # local *Frog::speak = \&Frog::Japanese::speak;
>
> print $forest->make_noise(); # "kerokero"
> }
>
> print $forest->make_noise(); # "ribbit-ribbit"
I don't find this a suitable solution to this problem. The Forest
class API has provided a sort of contract which by changing
Frog::speak locally in a block, you avoid. By circumventing the API,
your code will break if/when the implementation of Forest is changed
but the API is preserved.
Even disregarding the issue of the API contract, "wherever [I] need
to" may be in code that I can't readily change. The code making
calls to such a method (make_noise()) might be strewn across many
modules and files, some of which might be system-wide (as in the
read-only site_perl). It is too much to ask that the programmer
define a local version of the method in every scope in which calls to
that method are made.
Also, with more ways to represent perl code than the usual 'normal'
perl source already implemented and proposed for perl6 (source
filtering, byte-code compilation, etc.), it is desirable to be able
to extend the functionality of said code by documentation and API
alone without changing the actual source.
In all sincerity, your Lingua::Romana::Perligata module is a good
example. Although not many people may desire to code perl in Latin,
it is certainly conceivable that modules similar to Perligata may
allow programming perl in a variety of languages native to the
programmer. That should not present a problem for others wishing to
extend such code provided they understand the documentation and API.
It may not be desirable or possible to edit the code as you suggest
with classes implemented in other languages, encrypted, or otherwise
created in a format which is not familiar to the programmer. It may
also not be desirable to avoid published class APIs as that will
break your code (as it should) when class implementations change.
REFERENCES
RFC 172 - Precompiled Perl scripts.
Filter::decrypt
http://search.cpan.org/doc/PMQS/Filter-1.19/decrypt/decrypt.pm
.greg
--
Greg Williams | If you wish to live a life free from sorrow,
Cnation | think of what is going to happen as if it had
[EMAIL PROTECTED] | already happened.
