| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Everyone knows that a `help` command will result in `more information`.
This commit moves the version string to the second line and adds some
verve to the welcome.
If anyone can't live without the old banner, they are now able to
configure it explicitly, so there is still no blood on our hands.
```
$ scala
Welcome to Scala version 2.11.6 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_40).
Type in expressions to have them evaluated.
Type :help for more information.
scala> :quit
$ skala
Welcome to Scala!
version 2.11.7-20150623-155244-eab44dd092 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_40).
Type in expressions for evaluation. Or try :help.
scala> :quit
```
REPL tests now lop off the actual length of the welcome header; or, if
necessary, remove the version number from a header embedded in output.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Closing the REPL with Ctrl+D does not issue a newline, so the user's
prompt displays on the same line as the `scala>` prompt. This is bad.
We now force a newline before closing the interpreter, and display
`:quit` while we're at it so that people know how to exit the REPL
(since `exit` doesn't exist anymore).
The tricky part was to only add a newline when the console is
interrupted, and *not* when it is closed by a command (like `:quit`),
since commands are processed after their text (including newline) has
been sent to the console.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It’s almost 1am, so I’m only scratching the surface, mechanistically
applying the renames that I’ve written down in my notebook:
* typeSignature => info
* declarations => decls
* nme/tpnme => termNames/typeNames
* paramss => paramLists
* allOverriddenSymbols => overrides
Some explanation is in order so that I don’t get crucified :)
1) No information loss happens when abbreviating `typeSignature` and `declarations`.
We already have contractions in a number of our public APIs (e.g. `typeParams`),
and I think it’s fine to shorten words as long as people can understand
the shortened versions without a background in scalac.
2) I agree with Simon that `nme` and `tpnme` are cryptic. I think it would
be thoughtful of us to provide newcomers with better names. To offset
the increase in mouthfulness, I’ve moved `MethodSymbol.isConstructor`
to `Symbol.isConstructor`, which covers the most popular use case for nme’s.
3) I also agree that putting `paramss` is a lot to ask of our users.
The double-“s” convention is very neat, but let’s admit that it’s just
weird for the newcomers. I think `paramLists` is a good compromise here.
4) `allOverriddenSymbols` is my personal complaint. I think it’s a mouthful
and a shorter name would be a much better fit for the public API.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One last flurry with the broom before I leave you slobs to code
in your own filth. Eliminated all the trailing whitespace I
could manage, with special prejudice reserved for the test cases
which depended on the preservation of trailing whitespace.
Was reminded I cannot figure out how to eliminate the trailing
space on the "scala> " prompt in repl transcripts. At least
reduced the number of such empty prompts by trimming transcript
code on the way in.
Routed ConsoleReporter's "printMessage" through a trailing
whitespace stripping method which might help futureproof
against the future of whitespace diseases. Deleted the up-to-40
lines of trailing whitespace found in various library files.
It seems like only yesterday we performed whitespace surgery
on the whole repo. Clearly it doesn't stick very well. I suggest
it would work better to enforce a few requirements on the way in.
|
| |
|
| |
|
|
|
|
|
|
| |
This brings all the files into line with the .gitattributes
settings, which should henceforth be automatically maintained
by git.
|
|
Our name mangling scheme w.r.t stuff nested into objects conflicts
with JVM's ideas of beauty, which messes up getDeclaredClasses.
Scala reflection needs getDeclaredClasses to convert between Scala and Java,
so the situation looked grim. Greg suggested a workaround described in:
https://issues.scala-lang.org/browse/SI-4023?focusedCommentId=54759#comment-54759.
Luckily the workaround worked!
|