Re: [Caml-list] [ANN] ppx_protobuf

[Malcolm Matalka <mmatalka@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2227 bytes --]

I think making the application of a ppx look more like a functor
application solves the name spacing issue for the most part.
Den 6 maj 2014 06:29 skrev "Alain Frisch" <alain@frisch.fr>:

> 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
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 2939 bytes --]