> According to TOGoS: > > Chip said: > > > A Perl runtime won't have the > > > necessary information > > > to present [a unified namespace]. > > > > I'm not so sure about that. Most of the time, > > only one variable with > > a name will be defined ($foo, @foo, or &foo, but > > not more than one). > > That looks good in static analysis. But masking > effects are serious > enough that it's a bad idea, IMO. > > Consider: A working Perl/Python hybrid program would > be broken by an > upward-compable upgrade of the Perl part that makes > a given name > ambiguous, thus defeating the single-namespace view > that used to work. > > Requiring explicit imports avoids this problem.
Or explicit exports :) that way you only need to define the interface once, and then all unified-namespace languages can use it. But we can have it both ways, if we want. The only issue is 'how do we separate the imported/exported namespace from the original'. Does ["Foo","bar"] (external interface) become ["\0:Foo","\0$bar"], or ["\0namespaces","Foo","\0scalars","bar"], etc? > > This reminds me just a little bit of > > what J# does to implement > > accessors that can be used by other .NET programs. > > Do tell, please. Well, it's not entirely related, but it goes something like this: /** @property */ public void set_SiteTitle( String value ) { this.siteTitle = value; } /** @property */ public String get_SiteTitle() { return this.siteTitle; } The J# compiler then creates 'SiteTitle' accessor methods. The point is that a C# programmer using your object can say 'Server.SiteTitle' instead of having to remember that you programmed the thing in Java (which didn't originally have any way to make accessor methods appear as fields) and calling it 'Server.getSiteTitle()'. The aliasing is taken care of once, by the module, instead of each time someone wants to use the module. __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail