Yes, but, now try to work with these. As you said before, '?? extends
Foo' is general purpose: It's compatible with ?! extends Foo..
However, neither ?! super Foo, nor ?? super Foo, are general
purpose. ?! cannot be assigned to ?? because, obviously, ?? would
allow you to add nulls to this list.
However, ?? cannot be assigned to ?! either. Okay, sure, when adding
things this works out fine (forced to add non-null, so that's great),
but, you can still read from these things; you just get Object back.
However, in the case of ?! super Foo, it would be really -really-
strange if "Object?" instead of "Object!" rolled out.
Now try this with no bounds, just a type, e.g "List<String>". Without
all three modifiers (non-null, definitely null, unknown), you just
can't cover all reasonable use cases.
On Oct 20, 1:16 pm, "Viktor Klang" <[EMAIL PROTECTED]> wrote:
> Reinier,
>
> Ok, <?? super String> == Something that is a (supertype of String) or null
> or <?! super String> == something that is a supertype of String
>
> Is this what you meant?
>
> On Mon, Oct 20, 2008 at 12:17 PM, Reinier Zwitserloot <[EMAIL
> PROTECTED]>wrote:
>
>
>
> > Now try this for generics 'super' and you run into your first problem.
> > Then try without any bounds (just a flat type, not a T extends/super
> > Type).
>
> > On Oct 19, 12:12 pm, "Viktor Klang" <[EMAIL PROTECTED]> wrote:
> > > But think about it Reinier,
>
> > > type! can be assigned to a type?
>
> > > ie.
>
> > > Example no 1:
>
> > > String! ns = "";
> > > String? s : somecondition ? ns : null;
>
> > > We also for generics have:
>
> > > ?? = something or null
> > > ?! = something
>
> > > Since we cannot allow to cast:
>
> > > List!<String!> to List!<String?> (for obvious reasons)
>
> > > What we can do though is to convert non-genericised types (as the example
> > > no1)
> > > by this:
>
> > > List!<?! extends String> foo = ...
> > > List?<?! extends String> bar = ...
>
> > > bar = foo //this is ok
>
> > > But!
>
> > > Since we know that bar.get(0) returns non-null instances of subtypes of
> > > String, we can do this:
>
> > > String? baz = bar.get(0) //returns non-null instance of subtype of
> > String,
> > > and we can assign that value to a String?
>
> > > So you can write methods like this:
>
> > > public <T! extends String> doSomethingGeneric(final List!<T> thelist)
> > > {
> > > return thelist.get(0); //Completely nullsafe
>
> > > }
>
> > > Ye,s since you will not be able to cast a parametricized type to another
> > > parametricized type with changed nollness constraints, you would need
> > some
> > > additions to the standard libraries: wrapper-types that implement
> > > view-semantics (can be lazy) that provides read-only access.
>
> > > On Sat, Oct 18, 2008 at 9:50 PM, Reinier Zwitserloot <[EMAIL PROTECTED]
> > >wrote:
>
> > > > You can't enforce one of the two with no way to go for either. That's
> > > > just not feasible. Think about it; it would be impossible to write
> > > > even the simplest utility methods.
>
> > > > Just like in generics, where you can specify: Don't care what it is
> > > > ('T extends Object', it should be possible to say: Don't care which
> > > > type of nullable we have).
>
> > > > Unlike generics, where the amount of things you can do with a random
> > > > 'T' is fairly limited, for nullity there's loads you can do. The
> > > > number of methods that never write null but do null checks when
> > > > reading / don't actually read are virtually limitless. And yet all of
> > > > those would have to pick a side and allow null or not, eventhough IT
> > > > DOESNT MATTER to them. When the type system gets in the way of you not
> > > > repeating yourself, the type system completely failed.
>
> > > > On Oct 17, 9:09 am, "Viktor Klang" <[EMAIL PROTECTED]> wrote:
> > > > > On Thu, Oct 16, 2008 at 9:21 PM, Reinier Zwitserloot <
> > [EMAIL PROTECTED]
> > > > >wrote:
>
> > > > > > On Oct 15, 3:04 pm, "Viktor Klang" <[EMAIL PROTECTED]> wrote:
> > > > > > > This expands to:
>
> > > > > > > List?<X?> list = someMethodThatReturnsAStringList();
> > > > > > > list.add("foo");
>
> > > > > > No; it doesn't. The above means that 'list.add(null);' should be
> > > > > > legal. This is a meaningful property of a type, but it does come
> > with
> > > > > > caveats. Specifically, if the 'someMethodThatReturnsAStringList'
> > > > > > method returns a list that does not allow nulls, this should be a
> > > > > > compile-time error.
>
> > > > > Of course it should.
>
> > > > > > There's really no way that I can see to get around
> > > > > > the notion that you need 3 different properties in generics
> > > > > > parameters:
>
> > > > > > A. Definitely allows null, (benefit: Can write nulls in)
> > > > > > B. Definitely does not allow null (benefit: No need to null-check
> > when
> > > > > > reading)
>
> > > > > > C. Don't know / Don't care if its allowed (benefit: Accept
> > anything)
>
> > > > > I don't think that's an option, that kind of thinking was what got us
> > > > into
> > > > > this mess in the first place.
> > > > > A type is a type is a type.
>
> > > > > String? is another type than String!
>
> > > > > Not caring about types should place you in the dynamic languages
> > section.
> > > > > Either you design the code to handle nulls, or you don't. It's
> > binary.
>
> > > > > > Because the whole point, in a sense, is to eliminate null checks as
> > > > > > much as possible, it seems fundamentally bad to ADD situations
> > where
> > > > > > you need to perform null checks (which is what you'd do if you
> > tried
> > > > > > to e.g. combine B and C, for example). that's what I meant.
>
> > > > > > Now, 3 types might be acceptable, but syntax is definitely an
> > issue.
> > > > > > ESPECIALLY if non-null becomes the default; there are two different
> > > > > > more nully options, so you need 'nully' and 'even more nully';
> > using
> > > > > > '?' and '??' seems kinda wrong, and the ? is used a lot more in
> > java
> > > > > > than the !, which makes it hard to use ? or even ??. I'd say it's
> > > > > > pretty bad to let parser architecture dictate syntax, but its
> > > > > > undeniable that suffix-! for non-null, suffix-? for most definitely
> > > > > > allows null, and -nothing- to indicate 'don't know/care' is easiest
> > on
> > > > > > the parser and thus easiest for tools out in the wild to adapt this
> > > > > > change, and easiest for the tutorials. It's not easiest on the eyes
> > > > > > once everyone's used to it, which is a pretty big problem, but for
> > now
> > > > > > it's the front-runner for me.
>
> > > > > > > Whis is exactly (I don't care wether list is null or String, and
> > if
> > > > it
> > > > > > > contains Xs or null) what you said.
>
> > > > > > > > in such a way that the method can return either a list of
> > > > strings-or-
> > > > > > > > nulls, or a list of definitely-not-null-strings.
>
> > > > > > > > Eventhough, given the only thing it does is add a non-null
> > string,
> > > > it
> > > > > > > > doesn't matter.
>
> > > > > > > > I'm pretty much positive not being able to do that makes this
> > > > feature
> > > > > > > > very stupid.
>
> > > > > > > Reinier, that's an opinion, and not an argument.
>
> > > > > > > I'd like to continue this discussion, so it'd be nice if more
> > people
> > > > join
> > > > > > in
> > > > > > > with ideas, questions, etc.
>
> > > > > > > > On Oct 14, 4:49 pm, "Viktor Klang" <[EMAIL PROTECTED]>
> > wrote:
> > > > > > > > > I don't like the possibility to not specify nullness.
>
> > > > > > > > > Let's say that ? is implicit
>
> > > > > > > > > List<String> = List?<String?> = (a list with Strings or null)
> > or
> > > > null
>
> > > > > > > > > List!<String!> = a list with strings
>
> > > > > > > > > List<String!> = (a list with Strings) or null
>
> > > > > > > > > List!<? extends String> = a list with (subtypes of string or
> > > > null)
> > > > > > > > > List!<?! extends String> = a list with subtypes of string
> > > > > > > > > List!<? super String> = a list with (supertypes of String or
> > > > null)
> > > > > > > > > List!<?! super String> = a list with supertypes of String
>
> > > > > > > > > List?<? extends String> a = ...
> > > > > > > > > List!<? extends String> b = ...
>
> > > > > > > > > a = b is legal (since they have the same generics signature)
> > > > > > > > > b = a is not legal since a can be null
>
> > > > > > > > > I haven't really thought this through, I'm just exploring the
> > > > > > > > possibilities.
>
> > > > > > > > > /Viktor
>
> > > > > > > > > On Tue, Oct 14, 2008 at 2:54 PM, Reinier Zwitserloot <
> > > > > > [EMAIL PROTECTED]
> > > > > > > > >wrote:
>
> > > > > > > > > > Introducing ! as definitely never null, and ? as might be
> > null,
> > > > in
> > > > > > an
> > > > > > > > > > Either/Maybe kind of construct, doesn't really help, unless
> > you
> > > > are
> > > > > > > > > > willing to throw out the ability to make a
> > list/map/anything
> > > > else
> > > > > > with
> > > > > > > > > > generics in it which will take arbitrary type input; it
> > doesn't
> > > > > > matter
> > > > > > > > > > if the type you're passing in is of the 'never null' or of
> > the
> > > > > > 'maybe
> > > > > > > > > > null' or of the 'I don't know' variety. Throwing that out
> > seems
> > > > > > like a
> > > > > > > > > > death sentence for the entire feature; the point is ease of
> > > > use,
> > > > > > and
> > > > > > > > > > getting rid of pointless null checks, not conflagrating the
> > > > issue
> > > > > > by
> > > > > > > > > > adding a bunch of neccessary null checks just to satisfy
> > the
> > > > > > compiler.
>
> > > > > > > > > > In other words, you need to be able to say:
>
> > > > > > > > > > List< AAAAA > list;
>
> > > > > > > > > > where AAAA is something that says: "Strings, but the
> > nullable
> > > > or
> > > > > > non-
> > > > > > > > > > nullable nature of them is irrelevant; I'll only be reading
> > > > from
> > > > > > them,
> > > > > > > > > > and I'll do explicit null checks when I do, so I just don't
> > > > care,
> > > > > > and/
> > > > > > > > > > or when I write to it, I'll definitely write non-null."
>
> > > > > > > > > > You also need: I do care; only one particular variant of
> > > > > > null-allowed
> > > > > > > > > > is okay here.
>
> > > > > > > > > > This is actually one less scenario than generics (which
> > splits
> > > > up
> > > > > > the
> > > > > > > > > > first scenario into: I'll only be writing into it, so I'll
> > give
> > > > an
> > > > > > > > > > type range going from Object to the thing I'll be putting
> > in,
> > > > say,
> > > > > > > > > > Integer, and you can then feed it a List of Object, Number,
> > or
> > > > > > > > > > Integer, it'll all be good, and into a second scenario:
> > I'll
> > > > only
> > > > > > be
> > > > > > > > > > reading from it, so I'll give a type range going from,
>
> ...
>
> read more »
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
