In LP8.x encode_url would basically take any type that was thrown at it
and return a value whether the input type made sense or not... give it a
map, array, integer, decimal etc. and it returned a string type, encoded.

[
encode_url(null);'<br />';
encode_url(1);'<br />';
encode_url(1.25);'<br />';
encode_url(map('y'='yes'));'<br />';
encode_url(array('n'='no'));'<br />';
encode_url('this is a string.');'<br />';
]
=>
=> 1
=> 1.25
=> map%3A%20(y)=(yes)
=> array%3A%20(pair%3A%20(n)=(no))
=> this%20is%20a%20string.

In LP9, it will choke on all but strings and bytes. I see in the compat
layer, the encode_url tag uses this:

define encode_url(b::bytes) => #b->encodeUrl(false)
define encode_url(s::string) => bytes(#s)->encodeUrl(false)

but is there a reason it doesn't just do the following instead?

define encode_url(a::any) => bytes(#a)->encodeUrl(false)

also, integers don't work currently, or with the "any" code above, so I
suppose I could do this...

define encode_url(i::integer) => bytes(string(#i))->encodeURL(false)

Or even this:

define encode_url(i::integer) => bytes(string(#i))

Of course, since encode_url in LP8 returns a string, shouldn't it also
return a string in LP9 for truer compatibility? but I was going with
bytes since that is what LP9 is using...

I know I can so easily extend this as such myself in LP9 [LOVE!], but
since they're not that way already I'm wondering if I'm being foolish
for suggesting it. And, if so, I want to understand rather than carry on
acting a fool. :)

-Trevor
#############################################################
This message is sent to you because you are subscribed to
the mailing list Lasso
Lasso@lists.lassosoft.com
To unsubscribe, E-mail to: <Lasso-unsubscribe@lists.lassosoft.com>
Send administrative queries to <Lasso-request@lists.lassosoft.com>