From: "Bünzli Daniel" <daniel.buenzli@erratique.ch>
To: Vincent Hanquez <tab@snarc.org>
Cc: caml-list caml-list <caml-list@yquem.inria.fr>
Subject: Re: [Caml-list] [OSR] Suggested topic - XML processing API
Date: Tue, 5 Feb 2008 11:31:22 +0100 [thread overview]
Message-ID: <42E82E2A-5A21-426A-9D3F-E4BBE32F0EEC@erratique.ch> (raw)
In-Reply-To: <20080205095137.GA3573@snarc.org>
Le 5 févr. 08 à 10:51, Vincent Hanquez a écrit :
> On Tue, Feb 05, 2008 at 09:36:02AM +0100, Bünzli Daniel wrote:
>>> - having a common spec for several libs makes more sense if they
>>> can share
>>> common types; maybe you should use polymorphic variants instead of
>>> regular
>>> ones?
>>
>> Agreed. In xmlm these variants become polymorphic in the next
>> version.
>
> that's really a bad idea; As a user of xmlm, I hope you're going to
> re-consider. the polymorphic variant namespace is so easily polluted
> by
> random "value"
What people seem to fail to understand is that with polymorphic
variants if you close them and write mlis you get exactly the same
typechecking as with regular variants but without being tied to a
particular module. For example if define
type encoding = [ `ISO_8859_1 | `US_ASCII | `UTF_16 | `UTF_16BE |
`UTF_16LE | `UTF_8 ]
and then ask for this type exactly in a function type, e.g.
val encoding_to_string : encoding -> string
then you get exactly the same typechecking as with a regular variants
on applications of encoding_to_string.
Using variants allows you to have a better decoupling between say your
own modules that hande encodings and xmlm. As Jacques mentions this
actually may prevents pollution from xmlm to your own modules.
Best,
Daniel
next prev parent reply other threads:[~2008-02-05 10:31 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-30 0:54 Jim Miller
2008-01-30 2:37 ` [Caml-list] " Bünzli Daniel
2008-01-30 3:26 ` Jim Miller
2008-01-30 7:35 ` Alain Frisch
2008-01-30 10:32 ` Bünzli Daniel
2008-01-30 10:35 ` Jon Harrop
2008-01-30 17:25 ` Jim Miller
2008-02-05 3:23 ` Jim Miller
2008-02-05 5:02 ` Alain Frisch
2008-02-05 8:36 ` Bünzli Daniel
2008-02-05 9:51 ` Vincent Hanquez
2008-02-05 10:13 ` Jacques Garrigue
2008-02-05 11:14 ` Vincent Hanquez
2008-02-05 10:31 ` Bünzli Daniel [this message]
2008-02-05 10:43 ` Nicolas Pouillard
2008-02-05 13:29 ` Jon Harrop
2008-02-05 14:53 ` micha
2008-02-05 14:53 ` Jon Harrop
2008-02-05 14:57 ` David Teller
2008-02-05 11:21 ` Vincent Hanquez
2008-02-05 8:15 ` Vincent Hanquez
2008-02-05 11:16 ` Stefano Zacchiroli
2008-01-30 15:55 ` Vincent Hanquez
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=42E82E2A-5A21-426A-9D3F-E4BBE32F0EEC@erratique.ch \
--to=daniel.buenzli@erratique.ch \
--cc=caml-list@yquem.inria.fr \
--cc=tab@snarc.org \
/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;
as well as URLs for NNTP newsgroup(s).