Re: [scala-user] namespacing in Scala - a suggestion

[Josh Suereth]

This kind of statement (possible language improvements) belongs on the Scala debate mailing list.   Please move continued discussion there.

If discussing an implementation, scala-internals.

If asking how scala's imports differ from RDF, then scala-user is fine.

On Jul 11, 2012 4:38 AM, "Geir Hedemark" <geir.h...@gmail.com> wrote:

On 2012, Jul 11, at 10:33 AM, Henry Story wrote:
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
> @prefix : <#> .  // this is the prefix for the local names
>
> :me a foaf:Person;
>   foaf:name "Henry Story";
>   foaf:homePage <http://bblfish.net/> .
>
> Here it is clear when I see the relation foaf:homePage exactly what its namespace is (and also where I can find it: namely at http://xmlns.com/foaf/0.1/homePage (just click that).
>
> I think it would be really worth the Scala language designers to think about this for future improvements. this could make a big difference.
>
>
> Just a thought,...

As a scala user I absolutely do _not_ want the versions of the libraries I use to show in my code, thank you so very much. I want the versions to be located centrally, in one file. In this case, that would be the sbt build file.

That way, I don't have to touch hundreds of files when I want to do a minor upgrade of a library.

yours
Geir

[Daniel Sobral]

On Wed, Jul 11, 2012 at 5:33 AM, Henry Story <henry...@gmail.com> wrote:
> Here is a thought which comes from working with RDF, especially the N3 notation and it's simpler sibling Turtle [1]. If you want a quick summary of RDF it can hold in one sentence: it is a logical system built on URIs for global distributed information networks. That is Naming is key to it. Languages such as Java that work usually with closed world assumptions don't see this aspect of things so clearly. But there is something that Scala could learn from it for future versions. Let me explain.
>
> In Scala the naming system requires one to use more and more sophisticated IDEs. Why? For many reasons, but one of them is that imports such as
>
> import foo.util._
> import bar.twiddledee._
>
>
> import all names in those packages into the namespace locally. The only way to know when one finds a class - e.g. a class called Sphinx - in the file containing those imports, say in the

That's because having namespaces spread all over the code is noise,
and it detracts from everyone's ability to work on the source code,
for the sole benefit of making clear where an identifier comes from --
which IDEs can do for the programmer without getting in the way.

Note that you can easily declare prefixes for namespaces and use it,
if you want to, as Rex has shown.

--
Daniel C. Sobral

I travel to the future all the time.

[Henry Story]

Here is a new issue that comes up because the namespace design is not clean.

I often find that I see code with lots of imports

import org.fun.scala._

import net.love.programming._

import me.pet.project._

...

It is not unusual for projects to have 20 of these.

Then you have code that uses a lot of methods. But somehow perhaps you no longer have access to the jars - perhaps they dissapeared as when scala-tools recently was taken down. 

Now you have no way of knowing which package the methods used in the code are referring to.   Take the code

    def foo(arg: Blob): Vlorg 

does Blob refer to 

 - org.fun.scala.Blob

 - net.love.programming.Blob

 - me.pet.project.Blog

 ....

You may have to search the whole web to find that out.

[Rex Kerr]

If you have your own jar built when it's working, you can find out easily enough by looking at the bytecode.  If you just have source code, yes, it might be tricky to find out which package provided a missing class Foo.  (This is a general problem for programming, not just for Scala.  You may elect, for your own code, to add bulk to the source code to try to fix this.  Java encourages (with IDE support) listing each import on its own rather than using wildcard imports, for example.)

  --Rex