the properties

[LCMark]

@monte:

Looks like there is a bit of backlash about not returning unset values... I'm happy to reverse that but I think it was @runrevmark that wanted it.
To deal with the colour/pattern issue we could not return a color if that pattern is set but otherwise return a color (empty or otherwise)...

Well, I'm not sure I'd class that as a backlash - relatively mild compared to some in the past

Okay so the unset properties thing was kinda my fault - I made a comment about that but was very much thinking of the unicodeTitle/title (which we solved in a different way) and the color/pattern properties and I think I hadn't considered the wider ramifications of it being a general thing. The color/pattern properties still present an issue though since really 'hilitePattern' and 'hiliteColor' are the same property internally (notionally at least) - one which expresses a 'paint' for that particular aspect.

So, anyway, on set - 'the properties' should probably set all properties in the array (or try to) - if the value is empty, then it should set it to empty. On get, 'the properties' probably should return the entire minimal set, regardless of whether they are empty or not. As said above, the only wrinkle is the pattern/color properties, since notionally, 'the hilitePattern' and 'the hiliteColor' are the same property... However, that could be solved using the prioritisation mechanism that is already there (maybe color first, then pattern?).

Btw, the docs don't actually specify what happens if a property is empty - thus you can assume it should set them if present (even if empty). Indeed, it even states that to cause a property not to be set (it uses the name as an example) you should delete the key in the array.

[monte]

Hmm... ok for everything but I think the colors/patterns should only return pattern if set otherwise color. Either that or we will need to do some funky stuff when setting to... find out if there's a value in a pattern key or if it's empty and there's no matching color key then set it... otherwise find out if there's a color key and set it if there is... I guess that's not too bad and perhaps needs to be done either way...

[LCMark]

Hmm... ok for everything but I think the colors/patterns should only return pattern if set otherwise color. Either that or we will need to do some funky stuff when setting to... find out if there's a value in a pattern key or if it's empty and there's no matching color key then set it... otherwise find out if there's a color key and set it if there is... I guess that's not too bad and perhaps needs to be done either way...

Well, I think it makes perfect sense to only return either *color or *pattern - depending on which one is set since that's representative of what is going on. (Prioritisation on 'set' is probably still needed - just so that what happens when you have both in the array is consistent).

[monte]

ok... I'll have a play with it

[jacque]

Sorry I misspoke. When in doubt, listen to Mark. Either of them.

I was probably thinking of the colors, where there are blank lines if a color isn't set.

[monte]

I'm working on this thing but set props is synonym hell with colors and patterns...

[monte]

OK.. sent another pull request... same branch as the closed one so I hope that works... anyway, I hope that makes people happy with what I've done. It needs to be documented that colors have precedence if both have non-empty values.

[mwieder]

Pete Howarth is requesting that synonyms be included in the propertynames. This makes no sense to me. Can someone give me a clue?

[monte]

I think we need a separate topic on the propertyNames and if/how it could be extended to include an object reference... and what it might return... the bigger question to me is if it didn't return synonyms we would need a way in the engine to specify what is the official syntax and what's a synonym/abbreviation... there's nothing like that now as far as I can see... That would I think result in someone having to go through the factor table and add a boolean to is_synonym or something to each entry... if that needs to happen it ain't gonna be me..

Regarding actually implementing the thing my current idea is to parse the factor table and try getting each of the properties from the object. If there's an error thrown then it doesn't have it so don't add that property to the list. It's brute force stuff but I can't think of another way to do it with the way things currently are... perhaps the refactoring changes things???

[monte]

hmm... I just realised we could implement propertyNames(objectRef) even if we can't implement the propertyNames of objectRef...

[mwieder]

Implementing that as a function would be easy enough.

But I still don't understand why synonyms are necessary or even desired.

[mwieder]

...moving propertynames to its own topic to keep things on course.

You cannot make another post so soon after your last.

[monte]

Working my way through lcVCS I found this pearl:

Code: Select all

 -- we don't want object names that are really abbrev ids because the id might change
   if the short name of pObject <> the abbrev id of pObject then
      put uniDecode(uniEncode(tObject["properties"]["name"],"ANSI"),"UTF8") into tObject["properties"]["name"]
   else
      delete variable tObject["properties"]["name"]
   end if

It occurs to me that round tripping the properties on an object that doesn't have it's name set will actually set the name to the abbrev id which is not ideal.. perhaps the properties should return empty for name if it's not set?

[monte]

OK, another one... setting an image filename to empty (or I guess any unfound file) clears the image. Probably better if it doesn't clear the image but continues to set the result to "could not open image" but I guess the quicker fix if that's not really seen as a bug worth spending time on is to add filename to the pre-process list... let me know which you would prefer me to do?

[monte]

OK, I've pushed a change to fix the filename setting to empty when there is imported image data. Not sure if setting the text to empty when there's a filename should work the same way...