POLL: @Nullable etc.

I think the best thing would be to make a new java.net project called "Common
Invariant Annotations." Then the package would be net.java.invariants. Me,
you, and Bill Pugh would be among the project administrators, and we could
all agree on naming and semantics, and define standards to be posted as part
of the project. Do you like this idea? Would you be willing to do it?


I have a somewhat OT question, I was looking around idea.jar, and it appears
that the JB dataFlow inspection IR compiler (dataFlow.instructions package)
could be easily converted to Soot IR, more efficiently than by passing preprocessed
source code to Soot for each analysis. This would help my plugin's performance
a great deal, I think. Is this API stable? If I requested in JIRA for it
to be moved to OpenAPI would it be possible to happen within Irida timeframe?

If it's stable, is there a way to add idea.jar to library classpath, but
have DevKit Plugin deployment not copy the JAR to the plugin output path?

On Fri, 06 May 2005 19:25:49 +0000, Keith Lea wrote:

1. I think NotNull is very bad style and I don't want to associate my project
with it

If precedent helps, I can think of two examples of not- being used to form
an adjective :

- not-for-profit (e.g. a not-for-profit organization)
- not-out (e.g. a not-out batsman (in a game of cricket))

Not-out is more commonly used as an adverb but its use as an adjective is
perfectly acceptable.

2. I think Nullable may be confusing because the name implies the value
may be null, but null cannot be assigned to it

It implies exactly the reverse to me - that a value cannot be null to
start with but could become null after previously having a value other
than null (the value is "able to become null", so to speak).

--
Mark Scott
mark@codebrewer.com

On Fri, 06 May 2005 19:25:49 +0000, Keith Lea wrote:

>> 1. I think NotNull is very bad style and I don't want to associate my
>> project with it
>>

If precedent helps, I can think of two examples of not- being used to
form an adjective :

- not-for-profit (e.g. a not-for-profit organization)
- not-out (e.g. a not-out batsman (in a game of cricket))
Not-out is more commonly used as an adverb but its use as an adjective
is perfectly acceptable.

I've never heard "not-out," but I'm from the US, I think it's probably a
British thing (judging from your cricket reference). "not-for-profit" is
an okay example, but "nonforprofit" would not make sense - I think in general,
when forming an adjective, non is preferred over not, unless using "non"
would not make sense.

>> 2. I think Nullable may be confusing because the name implies the
>> value may be null, but null cannot be assigned to it
>>

It implies exactly the reverse to me - that a value cannot be null to
start with but could become null after previously having a value other
than null (the value is "able to become null", so to speak).

I misspoke. I meant to say that to me, it implies that the value's current
nullness is not important, and only future assignments cannot be null.

If it's stable, is there a way to add idea.jar to library classpath, but
have DevKit Plugin deployment not copy the JAR to the plugin output path?

You can do this by defining a new 'IDEA JDK' and adding idea.jar to the
JDK's classpath. Idea.jar will be available for your project but won't be
copied
by DevKit.

Vince.

Thanks!

>> If it's stable, is there a way to add idea.jar to library classpath,
>> but have DevKit Plugin deployment not copy the JAR to the plugin
>> output path?
>>

You can do this by defining a new 'IDEA JDK' and adding idea.jar to
the
JDK's classpath. Idea.jar will be available for your project but won't
be
copied
by DevKit.
Vince.

In my mind, "is nullable" is related to Null Objects:

interface isNullable {
boolean isNull();
}

Based on that, the current naming annoys me a little, because it
conflicts with the interface.


What about the pair:
@NeverNull
@NullOrNot


I think the meaning is clearer.

Alain

In my mind, "is nullable" is related to Null Objects:

interface isNullable {
boolean isNull();
}

Based on that, the current naming annoys me a little,
because it
conflicts with the interface.


What about the pair:
@NeverNull
@NullOrNot


I think the meaning is clearer.

+1, the meaning is much more clear!

(What do you think about @PossiblyNull instead of @NullOrNot ? We could even have an @AlwaysNull annotation :)

(What do you think about @PossiblyNull instead of @NullOrNot ? We
could even have an @AlwaysNull annotation :)

Some others like PossiblyNull as well, including Bill Pugh of FindBugs. I
like it a little better than @Nullable for clarity, but not for ease of typing.

vlad

>(What do you think about @PossiblyNull instead of @NullOrNot ?
>

I do find it a little too long to type and read.


And also like that
@NeverNull
@NullOrNot
have the same length.



To be complete, a more symetrical alternative would be
@NullNever
@NullOrNot
, but I find it a little strange.

We could even have an @AlwaysNull annotation :)

>

What would be the purpose of such a method/variable?

Alain

@MaybeNull ?

N.

Keith Lea wrote:
>> (What do you think about @PossiblyNull instead of @NullOrNot ? We
>> could even have an @AlwaysNull annotation :)

Some others like PossiblyNull as well, including Bill Pugh of FindBugs.
I like it a little better than @Nullable for clarity, but not for ease
of typing.

Keith Lea wrote:
>> On Fri, 06 May 2005 19:25:49 +0000, Keith Lea wrote:
>>
>>> 1. I think NotNull is very bad style and I don't want to associate my
>>> project with it
>>>
>> If precedent helps, I can think of two examples of not- being used to
>> form an adjective :
>>
>> - not-for-profit (e.g. a not-for-profit organization)
>> - not-out (e.g. a not-out batsman (in a game of cricket))
>> Not-out is more commonly used as an adverb but its use as an adjective
>> is perfectly acceptable.

I've never heard "not-out," but I'm from the US, I think it's probably a
British thing (judging from your cricket reference). "not-for-profit" is
an okay example, but "nonforprofit" would not make sense - I think in
general, when forming an adjective, non is preferred over not, unless
using "non" would not make sense.

And to further complicate matters, I have also seen "nonprofit
organization" used...

N.

How about a new configuration setting, like
"annotation(s) for nullable parameter: ________" and
"annotation(s) for not-null parameter: ________"?

So everybody may build his own annotation library.

In article <d5ku3b$c44$1@is.intellij.net>,
Nathan Brown <nedski@yNaOhSoPo.cAoMm> wrote:

@MaybeNull ?

:D

That would be @MayBeNull... Maybe null is like you're not sure if it is
or isn't. May Be null as in can be null.

R

NullOrNotNull, that is the question.

Tom

Tom

@NullOrNotNull, that is the question.

>

I prefer the Readers' Digest version:

@NullOrNot ?

Alain

Robert S. Sfeir wrote:

>>@MaybeNull ?

Could this be cleared up with an enum?

@Null(ALWAYS)
@Null(NEVER)
@Null(MAYBE)

?

Oooh, cute, although the use case of @Null(ALWAYS) is covered by "void". Based on some of the code I've had to maintain, though, we'll also need @Null(SATURDAY_AT_3_AM).

--Dave Griffith

Dave Griffith wrote:

Oooh, cute, although the use case of @Null(ALWAYS) is covered by
"void".

True.

Based on some of the code I've had to maintain, though,
we'll also need @Null(SATURDAY_AT_3_AM).

Customizable and overridable by an XML (or four) sprinkled magically
through the classpath?

Robert S. Sfeir wrote:

>>> @MaybeNull ?
>>>

Could this be cleared up with an enum?

@Null(ALWAYS)
@Null(NEVER)
@Null(MAYBE)
?

Imagine typing that for every method parameter. I don't think I'd like it.
These annotations are all about ease of use. (There are lots of systems for
defining and checking nullness of program elements. These annotations are
just an easier way to do it.)

Keith Lea wrote:

>> @Null(NEVER)

Imagine typing that for every method parameter. I don't think I'd like
it. These annotations are all about ease of use. (There are lots of
systems for defining and checking nullness of program elements. These

It's not entirely that much more to type than say @NeverNull or some
other variants that've been mentioned previously. I was thinking this
might be a simpler avenue than the endless thread on the correct grammer
of Non or Not.

I think the parentheses and capital letters make it hard to type.

I'm starting to lean towards @Nonnull for a balance of typability and clarity.
I realized it's more grammatically correct because people don't say "non-violent"
but instead "nonviolent." So "nonnull" is the correct word, maybe.

Keith Lea wrote:

>>> @Null(NEVER)
>>>
>> Imagine typing that for every method parameter. I don't think I'd
>> like it. These annotations are all about ease of use. (There are lots
>> of systems for defining and checking nullness of program elements.
>> These
>>

It's not entirely that much more to type than say @NeverNull or some
other variants that've been mentioned previously. I was thinking this
might be a simpler avenue than the endless thread on the correct
grammer of Non or Not.

Alain,

vlad

>(What do you think about @PossiblyNull instead of
@NullOrNot ?
>

I do find it a little too long to type and read.

Why should we type the entire annotation? We'll use IDEA's auto-completion! ;)

And also like that
@NeverNull
@NullOrNot
have the same length.

Yes, I like that too! (But I still find @PossiblyNull more in line with @NeverNull)

To be complete, a more symetrical alternative would
be
@NullNever
@NullOrNot
, but I find it a little strange.

Yes, indeed.

We could even have an @AlwaysNull annotation :)

>

What would be the purpose of such a method/variable?

Well, I suggested this half jokingly. Still, there are a couple of cases when always returning null could make sense (e.g., when a method implements an abstract, non-void method which has the @PossiblyNull semantics specified in the declaring interface or class, but one or more particular implementations must always return null).

Vlad

Alain

P.S. Did the latest EAP build make your mother happy?

Vlad

P.S. Did the latest EAP build make your mother happy?

@AlwaysTrue

Alain

Some terms I've seen elsewhere:

@Optional (== @Nullable)
@Mandatory (== @NotNull(able))


For your consideration...

Good idea!

Tom

>@Optional (== @Nullable)
>@Mandatory (== @NotNull(able))
>

>

In what dimension are those words synonyms? Not in mine.
-10

Alain

On Mon, 09 May 2005 12:32:08 +0200, Alain Ravet wrote:

In what dimension are those words synonyms? Not in mine. -10

Lack of sugar does strange things to a man...

He needs more donuts...

Mark :

>>In what dimension are those words synonyms? Not in mine. -10
>>
>>
>
>Lack of sugar does strange things to a man...
>

>


True, I was a little harsh - sorry Maarten - , but I was competing with
Tom's "good idea", so I felt a simple "-1" was too shy.
My mistake. Sorry.


Anyway, my point is still valid: AFAIK, there is no planet in the
federation where

"optional"
means
"can return or have a value equal to 'null'"

, and
"mandatory"
means
"never has a value equal to 'null'"


Did I miss something?


Alain

>@Optional (== @Nullable)
>@Mandatory (== @NotNull(able))

In what dimension are those words synonyms? Not in
mine.

Read them as 'value is optional' and 'value is mandatory'.

I picked up 'optional' from the Nice language (http://nice.sourceforge.net/ ), a Java variant that, among other things, aims to eliminate NullPointerExceptions by applying compile-time analysis similar to what these annotations enable.

Nice uses 'option types' to indicate which variables can contain null values, and required null-checking code before accessing the value. Option types are indicated by prefixing the normal type with '?':
?String

Mandatory is of course just the oposite of Optional.


Maarten

True, I was a little harsh - sorry Maarten - , but I
was competing with
Tom's "good idea", so I felt a simple "-1" was too
shy.
My mistake. Sorry.

No problem Alain.
I'm not scared of big numbers. My current project uses more longs than ints. And I wanted to know the value of 25! recently. (! means factorial).

For the rest, see my other message below.


Maarten