Import required?

[Harri Porten]

Hello Jeff,

On Mon, 9 Apr 2007, Jeff Dyer wrote:

> 'import' is not required to access a package property with a fully
> qualified reference. However, the package qualifier must be statically
> known to be a package name so that the reference can be properly
> resolved ahead of time.
[...]

> There is no loading implied by 'import'.

I see what you mean. Although I'm not sure whether I agree it's the best 
solution :)

> It is simply the way to open a
> package namespace. Implementations can add loading semantics to import
> pragmas and package qualified references if they want to. FlexBuilder
> does this by searching a "class path" to find references to definitions
> outside of the current program.

How does FlexBuilder error out if a package could not be found? With an
"Package not found" error at compile time? At run time?

The reason why I am bringing this up: in some environment there can be 
numerous reasons for a package access (said in neutral terms) to fail. Be 
it a lack of an extension installation, incompatible versions or maybe the 
package's author desire to throw an exception from an initialization 
function. Throwing an exception (or compile error?) on "import" sounds 
feasible. But what if the developer did as you suggested and wrote

  package Foo.Bar { }

What kind of error will he get if Bar is not available?

Before I discovered that the ES4 effort was pick up again I had added 
"import" support to a forked version of the KDE JS library. I (perhaps 
naively) implemented the following semantics:

- import loads a module and that loading can cause an exception
- A module object is created that gets populated with the package's
   symbols.

Granted, an import into the local namespace might be desired in some 
cases. This could be solved by a syntax similar to Perl's "use" or 
Python's "import x ... from y".

Harri.