Re: proplib

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:
> I'm using 5.2, and finally ran into something I wanted to do that
> apparently involves proplib.
> 
> But the documentation is...insufficient.  Unless I missed something
> chasing pointers from proplib(3).
> 
> I can't see how to create a prop_object_t.  The only routines I see
> that return them are prop_array_get, prop_dictionary_get,
> prop_dictionary_get_keysym, and prop_object_iterator_next.  Given the
> recursive nature of the structure, I'd've expected practically
> everything to return them, but most routines return distinct types like
> prop_array_t or prop_number_t, with no indication I can see of how to
> wrap one of those up with a type discriminant into a prop_object_t.

You ought to use prop_dictionary_create(), prop_array_create() and
others.  Think of polymorphism by abusing C types.. and see below.

> It occurred to me as possible that all those types are really the same,
> with the caller expected to ignore the distinction, but (a) then I
> can't imagine why the different types exist at all and (b) I'd expect
> to see something that allows me to tell what type a given prop_object_t
> is.  It really looks as though it was half-designed by someone who
> wanted to go fully type-correct but then finished by someone who didn't
> understand, or perhaps didn't care about, compile-time type safety.
> Alternatively, there's some documentation I haven't managed to find.
> In any case, I'm clearly missing _something_.  What?

They are the same.  It is one (there are more!) of the depressive parts
of proplib(3).  There were some discussions about replacing it.

I am not against the dynamic serialisation model (as opposed schema
based with compile-time safety, like XDR or Protocol Buffers) per se,
as in various cases it provides more flexibility.  However, it can be
much safer, simpler, smaller and more efficient than proplib(3) is.

-- 
Mindaugas