![[de]](/mwf/flags/de.png "Germany")
I wanted to talk about this in the meeting, but we can do it here too. With the new properties, I find it a bit unclear what are properties of objects, what are properties definitions and what is queryable through functions.If object properties can be added freely during runtime, why are there local variables? When to use variables, when to use properties? Should properties like
this["IsClonk"] be used instead of Is*-Callbacks like func IsClonk()? Why are local variables not (really) accessible from the outside (only through LocalN) but properties are - are local variables the new "private" variables?These are some questions which confused, especially because some properties of objects are ["properties"] and others not. Is there a pattern behind this or is this random? Some properties are object-properties, others definition-propertes. Examples:
Set X-speed: object->SetXDir(5);
Set visibility: object["Visibility"]=VIS_All; (instead of SetVisibility)
Collectible: object["Collectible"] (instead of being in the defcore?)
Value: in the defcore
There are several styles how to write that you want the object category of a definition (I am not sure if everything of that works:
CLNK->GetCategory();
clonk->GetDefCategory();
CLNK->GetDefCategory(); ??
CLNK->GetProperty("Category") ??
CLNK["Category"]; ??
I think half of what I said is wrong after all. But I'd like to get to a simple interface again where one can easily distinguish between functions, only-object-properties(?), definition-properties and local variables. This might also involve unifiying the syntax.
I believe you should generally use accessor methods (GetCategory/SetCategory) instead of accessing local variables directly. That's common coding style in other object oriented languages. If there is no getter/setter for your attribute, you can write one.I don't think GetDefCategory is needed at all. CLNK->GetCategory() should work. I'm pretty sure it works for names and descs. If it doesn't work, the engine should be changed to make it work.
> If object properties can be added freely during runtime, why are there local variables?
Reimplementing local variables as properties is on my todo-list.
The general idea of properties is that eventually, most of the various existing properties of Objects and Definitions will be reimplemented that way, and Defcore properties will be changed into object properties, which just happen to be mostly inherited from the object prototype/definition. That way, only those objects which really need to change some property will need to store it. Though, whether that's really a good idea I'm a little unsure of - just giving every object the property, but as a simple C++ field would be cheaper as long as there aren't many objects.
But right now, my impression is that this process happens (random) piece by piece now, which causes somewhat of a confusing (for me at least).Just to get this straight:
X-dir is NOT a property
category is NOT a property
name is a property of a definition and thus of an object too
visibility is a property of an object
Yeah, the reason was that I wanted to hardwire the name property a little deeper, so that every proplist has one, so it can be displayed in debug output. Also, name already was a property - both the definition and the object could have it set, and if the latter hadn't, it inherited the one from the definition. Actions are based on properties, because dynamically defined actions was a feature that motivated the whole thing. Visibility is a property because that way, it works without Local(0) and Local(1).Now, it wouldn't be that hard to just go in and replace lots and lots of stuff with properties. The question is, how much performance would that cost? And would it be worth the work? So what would probably help is a list of defcore fields sorted by "importance of mutability" from the point of view of scripters. Hm, and we should probably split the category into a "layer" property and something else for the other stuff. At the moment, it's a random bag of bits. Problem is, category is one of those fields which are read a lot by the engine, so it would probably need some cache or something...
Also, is it even possible to have certain properties of an object as 'properties', thus being able to change them with a '=' instead of a setter-method? I can imagine that if you changed certain properties, it'd need some callbacks here and there.
We should benchmark whether doing an additional redirection via virtual C4PropList::Get/Set impacts performance a lot, because if it doesn't, we can keep structure fields for objects and interface those via C4Object::Get/Set for scripting.
I would appreciate this. Not just from a performance point of view, but also because it makes engine coding much easier. Accessing properties (+check existence, check type) from the engine is just awkward.
That's not so easy, unfortunately: You can get a reference to a property, and references to stuff that aren't C4Values would need to be implemented first. (So, yeah, the prototype field is slightly broken at the moment.) Or, alternatively, you'd need to somehow notify the proplist of changes to the C4Value and keep the fields updated.But if we solve that, an extra switch/case on the C4PropertyName should be lost in the noise of C4Script execution.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
