eclipse-archived / ceylon

The Ceylon compiler, language module, and command line tools
http://ceylon-lang.org
Apache License 2.0
399 stars 62 forks source link

Discussion: do we always need two import statements? #6663

Open quintesse opened 8 years ago

quintesse commented 8 years ago

So this is just something I thought about when reading the new Ceylon tour page about modules and came to the part about the Gotcha of Ceylon always needing two import statements.

Reading that and remembering that quite a number of times when adding a new import to a module I go like "grrr, why am I basically copying this line twice?" I decided to ask the question:

"Really, why exactly do we always have to have two import statements?"

I mean in a Java world where there is(was) no modularity perhaps I can understand needing to import in each source file (after all there isn't a central place to put them anyway). But in Ceylon what does that gain us exactly? Especially in a time where almost everybody uses IDEs which make looking up things very easy it doesn't seem as necessary to have the imports appear at the top of each source file.

So how about adding the possibility to mention the declaration you want to import for all files in a module right in the module descriptor?

Like this:

module mymodule "1.0.0" {
    // Import a Ceylon module
    import ceylon.collection "1.3.0" {
        HashMap
    }
    // Import a native module
    import java.base "8" {
        java.util { JMap = Map, JHashMap = HashMap }
    }
}

You would of course still have the current way. But I see it like this: some people like to specify each and every import, others don't care so much and just use { ... }. This would just be a power-version of that.

jvasileff commented 8 years ago

I would definitely find this useful, for module wide imports and especially for import aliases. I've experimented with using aliass for module wide imports, but that doesn't work well.

This would also address the same pain point as https://github.com/ceylon/ceylon/issues/6296.

The problem I see is that it may conflict with other possible additions to module.ceylon, such as overrides and listings of package->backend associations to help with native.

xkr47 commented 8 years ago

Would it be allowed to have conflicting (overriding) imports in individual files in the module?

quintesse commented 8 years ago

@xkr47 this is a request for feedback, so instead of asking a question I'd say that if you could make a good argument for allowing that we could make it part of the proposal :)

quintesse commented 8 years ago

The problem I see is that it may conflict with other possible additions to module.ceylon

@jvasileff we might indeed need to think about that. Perhaps something like:

    import ceylon.collection "1.3.0" {
        HashMap
    }
    overrides {
        // Put overrides here
    }
    native {
        // Put native mappings here
    }

But I admit this might be getting out of hand ;)

LisiLisenok commented 8 years ago

The feature might be available for packages also, like:

package mymodule.mypackage "1.0.0" {
    // Import a Ceylon module
    import ceylon.collection "1.3.0" {
        HashMap
    }
    // Import a native module
    import java.base "8" {
        java.util { JMap = Map, JHashMap = HashMap }
    }
}
xkr47 commented 8 years ago

Great idea! I think the overriding rules should work the same as in #6646. I like the idea of being able to bootstrap new modules with some basic set of imports that I always need but also always forget where to find :)

jvasileff commented 8 years ago

The feature might be available for packages also

That sounds like a great idea to me, and much more natural than module wide imports (even declarations made in the same module aren't automatically imported across package boundaries). It also solves the problem with module.ceylon serving too many purposes.

xkr47 commented 8 years ago

I vote for both!

The version number is not supposed to be in the package statement I guess?