properties property refactor

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark

Locked
monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

properties property refactor

Post by monte » Sun Oct 11, 2015 7:40 am

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
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

livecodeali
Livecode Staff Member
Livecode Staff Member
Posts: 192
Joined: Thu Apr 18, 2013 2:48 pm

Re: properties property refactor

Post by livecodeali » Tue Oct 20, 2015 5:49 pm

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

Code: Select all

MCPropertyInfo *lookup_object_property
).

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: properties property refactor

Post by monte » Tue Oct 20, 2015 9:12 pm

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.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9802
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: properties property refactor

Post by FourthWorld » Tue Oct 20, 2015 9:47 pm

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.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: properties property refactor

Post by monte » Wed Oct 21, 2015 12:52 am

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.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

Locked

Return to “Engine Contributors”