Get/Set Properties.
Author
I think it might be a good feature to register the return value of functions as properties to the Script writer.
The script writer uses this:
//script
int myval = ScriptApi.MyVal;
//in c++
int ScriptApi::MyVal()
{
return MyNum() + GetTickCount();
}
It would be useful to allow this i think.
I agree, and this is already on the to-do list for some time. [smile]
Thanks for the suggestion anyway.
Thanks for the suggestion anyway.
Is it going to be Getter/Setter property syntax C# style, or will getter/setter methods be treated like Java bean properties? Personally I am all for explicit syntax as in C#. I wonder what is the general consensus on this.
I'm not familiar with neither the C# nor the Java beans way of doing it.
My idea is that the get/set property function would be transparent to the scripts. They would for example be used to allow the application to detect when a property is being changed.
My idea is that the get/set property function would be transparent to the scripts. They would for example be used to allow the application to detect when a property is being changed.
C# property syntax is mostly syntactic sugar for getter/setter methods. The following link provides a decent explanation:
http://www.c-sharpcorner.com/Language/PropertiesInCSRVS.asp
In C#, a property of type Type called SomeProperty is defined as follows:
public static Type SomeProperty
{
get
{
// do some additional stuff here..
// ..
return this.someProperty;
}
set
{
// do some additional stuff here..
// ..
// and how about storing the given value? :)
this.someProperty = value; // value is a reserved keyword
}
}
Java bean properties are probably more in line with what you (Witchlord) have in mind). That is, if a class has methods of the form:
Type getSomeProperty()
and
void setSomeProperty(Type someProperty)
then a class instance, in the context of beans (components) is assumed to have a property (usually exposed in a visual tool) of type Type called SomeProperty. If no setter method is defined, the property is assumed read-only. Conversely, if only the setter method is defined, it is considered write-only.
The beauty of C# properties per se is they can be used conveniently as public class members but provide strict control as with getter/setter methods.
Having said all this, I understand that 'properties' in script will likely be mapped (or must be mappable) from a host application class (C++). Hence, the 'bean' approach really makes more sense since C++ has no notion of properties. On the other hand, it is still possible in theory to define a registration method for properties that accepts two function pointers: one for the getter and one for the setter.
[editted because link anchor didn't work]
http://www.c-sharpcorner.com/Language/PropertiesInCSRVS.asp
In C#, a property of type Type called SomeProperty is defined as follows:
public static Type SomeProperty
{
get
{
// do some additional stuff here..
// ..
return this.someProperty;
}
set
{
// do some additional stuff here..
// ..
// and how about storing the given value? :)
this.someProperty = value; // value is a reserved keyword
}
}
Java bean properties are probably more in line with what you (Witchlord) have in mind). That is, if a class has methods of the form:
Type getSomeProperty()
and
void setSomeProperty(Type someProperty)
then a class instance, in the context of beans (components) is assumed to have a property (usually exposed in a visual tool) of type Type called SomeProperty. If no setter method is defined, the property is assumed read-only. Conversely, if only the setter method is defined, it is considered write-only.
The beauty of C# properties per se is they can be used conveniently as public class members but provide strict control as with getter/setter methods.
Having said all this, I understand that 'properties' in script will likely be mapped (or must be mappable) from a host application class (C++). Hence, the 'bean' approach really makes more sense since C++ has no notion of properties. On the other hand, it is still possible in theory to define a registration method for properties that accepts two function pointers: one for the getter and one for the setter.
[editted because link anchor didn't work]
Author
The whole idea is to facilitate better data hiding and encapsulation.
A script writer does not really need to know that myObj.Count is really a function call.
A script writer does not really need to know that myObj.Count is really a function call.
Well, I haven't really consider how the properties would be declared in script classes. That is too far away. Right now I'm only thinking about how the application could register get/set functions to be used as properties in the script.
It will probably be like this:
Both or either can be registered to set read/write access as desired.
The current way of registering properties will of course continue to exist as well.
It will probably be like this:
engine->RegisterObjectPropertyGet("object", "int property", asMETHOD(Object,GetProp), asCALL_THISCALL);engine->RegisterObjectPropertySet("object", "int property", asMETHOD(Object,SetProp), asCALL_THISCALL);Both or either can be registered to set read/write access as desired.
The current way of registering properties will of course continue to exist as well.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
