Why aren't some methods integrated within global classes?

Normally in ActionScript methods such as every, some (or all/any ) and reduce are built-in in Array. In JavaScript, String comes with trim. Haxe implements StringTools.trim(s) instead of s.trim.

Is it because of reflection or target-platform reason?


using StringTools; as mentioned by Gama11 resolves s.trim.

Does anyone know why Array hasn’t some methods like I mentioned?

Update (2)

using Lambda; provides additional Array methods, however I found the naming conventions out of the standard:

  • all in Haxe is foreach
  • any in Haxe is exists
  • reduce in Haxe is fold
1 Like

Every Haxe project should have an import.hx that contains using StringTools; in its root directory, then you always have s.trim(). :smiley:


All the more reason to add those methods to String, rather than StringTools

Would be nice to have more array/string methods without import hacks and libraries tho. What a point to have single String extension class in std? It’s only makes difficult to find basic string features for new users.

1 Like

For array methods there is using Lamda; which has a couple functions.

As for why these are in separate classes, I’d guess it is for historical reasons, maybe at some point method couldn’t be added in base classes if a target didn’t have support for it, and now it stayed like that.

But it does make it harder to find these functions.

It doesn’t seem bad to have a class providing these extension methods. Though it seems like Lambda doesn’t have reduce and other functional programming methods (like any/all), which anyone would expect, since Haxe is old.

It has any, but it’s named exists and reduce is named fold.
It doesn’t seem to have all, though this would be easy to add.

1 Like

all/every is implemented by Lambda.foreach (the naming is a bit weird when you are used to JavaScript or PHP).


it seems like both String and Array have static extensions for methods that a lot of devs expect to find out-of-box. I don’t think these classes would seem crowded if we exposed them at all times

1 Like

One upside I see in putting these in static extensions is that it makes it possible to provide alternative implementations of these methods without having to actually touch the original String type.


Thats an interesting point - i never thought about that. :+1:

you can always replace methods with new implementations via abstracts

1 Like