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