> 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
