| Newsgroups |
gmane.comp.lang.nice.general |
| Message-ID |
<[email protected]> |
Quoting Daniel Bonniot <[email protected]>:
> >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).
> >
> OK, it happens that clear() is defined in Vector, and that Stack extends
> Vector, so this was not the good exemple. My point was that if the
> designer left-out/forgot an operation related to a class, you cannot add
> naturally that operation in an importing package (while maybe that
> operation only makes sense there, if it doesn't have a general prupose).
> You could find plenty of examples dealing with strings (which is why you
> see so many StringUtils classes).
>
> So I guess what it boilds down to is that one of the cons of
> mono-methods is that they limit the way you can define new operations
> and the way you organize your code in packages/modules.
I believe that you can do that in SmallTalk and Objective C since they have
"open classes." You can have open classes without multiple dispatch. Similarly,
you can have a method nested inside of a class that doesn't dispatch on the
class (static methods in Java and C++). So, whether methods are "contained" by a
class or by a package is orthogonal to dispatch issues. But it seems like you
can't have multiple dispatch without open classes. And, while a multi-method
could in theory be nested inside a class (even one that it doesn't dispatch on),
it seems to not make much sense to do so.
> BTW, what are their pros?
Apparently they are easier to understand and presumably easier to implement.
Combined with single inheritence they also ensure that there are no dispatch
ambiguities like we have in Nice.
> Yes. Fundamentally, I agree that Nice is based on a quite different form
> of OO (or different from class-based OO). The good part is that that
> form is more powerful; the bad part is that it's much less known, and so
> newcomers need to learn it. The whole question is: when and how?
Teach them methods before classes. If you think about "Hello World" in Nice you
don't even have to know what a class is. Similarly, you can do fibonacci, gcd,
rock-scissors-paper, ackerman, heapsort, etc. (almost all of the Novice Examples
in wiki including many of the language shootout ones) without classes.
Functional language tutorials often teach recursion and higher-order functions
before records. But, you cannot do any of these without knowing about methods.
That indicates to me that methods should be learned first.
Furthermore, making a distinction between monomethods and multimethods is
something better done in a language comparison paper than in the user manual.
Just say "here is a method, here is how you specialize it on its parameter(s)."
> My way to look at it is: multi-methods allow you to do everything that
> mono-methods do. So it's possible to "make them look like" mono-methods
> (that's the syntactic sugar), so that new users can feel at home and be
> able to write code very soon.
>
> Besides that, multi-methods are usable in other situations where,
> without them, you would need to work around the limitations of
> mono-methods (visitor pattern, static methods, manual dispatch, ...).
> When you get there, this is the time to learn the features that you need
> (declare a method outside a class, dispatch on several arguments).
That is the point I disagree with you on. The fact that one can make Nice look
like Java is what has created the most confusion and started numerous debates
including this one, the one about method lookup, do we even need interfaces,
what does "private" mean, overloading/overriding syntax, etc. Basically, you are
saying that you want people to be able to write programs in Nice without
understanding the language, by assuming it is just like Java. But, I don't see
the harm in asking them to learn a little first. And, I think Nice would be
easier to learn without the syntactic suger. In particular, I don't think the
manual should use it.
> I think it is fair to say that a multi-method is exactly what you get
> when you take mono-methods, and you add them the ability to dispatch on
> several arguments and to be declared outside classes. Maybe the
> documentation is not telling this story, and maybe it should.
I think this view does not belong in the language manual. Instead, it belongs in
a seperate "how do I migrate from Java" manual. If somebody was migrating from
ML then the "progressive" presentation would be useless to them; they would be
better off starting with the pure view. I don't think that the language manual
should refer to Java at all. I think an ML programmer should be able to learn
Nice without knowing any Java first.
To be honest, I don't think that knowing Java is really that much of a benefit
to learning Nice anymore. It has diverged too much.
> Furthermore, I agree this is not the most direct definition. So it could
> be worth to also present the "pure" view too, and that would be most
> suitable for beginer programmers and people not familiar with
> class-based OO.
I agree both presentations are important but I think the "pure" view is what
belongs in the language manual and the "progressive" view should go in a
migration/interoperability manual.
> Agreed. What about:
>
> Nice is a new programming language. It extends the ideas behind
> object-orientation in order to better support modular programming and
> static type safety. it also incorporates features from functional
> programming, and puts into practice state-of-the-art results from
> academic research. This results in more expressivity, modularity and safety.
I agree that that sounds better but I don't think it describes the language as
it is right now. In particular, most of the support for modularity has not been
designed or implemented yet.
- Brian
----- End forwarded message -----
-------------------------------------------------------
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