Well, I have two ideas kind of related to this subject, not very directly,
but...

Jarkko Hietaniemi wrote:
> A gut feeling that I have is we can't simply go by interface 'names',
> be they just simple names of funtions/methods or their full 'signatures'
> (let us not even start on (1) how difficult with Perl's type system
> and functions it is to define signatures (2) the difficulty in
> defining an ontology/vocabulary), either would not really be enough.

I really would suggest a close look at CORBA's IDL. I don't know if it can
handle not-objects, as I'm sure it's desired. But I think having CORBA & IDL
support will be certainly a need in Perl6, as it was stated this was one of
the objectives behind making strong-typing possible. If IDL could be used in
general, it would also make it more friendly to programmers that don't have
OO background to learn it (by contrasting it with the Perl language...).
Maybe I'm shooting way off here, and IDL is too far away from Perl, but I
guess it's worth looking into...


> What I think is needed is some sort of opaque tag: the name of the
> 'contract' the API claims to fulfill.  The name can be the name of
> the standard, the name of the company, the name of the individual.
> (Java does a very similar thing but they propose embedding the DNS
> name as part of the package name: I think they the right idea but
> the proposed implementation sucks.)

Well, there's a thing that really bothers me in Perl5, that's related to
this (could solve this), that I wanted to see solved in Perl6. The thing is,
when I download a module from Internet, say module Foo, then I install it
and try to use it, it promptly breaks when it tries to `use Bar' and sees
that Bar is not installed on my system. So I have to go on to Internet
again, find Bar, install it, so on, until I find Bar needs Baz, or anything
like it.

Well, I think this could be handled by Perl itself. I don't know if there's
a way of doing it directly with CPAN, but I think it should be independent
of CPAN, since there could be proprietary modules, that someone would like
to expose only to their own users. So, what I propose is attaching a URL to
each `use'-d module, as

# use Bar & Baz
use Bar  URL => 'http://www.cpan.org/modules/Bar';
use Baz  URL => 'ftp://my.local.domain/pub/share/perl-modules/Baz', VERSION
=> 2.0;


This way, Perl could automatically fetch and install modules (supposing
module install is not so hard as now, involving makefiles, and such...). And
this could also be used to identify interfaces. That's only an idea, but I
think it can lead to good things.

- Branden



Reply via email to