Script binding automation

Since this switch (and others) would be such a hassle in the current AS situation, it seems to me like getting its autobinding up and running should be our main priority.

Urho3D script binding automation projects:

Not exits any magical automatcs bindings. Just look it With a significant change of engine, this will also have to be changed.

So far I didn’t see anybody willing to bring automatic AS bindings in Urho. I saw one attempt, but it didn’t look finished.

There’s no point to call task “main priority” when said priority doesn’t affect the outcome in slightest /sad smile/

How often do you change classes listed in the folder you linked?

I don’t understand why this is a question. I don’t often change engine classes.

Would you agree it is better to remove a boulder from the road than to headbutt it?

Because the folder you mentioned has manual bindings for

  1. Object
  2. RefCounted
  3. Context
  4. StringHash
  5. Math

And these are not complete bindings. Just a fraction of their functionality requires manual bindings.
What kind of changes in the engine will require changes in these files?

Firstly, there are much more files than you listed. Secondly, where is the contradictory in what I said? Imagine you have to change containers in rbfx. Do these automatic bindings help you in some way and you don’t have to redo all this?

Not in case lf AS. If SWIG was to be used for lua then it is possible to make use of lua bindings for stdlib, due to identical interfaces. I did just that. Bindings started before EASTL port and making SWIG bindings for custom urho containers was tedious work.

That is, the bindings were made earlier by someone else? Great, we already have AS bindings made by someone else. You only need to change the bindings to the container when changing containers and so on.

I see a lot of annotations in these files. When you just tell SWIG what to bind and what not to bind.
Annotations are not the bindings, and they are much simpler to edit.
I see a lot of autogenerated files there.
I don’t see a lot of manual bindings there. Unlike Urho3D/Script that has thousands of LOCs.

How often do you change containers and how often do you change not containers?

The point is not to get rid of manual bindings at all.
The point is to remove them from the hot path.

PS. Anyway, autobindings for AS do not exist in the nature, so this is moot point to talk about how they can help us

Thus, you say that you do not have to change these files when changing the engine?

Yes, I do not. Because engine has hundreds of classes, and manual bindings are written only for maybe 0.1% of functionality. @rku correct me if I’m wrong

Yeah well… rbfx happened so i do not have to deal with bindings. So there is a conflict here.

Correct. Most manual part of SWIG bindings is writing rules of what binding code SWIG should generate for certain types in certain cases. StringHash.i is a good example, being compact and not trivial. See StringHash is implemented in C# directly and that SWIG interface tells SWIG how to convert between C++ and C# types. Once written it becomes extremely low maintenance thing.

At the moment our highest maintenance cost comes from template classes. If we add some template type to API, that SWIG is not aware of - we must add one line to the .i file to generate wrapper for that particular template instantiation.

Some bells and whistles (like turning getters and setters into properties) require more effort and maintenance. They are also optional.

True. Manual bindings are a special case. These are our manual bindings: As you can see we have very little of them. Most of which are dealing with quite specialized features (factories, events, callbacks). SWIG is not perfect, but it gets us 95% of the way.

So far the biggest flaw of SWIG comparing it to our current AS bindings is that we have no facility to easily wrap user classes when rbfx is linked as 3rdparty.

@rku You have any idea how can it be supported?

To the contrary - if they indeed do not exist - creating them would add them to nature, making them available to the whole world. It would amount to more than just contributing (greatly) to Urho.

This is actually a strong point of SWIG. User code may import our SWIG modules and magically use of all the rules to bind said types in their own API. User does not need to care how to bind ea::string, VariantMap or Material. All user would have to do is include their headers in .i file and mark class as inheriting from RefCounted (another weak point, still beats writing manual bindings).

Our build system is not rigged to do all that, but it would not be that much work to make it happen. Day’s work maybe.


@1vanK not sure what you are trying to say :slight_smile:

My manual version seems more understandable to me than your manually written module

This is actually interesting question how those are different, in the specific case of StringHash. @rku can you explain? I’m curious too.