[erlang-patches] Add a proplist() type
Henrik Nord
henrik@REDACTED
Tue May 24 09:17:20 CEST 2011
On 05/23/2011 09:37 PM, Ryan Zezeski wrote:
> I went ahead and amended my commit and forced the push. So if you
> refetch it should include the export declaration now.
>
> Richard, I think specifying it as [property()] makes more sense
> because [any()] is just a list, and at that point why are you using a
> proplist? Said another way, if the type was [any()] then I don't
> really see much of a benefit of typing it at all.
>
> -Ryan
>
> On Mon, May 23, 2011 at 11:36 AM, Richard Carlsson
> <carlsson.richard@REDACTED <mailto:carlsson.richard@REDACTED>> wrote:
>
> On 2011-05-23 17:00, Ryan Zezeski wrote:
>
> I found it odd the there is no canonical proplist() type
> defined so this
> is my attempt at adding one.
>
> git fetch git://github.com/rzezeski/otp.git
> <http://github.com/rzezeski/otp.git>
> <http://github.com/rzezeski/otp.git> add_proplist_type
>
>
> Good idea. It fixes a few overspecified local definitions which
> state that a proplist has the type [{atom(),term()}] while the
> proplists module define it to be [property()] where property() =
> atom() | tuple().
>
> (If some of those local definitions really mean that only {atom(),
> term()} are allowed, and they don't actually use the proplists
> module, they should preferably change the name of their local type
> instead.)
>
> A couple of examples should make it clear: to the proplists
> module, all of these elements are valid properties:
>
> foo % interpreted as equal to {foo, true}
> {bar, 42}
> {<<"baz">>, 1234} % the key can be any term, not just an atom
> {foo, 1, 2, 3} % the tuple may have more than two elements
> {foo} % even a tuple with only a key is allowed
>
> In fact, the functions in the proplists module generally allow
> other terms to be present in the list, so they actually accept
> [any()] as input, but elements that are not of the property() type
> are ignored.
> Specifying that they require [property()] instead might
> concievably make some existing code be considered as broken by
> Dialyzer, but it could be worth it in order to get better checking
> in normal cases. I'll leave this decision to Kostis and the OTP team.
>
> /Richard
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED <mailto:erlang-patches@REDACTED>
> http://erlang.org/mailman/listinfo/erlang-patches
>
>
>
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches
Hi
I have now fetched your patch, and will cook it in 'pu' for a while,
Thank you for the contribution!
--
/Henrik Nord Erlang/OTP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20110524/05743175/attachment.htm>
More information about the erlang-patches
mailing list