Responses in-line:
On 28 May 2010 16:39, Reinier Zwitserloot wrote:
> Ah, that helps.
>
> There remain things you cannot do with that which are perfectly
> possible with java's generics. For example:
>
> someNumberList.addAll(someIntegerList);
>
>
Perfectly valid, so if we assume the existence
Ah, that helps.
There remain things you cannot do with that which are perfectly
possible with java's generics. For example:
someNumberList.addAll(someIntegerList);
For that to work, a List has to be some sort of List,
so List would need to be declared as List[+T]. However, if you do
that, you br
Sorry I couldn't give a full reply sooner! The android phone may be a
wonderful thing, but it's ill-suited for writing small essays :)
To elaborate then... First consider the Lists.transform method in Google
Collections, with the signature:
public static List transform(
List fromLi
Generics are complex (more to produce API than consume), but I
> don't
> > > > think
> > > > > > it's fair to say that all it did was add boilerplate. As a
> consumer of
> > > > > > generified API, I hardly ever see cast
e (which should count as
> > > a
> > > > > reduction in boilerplate as well as an improvement in type safety --
> > > one of
> > > > > Java's cornerstones), I don't have to express in comments what is now
> > > both a
> > > > &g
On 28 Mai, 03:04, Reinier Zwitserloot wrote:
> What is this, a terrorist interrogation? Stop being flippant.
Wow! Just wow.
> What do you mean with declaration site variance then?
When declaring a type with a type parameter T that only appears in co/
contravariant position you mark it as such. It
What is this, a terrorist interrogation? Stop being flippant. What do
you mean with declaration site variance then?
On May 27, 8:39 pm, Kevin Wright
wrote:
> The obvious answer here is: Java uses call-site variance
>
> On 27 May 2010 19:16, "Reinier Zwitserloot" wrote:
>
> I haven't seen any pro
this is just in! Initial Project Lambda prototype code push:
http://bit.ly/a2SApZ
On May 27, 2:39 pm, Kevin Wright
wrote:
> The obvious answer here is: Java uses call-site variance
>
> On 27 May 2010 19:16, "Reinier Zwitserloot" wrote:
>
> I haven't seen any proposals back then or now or know o
The obvious answer here is: Java uses call-site variance
On 27 May 2010 19:16, "Reinier Zwitserloot" wrote:
I haven't seen any proposals back then or now or know of any languages
that use "call site variance". Can you elaborate a bit on what this
means?
On May 27, 2:15 pm, Viktor Klang wrote:
> > > > Generics are complex (more to produce API than consume), but I
> > don't
> > > > think
> > > > > > it's fair to say that all it did was add boilerplate. As a
> > consumer of
> > > > > > generified API, I hardly ever see casts anymo
#x27;t
> > > think
> > > > > it's fair to say that all it did was add boilerplate. As a
> consumer of
> > > > > generified API, I hardly ever see casts anymore (which should count
> as
> > > a
> > > > > reduction in boilerplate as well as an improvement in type s
> generified API, I hardly ever see casts anymore (which should count as
> > a
> > > > reduction in boilerplate as well as an improvement in type safety --
> > one of
> > > > Java's cornerstones), I don't have to express in comments what is now
> > bo
cornerstones), I don't have to express in comments what is now
> both a
> > > concrete expression in the code and is picked up by javadoc. It has
> made
> > > light structural typing convenient (rolling your own Pair-like
> constructs).
> >
> > > Alexey
> &
t; > 2001 Honda CBR600F4i (CCS)
> > 2002 Suzuki Bandit 1200S
> > 1992 Kawasaki EX500
> >http://azinger.blogspot.com
> >http://bsheet.sourceforge.net
> >http://wcollage.sourceforge.net
>
> > --
> > *From:* Kevin Wright
>
Generics attempt to represent co- and contravariance in the type
system.
co- and contravariance are inherently complex. You can't make them non-
complex. See scala, haskell, and any other language with them. You
could go without it altogether, but then we have a dynamic typing
system - a system wh
> *From:* Kevin Wright
> *To:* javaposse@googlegroups.com
> *Sent:* Wed, May 26, 2010 11:29:52 AM
> *Subject:* Re: [The Java Posse] Re: "The closure debate is pants" - No, no
> it isn't.
>
> There's *some* merit in objecting based on compl
Well, the promise of closures has always been to support more elegant
(functional) styles of programming; so I'm ever hopeful...
I'm under no illusion that Java can ever be made as syntactically nice as a
language designed with this stuff from the beginning.
But, until we can persuade everyone to
ki Bandit 1200S
1992 Kawasaki EX500
http://azinger.blogspot.com
http://bsheet.sourceforge.net
http://wcollage.sourceforge.net
From: Kevin Wright
To: javaposse@googlegroups.com
Sent: Wed, May 26, 2010 11:29:52 AM
Subject: Re: [The Java Posse] Re: "The closure
On Wed, May 26, 2010 at 5:29 PM, Kevin Wright wrote:
> There's *some* merit in objecting based on complexity
I don't see the difference between anon classes and closures from a
complexity-standpoint if we omit non-local returns and control flow.
>
> Why must it always be the case (in Java at
There's *some* merit in objecting based on complexity
Why must it always be the case (in Java at least) that new functionality so
often seems to come with a whole bucketload of new boilerplate as well?
Other languages have already shown us that this needn't be the case, and
that features can be c
oh well. Back in the box I go
On Wed, May 26, 2010 at 3:41 PM, Viktor Klang wrote:
>
>
> On Wed, May 26, 2010 at 4:36 PM, Reinier Zwitserloot
> wrote:
>>
>> Rakesh, as I already said, closures itself are in. Folks like you that
>> think generics sucked and closures are too complicated lost.
On Wed, May 26, 2010 at 4:36 PM, Reinier Zwitserloot wrote:
> Rakesh, as I already said, closures itself are in. Folks like you that
> think generics sucked and closures are too complicated lost.
> Fortunately.
>
Hehe, :-)
>
> On May 26, 11:42 am, Rakesh wrote:
> > I recently read Coders At Wo
Rakesh, as I already said, closures itself are in. Folks like you that
think generics sucked and closures are too complicated lost.
Fortunately.
On May 26, 11:42 am, Rakesh wrote:
> I recently read Coders At Work and in the interview with Joshua Bloch,
> he pretty much inferred that generics may
non-local returns and control flow in general are 'out' - they have
been explicitly excluded from the scope of project lambda.
However, the ability of whatever proposal makes it to be expanded
later to support of course isn't, and this is in fact a (minor) aspect
of the closure debates - how much
Most definitely!
Use-site variance declarations are a total pain, and worse still, they push
that pain onto library consumers... never good.
For comparison, take a look at the declaration-site variance that Scala
uses. In this regards it's a very different type system to Java, made
possible in pa
I recently read Coders At Work and in the interview with Joshua Bloch,
he pretty much inferred that generics may not have been a good thing
because of the complexity it produced.
If generics had been used to restrict types in collections, fine but
people were using the and too much
making things
Another point brought up I think on the IllegalArgument podcast was
how these would interact with non java languages - ie if JDK apis
start using these closures - how will they map to other languages
model of a closure.
On May 26, 12:24 am, Reinier Zwitserloot wrote:
> I got the impression from D
27 matches
Mail list logo
