I don't wish to complicate issues any, but it seems to me more sensible to
specify the desired separator string as an optional parameter to the URI
constructor. This also avoids the mentioned caveats, as it would otherwise
have to be explicitly changed. I recall there was a question of instance
variables and lack thereof, and having not looked at the module code in
depth I don't know how much work is entailed in using a hash reference
instead of a scalar reference, but IMHO doing so would make the code more
extensible.
on 9/3/02 4:57 PM, [EMAIL PROTECTED] purportedly said:
> Ville Skytt� <[EMAIL PROTECTED]> writes:
>
>> On Wed, 2002-09-04 at 01:05, Gisle Aas wrote:
>>
>>>> However, if the query_param method interface has been there for only a
>>>> couple of days now, perhaps it wouldn't be impossible to change it to
>>>> have the sepchar there and quickly release URI-1.23.
>>>
>>> The sepchar proposal as it stands now is backwards compatible and can
>>> go in anytime.
>>
>> Ok, I just somehow got the impression that you were after a caveatless
>> implementation.
>
> I am. It should look nice.
>
>> But I'm fine with the current one; maybe the caveat of
>> "resetting" sepchar with 1 param in query string (or no query at all)
>> should be documented though.
>
> Sure. If we go with it, this caveat must be documented. I have not
> really said that I want to go with this one. I'm kind of waiting for
> somebody to come up with something that is better :)
>
>>> You want to extend the new query_param() in some way?
>>
>> I was thinking about $u->query_param(';', foo => 0..3), ie. taking the
>> first arg as the separator. But I'm not sure if this is actually better
>> than the former suggestion at all.
>
> This would clearly need Sean's ref trick to be unambiguous
>
> $u->query_param(\';', foo => 0..3)
>
> and that makes it really ugly.
>
> Regards,
> Gisle
>
Keary Suska
Esoteritech, Inc.
"Leveraging Open Source for a better Internet"
