Why aren't some methods integrated within global classes?

1

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?

Update

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
2

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

3 Likes
3

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

4

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
5

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.

6

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.

7

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
8

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

2 Likes
10

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
11

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.

3 Likes
12

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

13

you can always replace methods with new implementations via abstracts

1 Like