From: Alain Frisch <alain@frisch.fr>
To: Peter Zotov <whitequark@whitequark.org>,
caml-list <caml-list@inria.fr>,
"wg-camlp4@lists.ocaml.org" <wg-camlp4@lists.ocaml.org>
Subject: Re: [Caml-list] [ANN] ppx_protobuf
Date: Tue, 06 May 2014 06:29:08 +0200 [thread overview]
Message-ID: <53686514.8070200@frisch.fr> (raw)
In-Reply-To: <6232dace806569a16f7fbfaa1689ef42@whitequark.org>
On 5/2/2014 4:29 PM, Peter Zotov wrote:
> I have just released the first version of ppx_protobuf, a complete
> Protocol Buffers implementation.
This is a very cool project, and a good first public use of extension
points!
An aspect of attributes that is not fully settled is how to use
namespacing in order to ensure that multiple tools interact nicely.
This topic will hopefully be explored by the community to reach a good
consensus.
For instance, ppx_protobuf relies on attributes with quite generic names
such as @default or @key, that might also be useful to other tools. It
might very well be the case that the same @default attribute (with the
same value) would actually be useful to both ppx_protobuf and another
deriving-like extension. This is good, since attributes are not
designed to be necessarily targeted to only one specific tool. But in
some cases, one might want to use a different @default attribute for
different tools. What about supporting both a short form @default and a
more qualified one @protobuf.default? This should support both situations.
Another point: for record fields, you interpret attributes at the
toplevel of their type. I did not look precisely at the semantics of
ppx_protobuf, but it seems that it might be more logical to attach them
to the field directly (do you confirm?):
type defaults = {
results [@key 1] [@default 10]: int;
} [@@protobuf]
I understand that this form is syntactically "more intrusive" in the
non-decorated type definition. Is it the reason to use:
type defaults = {
results : int [@key 1] [@default 10];
} [@@protobuf]
?
I don't see anything wrong with doing so, although it might be worth
supporting both forms.
-- Alain
next prev parent reply other threads:[~2014-05-06 4:29 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-02 14:29 Peter Zotov
2014-05-03 16:08 ` Malcolm Matalka
2014-05-03 16:24 ` Peter Zotov
2014-05-03 18:46 ` Malcolm Matalka
2014-05-03 18:52 ` Peter Zotov
2014-05-04 4:49 ` Malcolm Matalka
2014-05-04 8:55 ` Peter Zotov
2014-05-04 15:18 ` Malcolm Matalka
2014-05-04 22:21 ` Peter Zotov
2014-05-04 22:38 ` Daniel Bünzli
2014-05-04 20:34 ` Gerd Stolpmann
2014-05-06 4:29 ` Alain Frisch [this message]
2014-05-06 4:59 ` Peter Zotov
2014-05-06 7:33 ` Alain Frisch
2014-05-06 10:42 ` Malcolm Matalka
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=53686514.8070200@frisch.fr \
--to=alain@frisch.fr \
--cc=caml-list@inria.fr \
--cc=wg-camlp4@lists.ocaml.org \
--cc=whitequark@whitequark.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