On Tue, Oct 21, 2008 at 4:23 AM, Reinier Zwitserloot <[EMAIL PROTECTED]>wrote:
>
> 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.
Are you talking about List?<?! super Foo> vs. List?<?? super Foo>?
If so, no, you cannot promote List?<?? super Foo> to List?<?! super Foo>,
but really, I think it needs to be evaluated with a context.
If many of the ugly if-checks are eliminated, and many NPEs are avoided, I
would be rather surprised if LoC wouldn't drop drastically (even though the
"problem" mentioned above)
>
>
> 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.
List!<?! super Foo>.get(0) would yield either an OOBE or Foo! (and Foo! can
be autocasted to Foo?)
>
>
> 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.
List<String> is syntactic sugar for List?<String?> :)
So, if we boil it down, what are the benefits and drawbacks?
>
>
> 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 ยป
> >
>
--
Viktor Klang
Senior Systems Analyst
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
