Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote:
Sex, 2008-05-02 às 09:08 -0500, John M. Dlugosz escreveu:
A syntax is needed for this express concept: "accept B as a substitute
for A", without changing A.
Which I'm advocating as....
class CGI::Simple realises CGI { ... }
or
CGI::Simple is also { realises CGI }
or even...
$cgi_simple realises CGI;
daniel
Yes, I agree. I don't know if "realizes" will be without conflict of
meaning after coming up with consistent nomenclature for generic
specializations, role composition, and virtual type names. That is one
advantage of using symbols as placeholders for now.
I'll split the difference and use Allomorph to specifically mean the
duck-typing effect we've been discussing. Conjugating it is tough, but
I'll punt on making it roll off the tongue. The point for now is that
the word is unique to my specdoc and other discussions so it can be
replaced easily.
I agree that you should be able to define an Allomorph as part of the
class to indicate it is intended to re-implement the same interface
(more or less) without having to refactor the two classes to identify
that overlap and make it a defined Role.
Doing it to a single object is sensible too. Some of them are vetted as
such, but generally no.
I also want to be able to declare an Allomorph as a scoped directive, so
without adding a line into the class I can say it's OK in this scope.
class CGI::Simple {
...
is allomorph(CGI, :exclude<bark>);
}
my CGI::Simple $x;
...
allomorphism :from<CGI::Simple> :to<CGI>; # for the duration of this
scope
foo($x); # no complaints, also applies details specified in
allomorphism declaration
All strawman for syntax.
--John
