| <<O>> Difference Topic FunctionsAndMethods (r1.7 - 25 Jan 2004 - TWikiGuest) |
| Changed: | |
| < < | private double top; private double left; private double height; |
| > > | private double length; |
| Changed: | |
| < < | Using this syntax, you already know how to write methods in Nice. For every method written in Java, you can write an equivalent one in Java, applying the two differences. In the next section, we see more advanced features for writing methods in Nice that have no equivalent in traditional OO languages. |
| > > | Using this syntax, you already know how to write methods in Nice. For every method written in Java, you can write an equivalent one in Nice, applying the two differences. In the next section, we see more advanced features for writing methods in Nice that have no equivalent in traditional OO languages. |
| <<O>> Difference Topic FunctionsAndMethods (r1.6 - 28 Dec 2003 - IsaacGouy) |
| Changed: | |
| < < | overlap(s1@Rectangle, s2@Rectangle) |
| > > | overlap(Rectangle s1, Rectangle s2) |
| Changed: | |
| < < | First, Simple Examples so that bad developers like me and those who haven't got any base in Java can understand such a good concept of name@class-name used for method arguments when implementing that particular method. |
| > > | First, Simple Examples so that bad developers like me and those who haven't got any base in Java can understand such a good concept of "class-name name" used for method arguments when implementing that particular method. |
| <<O>> Difference Topic FunctionsAndMethods (r1.5 - 05 Dec 2003 - TWikiGuest) |
| Changed: | |
| < < | In our exemple, we declare some classes to describe geometrical figures. |
| > > | In our example, we declare some classes to describe geometrical figures. |
| <<O>> Difference Topic FunctionsAndMethods (r1.4 - 30 May 2003 - TWikiGuest) |
| Changed: | |
| < < | 1 Simple Examples so that bad developers like me and developers who hasn't got any base in Java can understand such a good concept of name@class-name used for method arguments when implementing that particular method. |
| > > | First, Simple Examples so that bad developers like me and those who haven't got any base in Java can understand such a good concept of name@class-name used for method arguments when implementing that particular method. |
| Changed: | |
| < < | 1 Second, examples of Nice with no comparison to any other OOL i.e examples can be given in comparison to C++, smalltalk etc ,which will help a newbie to grab more of Nice. |
| > > | Second, examples of Nice can be given with no comparison to any other OOL and then can be explained with a normal OOL fundamentals and basics, which will help a newbie to grab more of Nice. |
| Changed: | |
| < < |
|
| > > |
|
| <<O>> Difference Topic FunctionsAndMethods (r1.3 - 30 May 2003 - TWikiGuest) |
| Added: | |
| > > |
I think it needs to be bit more simplified1 Simple Examples so that bad developers like me and developers who hasn't got any base in Java can understand such a good concept of name@class-name used for method arguments when implementing that particular method. 1 Second, examples of Nice with no comparison to any other OOL i.e examples can be given in comparison to C++, smalltalk etc ,which will help a newbie to grab more of Nice.
|
| <<O>> Difference Topic FunctionsAndMethods (r1.2 - 30 May 2003 - DanielBonniot) |
| Changed: | |
| < < |
External methods in Nice |
| > > |
External methods and multiple dispatch |
| Changed: | |
| < < |
Not very pretty. First, it is not object-oriented: you need to use instanceof to decide which code to execute. In that code, you will need to cast s1 and s2 to class Rectangle.
Second, if you create a new subclass of Shape, you will need to edit the source of Tools to handle that new case. If this is done by a user of your code who cannot change the source, it is simply impossible to do that, so extensibility is blocked.
Third, if you forget a case, the compiler will not tell you, but the code will fail at runtime.
|
| > > |
Not very pretty. And this solution has three fundamental problems:
|
| Added: | |
| > > |
package my.package;
import geometry;
// We declare a new method, that has two arguments.
boolean overlap(Shape s1, Shape s2);
// Here is the code for overlap, when both arguments are rectangles
overlap(s1@Rectangle, s2@Rectangle)
{
// Here s1 and s2 are both rectangles. We don't need to use instanceof or cast.
...
// return the result
}
This solution solves all three problems:
|
| Added: | |
| > > |
If you go back to the first example now, you will see that we could also have defined area as an external method, instead of declaring it inside the class. Both forms are stricly equivalent. It is a matter of style to decide which one to use in that case. |
| <<O>> Difference Topic FunctionsAndMethods (r1.1 - 30 May 2003 - DanielBonniot) |
| Added: | |
| > > |
%META:TOPICINFO{author="DanielBonniot" date="1054291617" format="1.0" version="1.1"}%
%META:TOPICPARENT{name="NiceTutorial"}%
Methods are one of the main area where Nice differs from traditional object oriented languages. This difference makes Nice much more powerful, but it also requires some adaptation when learning the language. Let's take a simple example in Java, and see how it can be done in Nice.
Java versionIn our exemple, we declare some classes to describe geometrical figures.
package geometry;
public abstract class Shape
{
abstract double area();
}
public class Rectangle extends Shape
{
private double length;
private double width;
double area()
{
return length * width;
}
}
In class Shape, we declared a method area, and we implemented it in Rectangle.
Nice versionIn Nice, you would write the following:
package geometry;
public abstract class Shape
{
double area();
}
public class Rectangle extends Shape
{
private double top;
private double left;
private double height;
private double width;
area()
{
return length * width;
}
}
There are only two differences:
External methods in NiceSuppose that a geometry library is already written. It might be in the standard library of the language, or distributed as a jar file by a company or a freeware website. In any case, you can only use it, but not modify this library. Now, what happens if you need some functionality that is not in the library? For instance, you would like a method that takes two shapes, and returns a boolean, depending on whether they overlap or not. If you are using Java, your only possibility is to create a utility class, with a static methodoverlap that has two Shape arguments.
package my.package;
import geometry.*;
class Tools
{
static boolean overlap(Shape s1, Shape s2)
{
if (s1 instanceof Rectangle && s2 instanceof Rectangle)
{
...
// return the result in this case
}
throw new Error("Case not supported: " + s1.getClass() + " and " + s2,getClass());
}
}
Not very pretty. First, it is not object-oriented: you need to use instanceof to decide which code to execute. In that code, you will need to cast s1 and s2 to class Rectangle.
Second, if you create a new subclass of Shape, you will need to edit the source of Tools to handle that new case. If this is done by a user of your code who cannot change the source, it is simply impossible to do that, so extensibility is blocked.
Third, if you forget a case, the compiler will not tell you, but the code will fail at runtime.
What you would really like to do is to add a new method to class Shape. This is something very simple and natural to do in Nice:
-- DanielBonniot - 30 May 2003 |
| Topic FunctionsAndMethods . { View | Diffs | r1.7 | > | r1.6 | > | r1.5 | More } |
|
Revision r1.1 - 30 May 2003 - 10:46 GMT - DanielBonniot Revision r1.7 - 25 Jan 2004 - 21:37 GMT - TWikiGuest |
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. |