Import required?
'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.
Here are two cases to illustrate this point (program 2 gets loaded after program 1):
CASE 1
// program 1 package p.q { public var x = 10 }
// program 2 print(p.q.x) // error: unresolved reference to 'p'
CASE 2
// program 1 package p.q { public var x = 10 }
// program 2 package p.q {} // could also be an import of any member of 'p.q' print(p.q.x) // prints 10
There is no loading implied by 'import'. 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.
Jd
-----Original Message----- From: es4-discuss-bounces at mozilla.org [mailto:es4-discuss- bounces at mozilla.org] On Behalf Of Harri Porten Sent: Sunday, April 08, 2007 9:05 AM To: es4-discuss at mozilla.org Subject: Import required?
Hello,
reading the description of the "import" directive
"An ImportDirective causes the simple and fully qualified names of
one
or more public definitions of the specified package to be
introduced
into the current package."I am wondering whether "import" is required to access definitions
inside a
package. After all, the symbols can otherwise be accessed directly as shown by the cited in the Package section:
package P { function f() {} } P.f()
If "import" is required I suggest to make this "loading" aspect a bit clearer in the text. Actually, I am wondering whether there is a way
to
just just load a package without polluting the current namespace. A
bit
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.
Hello,
reading the description of the "import" directive
"An ImportDirective causes the simple and fully qualified names of one or more public definitions of the specified package to be introduced into the current package."
I am wondering whether "import" is required to access definitions inside a package. After all, the symbols can otherwise be accessed directly as shown by the cited in the Package section:
package P { function f() {} } P.f()
If "import" is required I suggest to make this "loading" aspect a bit clearer in the text. Actually, I am wondering whether there is a way to just just load a package without polluting the current namespace. A bit like "use" vs. "require" in Perl.
Harri.
Hello, reading the description of the "import" directive "An ImportDirective causes the simple and fully qualified names of one or more public definitions of the specified package to be introduced into the current package." I am wondering whether "import" is required to access definitions inside a package. After all, the symbols can otherwise be accessed directly as shown by the cited in the Package section: package P { function f() {} } P.f() If "import" is required I suggest to make this "loading" aspect a bit clearer in the text. Actually, I am wondering whether there is a way to just just load a package without polluting the current namespace. A bit like "use" vs. "require" in Perl. Harri.