TWiki > Dev > FeatureProposals > UnknownType	TWiki webs: Dev | Doc | Main | TWiki | Sandbox
	Dev . { Changes | Index | Search | Go }

Unknown Type

In Java or Nice today, we are forced to get by using an Object type, when we don't or can't know the type. The main problem with using Object is all of the type casting and instanceof operators that must be used with these variables or members.

Since Nice has MultiMethods?, meaning that methods are found dynamically, it only seem logical that this also be possible to accomplish at runtime, rather than compile time.

Syntax

    unknown depthSearch(Tree tree, unknown find);

    unknown entry = "This is a string";
    ?unknown first = null;
    unknown[] list1 = new unknown[50];
    var list2 = new ArrayList<unknown>();

    int len = entry.length();       // works because entry currently refers to a String and because
                                    //   String.length() returns an int
    file = new File(entry);         // works because File has a Sring constructor, and without typecasting
    int width = entry.width();      // would compile, but fail at runtime
    Set<int> set = entry.charAt(0); // seems silly, but would compile, then fail at runtime

Pros

• Variables may refer to diverse objects
• The programmer doesn't need to know what objects types will eventually be used
• The actual type will be known at runtime, so correct methods will be looked up and called
• No type casting is needed to pass these objects to strictly typed methods
• No type casting is needed to call methods or access fields of unknown variables
• May hold anything: primitives (built-ins), arrays, or Objects
• Allows programmers to add scripting capabilities or hooks to their applications

Cons

• Slower access because of runtime lookups. This could be improved by the compiler in 'if' statements as follows:

    unknown found = list2[15];
    if (found instanceof Number) {
        /* Compiler knows 'found' is a Number here and can take advantage of that */
    }

• More potential runtime errors. Theses are inevitable, because the compiler can't help much.
• Complex and tedious to implement in Nice. I'm guessing here. But I would bet that since Nice is strongly typed, adding the unknown type will cause lots changes and ripples throughout the compiler. I still think they are worth the effort, however.
• Fields of unknown objects must also all be considered as type unknown. This is because at compile time we can't know if fields will exist or their types. This may also be the case for the return types of methods called on _unknown_types.

See also DynamicMembers for an idea of how to possibly implement runtime member lookup.

-- TroyHeninger - 25 Oct 2003

Thanks for your ideas. It is true that although strong typing is better when it is possible (and with Nice we try to make it possible more often), there will always be cases where it is not "clever" enough.

One aspect of Nice you might have missed is that, with type parameters, you can handle some of the situations you mention. For instance, instead of

  unknown `.`(row@Results, String column);

  <T> T `.`(row@Results, String column);

which says: the return type is T, for whatever value of T you choose (since T does not appear in the parameter list). This is already used in the standard library for serialization/deserialization without casts. You can also look at this forum thread about reflexion support.

This does not allow to have a local variable of any type, though, because T must be declared in a method type. But I believe this already covers many interesting cases.

-- DanielBonniot - 25 Oct 2003

-- TroyHeninger - 12 Nov 2003

1) You can put anything inside ``, so a method definition using `.` is valid. However, you would not be able to call it using the e1.e2 syntax, so that's not yet what you want (in the other discussion). My point here was about typing.

2) You're right, using <T> for unknown types does not carry on to arrays. What you can do currently is use Object for that purpose. You can convert any value to Object by using the method object(...). On the way back, you would use a cast or instanceof.

3) Basic support exists, using Object as described above. One could do better, by not requiring the use of object(...) (that is, make Object the top type). This should not be very difficult.

If you want to allow any operation on Object (or unknown) to succeed, and discover the operation at runtime, that would more work. Although maybe you could just rewrite f(e1, ..., eN) where at least one of e1...eN has the unknown type into dynamic_call("f", e1, ..., eN), and implement dynamic_call as a library function that uses reflexion and the class of its arguments to find what method to call. Is this what you are driving to?

It's interesting, although my bias is usually more towards static solutions. I'm not sure if you are awre that Nice is already quite clever about instanceof, so you don't need casts in addition:

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.
}

This removes about half of the boilerplate needed in Java when using arbitrary types. If the removal of object(...) mentioned above was implemented, would not this provide quite a good support already, without loosing any type safety?

-- DanielBonniot