From: "Chris King" <colanderman@gmail.com>
To: "Dario Teixeira" <darioteixeira@yahoo.com>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Smells like duck-typing
Date: Wed, 17 Oct 2007 10:33:42 -0400 [thread overview]
Message-ID: <875c7e070710170733h205fbe54ube172e969da65871@mail.gmail.com> (raw)
In-Reply-To: <932096.75090.qm@web54602.mail.re2.yahoo.com>
On 10/17/07, Dario Teixeira <darioteixeira@yahoo.com> wrote:
> c) Actually put the "Objective" part of OCaml to use. This is the solution
> I am using at the moment. This is what it looks like:
>
> class story (id, title, intro, body) =
> object
> val id: int option = id
> val title: string option = title
> val intro: string option = intro
> val body: string option = body
>
> method id =
> match id with
> | Some thing -> thing
> | None -> failwith "oops"
>
> method title =
> match title with
> | Some thing -> thing
> | None -> failwith "oops"
>
> method intro =
> match intro with
> | Some thing -> thing
> | None -> failwith "oops"
>
> method body =
> match body with
> | Some thing -> thing
> | None -> failwith "oops"
> end
>
>
> class full (id, title, intro, body) =
> object
> inherit story (Some id, Some title, Some intro, Some body)
> end
>
> class blurb (id, title, intro) =
> object
> inherit story (Some id, Some title, Some intro, None)
> end
>
> class fresh (title, intro, body) =
> object
> inherit story (None, Some title, Some intro, Some body)
> end
>
>
> let print_metadata s =
> Printf.printf "%d: %s\n" s#id s#title
Why not have different object types for each of the story types? e.g.
type full = < id: int; title: string; intro: string; body: string >
type blurb = < id: int; title: string; intro: string >
type fresh = < title: string; intro: string; body: string >
print_metadata can remain as is in your object example. In order to
allow functions that operate differently depending on which story type
they're given, use a polymorphic variant like in your first example.
If you wanted print_metadata to take such a type, it could be written
as:
let print_metadata s =
let s' =
match s with
| `Full f -> (f :> < id: int; title: string >)
| `Blurb f -> (f :> < id: int; title: string >)
in
Printf.printf "%d: %s\n" s'#id s'#title
(Note the match gook is unfortunately needed to get the typing right...)
If on the other hand you wanted to ditch objects entirely, you could
do a similar thing using modules and functors. E.g.:
module Full = struct
type t = { id: int; title: string; intro: string; body: string }
let id s = s.id
let title s = s.title
let intro s = s.intro
let body s = s.body
end
(* etc. *)
module Print_metadata(S: sig type t val id: t -> string val title: t
-> string) = struct
let f s = Printf.printf "%d: %s\n" (S.id s) (S.title s)
end
Of course, since calls to print_metadata now look like
"Print_metadata(Full).f story", you're essentially forced to write out
the types of everything, which is probably what you wanted to avoid
anyway.
HTH,
Chris
next prev parent reply other threads:[~2007-10-17 14:33 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-17 13:35 Dario Teixeira
2007-10-17 14:13 ` [Caml-list] " Arnaud Spiwack
2007-10-17 14:47 ` Dario Teixeira
2007-10-17 14:25 ` Daniel Bünzli
2007-10-17 15:03 ` skaller
2007-10-17 15:13 ` Dario Teixeira
2007-10-17 15:25 ` Arnaud Spiwack
2007-10-17 15:32 ` Daniel Bünzli
2007-10-17 16:21 ` Chris King
2007-10-18 7:28 ` Stefano Zacchiroli
2007-10-18 8:33 ` [ANN] pa_oo and pa_polymap for 3.10 (Re: [Caml-list] Smells like duck-typing) Jacques Garrigue
2007-10-17 16:57 ` [Caml-list] Smells like duck-typing skaller
2007-10-17 16:52 ` skaller
2007-10-17 16:59 ` Robert Fischer
2007-10-17 14:33 ` Chris King [this message]
2007-10-17 14:59 ` Dario Teixeira
2007-10-17 15:24 ` Vincent Aravantinos
2007-10-17 15:26 ` Zheng Li
2007-10-18 16:13 ` Zheng Li
2007-10-18 16:37 ` [Caml-list] " William D. Neumann
2007-10-19 0:58 ` Jacques Garrigue
2007-10-17 19:59 ` [Caml-list] " Richard Jones
2007-10-17 20:24 ` Dario Teixeira
2007-10-18 7:37 ` Stefano Zacchiroli
2007-10-18 10:31 ` Dario Teixeira
2007-10-18 10:37 ` Stefano Zacchiroli
2007-10-18 13:28 ` Robert Fischer
2007-10-18 14:10 ` Dario Teixeira
2007-10-18 14:18 ` Brian Hurt
2007-10-18 14:29 ` Arnaud Spiwack
2007-10-18 14:45 ` Brian Hurt
2007-10-18 15:02 ` Arnaud Spiwack
2007-10-18 15:07 ` Robert Fischer
2007-10-18 15:14 ` Arnaud Spiwack
2007-10-18 16:39 ` skaller
2007-10-18 16:49 ` Arnaud Spiwack
2007-10-18 17:47 ` skaller
2007-10-18 19:55 ` Robert Fischer
2007-10-18 16:22 ` skaller
2007-10-18 16:30 ` Dario Teixeira
2007-10-18 14:58 ` Robert Fischer
2007-10-18 15:11 ` William D. Neumann
2007-10-18 15:47 ` Loup Vaillant
2007-10-18 16:08 ` William D. Neumann
2007-10-19 13:08 ` Ed Keith
2007-10-18 16:24 ` Dario Teixeira
2007-10-18 16:35 ` Vincent Aravantinos
2007-10-18 16:43 ` Brian Hurt
2007-10-18 17:04 ` William D. Neumann
2007-10-18 17:05 ` Dario Teixeira
2007-10-18 17:22 ` Brian Hurt
2007-10-18 17:58 ` Dario Teixeira
2007-10-18 15:42 ` Vincent Aravantinos
[not found] <47161E3B.3060704@tsc.uc3m.es>
2007-10-17 15:01 ` Dario Teixeira
2007-10-17 20:20 ` Alain Frisch
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=875c7e070710170733h205fbe54ube172e969da65871@mail.gmail.com \
--to=colanderman@gmail.com \
--cc=caml-list@yquem.inria.fr \
--cc=darioteixeira@yahoo.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