🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Property accessor mode was changed

Started by
3 comments, last by Miss 4 years, 10 months ago

Noticed there were some new commits about a "property" keyword that was added and the default property accessor mode was changed: https://github.com/codecat/angelscript-mirror/commit/9e7e64b997653301971aadd2de1c5947f7ee3bea

I wonder what the decision is behind that, as I was quite surprised to see a ton of script errors after updating from source today, without any indication that I am missing property keywords on them. I think this is quite a big breaking change for a lot of people.

I'm not against change of course, I'm happy to adjust my code if necessary!

For anyone curious as well, setting the engine property for this back to 2 allows you to revert this behavior:


m_engine->SetEngineProperty(asEP_PROPERTY_ACCESSOR_MODE, 2);

 

Advertisement

The decision for this change was due to the need to improve how the virtual property accessors are evaluated (previously only done when the virtual property accessor was used, and not when declared/registered), and also to give the script writer the option to chose whether or not a method with set_/get_ prefix actually should be treated as a virtual property accessor by the compiler.

As you rightly figured out, if desired the backwards compatibility is maintained by setting the asEP_PROPERTY_ACCESSOR_MODE to 2.

 

I've yet to update the documentation with these changes. I plan to do so over the next few days.

 

Let me know if you think it could have been done better in a different way. I'll be happy to review any suggestions and change if they are better.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

I maintain my hobby game engine. I have a set of properties per module. The universal method to change module specific options is in my opinion a good way to go. It simplifies the life of the programmer that is not concerned with where the option comes from he knows it exists and just wants to configure it.
I'm considering it to be an improvement to implement in the engine.

Yes, it is probably a good change. I was just surprised to see it.

This topic is closed to new replies.

Advertisement