According to TOGoS:
> Or explicit exports :) that way you only need to define the
> interface once, and then all unified-namespace languages can use it.

I think an (until now) seldom-mentioned aesthetic of Parrot is that
all languages get to work in their own way, and don't have to present
unnatural (for them) interfaces.  If module A asks for services from
module B, the onus for interoperability is on the petitioner: A.

Asking Perl programmers to go out of their way to present foreign and
unnatural interfaces is, well, foreign and unnatural for Parrot.

Suggesting that only Perl code that will be used from non-Perl has to
care about this issue misses the point.  How am I, the module author,
to know whether my module will catch the fancy of a Python user?

In short: Any system that depends on prescience is doomed to failure.
I can tell you that in advance.  :-)

> /** @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.

Ah, I see.  I agree this is somewhat different; it's mapping a C#
language feature (for the CLR wouldn't have had this feature if C#
didn't need it) onto a language that lacks it.

On an even less related note, I'm really quite surprised that J#
doesn't use the bean method names.  Or maybe it does, and I just
don't remember the bean method names correctly?
-- 
Chip Salzenberg               - a.k.a. -              <[EMAIL PROTECTED]>
 "I don't really think it is a question of bright people and dumb
  people, but rather people who can see the game they're playing and
  those who can't." -- Joe Cosby

Reply via email to