On Jan 28, 1:34 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
>
> How would this work? I don't think the scala strategy (cartoon
> swearing instead of 'extends' and 'super' keywords) is viable.
That's focusing too much on syntax. Use keywords. I don't care.
Whatever. C# 4 is stealing Scala's definition site variance, but uses
"out" and "in" to mean co- and contra- variant type parameters
respectively. Steal that. Make up your own. Who cares? It's just
syntax.
http://andersnoras.com/blogs/anoras/archive/2008/10/28/c-4-0-covariance-and-contra-variance.aspx
> > 3) Type aliasing (aka typedefs). Same motivation as with type
> > inference, but type aliases can handle types that can't be inferred.
>
> Meh. Complicates the language quite a bit just to work around some
> problems, never the right motivation for a language update.
Complicates? It's just an alias. I'm not talking about abstract
type members or anything "woah, scary" here. It's no more complicated
than public static final String MY_CONSTANT = "hello world"; Except,
you know, it's types. public static final type MY_TYPE = Foo<Bar<Baz,
Quux>>; Make it a syntax error to not make a type alias final if you
don't want the "woah, scary" stuff.
>
> > 4) Deprecate "primitive" arrays and replace with properly generic type
> > constructor Array<T>. Make Array<T> invariant so that Array<String>
> > isn't an unsound subtype of Array<Object>.
>
> Not a bad idea in a possible post-reification future but the dichotomy
> between having Array<T> that *IS* reified and List<T> that is not, is
> too great.
So hide the reified nature of Array<T> until the "post-reification
future" is here.
>
> > 5) Root the type hierarchy above object so that primitives are part of
> > the hiearchy.
>
> Maybe. But it would be a shame that the compiler isn't as helpful as
> it could be in regards to nullity. Probably better solved with .NET-
> style templating of the class code for each primitive, -or-, added
> along with full nullity support.
A hierarchy rooted above both primitives and reference types is
probably necessary to make List<int> participate in a wildcard
scheme. Scala uses "Any" as that root type, so in Java-ish notation
you could have List<? extends Any> to mean a List that might contain
primitives or objects. Feel free to make up your own word if you
don't like "Any."
.Net style polyinstantiation is nice. Along with what they call
"value types" you can do some kinds of "generic" numeric processing
much more efficiently on .Net than on the JVM.
> > 8) Don't call it "generics."
>
> Damage done. Also, only language nuts get hung up on using the proper
> verbiage. For everyone else, its a massive turn off. One of the many
> reasons that scala/haskell/lisp using language pedants are never
> actually listened to and just ignored. Too much jargon. There might be
> more suitable words, but its of little importance.
To clarify, it's not that it's incorrect verbiage. I did suggest
"foozles" as an alternative. It's just that now when I say "generic
programming" to a Java programmer he or she assumes I mean List<T>
instead of something more...well, generic. But as you say that's
damage done, and what can you do?
>
> If only Scala was a language that had more features. Like, say, 'class
> interfaces' that captured constructors and static methods.
Um, Scala doesn't have static methods. Seriously. Doesn't have 'em.
But, oddly enough, Scala can capture a requirement that an type have a
companion object with certain properties (which is where you put the
equivalent of static methods). So Scala basically achieves your goal.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
