[Grace-core] How Does Grace Compare with Java? [Was: Inheritance: what is it meant to be good for?]

Marco Servetto marco.servetto at gmail.com
Sun Feb 1 06:11:01 PST 2015


Hi guys, sorry it toked soo long, but I'm sort of in vacation now...
So, that is my revised opinion in front of this list:
----Good removal
**Type-based overloading.
**Arity-based overloading.
Yep, overloading is not there, we agree.
**Primitive data — int, boolean, char, byte, short, long, float, double.
Yes, this is an advantage w.r.t. Java I should have listed.

** import * — introduction of names invisibly.
True, how you handle the namespace? all full qualified stuff? smart
"extension" of some module that contains your desired prelude?
**final//but you are thinking on how to put it back in, right?
**Arrays (as a special built-in construct with their own special
syntax and type rules).


---Disagree that is removed
**Operations on variables, like x++ meaning x := x + 1.
In grace this is a library decision, not so much a language one. Or do
you mean that there are less unary operators available?

**Multiple numeric types (so that, for example, 3.0 and 3 are different).
Numeric literals with F and L. Integer arithmetic defined to wrap. ==
as a built-in operation on objects.
Again, it is now library decision.


**static variables. static methods. static initializers.
How the module fields are less bad than static variables (and so on?)

**C-style for loops. switch statements. and so on, now is library.
Worst, following the word of Kim, they are library stuff that we try
to trick the students into believing
is fixed by language because in that way is simpler for them.


---Different design decisions makes for incompatible comparision

**inheritance as in Java versus Inheritance from "fresh" objects and
the special semantics of method requests after inherits.

**Classes (as built-in non-objects), Packages (as built-in non-objects).
if you believe this is a simplification, then you must believe that
Object with "functional interfaces" treated as λ-expressions. is also
good and that is a simplification w.r.t. closures as building block in
the language.

**Constructors (as distinct from methods) and new.
So, how "superinitialization" works exactly in grace? for the best of
my memory was a grey area, so I'm not sure that the result will be any
better then java here.

**Class-types. are replaced by structural typing, that is not simpler at all.

**Package-based visibility. and private stuff//again, too much of a
gray area still?



---Minimal syntax difference, I can not see a real improvement here:
**Object initializers ( code in a class enclosed in { and } )
You mean you can omit the {} and write your initializer anyway? that
is what happens now, right?

**Required semicolons.
**() in method requests that take no parameters.
**String interpolations:  "the value of x is {x}." rather than "the
value of x is " + x.toString + ".".



More information about the Grace-core mailing list