Re: But is it Object-Oriented?

Recently I've started to gain a better understanding of Nice (as a
result of some of the things Brian has mentioned, and as a result of
some of the changes to the manual, and as a result of some background
reading on multimethods).

As a result of this new understanding, I wonder what was so confusing
to me, and how the way Nice is presented can try to avoid similar
confusion. 

Obviously the years I spent doing the Smalltalk pure OO dance give me a
somewhat different perspective from someone with an C++ Java
procedural-OO background. 

(I do realize that the following was given as an example of adding an
operation when "extending" existing code.)

I'd think of this as an ADT style of programming, something I would do
just the same in Modula-2:

   public class StackUtils {
      public static void clear(Stack s) {
         while (! s.isEmpty())
            s.pop();
      }
   }
   StackUtils.clear(myStack)

Even in Java wouldn't the OO style of programming be:

   myStack.clear(); // inherit *instance method* clear() from Vector

Like everything else in an OO language, the method 'clear' is a feature
of an object (and that has it's pros & cons). 

(In contrast, Bjarne Stroustrup has argued that the methods which
support the class invariant have to be encapsulated in the class, and
other "utility methods" should be written as functions in the style you
demonstrated.)

AFAIK in Java or C# we can both have methods that are "encapsulated" in
a class (in the OO style) and functions (in the ADT style).

AFAIK in Nice, no methods are "encapsulated" in a class (or interface).
Nice is a multimethod language - we use generic functions - and despite
the syntax sugar, that makes it quite different from an OO language
(and that has it's pros & cons). 

---

The web presentation begins "Nice is a new object-oriented programming
language based on Java." 

IMO that sets the wrong expectations - it's misleading.

If Nice is an OO language then it's not in the way that Java (or C#,
Eiffel, Smalltalk...) is object-oriented (maybe like Ada95 or
Oberon-2).

The consequences of this confusion can be seen throughout the user
manual - we repeatedly have to explain how a language feature is really
not like the Java language feature with the same name.

IMO any advantage the correspondence gives when re-typing / re-using
Java classes and methods is overweighed by the mismatch we experience
when working with Nice types and multimethods.

---

> There is not less data abstraction when you have multi-method than
> when you are restricted to mono-methods.

I'm more interested in telling a coherent story about Nice, than
discussing if multi-methods are better than mono-methods.

Nice "classes" only encapsulate fields (not constructors or methods).
They are like Oberon-2 extensible records and Ada95 tagged records with
a Java syntax. I understand the desire to make clear that these are
extensible types - however, it's a lot easier to understand that these
are types and in Nice types are extensible, than it is to understand
that these are classes and in Nice classes are not like classes in OO
languages.

Nice "packages" encapsulate fields, types, constructors, and methods
(but packages aren't first-class). Let me put aside discussion of
packages for the present.

---

How can we express that 'In Nice, an interface doesn't really "contain"
anything at all, it's just a marker'?

How can we express the nature of Nice classes? 

Would type and datatype be less misleading than interface and class? 


best wishes, Isaac



__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click