onyxblade / godot-ruby

ruby language binding for godot game engine
MIT License
37 stars 2 forks source link

Getters/setters for properties #3

Open KoBeWi opened 6 years ago

KoBeWi commented 6 years ago

So, I just found out this repo and looking at the limitations, I noticed something odd:

Ruby's method semantic is incompatible with the seperate properties and methods in GDScript since there are only methods in Ruby. For this we have to use get which looks weird [...] rect2.get(:position)

All properties in Godot already have getters/setters, e.g. it's get_position()/set_position() for position property. Isn't it possible to bind Ruby methods to these methods? Or auto-generate Ruby attribute accessors? It should be possible to use position/position= directly as methods instead of awkward get/set.

onyxblade commented 2 years ago

Hi @KoBeWi,

Sorry for the late reply. I can only try to explain the problem since I haven't been working on the plugin for so long.

What you said is possible, but might introduce heavy overheads. Consider a ruby code gets a godot object a, it does not know what properties and methods a responds to. Suppose the user call from the ruby side a.some_method, it is now uncertain how should we interpret this method call. It can be (1) getting a property named some_method, or (2) calling a method named some_method.

In order to support this, we have to first use reflection to list the properties and methods of an object, then decide what to do. But GDScript is also a dynamic language, thus it is possible that every time we use a godot object, it has a different properties list. In the worst case, we would need to reflect every time when calling on a godot object to ensure correctness.

KoBeWi commented 2 years ago

tbh I don't know how this works in GDNative. Maybe it's possible to predefine some Ruby classes based on the API, so that the setters/getters are known (at least for core classes). And in worst case, they can be cached on first lookup.

onyxblade commented 2 years ago

You are right. It is possible to cache the method table and reflect only when method_missing, and it should be sufficient for most cases.