On Mon, Mar 07, 2005 at 05:53:23PM +0100, Thomas Sandlaß wrote:
: Larry Wall wrote:
: >Yes, and it wouldn't work at all if you ever wanted to autoload anything.
: >If we ever get to where we're autoloading class bodies, they'd have the
: >same problem with embedded declarations. The compiler can't work with
: >information that isn't there.
:
: This is something that is blurry to me: how does one separate declaration
: and implementation. It is clear that a declaration has got a {...} block
: and an implementation doesn't. But does that mean that there are package
: files that function like header files in C++ or like interface files in
: Ada and Modula?
In theory, yes, though I would hope more like Ada than C++. #include
is a rotten way to do business. The idea of Perl's "use" is that you're
essentially calling a subroutine in the package that gives you as much
of the definition as you need. The fact that it might define a whole bunch
of other stuff at the same time is immaterial to you. As in happens,
it might have already been declared by a previous "use", as well as later
in a lazy fashion. It's really the import function that is managing the
interface though. The import mechanism might be different in Perl 6, but
the underlying idea that you execute real Perl code to define things
is certainly going to carry over from Perl 5.
: Or does that work more like Cecil signature declarations which can be
: spread out as needed and actually express a callers expectations which
: can be matched with the implementation side?
I am not familiar with Cecil, but in Perl 6 caller expectations
are primarily expressed through the actual types you feed to MMD.
If the compiler can figure out more based on your own declarations,
that's fine, but the bias is definitely toward late binding.
I suppose if a user defines an normal inner sub that redispatches to
an outer set of multi subs, it functions a bit like a user-defined
expectation. We don't currently have a way of directly mapping a set
of inner multis to a set of outer multies without going through an
interposed non-multi.
We also give a bit of user-defined interface control in letting the user
tell the module which version it wants to act like. In the degenerate
case, that means it just picks the right file, but we should recognize
that the version we specify in a use is maybe an interface version, and
multiple interfaces could be served up by a single back-end implementation.
That approach might help with resource collisions between different versions
of the same module.
Beyond that, we provide the user with aliasing and delegation and
wrappers, at least on a sub/method level. But given that all code
that executes is a sub on some level, there can probably hooks to
wrap classes and modules too, if ordinary inheritance, composition,
and delegation aren't up to the task. But at some point you just
give up and call it cheating, er, I mean, AOP. :-)
Basically, once you realize the compiler is not longer doing the
compilation, but just helping the program compile itself by running
odd bits of code here and there, the door is open to turn Perl into
any other language you like. The only question is what discipline
the culture will enforce around the complete mayhem that is possible.
It is at this point that I am placing my trust in the Perl community.
(But then, my definition of "community" is somewhat Darwinian...)
Larry
