View previous topic :: View next topic |
Author |
Message |
JoeCoder
Joined: 29 Oct 2005 Posts: 294
|
Posted: Thu Feb 01, 2007 10:14 am Post subject: Properties or Methods? |
|
|
Yage currently uses methods to access everything inside a class, while all fields are private. Take yage.node.light for example. It stores ambient, diffuse, and specular values in Vec4f's. There are three methods for each value:
Vec4f getDiffuse();
void setDiffuse(Vec4f);
void setDiffuse(float r, float g, float b); // since OpenGl takes 4 colors but the 4th is rarely used.
I've come up with the following advantages for both properties and methods:
Properties
Less code inside the engine, and therefore...
Less documentation
More direct and powerful access. (defensiveness, if necessary can still be applied by invisible getters/setters acting as properties)
Methods
Similar style to java and other languages.
You don't have to remember if what you want to get/call is in a property or a method.
Import headers for languages that don't support properties won't need separate docs.
Setters can be overloaded to take various formats of input (but is this just bloat?)
No refactoring of existing code.
Thoughts? Any more advantages / disadvantages? Should Yage switch to properties where appropriate? |
|
Back to top |
|
|
PsychoBrat
Joined: 23 Jul 2005 Posts: 22
|
Posted: Fri Feb 02, 2007 5:01 am Post subject: |
|
|
I like the get/set way of doing things, especially in this case, where there will be a LOT of cases like your setDiffuse example. If (almost) all such things aren't able to sanely become properties, it'd seem really messy to have some things as properties and others as get/set.
(However, setters for properties can be can't they? Well, not to take multiple parameters (e.g. with your setDiffuse example above), but to take single parameters of varying types.)
I'd be more in favour of using properties if one could write, for example:
Code: | yadaYada.diffuse = (1.0f, 0.0f, 0.0f); // hot red! |
So, ok, the way D tuples are at the moment that would actually be more like...
Code: | yadaYada.diffuse = Tuple!(0.5f, 0.0f, 0.0f); // not so hot... |
...which would make it a bit of a turn-off, even if tuples for setting properties were possible.
At the moment, though, properties for structs and classes in D seem to me like a bit of a quick and dirty hack, and I don't get that warm fuzzy feeling using them... so I'm more comfortable sticking to the "old" ways.
(P.S: I wonder if it would be possible to rework D's grammar to unambiguously allow (foo, bar) syntax for tuples - maybe if more things were treated as tuples internally... like argument lists etc.?) |
|
Back to top |
|
|
JoeCoder
Joined: 29 Oct 2005 Posts: 294
|
Posted: Fri Feb 02, 2007 2:48 pm Post subject: |
|
|
I'm leaning toward methods also, mainly for the reasons outlined in the first post. Yage does use the op-apply/constructor hack for structs, so to set the values via properties it would be: Code: | light.diffuse = Vec4f(1, 1, 1, 1); |
However, direct access to the property may be more convenient in some cases, and also have faster execution times? Take the following pseudo-example:
Code: | Matrix m = node.getTransform();
m.v[12]+=3;
node.setTransform(m); |
Not only does it have to perform 16 copy operations to copy the matrix to the temporary variable, and 16 more to get it back again, but it's much more code than say: Code: | node.transform.v[12]+=3; |
But if I eventually add export headers for java, c++, or a scripting language, and the property isn't directly accessible but provided instead through a hidden method, it would still make since to have the getter/setter.
Not to hijack this thread, but Yage now compiles and runs perfectly for me in Linux, changes are in the svn. I remembered that you'd asked about that in a much older thread. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|