Eiffel and Java, a comparison by RIT

[wtd]

http://66.102.7.104/search?q=cache:gPLjkZQbi68J:www.cs.rit.edu/~jeh/eiffel/JvsE.html+eiffel+site:rit.edu&hl=en&client=firefox

Oh, and why they chose Eiffel for intro CS.

http://66.102.7.104/search?q=cache:LHP9doWEYzAJ:www.cs.rit.edu/~jeh/Papers/Eif-joop.html+eiffel+site:rit.edu&hl=en&client=firefox

[Hikaru79]

Your second link doesn't seem to work

[wtd]

Do a Google search for "eiffel site:rit.edu".

[rizzix]

ha.. that report is soo outdated... and the advantages are not that great... you should check out AspectJ.. ha... makes Eiffel look bad.

[wtd]

Is it?

Where's the DbC is Java? Pre-conditions, post-conditions, class invariants that are inherited, and the ability to give names to the exceptions they throw.

The syntax is simpler. Tell me that Java has only one way to loop.

code:

test_loop is    local       index : INTEGER    do       from          index := 1       until          index >= 10       loop          std_output.put_integer(index)          std_output.put_new_line          index := index + 1       end    end

Where are the externally read-only attributes? Where's the strict enforcement of encapsulation?

Where are the real generic classes (as opposed to some auto-boxing and Object casting hackery)?

Where's the feature adaptation to resolve name clashes?

Where's the high level of control over feature access (beyond simply public, private and protected)?

Where's the strict separation of procedures and functions?

Can you use any procedure to set up the initial state of an object?

[rizzix]

oh? yes.. pre, post and a heck a lot more is possible though aspects.. including stuff that even eiffel can't do..

every thing else you mentioned is soo useless and pointless i'm not even going to bother replying.. except for this one.. if what you say is true.. i'll have to simply accept that eiffel has a greater advantage over java in this respect: "Where's the high level of control over feature access (beyond simply public, private and protected)?"

[wtd]

So this:

Java:

public class MyClass {   private String name;   public boolean invarName() { return name != null; }   public void    setName (String n) { name = n; }   public boolean preSetName (String n) { return n != null; }   public String  getName () { return name; }   public boolean postGetName (String result) { return result != null; }   public String  doIt (int n, String s) {...}   public boolean preDoIt (int n, String s) {     return n > 10 && s != null;   }   public boolean postDoIt (String result, int n, String s) {     return result != null;   }   ... }

Is prefereable to:

code:

class    MY_CLASS feature    name : STRING    set_name(new_name : STRING) is       require          new_name /= Void       do          name := new_name       end    do_it(n : INTEGER, s : STRING) : STRING is       require          n > 10 and then s /= Void       do          ...       end invariant    name /= Void end

Is a simple syntax pointless? I know a lot of people struggling with C-like syntaxes who would disagree.

Are externally read-only attributes useless? Notice I declared my "name" attribute openly, and no harm came of it. That's because I can't modify it from outside the class. At the same time, it saved me from having to write a "get" accessor.

I can't do the bad thing and break encapsulation in Eiffel. It just isn't allowed.

Separation of functions and procedures doesn't matter? Not having functions capable of mutating the object makes a tremendous amount of sense, and saves much confusion. It enforces the idea that each routine should do one small job, thus making it easier to isolate the source of errors. Consider a simple IO example:

code:

class    TEST creation    make feature    make is       do          std_output.put_string("Your name is? ")          std_input.read_line          std_output.put_string("Hello " + std_input.last_string + "!")          std_output.put_new_line       end end

The act of reading the line in, and then actually getting what it read become two separate features.

As for feature access... you're right to envy it. The class ank account example:

code:

class    BANK_ACCOUNT feature { TELLER }    balance : INTEGER end

The balance becomes available only to objects of the TELLER class.

[wtd]

Another semantic simplicitythat Eiffel brings to bear is that there are no unatural breaks in execution. There are no gotos, breaks, continues, or returns.

This eliminates another huge class of errors by making it easier to trace the flow of execution.

Also, where is Java's ability to create value types? Consider:

bar.e

code:

class    BAR creation    make feature    foo, baz : INTEGER    make is       do          foo := 1          baz := 2       end    inc is       do          foo := foo + 1          baz := baz + 1       end end

test.e

code:

class    TEST creation    make feature        inc(input : BAR) is       do          input.inc       end    make is       local          b : BAR       do          create b.make                  std_output.put_integer(b.foo) ; std_output.put_character(',')          std_output.put_integer(b.baz) ; std_output.put_new_line          inc(b)          std_output.put_integer(b.foo) ; std_output.put_character(',')          std_output.put_integer(b.baz) ; std_output.put_new_line       end end

This outputs:

1,2
2,3

And now, compare that to:

bar.e

code:

expanded class    BAR feature    foo, baz : INTEGER    make is       do          foo := 1          baz := 2       end    inc is       do          foo := foo + 1          baz := baz + 1       end end

test.e

code:

class    TEST creation    make feature        inc(input : BAR) is       do          input.inc       end    make is       local          b : BAR       do          b.make                  std_output.put_integer(b.foo) ; std_output.put_character(',')          std_output.put_integer(b.baz) ; std_output.put_new_line          inc(b)          std_output.put_integer(b.foo) ; std_output.put_character(',')          std_output.put_integer(b.baz) ; std_output.put_new_line       end end

Which prints:

1,2
1,2

How do I accomplish this in Java - creating objects which are handled by value rather than by reference?

[wtd]

Let's consider another syntactic and semantic simplicity. Exception handling occurs only at the feature-level. That is, you cannot have arbitrary exception handling blocks.

This further encourages concise, focused features, rather than lengthy methods.

Additionally, with Eiffel's exception handling you have the "retry" instruction which allows you to "fix" variables, and then run the feature again.

Imagine if you have a queue class, and you try to add something, but there isn't room for it. Your exception handler could grow the queue by one slot, then retry the method.

[wtd]

Oh yes, and no overloaded features. You can't have something like:

code:

class    TEST feature    foo : STRING is       do          Result := "foo"       end    foo(n : INTEGER) : STRING is       local          counter : INTEGER       do          from             Result := ""             counter := 0          until             counter > n          loop             Result := Result + "foo"             counter := counter + 1          end       end end

Seems to be a nice way of reducing confusion.

[rizzix]

wtd wrote:

So this....

wait.. i'll get back to you on this.. i'll show you how it's actually done in java.. using aspects..

wtd wrote:

Are externally read-only attributes useless? Notice I declared my "name" attribute openly, and no harm came of it. That's because I can't modify it from outside the class. At the same time, it saved me from having to write a "get" accessor.

No it's best to access all properties through accessors.. properties are but private members of a class... that's how we program in java.. that's our philosophy.. you could argue that we have such a philosophy because we do not have read-only attributes... maybe.. but we see advantages in creating accessors since later on as the code matures.. we could come across a situation where you now need to do some sort of error checking or maybe more than just that.. maybe notify oberserver etc... then as you can see it's just a matter of modifying an accessor and implementing the necessary code.. the details are hidding from the client code... and there's no need to inform the clients that accessing data through the read-only attributes is now "deprecated".. it all happens behind the scenes..

wtd wrote:

Separation of functions and procedures doesn't matter? Not having functions capable of mutating the object makes a tremendous amount of sense, and saves much confusion. It enforces the idea that each routine should do one small job, thus making it easier to isolate the source of errors. Consider a simple IO example:

code:

class    TEST creation    make feature    make is       do          std_output.put_string("Your name is? ")          std_input.read_line          std_output.put_string("Hello " + std_input.last_string + "!")          std_output.put_new_line       end end

The act of reading the line in, and then actually getting what it read become two separate features.

Nope! I just fail to see the point to this... functions that return "void" or nothing.. are just as good.. and it's feels more consistent...

[rizzix]

wtd wrote:

Another semantic simplicitythat Eiffel brings to bear is that there are no unatural breaks in execution. There are no gotos, breaks, continues, or returns.

This eliminates another huge class of errors by making it easier to trace the flow of execution.

yes and prevents some really cool algorithms from being implemented..

wtd wrote:

Also, where is Java's ability to create value types?...

funny you bring that up... we java programmers are actually greatful we can't do this.. look at the complications involved if you do implement such a feature: the absolute necessity of implementing an = operator (or equivalent) and the so called copy-constuctor... all the annoying "have-to-follow" rules present in the c++ lang.. just because it has the ability to create value types... either way.. there's abosolutly no point to it!

[rizzix]

wtd wrote:

Let's consider another syntactic and semantic simplicity. Exception handling occurs only at the feature-level. That is, you cannot have arbitrary exception handling blocks.

This further encourages concise, focused features, rather than lengthy methods.

care to elaborate? i don't understand.

wtd wrote:

Additionally, with Eiffel's exception handling you have the "retry" instruction which allows you to "fix" variables, and then run the feature again.

Imagine if you have a queue class, and you try to add something, but there isn't room for it. Your exception handler could grow the queue by one slot, then retry the method.

such kind or error handling take place at the function level (of a class etc)... and recursive functions allow for similar functionality...

[rizzix]

wtd wrote:

Oh yes, and no overloaded features. You can't have something like:....

oh yes there's a good side to this allright... it does reduce confusion.. but sometimes overloading can be very usefull...

for ex consider:

code:

class Line {     void setPoint(Point p) { .. }     void setPoint(int x, int y) { .. } }

the overloaded method (the one that takes two int) simplifies coding.. creating the point for you when you don't already have one.. but this is a poor example.. there are better ones.. i just currently can't think of one..

[wtd]

rizzix wrote:

wtd wrote:

Are externally read-only attributes useless? Notice I declared my "name" attribute openly, and no harm came of it. That's because I can't modify it from outside the class. At the same time, it saved me from having to write a "get" accessor.

No it's best to access all properties through accessors.. properties are but private members of a class... that's how we program in java.. that's our philosophy.. you could argue that we have such a philosophy because we do not have read-only attributes... maybe.. but we see advantages in creating accessors since later on as the code matures.. we could come across a situation where you now need to do some sort of error checking or maybe more than just that.. maybe notify oberserver etc... then as you can see it's just a matter of modifying an accessor and implementing the necessary code.. the details are hidding from the client code... and there's no need to inform the clients that accessing data through the read-only attributes is now "deprecated".. it all happens behind the scenes..

Why would you ever want to know when an access of that data occurs? Surely the only time you care to know such things is when you actually change the state of an object?

Since Eiffel requires a procedure for modifying (as opposed to simply reading) the state of an object, that gives you ample opportunity to add extra logic.

rizzix wrote:

wtd wrote:

Separation of functions and procedures doesn't matter? Not having functions capable of mutating the object makes a tremendous amount of sense, and saves much confusion. It enforces the idea that each routine should do one small job, thus making it easier to isolate the source of errors. Consider a simple IO example:

code:

class    TEST creation    make feature    make is       do          std_output.put_string("Your name is? ")          std_input.read_line          std_output.put_string("Hello " + std_input.last_string + "!")          std_output.put_new_line       end end

The act of reading the line in, and then actually getting what it read become two separate features.

Nope! I just fail to see the point to this... functions that return "void" or nothing.. are just as good.. and it's feels more consistent...

Ah, but the problem is that a method which returns some value can also make changes to the state of the object. This is bad, since it means a programmer can build methods which perform several operations, rather than short, concise, focused routines that make tracing errors easier.

For instance, in my very simple example, if there's an error reading the input line, it will occur there, before any output is attempted.

A more Java/C-ish way of doing this might look like:

code:

std_output.put_string("Hello, " + std_input.read_line + !")