FastIteratingStringMap: part 2

2015-03-16 Leave a reply

Some time ago I wrote a post about an idea, how StringMap could be implemented (for js target) to have ability to iterate fast. I continued to work in this direction, and finally idea evolved into nearly final implementation.

Tests were added;
Special iterators implementation for case when there is no data in the map;
Benchmark code instantiate a specific class now (instead of using creator function), to give Haxe ability to optimize map usage and inline functions;
Haxe 3.2 (from development branch) was used to compile benchmark;
Another idea was tested (CachingKeysStringMap);
Constant time complexity.

FAST iterators for StringMap

2015-02-23 2 Replies

StringMap is probably most used class in Haxe (I think only Array is used more often). Probably you never use it directly, rather you use Map<String, SomeType>, which use haxe.ds.StringMap under the hood.

Since it is used very often, it must be very fast. At least it should be… So let’s go a little deeper and look how haxe.ds.StringMap is implemented for javascript target.

Tricky unsafe cast is too tricky

2015-02-05 Leave a reply

Important: this article is written about Haxe 3.1.3. It works well in Haxe 3.2 🙂

Few days ago I wrote about eight things I don’t like in Haxe, and one of thing was tricky unsafe cast syntax:

(cast findViewById(R.id.myTextView):TextView).setText("Cool");

compared to safe cast:

cast(findViewById(R.id.myTextView), TextView).setText("Cool");

However I was wrong. This unsafe cast work fine only on dynamic targets, but on cpp it cause compilation error:

5 more things I don’t like in Haxe, and how to fix them

2015-02-02 6 Replies

1. Non-consistent utf-8 support across platforms

There is excellent haxe.Utf8 class, which allows us to work with utf-8 in a cross-platform way.

But what about cross-platform toLowerCase() or toUpperCase()? What regular expression should I write to replace all non-letters (including unicode ones) with, say, spaces?

To solve this problems, I created zame-haxe-stringutils library.

8 things I don’t like in Haxe

2015-02-02 11 Replies

STOP right here. Before I say a few words of criticism about Haxe, you should know, that i REALLY like this language.

Btw, this post is pretty old, haxe was improved since I wrote it.
Feel free to read other posts 🙂
Top 3 (in my taste):

Ok, let’s continue.

I use many programming languages everyday, and ~~Ruby~~ Haxe is the most promising of them. Thanks to Haxe I can build my projects for web, for mobiles, build them as native applications. Comparing with JavaScript, Haxe has strict typing; comparing with C++, Haxe is MUCH easier to write. Enum-matching is fantastic thing! And last, but not least, Haxe allow me to write platform-specific code via untyped keyword (just like old good #ifdef in C / C++).

But there are several things that make programming in Haxe more complex and not so exciting. Maybe some of that things will be fixed in next versions of Haxe, while other things is by design and will not be fixed even in Haxe 4 / Haxe 5. Anyway, I still want to talk about them.

Setter with default getter + Actuate = problem

2015-02-02 Leave a reply

Let’s say you need to animate some custom property of object. And you choose to use Actuate as tweening library:

Actuate.tween(someObject, 1.0, { myOffsetX: 100 });

Moreover, you need to do some work when property updated, so you decide to create a setter:

public var myOffsetX(default, set):Int;

private function set_myOffsetX(value:Int):Int {
    if (value != myOffsetX) {
        myOffsetX = value;
        doSomeWork();
    }

    return value;
}

It works fine while you building it to flash, but stop working on html5 or native.

Game dev in general and Haxe in particular