[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