> 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.
That is precisely the point: the Perligata code is *not designed* such that
the language it translates is configurable. If you want configurability
you can either ask me to redesign the class, or just redesign the class
yourself on-the-fly by dynamically replacing the non-configurable bits
that you now want to configure.
> 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.
In which case, you C<use delegation> (as described in RFC 193)
to wrap a new interface around the uncooperative Forest.
I have to leave this now, or I'll never get my remaining RFCs in
by the deadline.
Bottom-line: I think there are other ways to solve the problem
you're proposing to solve. But don't let that stop you trying to
convince Larry that your way is better! :-)
Damian
