Re: The Scourge of the Nullpointer

> My highly personal opinion is that it should be less code to make something
> notnull than to have something nullable.

lots of +1s there.

Re: The Scourge of the Nullpointer

> Tony Morris wrote:
> 
> Scala's Option does indeed solve the problem, however, avoiding the 
> ability to assign to null would sacrifice the ability to target the JVM 
> and inter-operate well with existing Java libraries. Also, the fact that 
> you can assign to null here is a slightly different issue. Without the 
> objective of inter-operating with Java, I suspect null would go away 
> altogether and the existence of other languages without this objective 
> are a testament to this.
> 
> It is in these cases that you have the best possible solution (unlike 
> less powerful alternatives such as the C# proposal (MSR influence 
> bubbling down no doubt)) for representing null with types so as long as 
> you accept the objective of interoperating with Java, I suspect (having 
> not thought it through to my own satisfaction) there's not much more to do.
>
> This is just a long winded way of saying, what do you propose instead?

I thought I had made a reasonably clear proposal in the rest of my message:

Introduce a type qualifier ("some" or "notnull") that will exclude null as a
valid value. Disallow (at compile time) assignment of nullable types to notnull
types (notnull <: nullable), and disallow method dispatch on nullable
types. This would be entirely compatible with Java. Java types are all
nullable, which would require some null-checking at the interface, a good thing. 
Most Scala code would work with notnull types, except for those cases where
null makes sense, i.e. those were you would use the Option monad in languages
that do not have null. Think of nullable types as a built-in kind of monad.

Re: The Scourge of the Nullpointer

Re: scaladoc variation preview

On 2008-02-29 00:31:18 David Bernard wrote:
> Hi,
> 
> I deploy a preview of the scaladoc generated by "my scaladoc
> variation" : take a look at, and send me your opinions/feedback :
> 
> http://scala-tools.org/tmp/scaladocs-demo/
> http://scala-tools.org/tmp/scaladocs-lift/
> 
> Some of the features :
> * basic support for package.html and overview.html so you could write
> it
> * display package info in the overview page
> * supports colorized code sample (use <pre name="code"
> class="scala">....</pre>)
> * links with source code (colorized)
> * links between companion object and class
> * use ajax to show/hide info in left bar and in the main page
>    * inherited item are hidden by default, need to click on "show
> inherited"
>    * details can be show/hide by clicking on [details] (no need to
> scroll between summary and details)
> * sort item by name (include inherited)
> * use a unique list to display classes and object
> * list classes and object by short name, not by long name, because
> when I read a code in general I see the short name not the long
> * use tooltip/title to display fullname of a type (keep the mouse
> over a type 2s)

Looks pretty nice David! Though I agree with the others that the CSS
could do with a little work.

Something that's occurred to me a few times that you might want to
consider adding:

In Scala I find myself writing quite a lot of one-line methods. Often
the documentation comment is longer and less clear than the code, and
it looks pretty silly when reading the source. It would be nice to have
an annotation that just causes the source code of a particular member
to be copied verbatim into the documentation.

/J

Re: The Scourge of the Nullpointer

Honestly, I don't think this is an issue. I used to think it was, but
I've since changed my mind.

Basically the only places I get NPEs in pure Scala code is when
dealing with things like constructor initialization order,
accidentally using a val in a method before it's been assigned, etc
(and these tend to be things which always go wrong or never go wrong.
It's not a subtle error like a lot of NPEs in Java). These are not
things which your proposal will help with, because they're
"non-nullable" variables which can still be null if you use them at
the wrong time. I get it a little more when using Java APIs, but only
a little.

The reason NPEs are a plague in Java is because it encourages a style
of initialize everything as null and assign to it at some later date,
and it's very hard to keep track of exactly what might and might not
be null at a given time. Scala discourages this sort of ubiquitous
mutability. If you keep most things immutable and keep your use of
nulls to a minimum this problem gets downgraded to an annoyance. In
particular, a significantly smaller annoyance than having to decorate
anything that touchs Java code with nullable declarations and adding
yet another little language feature would be.

Regards,
David

Re: The Scourge of the Nullpointer

Re: The Scourge of the Nullpointer

Re: The Scourge of the Nullpointer

Re: Scala native logging library using call-by-name's

Entertaining...

But I've come up with something slightly different that the log4j library. I
prefer recursive methods so sometimes I want my methods to recur :-/ and my
logs make much more sense if they are indented.

So I often do this:

def mult(that: Binary, level: Int) // this level is the level of recurrence

so that my (oversimplified) debug function looks like

def debug(msg: String, level: Int)
 = if(DEBUG) println(indent(level) + msg)

the problem is, my recursive methods tend to be named like "*" rather than
"mult". It's annoying to carry around the "level" parameter.

The solution I hit was...

class IntHolder(var value: Int)

and

def * (that: Binary)(implicit level: IntHolder) 

and I do this

level.value = level.value + 1
// could it be any clearer?
// note: my + and << methods use indented debug messages
val result = ((xL * yL) << (2 * m)) + (xL * yR + xR * yL) << m) + (xR * yR) 
level.value = level.value - 1

I know. Not elegant. But is working for me! 

--

-- 
View this message in context: http://www.nabble.com/-scala--Scala-native-logging-library-using-call-by-name%27s-tp15578551p15772687.html
Sent from the Scala mailing list archive at Nabble.com.

Should the Java Generic type <?> translate to C <: AnyRef

Because it seems that it translates to C <: Any