On Thu, Apr 24, 2008 at 12:50:09AM +0100, Rudolf Lippan wrote:
>
>
> On Wed, 23 Apr 2008 09:34:13 +0100, Tim Bunce <[EMAIL PROTECTED]> wrote:
>
> > Here's a more refined and detailed outline. It's evolved from one I
>
> aka more involved ;)
Naturally ;)
> > sub _concat_hash_sorted {
> > my ( $hash_ref, $kv_separator, $pair_separator, $value_format,
> > $sort_type ) = @_;
> Looks fine. I did draft of the above (without the neatsvpv for right now as
> I need to dig into that some more), and I have couple of questions:
>
> 1. You no longer want _concat_hash_keys() ?
The name has changed, the details haven't much. The idea is the same.
It was a poor name as it needs to concat both keys and values.
> 2. How closely are you expecting the C API to match the perl api? It looks
> like the C stuff would have to do less work if it were to pass some of the
> string lengths around.
I had originally thought I'd want a C API for _get_sorted_hash_keys()
for the ShowErrorStatement code to use. Now, with the revised
description, that's not needed. The new _concat_hash_sorted()
functionality means it can be used directly by the ShowErrorStatement
code as well as prepare_cached and connect_cached.
So I'd be happy to see an API like this:
SV *_concat_hash_sorted( HV *hv, char *kv_sep, char *pair_sep, SV
*value_format, SV *sort_type)
The kv_sep & pair_sep params could be SV*'s if that's easier to implement.
> 3. Do we worry about Magic here?
Not beyond the basic best practice of using this at appropriate places:
if (SvGMAGICAL(sv))
mg_get(sv);
> > p.s. Some tests with reasonable coverage would be the icing on the cake!
>
> Of course!
Wonderful. Thanks!
Tim.
