On 9 September 2010 11:47, Ricky Clarkson <[email protected]> wrote:
> I'm reasonably convinced that a minor modification from Scala will be
> a definite improvement over Java that even the more conservative Java
> users would not object to.
>
> So far, I think that modification would include:
>
> . C# style extension methods instead of implicit conversions.
>
They're en-route
> . Implicit parameters altered to look more like dependency injection
> (which they are).
>
Except when they're not, such as type classes
> . Absolute rather than relative package names.
>
ouch, boilerplatey. Relative names are especially nice when doing inline
imports.
> . No importing other than from packages.
>
I love this feature, it's one of my favourites. Why would you possibly want
to drop it.
> . Reification as Manifest provides, but without having to write it in
> the code explicitly.
>
There's a cost in using Manifests. Then JVM should optimise this away in
most cases, but I can still see it harming performance in a lot of scenarios
where the manifest isn't even used.
Also, what about interop with JavaFX, JRuby, Jython, etc.?
. C#'s covariance and contravariance syntax <in T>, <out T> instead of
> Scala's [-T], [+T]. I can never remember which the Scala syntax
> means.
>
Ironically, .NET has had co/contra-variance since version 2.0 of the CLR,
and uses +/- notation in IL.
I personally prefer +/-, thinking of `-` as negation
> . No wildcards.
>
Wildcards in generics have already been removed from Java as they aren't
needed with declaration-site variance.
Wildcards in imports are a feature copied from Java, do you propose to
remove these?
. No casting. Use type classes (via injection, see above) for things
> like equality so that you don't need an equals(Object).
>
This would *seriously* mess up interop with other languages on the JVM.
Interop is currently one of Scala's main goals
. Closure conversion as in the Java proposals. I.e., val runnable:
> Runnable = () => println("hello") should compile to final Runnable
> runnable = new Runnable() { public void run() { println("hello") } };
>
Automatic conversion of a function to a SAM type? Seems reasonable.
> . No underscores as lambda parameters, i.e., foo.map(_ + 2) has to be
> written foo.map(x => x + 2).
>
Again, many like this feature, why must the developer be forced to invent a
name and add boilerplate where none is needed?
. No type inference for non-local members, i.e., only as much type
> inference as C# does.
>
More boilerplate?
> . C#-style type parameter inference. Java doesn't infer the type
> parameter based on the context, only the parameters passed.
>
Not entirely sure what you mean here, are you referring to the inference of
A in something like this:
def sum[A](x : List[A])(implicit ev: Manifest[A])
How might that tie in with your proposal to automatically use Manifests
everywhere?
> . Named parameters, but no default parameters. Yes, this is an arbitrary
> one!
>
They're also essential for the generated copy method in case classes!
> . An 'untyped' keyword for those who don't like compiler guarantees.
>
opt-out typing, like structural types, but with an added keyword?
> Of course the harder problem will be coming up with a name for the
> language that provides inspiration for naming libraries written for it
> (Scala is a dreadful name for this, see Scalala, ScalaTest, SUnit,
> ScalaCheck)!
Given the list of features you want to remove from Scala, it's starting to
look like a suitable name for your language might be C# :)
> Ricky.
>
> --
Kevin Wright
mail / gtalk / msn : [email protected]
pulse / skype: kev.lee.wright
twitter: @thecoda
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
