From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 28B7EBC69 for ; Thu, 8 Mar 2007 21:44:15 +0100 (CET) Received: from smtp.janestcapital.com (www.janestcapital.com [66.155.124.107]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l28KiDbN004452 for ; Thu, 8 Mar 2007 21:44:14 +0100 Received: from [192.168.250.117] [209.213.205.130] by janestcapital.com with ESMTP (SMTPD-9.10) id A59C05D4; Thu, 08 Mar 2007 15:44:12 -0500 Message-ID: <45F0759B.608@janestcapital.com> Date: Thu, 08 Mar 2007 15:44:11 -0500 From: Brian Hurt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Harrop Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Operator overloading References: <3D1E4D9CA9BCE04D8F2B55F203AE4CE30666AB5E@selma.roomandboard.com> <45F04DD0.5010505@janestcapital.com> <200703081940.42856.jon@ffconsultancy.com> In-Reply-To: <200703081940.42856.jon@ffconsultancy.com> Content-Type: multipart/alternative; boundary="------------050209080300080808030904" X-Miltered: at discorde with ID 45F0759D.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; overloading:01 ocaml:01 overloading:01 ocaml:01 functors:01 functor:01 functors:01 functor:01 wrote:01 wrote:01 imho:01 imho:01 caml-list:01 int:01 int:01 This is a multi-part message in MIME format. --------------050209080300080808030904 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jon Harrop wrote: >On Thursday 08 March 2007 17:54, Brian Hurt wrote: > > >>Roland Zumkeller wrote: >> >> >>>Wasn't there a more or less good reason for OCaml *not* to support >>>operator overloading? >>> >>> >>Yes. Ocaml has modules and functors. IMHO, any time you thing "boy, >>it'd be really nice to use operator overloading here", you should use a >>module and a functor instead. >>... >> >> > >For me, operator overloading is about clarity. In the absence of operator >overloading, you cannot regain the lost clarity using modules and functors. > > Hmm. My experience from C++ was that operator overloading results in a net *loss* in clarity of the code. For every time I've seen operator overloading done correctly, I've seen it abused at least twice, probably more often. And this is even ignoring the use of << and >> in IO. By abused, I mean "used in a way that violates the numerical implications of the operator". There are also the case of bugs introduced by operator overloading. For example, in C++, this sucker has bitten me: int i = 10; cout << i << 2; The problem here is the two different meanings of <<. Brian --------------050209080300080808030904 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jon Harrop wrote:

On Thursday 08 March 2007 17:54, Brian Hurt wrote:

Roland Zumkeller wrote:

Wasn't there a more or less good reason for OCaml *not* to support
operator overloading?

Yes.  Ocaml has modules and functors.  IMHO, any time you thing "boy,
it'd be really nice to use operator overloading here", you should use a
module and a functor instead.
...


For me, operator overloading is about clarity. In the absence of operator 
overloading, you cannot regain the lost clarity using modules and functors.

Hmm. My experience from C++ was that operator overloading results in a net *loss* in clarity of the code. For every time I've seen operator overloading done correctly, I've seen it abused at least twice, probably more often. And this is even ignoring the use of << and >> in IO. By abused, I mean "used in a way that violates the numerical implications of the operator".

There are also the case of bugs introduced by operator overloading. For example, in C++, this sucker has bitten me:
int i = 10;
cout << i << 2;

The problem here is the two different meanings of <<.

Brian

--------------050209080300080808030904--