#105 Proposal: Less Java-dependent importing
Submitted by Kevin Reid at
http://www.eros-os.org/pipermail/e-lang/2004-December/010195.html
:
1. For any Java type foo.Bar, accept
<import:foo.makeBar> as equivalent to <import:foo.Bar>,
and deprecate (with a warning on use) the latter.
1a. Wait for adoption of the above.
2. Redefine <import:foo.Bar> to be equivalent to
current <type:foo.Bar>, and deprecate <type>.
2a. Wait for adoption of the above.
3. Remove <type>.
Benefits:
* code need not care whether makers and types it
imports are implemented in E or Java
* there will be slightly less of "the underlying java
bleeding through too much", as David Mercer put it recently
* there is no longer a whole namespace (<type>) that is
specific to Java libraries (objects? classes?
importables?) only
Alternate path, preserving backward compatibility
indefinitely:
For any Java type foo.Bar, accept <import:foo.makeBar>
as equivalent to current <import:foo.Bar>.
For any Java type foo.Bar, accept <import:type.foo.Bar>
as equivalent to current <type:foo.Bar>.
Redefine <type> as <import:type.*>.
(Or, if you'd prefer to preserve package grouping in
the filesystem, use <import:foo.type.Bar>, which is
slightly more complicated to implement and could be
argued to stomp on others' namespaces.)
Logged In: YES
user_id=54168
We have done most of step #1, but are not yet issuing a warning
Logged In: YES
user_id=54168
We are now also issuing a warning, and many individual cases
have been fixed.
Logged In: YES
user_id=54168
As Kevin suggested, we now warn on old style Java imports,
such as <unsafe:java.lang.System>, and suggest these be
replaced with <unsafe:java.lang.makeSystem>.
This version does not yet import Java nested classes
correctly. In this version, you need to change
<swing:event.HyperlinkEvent$EventType>
to
<swing:event.HyperlinkEvent$makeEventType>
rather than
<swing:event.makeHyperlinkEvent$makeEventType>