[groovy-dev] extending the import statement

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[groovy-dev] extending the import statement

Jochen Theodorou
Hi all,

as some may have noticed I made a very big commit this week. The commit
changes the way names are resolved to classes in groovy a little. It
seems that it was possible to do the following:

evaluate("Foo.groovy")
Foo a = new Foo()

where Foo is a class loaded through evaluate. This will not be possible
with my changes! The mechanism above worked only if Foo was in no
package if I remember right. But this leads to an problem... How to
resolve names of classes when the classname is not equal the filename?

my first idea for this is to not only look for a script file named like
the class we are searching for, but also for a file that has the same
name as the class. That would be easy to implement and would work at
runtimetime the same as at compile time

my next idea is to extend the import statement to something like:

a) import foo.Foo as Bar from "../Script.groovy"
b) import "AnotherScript.groovy"
c) import foo.Foo2 from "scripts/YetAnotherScript.groovy"

the "as" is used to change the visible name of a class. That's not new,
just rarely used. New is the from-part, pointing to a script file
relative to the current's file location.

In case a, a class Foo is imported from a script and will be known as
Bar in the current file. If the scriptfile contains only classes in the
default package, all classes are important implicitly. If they have a
package name, then that name has to be used if there is not another
import statement like "import foo.*" which dequalifies the name.
In case b we simply import all classes from the script, that's still
different from an include. The classes are referenced using the fully
qualified name as long as there is no other import statement, changing
that. The location of the script is in the same directory as the current
classes script file. Case c) is like a, but without renaming, the class
will be useable through the name "Foo2"

This solution doe require a syntax change and it does not work at
runtime. If any of such imported scripts classes are removed, the
runtime is not able to recompile the missing script as it would do now.

Maybe someone has an idea how to do this. Or maybe none of these options
are that great and another option should be thrown in the arena. Just
let me know ;)

bye blackdrag

Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] extending the import statement

tugwilson

On 15 Nov 2005, at 20:11, Jochen Theodorou wrote:

>
> Maybe someone has an idea how to do this. Or maybe none of these  
> options are that great and another option should be thrown in the  
> arena. Just let me know ;)


I like b!



John Wilson
The Wilson Partnership
http://www.wilson.co.uk


Reply | Threaded
Open this post in threaded view
|

RE: [groovy-dev] extending the import statement

Dierk König
In reply to this post by Jochen Theodorou
> a) import foo.Foo as Bar from "../Script.groovy"
> b) import "AnotherScript.groovy"
> c) import foo.Foo2 from "scripts/YetAnotherScript.groovy"

cool ;-)

> the "as" is used to change the visible name of a class. That's not new,
> just rarely used.

I personally, use it much more often than I expected at first. :-)

> New is the from-part, pointing to a script file
> relative to the current's file location.

Hm, hm, I must say that Ruby's require works with relative file
locations and it drove me crazy (that's one reason for my
apparent craziness).
The problem comes with transitivity of imports and starting
from different locations (e.g. when testing a sub-suite).

I would like it much better to resolve against classpath roots.
Is that reasonable?

cheers
Mittie
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] extending the import statement

Jochen Theodorou
Dierk Koenig schrieb:

>>a) import foo.Foo as Bar from "../Script.groovy"
>>b) import "AnotherScript.groovy"
>>c) import foo.Foo2 from "scripts/YetAnotherScript.groovy"
>
> cool ;-)

I'm a bit surprised you all like b), but well, why not ;)

>>the "as" is used to change the visible name of a class. That's not new,
>>just rarely used.
>
> I personally, use it much more often than I expected at first. :-)

I know such a mechnism from Ada95, and I didn't liked it there

>>New is the from-part, pointing to a script file
>>relative to the current's file location.
>
> Hm, hm, I must say that Ruby's require works with relative file
> locations and it drove me crazy (that's one reason for my
> apparent craziness).
> The problem comes with transitivity of imports and starting
>>from different locations (e.g. when testing a sub-suite).
>
> I would like it much better to resolve against classpath roots.
> Is that reasonable?

the problem I see is that
1) a file to be compiled maynot be part of the classpath, because it is
given at commandline
2) there are multiple classpath roots, each may contain a script of that
name

currently 2) is a problem too, so it would be not more worse than now.
but in combination with 1... currently a class given on the commandline
ios only compiled once, because I all files are poarsed one time and
then I know the classes that are inside. If I see import "f.groovy", I
may find a script with that name additional to the script I have given
at the command line. In the best case both are compiled and nothing
happens. In the worst case they the classpath script defines a class
that is already defined and you will not have a clue why there is an
error report about a f.groovy, which doesn't contain that class, because
you are looking at a different file. of course if we say we don't use
ioption b, then we will not have this problem directly, but it only
lowers the pccurance of the random event that I have a class I am
importing in a script on the classpath I am importing..

and simply adding alle files given on the commandline to the classpath
is no soultion too, since they don't have to be in a directory matchung
the package name.

bye blackdrag
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] extending the import statement

Jochen Theodorou
In reply to this post by Dierk König
Dierk Koenig schrieb:

>>a) import foo.Foo as Bar from "../Script.groovy"
>>b) import "AnotherScript.groovy"
>>c) import foo.Foo2 from "scripts/YetAnotherScript.groovy"
>
> cool ;-)

I'm a bit surprised you all like b), but well, why not ;)

>>the "as" is used to change the visible name of a class. That's not new,
>>just rarely used.
>
> I personally, use it much more often than I expected at first. :-)

I know such a mechnism from Ada95, and I didn't liked it there

>>New is the from-part, pointing to a script file
>>relative to the current's file location.
>
> Hm, hm, I must say that Ruby's require works with relative file
> locations and it drove me crazy (that's one reason for my
> apparent craziness).
> The problem comes with transitivity of imports and starting
>>from different locations (e.g. when testing a sub-suite).
>
> I would like it much better to resolve against classpath roots.
> Is that reasonable?

the problem I see is that
1) a file to be compiled maynot be part of the classpath, because it is
given at commandline
2) there are multiple classpath roots, each may contain a script of that
name

currently 2) is a problem too, so it would be not more worse than now.
but in combination with 1... currently a class given on the commandline
ios only compiled once, because I all files are poarsed one time and
then I know the classes that are inside. If I see import "f.groovy", I
may find a script with that name additional to the script I have given
at the command line. In the best case both are compiled and nothing
happens. In the worst case they the classpath script defines a class
that is already defined and you will not have a clue why there is an
error report about a f.groovy, which doesn't contain that class, because
you are looking at a different file. of course if we say we don't use
ioption b, then we will not have this problem directly, but it only
lowers the pccurance of the random event that I have a class I am
importing in a script on the classpath I am importing..

and simply adding alle files given on the commandline to the classpath
is no soultion too, since they don't have to be in a directory matchung
the package name.

bye blackdrag