Re: stuck on "Incorrect type in assignment" error

> Hi Steve,
> 
> > I'm trying to get a rather large Nice program written in a hurry,
> 
> How come ? ;-)

Why, because I don't like to write them slowly, of course! :)

I'm implementing the same moderately-sized Swing application in
seven or so JVM languages, preparing to write a series of articles
comparing and contrasting them.  Although there are over a hundred
languages for the JVM, only a handful of them are capable of handling
this (otherwise relatively simple) application because of the unique
challenges that Swing poses.  Nice is one of the few.

So think of me as a restaurant or movie critic! ;-)

> > First question, then:  why doesn't this code work --
> > [...]
>
> The compiler detects that the array you created is filled with null. You need
> to provide the values at the same time as the creation. Luckilly, this can be
> done easily with the help of a library method (as a bonus, you don't even need
> to write the loop!) :
> 
>   let Integer[][] grid = new Integer[w][h].fill
>     ((int i, int j) => new Integer(i+j));

Nice!  *Ahem*, er, so to speak.  Thanks for the tip.  I should have noticed that
function.  I usually dig around in nice.jar's
nice/functional/package.nicei when I'm
looking for a higher order-ish kind of function like that.  It's quite
a package of
goodies, and should be committed to printed documentation someday. :-)

> Actually, this fill method is currently only provided in nice.lang for
> single-dimension arrays. So here is the version for two dimensions. Just
> include it somewhere in your program, until the next version of Nice which
> will ship with it:
> 
> <T, U | U <: T> U[][] fill(T[][] array, (int,int)->U value)
> {
>   for (int i = 0; i < array.length; i++)
>     for (int j = 0; j < array[i].length; j++)
>       array[i][j] = value(i,j);
>   return cast(array); // all values have been initialized, the cast is safe
> }
> 
> (Quizz: is there a way to define this bi-dimensional fill by reusing the
> mono-dimensional one?)

I assume so, as Java lacks true multidimensional arrays.  I do this
with java.util.Arrays.fill() frequently, albeit without the function parameter.

> If you read attentively, you will see that 'cast' is a method that can be used
> when you seem to get stuck with such type errors and you *know* there is no
> problem. However, if you have the time, it's always better to stop and think
> about what is happening and try to find a safe way to do what you want. Or
> complain to the developers if you think the compiler should be smarter ;-)
> When the only problem is null, you can use 'notNull(...)' instead, which is
> "less unsafe" than cast.

Thanks!  notNull(...) is exactly what I need in a few cases.  I'm
sure I can steer clear of cast().  Although there are a few places where
Nice has assumed I was passing a byte, and I wanted to cast it as an int.
Is there a way to specify that a literal argument like -1 should be treated
as an int?  (Long is easy; -1L).

> > (Frankly, if Nice can't prevent run-time exceptions, then I don't believe it
> > should make you work so hard to prevent null-pointer exceptions.  It's
> > really and truly not worth the hassle, as far as I can tell.  The language has
> > a lot to offer, and right now this little issue just gets in your way.  Optional
> > types should be, well... optional.)
> 
> Nice can't prevent _all_ run-time exceptions, but is it a reason not to try to
>  prevent any? In my experience, array bounds errors are very often an issue
> that can be localized to a small portion of code. On the other hand, when
> types do not specify if they contain null or not, whole APIs become
> ill-specified, and the potential for errors diffuses to large portions of the
> program. In practice, a big proportion of the failures I see on distributed
> Java programs are NullPointerExceptions.

Yes, I just wanted to see how many of your buttons I could push, after being
pushed around by Nice all morning. :)   I like the general idea.  There are
some implementation details that I'm still getting used to.

> You're prefectly right that preventing those exceptions requires some work,
> and I know it can be annoying. Nice is still being improved (at this very
> moment, hey Artem! ;-) to make this process as little intrusive as possible by
> making nullness analysis more precise. Providing this new version of the fill
> method helps in you particular case.

Glad to hear it!  And yes, the fill method you provided works perfectly.
Thanks.

> By the way, why do you need to use type Integer[][] and not int[][] ?

I'm using another object class, not Integer; I just changed it to make
the example cleaner.  Should have used String, I suppose, as I forgot
about autoboxing.

Thanks for the quick response!

-steve

> Cheers,
> 
> Daniel
> 
> PS: Steve, are you subscribed to the list?

Nope!  If I wind up liking Nice a lot, then maybe... ;-)


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click