Re: A Perl Version of Java's import

I like the idea. I think it should be kept as minimal as possible, though - not 'Our::Code::O*' just 'Our::Code::*'.

I'm not sure about the import part. On the one hand, I want it to just be like a shortcut for a namespace, so not do an import; but on the other hand, that would be really messy to do the import at the last minute when you actually use a module from that namespace. I think you also have a problem of it not just being new that can be used, as some modules can use other names, and also there are package variables. I'm not sure how Java deals with package variables and namespaces.

And the last question about resolving DateTime versus Our::Code::DateTime, how does Java deal with that? Is it like putting the namespace at the beginning of @INC?

Comment on Re: A Perl Version of Java's import Select or Download Code

Replies are listed 'Best First'.
Re^2: A Perl Version of Java's import by Ovid (Cardinal) on Aug 07, 2007 at 10:32 UTC
Java deals with this by refusing to import any classes which conflict with other classes. Perl's dynamic nature makes this rather difficult to guarantee. This is particularly troublesome because authors might dynamically build a class at runtime, populate the namespace but not add an entry to `%INC`, thus causing mysterious bugs when only an `%INC` entry is relied upon when you actually need to check for the existence of a given namespace. I can work around some of this, but some of it would be in the hands of a programmer to be careful. I think this is the biggest drawback to this module. However, the question is whether or not this will prove to be a prevalent problem in practice, as opposed to theory. I've seen people refuse to use code whose philosophy they theoretically disagree with even when the reality is far less problematic than it's made out to be. Cheers, Ovid New address of my CGI Course.	[reply]

Replies are listed 'Best First'.

Re^2: A Perl Version of Java's import
by Ovid (Cardinal) on Aug 07, 2007 at 10:32 UTC

Java deals with this by refusing to import any classes which conflict with other classes. Perl's dynamic nature makes this rather difficult to guarantee. This is particularly troublesome because authors might dynamically build a class at runtime, populate the namespace but not add an entry to %INC, thus causing mysterious bugs when only an %INC entry is relied upon when you actually need to check for the existence of a given namespace.

I can work around some of this, but some of it would be in the hands of a programmer to be careful. I think this is the biggest drawback to this module. However, the question is whether or not this will prove to be a prevalent problem in practice, as opposed to theory. I've seen people refuse to use code whose philosophy they theoretically disagree with even when the reality is far less problematic than it's made out to be.

Cheers,
Ovid

New address of my CGI Course.

[reply]