On Tue, Sep 06, 2005 at 02:22:23PM +0100, Jonathan Worthington wrote: > "Tim Bunce" <[EMAIL PROTECTED]> wrote: > >Having said all that, I don't think it's worth worrying about > >inter-language issues until more fundamental namespace co-existance > >issues are more settled. > > > >Will a Python module clash with a Perl6 module of the same name? > >(That way lies insanity so I certainly hope not.) > > > >If not then separate namespace hierarchies are required. > > > >The most natural way to do that is to give each HLL its own > >'virtual root' near the top of a shared namespace hierarchy. > > It seems to me that this would mean that to use a module we always have to > care about what language it is written in.
Not a great hardship, and probably even important for non-trivial cases. > Yes, I agree that we don't want > clashes and it's for sure that some languages we support will have clashing > name spaces even in their standard libraries. So something like what is > suggested here is very much needed. > > At the same time, glancing at the .NET platform, if I remember correctly > you don't have to care what language another class was implemented in to > use it - you just go ahead and use it - which is nice. .NET started with a clean slate. We don't have that luxury. > (It means, for example, that the Perl 5 module that a Python program > was using, on conversion to Perl 6, doesn't break the Python program > because it's still looking in the Perl 5 namespace.) That ought to be a one line change (and here I'm ignoring the same heap of practical difficulties that you are :-). Having said that, it's possible that perl5 and perl6 could share the same namespace. > But maybe "look everywhere by default" is the wrong behaviour and could > create all kinds of confusion. So maybe (assuming we're writing in P6):- > > use perl5:What::Ever; # Only look in the Perl 5 namespace. > use What::Ever; # Only look in the Perl 6 namespace. > use *:What::Ever; # Look in any name space - not sure * will work > though. Perl6 will have a layer of indirection between the short module name in the code and the long module name that gets loaded. So there's flexibility that can be used to get the behaviour you desire. > I can think some stuff up on a Parrot level for this, if anyone believes > this idea worth considering. This is certainly an area that needs more thought. Tim.
