[erlang-patches] Add a proplist() type

Ryan Zezeski rzezeski@REDACTED
Mon May 23 21:37:46 CEST 2011


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> 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> 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
> http://erlang.org/mailman/listinfo/erlang-patches
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20110523/99543088/attachment.htm>


More information about the erlang-patches mailing list