TWiki . Dev . ObjectType

This page documents the support of the type Object in Nice, which has been present since version 0.9.5

Current Situation

Object is currently a sort of alien in Nice. It is not a super type of all types, nor of all class types like in Java. This is the case because in most situation your are better off using type variables. When using a Java library that uses Object in its API, it's usually best to use a retyping to give it a proper strict type.

It would also make the type system weaker to have a global super-type, because for a method declaration like:

<T> boolean `==`(T,T);
we want "ABC" == myFile to be a type error. If Object was a proper type, it would not be the case.

So currently, Object is an accepted type in Nice, but it is not related to any other type. One can convert a value to have type Object by using the method object(...).


There are still reason why we might want to add more support for Object. To avoid the problem noted above for methods like ==, Object would not be a proper type, in that type variables cannot be instantiated to Object. On the other hand, it would be consider as a top type, which means that any type is a subtype of Object.


Let's see what benefits this would bring.

Principle of least surprise

Currently, the Nice compiler can report:

Incorrect type in assignment to o
Found   : java.lang.String
Expected: java.lang.Object
Even when superior solutions exist that do not involve Object, some newcomers to Nice will sometimes try to use Object. In this case, it would be better to have a less surprising behaviour.

Note that with Nice's dynamic type inference, even when using Object you can avoid casts:

Object f = operationReturningAnything();
if (f instanceof String) {
  // f has type String here, no cast required.
  int len = f.length(); // String operation, resolved at compile time.
So even without using more advanced features, users can get typing benefits when moving from Java to Nice.

Legacy libraries

For Java libraries that use Object, the best thing to do will most often be to provide retypings. Still, this proposal will ensure that even without retyping, the typing will be sensible and unsurprising, like in Java.

Moreover, there are some libraries wich use Object to represent some heteregeneous set of classes (for instance, a value that can be eith a String or a File). While this design is very questionable, these cases still occur. The proposal would make it more natural to handle such cases.

Heterogeneous data structures

If for some reason, you need to put unrelated types in an array or a collection (for instance to pass it to a Java library), you could declare it as Object[] or List<Object>, and put any value in there.

Typing reflexion

Currently, reflexion operations are typed polymorphically. This means that you don't need explicit casts when using reflexion. However, if you want to read an arbitrary value by reflexion, the only safe type you can give for a local variable that holds that value is Object. If you want to also assign a known value to that variable (for instance a default value), then you need this proposal.

Unknown type

This is a generalization of the previous case. If for some reason you need to use an unknown type, Object needs to be used. It is only better to have the information that any value can be assigned to that variable.

-- DanielBonniot - 17 Nov 2003

----- Revision r1.3 - 15 Dec 2003 - 13:24 GMT - DanielBonniot
Copyright © 1999-2003 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback.