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

• overview short paragraph giving the big information - methods not contained in classes or interfaces; classes holders of state not methods; packages encapsulate state, type, methods -- IsaacGouy - 12 Feb 2004
• Additional type in patterns to resolve ambiguities: ident@type(additionaltype)
• OperatorOverloading? (including get and set )
• Treat ints as bit arrays (this is defined in nice.lang, not sure it belongs in the manual)
• || operator with nulls (idem, defined in nice.lang )
• Type inference (variables, for loops, null-tests, instanceof narrowing)
• Array type syntax (with option types)
• Function type syntax (with option types)
• Explanations of manual formatting conventions (for syntax examples and so on)
• Package Methods (which used to be toplevel methods) the section on 'Local Methods' refers to them but I can't find anything else in the manual that explains them. IsaacGouy
• References to Methods (maybe this is the same as function type syntax?) Explain how we get a reference to a package/local method and an object method let String->String f = toLowerCase; [Developer Guide not Manual] IsaacGouy
• Extending, implementing classes and difference between implements and finally implements
• Autoboxing
• Super calls
• Expression local variables
• Java differences no switch statement - how do you do that in Nice (value dispatch, nested if) [Developer Guide not Manual]
• How do you interoperate with Java code that relies on features Nice doesn't have (inner classes) [Developer Guide not Manual] -- IsaacGouy - 08 Feb 2004 (Answer for inner classes: nothing special, you can specify the name as ToplevelClass.InnerClass)
• Manual doesn't say that abstract interfaces are not inherited
• The requirement of using fully qualified name for the class at abstract interface implementations.
• Exceptions.

Aspects that should be updated:

• Range expressions - metioned in for loop section, should have a section in expressions chap.
• Classes - initializers, overridable finals
• Retypings - it needs more explaination and more kinds of retypings exist(constructors, fields, static methods)
• !T vs. T clarification, as discussed on the Nice-Info list. Include definition of 'subtype' in Nice.
• The type of Object

Things that we can't do yet:

• KnownIssues

Things that have now been done:

• Value dispatch - instances, null, chars
• Method override syntax changes
• (Toplevel) functions do not exist anymore, their syntax is now equivalent to a method declaration together with its default implementation.
• Multi-line string constants
• String concatenation by juxtaposition
• Array literals: [e1,...,eN]
• Main method should be outside a class
• Enums
• Class initializers
• Custom constructors
• Block call syntax
• Nullness inference on fields (need to make a local var and use that instead)

Discussion

The documentation for || with nulls should explain the interaction between || and autoboxing. In particular, 1 || 2 seems to be the same as new Integer(1) || new Integer(2). (The compiler should also be able to detected the dead code in this situation: new Integer(1) can never be null, so new Integer(2) is never executed.) Also, the documentation should explain the way that || coexists with the nullness checking for fields as demonstrated at the end of this example:

    class A { ?Integer n; }

    void main(String [] args) {
        println(0 || 1);
        println(2 || 1);


        println(null           || new Integer(1));
        println(new Integer(2) || new Integer(1));

        let a1 = new A(n: null),
            a2 = new A(n: new Integer(2));

        println(a1.n || new Integer(1));
        println(a2.n || new Integer(1));

        Integer n1 = a2.n || new Integer(1);
        println(n1);

        // NOT equivalent to
        //    n2 = a2.n || new Integer(1);
        // error:
        //    The value if(`!=`(a2.n(), null))
        //                 a2.n()
        //              else
        //                 new Integer(1)
        //    cannot be assigned to n2 because it might be null.
        //
        // Integer n2 = a2.n != null ? a2.n : new Integer(1);
        // println(n2);

        // equivalent to
        //    n3 = a2.n || new Integer(1);
        ?Integer temp = a2.n;
        Integer n3 = temp != null ? temp : new Integer(1);

        println(n3);
    }

    0
    2
    1
    2
    1
    2
    2
    2

Why do you use Integer as type instead of int? What made you trying out all kinds of variations with the || operator?

I don't think users need to know about how autoboxing happens. -- ArjanB - 29 Jan 2004

It was mentioned in the ConstructorSyntax discussion I believe. I tried it out because it wasn't documented and I wanted to figure out the semantics. I think it is important to document the semantics explicitly. But I think that I may be wrong about autoboxing anyway; it is also not documented and I haven't been able to figure out the autoboxing semantics yet. Anyway, I think that operator || is simply mistyped and should not apply to int/byte/long/float/double since it doesn't make any sense for numeric types. Maybe the typing should be:

    <Any T, T U> !T `||`(#?T e1, !U e2) = inline nice.lang.inline.OptionOr();
    <Any T, T U> ?T `||`(#?T e1, ?U e2) = inline nice.lang.inline.OptionOr();

The OptionOr? can make sense for numeric types too, example:

Map<String, int> map = new HashMap();
map["abc"] = 5;
int n1 = map["xyz"] || -1;
int n2 = map["abc"] || -1;
println(n1); //prints -1
println(n2); //prints 5

It's not possible to give OptionOr? a type so that it requires the first parameter to be an option type because of the typechecking rules for function application. But OptionOr? is an inlined operator so it would be possible to generate a warning when using it with a non option type first argument.

-- ArjanB - 29 Jan 2004

|| is a method defined in nice.lang, so I don't think it should be documented in the UserManual?. As soon as we have a working nicedoc, we'll publish the documentation for the standard libraries on the website.

The general question is to document when autoboxing happens. On the one hand, one can often see that as an implementation detail, but either when you use reference equality or for performance reasons, it is sometimes important to know. So yes, that should be better documented. I'm not sure if it should go in the UserManual?, or if we should have a different document for lower-level aspects like this (this does not really belong to the definition of Nice itself, it just happens to work like this when you compile to the JVM).

The rule is that when a primitive value is used when a generic type (T) or an Object is expected, the value is boxed. Unboxing happens as need when a boxed value is used where a primitive type is expected.

-- DanielBonniot - 30 Jan 2004

String Examples

The documentation mentions multi-line strings but it would be clearer to show how they would map to traditional syntax. For example, it is not clear how whitespace at the beginnning/end of an internal line works in a multi-line string.

    let greeting  = """
            Hello, world.
       You may be thinking, \"Why was I called here today?\"
       Well, there was a good reason. Honest.
      """;   

   let greeting  =   "Hello, world. "
                 + "You may be thinking, \"Why was I called here today?\" "
                 + "Well, there was a good reason. Honest.";

   let greeting  =   "Hello, world.\n"
                 + "You may be thinking, \"Why was I called here today?\"\n"
                 + "Well, there was a good reason. Honest.";

Hmmm maybe there's something to be said for being explicit, my guess would have been

   let greeting  =   "\nHello, world.\n"
                 + "You may be thinking, \"Why was I called here today?\"\n"
                 + "Well, there was a good reason. Honest.\n";