Nice TWiki > Doc > FunctionsAndMethods (r1.1 vs. r1.7) TWiki webs:
Dev | Doc | Main | TWiki | Sandbox
Doc . { Changes | Index | Search | Go }
 <<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:
<
<

  • Can i write an HTML page or two to simplify NICE a bit more comparing both wif C++ and Java. I would like to contribute to NICE but at the moment the only thing i can do is a more simplified tutorial and Help in compiling and running, but i don't know how to write documentations the way Microsoft and others guys do. Anyhow, i'll try my best to write a simplified help in couple of days time. One, thing more first i thought to write a NICE addin for SharpDevelop? but i dropped my idea because SharpDevelop? isn't developing fullon, instead i am planning to be on the side for Eclipse( I didn't know about it till today .... no wonder i am an idiot :) ) ...but i'll be needing some time and help in that.
>
>

  • Can i write an HTML page or two to simplify NICE a bit more by explaining it with basic OOL concepts. I would like to contribute to NICE but at the moment the only thing i can do is a more simplified tutorial and Help in compiling and running, but i don't know how to write documentations the way Microsoft and others guys do. Anyhow, i'll try my best to write a simplified help in couple of days time. One thing more, first i thought to write a NICE addin for SharpDevelop? but i dropped my idea because SharpDevelop? isn't developing fullon, instead i am planning to be on the side for Eclipse( I didn't know about it till today .... no wonder i am an idiot :) ) ...but i'll be needing some time and help in that.

 <<O>>  Difference Topic FunctionsAndMethods (r1.3 - 30 May 2003 - TWikiGuest)
Added:
>
>

I think it needs to be bit more simplified

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.

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.

  • Can i write an HTML page or two to simplify NICE a bit more comparing both wif C++ and Java. I would like to contribute to NICE but at the moment the only thing i can do is a more simplified tutorial and Help in compiling and running, but i don't know how to write documentations the way Microsoft and others guys do. Anyhow, i'll try my best to write a simplified help in couple of days time. One, thing more first i thought to write a NICE addin for SharpDevelop? but i dropped my idea because SharpDevelop? isn't developing fullon, instead i am planning to be on the side for Eclipse( I didn't know about it till today .... no wonder i am an idiot :) ) ...but i'll be needing some time and help in that.
Chetan Mittal

 <<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:

  • 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. Calling this method will look akward: Tools.overlap(s1, s2) instead of s1.overlap(s2).
  • 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.
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:

  • It is object oriented. You can simply call the method with s1.overlap(s2), as if overlap had been declared in class Shape.
  • If you declare a new subclass of Shape, you can simply add new implementations for the new cases that it belongs to. This can be done anywhere, including in a different package.
  • The compiler automatically checks that all cases are covered without ambiguity. It is guaranted that there will be no error at runtime.

Note that this solution uses two concepts in Nice:

  • External methods: methods can be declared outside of classes
  • Multiple dispatch: the selection of the code to execute for a method can depend on all arguments. In most OO languages, only the first one (this, or self) is used. This is important here, since we cannot decide if a rectangle overlaps with an arbitrary shape.
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 version

In 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 version

In 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:

  • the declaration of the area method in class Shape does not need the abstract keyword. It is obvious, from the fact that the is no implementation of area in class Shape.
  • the implementation of area in Rectangle does not mention the return type double. This type is already known from the declaration of the method (and the compiler will check that the returned value has really type double).

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.

External methods in Nice

Suppose 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 method overlap 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.