Hi, Greg and Brane. Thanks for your feedback.
Branko Čibej wrote:
> Greg Stein wrote:
>> We've seen some of this kind of stuff in svn_iter.h, and it did not
>> turn out to be useful. The additional concepts needed to
>> learn/keep/use costed more than the incremental benefit.
The new functions are aimed at making typical, shortish loops shorter and
clearer to read. Those previous iterators were too cumbersome for most cases
and rarely useful.
>> I find the SVN_ITER_T() and SVN_ARRAY_ITER() macros in your example to
>> be rather inscrutable.
At first sight, yes, of course, but they could quickly become a familiar idiom.
> Agreed. The new macros don't really add any type safety, since they rely
> on implicit conversions from void*.
That's right: they do not check that the declared element type of an array/hash
matches the type requested for iteration, except that it is a pointer.
The comment about 'parameterized element type' does not refer to type *safety*
but rather means that the iterator's 'val' field has the requested type rather
than 'void *', which enables using it directly as an element pointer like this:
for (SVN_ARRAY_ITER(i, array_of_string_t, pool))
foo(i->val->data, i->val->len);
rather than having to first assign it to a variable of the correct type like
this:
for (SVN_ARRAY_ITER(i, array_of_string_t, pool))
{
svn_string_t *s = i->val;
foo(s->data, s->len);
}
> I'm also *very* scared of the
> implicit, hidden qsort in the sorted.
It's invoked only if you write "..._SORTED()" or "..._sorted()". That's
explicit and visible. What's so scary about that?
> It would make sense to design type-safe, light-weight container and
> iterator template wrappers around the APR structures if we decided to
> write code in C++. Since we're not, "explicit is better than
> implicit".
I understand the point. I note that "explicit" is not a binary quality: there
are degrees of it.
I suppose I want to be writing in a higher level language. Maybe I should just
go ahead and really do so.
- Julian
