From: Markus Mottl <mottl@miss.wu-wien.ac.at>
To: dsyme@microsoft.com (Don Syme)
Cc: caml-list@inria.fr (OCAML)
Subject: Re: Looking for a nail
Date: Fri, 29 Jan 1999 01:25:16 +0100 (MET) [thread overview]
Message-ID: <199901290025.BAA22513@miss.wu-wien.ac.at> (raw)
In-Reply-To: <39ADCF833E74D111A2D700805F1951EF0F00B93A@RED-MSG-06> from "Don Syme" at Jan 28, 99 05:32:58 am
> Yes, I'd be interested to see a really convincing use of the utility of the
> OO features, e.g. a program or library which is manifestly shorter, cleaner
> and/or simpler when expressed with OO rather than the core features. I
> guess people can take this as a challenge if they like :-) I'm open to be
> convinced - but I'm not convinced yet.
Imagine that all basic types were classes and all of them would support
a method e.g. "print". Than you could do the following:
let print x = x # print
List.iter print [3; "hello"; 3.14; ["yeah, another list!"]]
or you want to map various objects to strings:
let to_string x = x # to_string
List.map to_string [some_object; another_object; 7; 2.7172]
Some (general) complex stuff you can do with OO (send some messages to
all objects in a container - they do not necessarily have to be members
of the same class, they only share parts of interfaces):
ASet.iter (fun x -> x#simplify; x#factorize; x#calculate_question 42) s
If you want, I show you a zillion similar constructs, which IMHO make
life *significantly* more comfortable...
I already use this where I can, but if basic types were classes, the first
two examples would also work. There is probably hardly any program, where
you wouldn't need such constructs. Although modules are a great means of
abstraction, show me how you can do such (very readable) things with them.
When I began using the OO features, I rewrote some program to use classes
instead of (algebraic) types. The code not only became much more readable,
but it is much easier to maintain - adding new features takes (in my
experience) far less time.
Best regards,
Markus
--
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl
next prev parent reply other threads:[~1999-01-29 8:50 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-01-28 13:32 Don Syme
1999-01-29 0:25 ` Markus Mottl [this message]
1999-01-31 18:43 ` John Whitley
-- strict thread matches above, loose matches on Subject: below --
1999-01-29 0:45 Frank A. Christoph
1999-01-25 20:53 Hendrik Tews
1999-01-26 19:20 ` Ian T Zimmerman
1999-01-28 1:30 ` John Prevost
1999-01-28 20:10 ` Hendrik Tews
1999-01-27 1:29 ` Jacques GARRIGUE
1999-01-27 8:27 ` Jean-Christophe Filliatre
1999-01-28 9:34 ` Cuihtlauac ALVARADO
1999-01-24 21:06 Miles Egan
1999-01-24 23:01 ` Lyn A Headley
1999-01-25 8:44 ` Jean-Christophe Filliatre
1999-01-25 20:45 ` Markus Mottl
1999-01-25 13:36 ` mattwb
1999-01-25 20:48 ` Trevor Jim
1999-01-25 21:57 ` Gerd Stolpmann
1999-01-25 12:45 ` Michel Schinz
1999-01-25 20:37 ` Markus Mottl
1999-01-28 9:54 ` Michel Schinz
1999-01-28 14:13 ` Markus Mottl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199901290025.BAA22513@miss.wu-wien.ac.at \
--to=mottl@miss.wu-wien.ac.at \
--cc=caml-list@inria.fr \
--cc=dsyme@microsoft.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox