On Jul 22, 2006, at 2:10 AM, Iain Hibbert wrote:

> Ok, is it worth having a *ternalize_to_file functionality in the  
> library?
> Although its fairly trivial to implement, having a standard  
> function would
> be useful if usage becomes widespread..

Yah, I'll probably implement those when I do the array internalize/ 
externalize.  Actually, I just whipped those up while waiting for the  
dishwasher to finish up :-)  I'll do the to/from file stuff a bit  
later today.



> I'm easy since I have no need for the array anymore, but I dont see  
> any
> big deal checking the object type - after all, you must to do that  
> most of
> the time anyway.

I've been thinking of making that a little easier, actually... but,  
yes, you need to check the object type when fetching from a  
collection... But again, I was trying to model it after some prior art.

> 	obj = prop_dictionary_get(dict, "count");
> 	if (obj == NULL || prop_object_type(obj) != PROP_TYPE_NUMBER)
> 		errx(...);

I am planning on changing prop_object_type() to return an invalid  
object type identifier if the argument is NULL, so you will be able  
to collapse that into:

	obj = prop_dictionary_get(dict, "count");
	if (prop_object_type(obj) != PROP_TYPE_NUMBER)
		errx(...);

> Although I think a standardised configuration format and parser is a
> desireable thing, and I'm happy with the tree structure, I think  
> that the
> lack of readability in XML is a major concern.

I guess I just don't find the XML unreadable.  Again, that may be  
that I'm saturated in it at my Day Job :-)  But also, I didn't want  
to create some new format, I wanted to use something that was already  
in wide use... and I don't think anyone can argue against OS X having  
the largest installed base of all of the BSD-derivatives :-)

-- thorpej