LiveCode Forums

Hi

I'm wondering about refactoring the properties property so that it runs off kProperties rather than requiring the maintenance of props.cpp.

So... what I'm thinking is to do this we would need to add a bool to MCPropertyInfo indicating if the property should be in the properties array (fits within the rules - writable & no duplication). Then we need to add a bool to LT to indicate if a token is a synonym or not which will allow us to work out what the array keys should be for a property. Then we need a method for each object type that will iterate over kProperties and set the array and then call the super class for it to set them and so on. I think that should cover it. I'm not sure if there are any overloaded properties though which would throw a spanner in the works...

The only thing I can't work out is how to camel case without maintaining a separate list but I think we can live without camel casing if we end up with a properties property that needs no constant maintenance.

One advantage is we could fairly easily extend it to allow for things like getting a complete array of properties (including all the ones that aren't included because of the properties property rules) or just the writable properties or just the read only properties etc and so on...

Cheers

Monte

You wouldn't need to add a method for each object type, as the property info structs contain a reference to the parent table (see for example ).

Handy, the discussion about this on the use list sort of ended up that it might be better to deprecate the properties property. The idea might still be valid for introspection though. Both of the engine (list synonyms of X, filter out synonyms from lists) and objects (list all properties, read only, writable, inherited). Interesting info at least in the development engine.

To list synonyms we could alter my original idea to have an extra bool in LT and change that to a value from the Properties enum which would indicate the standard version of a synonym.

What could we do with this info??? Well for one thing we could have a script editor property that would check your code and give warnings when you didn't use the standard version of something. I imagine this would be quite helpful to standardise syntax in large teams.

monte wrote:Handy, the discussion about this on the use list sort of ended up that it might be better to deprecate the properties property.

I don't recall that outcome from the discussion. A lot of us have code that makes good use of that feature.

I currently make use of it for lcVCS myself. The discussion led to exporting & importing objects as arrays which will give a truer representation of the object. It also discussed that the properties property is not ideal for some of the uses it is being put to. That's one reason why I'm steering this conversation in the direction of improving the introspection of objects and syntax rather than just on the properties property. The properties property could still get the refactor I'm suggesting put perhaps it wouldn't be the primary goal.