Does AngelScript support the concept of 'getter'/'setter' for object properties? For instance, in my code I define that an object has the propertty 'Name'. The object I am exposing doesn't really have a variable backing the Name property, because it is defined dynamically at runtime in a sort of blueprint file. When the script writer acceses name (via doing this.Name = "Hello World", or someVar = this.Name), I would like a function invoked with the properties name, so that I can look it up in the objects dynamic data store and get it's value. I know I could expose the functions GetName(), SetName(), or Get/Set more specifically, but I would like the concept to be transparent to my world builders. If a property is defined in a blueprint file, I would like them to be able to access it via an AngelScript object property, even though that property probably does not have a concrete backing as a member variable in the concrete C++ class. I guess this gets pretty deeply in the details of dynamic objects, as thats really what I am trying to support here. Runtime defined objects that may or may not have concrete implementations at compile time.

I guess the on-topic short answer to your question would be: No, AS doesn't support properties. That said, I think it would be a nice addition as it doesn't break compatibility with C++. If all you want is the ability to have designers use property notation in their scripts, I think properties are a must.

But...

Without going further into the merits of having C# style properties in AS (I'm not the author :)), if you had in mind to build an editor with property sheets for objects, you could borrow from the concept of Java Beans, that is, using getter and setter methods coupled with a mechanism for mapping property sheets to the getters/setters. You could implement a property descriptor mechanism via a manager class or a wrapper around AngelScript type registration functions that not only register the corresponding getter and setter methods but also manage the property descriptors. The last link in the chain would then be to have your system look up the property descriptors for a given object type in your editor, construct a corresponding property sheet and perform calls to the corresponding getter and setter depending on user input.

Hope I've been of help.. please bear with me if I WOOTed a little bit :)

Calefaction:

SharkBait is correct. AngelScript is currently not supporting getter/setter methods for object properties yet. It is something that has been asked for before and that I intend to implement in time.

Properties like this fits well into what I have planned for AngelScript in the future. My current plans (nothing concrete yet) are to allow applications to register interfaces, which both application registered objects and script declared objects may expose. The properties would then be registered to these interfaces, and it is up to the implemented to decide how the getter/setter methods map to the internal structure.

The idea is that an object can expose various interfaces, and the object handle can be dynamically casted between the interfaces. If the real object that the handle refers to doesn't expose a wanted interface then the cast would return a null pointer.

This design is similar to that of COM+ components, and should be quite easy to implement in the library, and also to use by both application writers and script writers.

This implementation will likely be implemented shortly after the release of 2.2.0, maybe in version 2.3.0, or 2.4.0.

This is not yet true inheritance, as in OO design. Inheritance is something that is very complicated to implement, especially when the classes are implemented in separate languages (C++ and AngelScript). I've yet to find a solution that can be implemented without too much inconsistencies.

I know you didn't ask about all this, but I thought you might be interested in where I'm headed with AngelScript to know that it will be able to do what you want.

Regards,
Andreas