My comments:1) I'd call the new feature "export", because: a) hard to understand what "implicit import" means (import all implicits? import only implicits?), b) export is used for similar purpose in Lisp
2) I think we need just an additional field in ClassSymbol instead of a designated ImportSymbol
3) Also I'd prefer if we had a new AST node for "implicit import" or "export" in order not to break already existing usages of Import(_, _)
Problem that export is not a keyword now, so we must or add export as new keyword (which would break existing code) or think about context-depended 'export' keyword [which add complexity to grammar]implicit import may be is not such intuitive as export, but it does not break existing code and does not require new keywords. From other side -- it's not contr-intuitive: implicit imports are introduced into scopes exactly as implicit vars and defs.
And yet one variant about export: it can-be be keyword only if language.export included ?i,e, if we have import language.export than export is keyword, otherwise -- normal identifier.
And could even be used as a way to shoehorn whitespace sensitive syntax into the language! This would give everybody what they want: I'd have cleaner code and the haters would have yet another thing to complain about the complexity of.
On a serious note though, this would be an excellent way to introduce changes like sip-12, whilst also providing a convenient way to allow old code to compile after it or similar changes became part of the spec.
Another interesting idea: public imports from D: http://dlang.org/module.html.
"public import" is not bad, but I have similar concerns as Russ here. I'm not sure how it fits into Scala's philosophy that things are public by default and you have to explicitly restrain the accessibility. "public" is not a keyword in Scala, but every Scala programer understands the word "public" in the "java"-sense, but in "public import" it is a different sense. So to summarize in "public import":
1. "public" used in different sense
2. "public" used at all, i.e. public is not default
How about:
@visible import
import @pass
On Tue, Sep 11, 2012 at 3:56 PM, Jan Vanek <j3v...@gmail.com> wrote:
"public import" is not bad, but I have similar concerns as Russ here. I'm not sure how it fits into Scala's philosophy that things are public by default and you have to explicitly restrain the accessibility. "public" is not a keyword in Scala, but every Scala programer understands the word "public" in the "java"-sense, but in "public import" it is a different sense. So to summarize in "public import":
1. "public" used in different sense
I think it is the same sense. Private variables are ones you don't access externally. Private imports are ones you don't access internally. Public variables are ones you can see externally. Public imports are ones you can see externally. How is it a different sense?
2. "public" used at all, i.e. public is not default
That is true.
How about:
@visible import
import @pass
I don't like using annotation syntax to control basic language features that change the interface of the class. It is okay to parse random words before "import" since
import cannot occur in very many places in the language.
So,
broadcast import
forwards import
export import
import and export
should all work. It's a little tricky in that "import" is used as a verb, so we need an adverb like "exportingly".
--Rex
public/protected/private controls the accessibility of members, of something what is "physically" there. "import" puts a name in the scope, where the name is not "physical" as members are. With "public import" you don't control the accessibility of the name, rather you make the name importable.On 11.09.2012 22:14, Rex Kerr wrote:
On Tue, Sep 11, 2012 at 3:56 PM, Jan Vanek <j3v...@gmail.com> wrote:
"public import" is not bad, but I have similar concerns as Russ here. I'm not sure how it fits into Scala's philosophy that things are public by default and you have to explicitly restrain the accessibility. "public" is not a keyword in Scala, but every Scala programer understands the word "public" in the "java"-sense, but in "public import" it is a different sense. So to summarize in "public import":
1. "public" used in different sense
I think it is the same sense. Private variables are ones you don't access externally. Private imports are ones you don't access internally. Public variables are ones you can see externally. Public imports are ones you can see externally. How is it a different sense?
I was not aware of it - that the interface of the class would be changed. I thought it was strictly about visibility of names. Still, even if that was true, I agree that annotation would be on the edge.
I don't like using annotation syntax to control basic language features that change the interface of the class. It is okay to parse random words before "import" since