Standard for String.substr

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Standard for String.substr

Pimm Hogeling
Nicolas said that "there [seem] to be some crossplatform issues with current substr implementation" (source)

I've decided to make sure the haXe implementation of String.substr works consistent across at least the AVM2, AVM1, ActionScript 3, JavaScript and PHP targets. However, the problem is that the  documentation of String.substr doesn't mention what should happen in the border-cases (such as negative lengths or extremely low starts/positions).

My question is, how do you want the haXe implementation of String.substr to work? Is there any standard we should follow? We could follow the implementation Adobe uses for ActionScript 3, just to name something.

Have an awesome day, everyone.

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Standard for String.substr

Nicolas Cannasse
Le 01/02/2011 13:57, Pimm Hogeling a écrit :

> Nicolas said that "/there [seem] to be some crossplatform issues with
> current substr implementation/" (source
> <http://code.google.com/p/haxe/issues/detail?id=325#c2>)
>
> I've decided to make sure the haXe implementation of String.substr works
> consistent across at least the AVM2, AVM1, ActionScript 3, JavaScript
> and PHP targets. However, the problem is that the  documentation of
> String.substr <http://haxe.org/api/string> doesn't mention what should
> happen in the border-cases (such as negative lengths or extremely low
> starts/positions).
>
> My question is, how do you want the haXe implementation of String.substr
> to work? Is there any standard we should follow? We could follow the
> implementation Adobe uses for ActionScript 3, just to name something.

In general I'm trying to stick to the most expected/logic/coherent behavior.

If some parameters combinations doesn't make a lot of sense (such as -
maybe - negative pos + negative length), then we can make it
"unspecified" which mean we can keep the native implementation even if
they wary from one platform to another in that particular case.

Hope that helps,
Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Standard for String.substr

justin_mills
In reply to this post by Pimm Hogeling
Le 01/02/2011 13:57, Pimm Hogeling a écrit :
Nicolas said that "there [seem] to be some crossplatform issues with current substr implementation" (source)

I've decided to make sure the haXe implementation of String.substr works consistent across at least the AVM2, AVM1, ActionScript 3, JavaScript and PHP targets. However, the problem is that the  documentation of String.substr doesn't mention what should happen in the border-cases (such as negative lengths or extremely low starts/positions).

My question is, how do you want the haXe implementation of String.substr to work? Is there any standard we should follow? We could follow the implementation Adobe uses for ActionScript 3, just to name something.

Have an awesome day, everyone.
I like the as3 one, but depends what overhead it adds on javascript platform.

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Standard for String.substr

justin_mills
Le 01/02/2011 17:13, justin_mills a écrit :
Le 01/02/2011 13:57, Pimm Hogeling a écrit :
Nicolas said that "there [seem] to be some crossplatform issues with current substr implementation" (source)

I've decided to make sure the haXe implementation of String.substr works consistent across at least the AVM2, AVM1, ActionScript 3, JavaScript and PHP targets. However, the problem is that the  documentation of String.substr doesn't mention what should happen in the border-cases (such as negative lengths or extremely low starts/positions).

My question is, how do you want the haXe implementation of String.substr to work? Is there any standard we should follow? We could follow the implementation Adobe uses for ActionScript 3, just to name something.

Have an awesome day, everyone.
I like the as3 one, but depends what overhead it adds on javascript platform.
Or what Nicolas said sounds fine.

--
haXe - an open source web programming language
http://haxe.org