Page 1 of 1
resolved object comparison
Posted: Tue Nov 12, 2013 8:55 pm
by monte
I think it would be nice if this resolved to true:
Code: Select all
put the abbrev id of me into tAbbrevRef
put the long id of me into tLongRef
put tAbbrevRef is tLongRef
So the object references are resolved then compared as objects rather than strings. Perhaps is [not] object?
Re: resolved object comparison
Posted: Wed Nov 13, 2013 10:27 am
by LCMark
I like the idea, but I wonder if there might be a potential future syntax issue with using the 'object' keyword in this way.
At some point it would be good to add faceless objects which could have any sort of parent, and indeed generalize the object structure with an application/project object at the root. With this idea, 'object' would then be needed to refer to these things just as 'stack', 'card' and 'control' etc. are at the moment. The problem comes because '<chunk> <name>' expressions evaluate to the contents of the object - and although only defined for buttons and fields, you still get the same behavior if you reference a field as 'control ...'; thus a logical and natural expectation would be that you could do the same with 'object ...'.
This poses a problem because then you have an ambiguity - does 'a is object b' mean '(a) is object (b)' or, '(a) is (object b)'.
Re: resolved object comparison
Posted: Wed Nov 13, 2013 9:56 pm
by monte
Hmm... any other possible syntax? It seems to me that 'object' should be used here (and elsewhere) as a super class of everything much like control is for layers. It might be better to come up with another name for faceless objects so they can both be objects and <insert name for faceless object here>.
How about "refers to"?
The other thing I've been wondering is about: "is [not] a <controltype>"... at the moment I check word 1 of the abbrev or long reference so this would avoid a couple of steps there... extracting the word & string comparison.
Re: resolved object comparison
Posted: Thu Nov 14, 2013 6:03 am
by monte
Oh... I'd also like:
Code: Select all
switch the controlType of <object ref>
case stack
...
Re: resolved object comparison
Posted: Thu Nov 14, 2013 12:21 pm
by LCMark
It seems to me that 'object' should be used here (and elsewhere) as a super class of everything much like control is for layers. It might be better to come up with another name for faceless objects so they can both be objects and <insert name for faceless object here>.
Yes - I'd propose 'object' being the catch-all. I must confess I always thought 'object' would be fine for referring to faceless objects. They'd just be customprops+name+id+layer+script with no other properties. However, when we get 'open language' it might be that they wouldn't be of much use - as syntax wrapped arrays or something similar would probably work better.
How about "refers to"?
Yup - that sounds good to me. Indeed, if the syntax is implemented as:
Code: Select all
<left: MCExpression> refers to <right: MCChunk>
We get 'x refers to y', 'x refers to button 3', 'x refers to me' etc.
The other thing I've been wondering is about: "is [not] a <controltype>"... at the moment I check word 1 of the abbrev or long reference so this would avoid a couple of steps there... extracting the word & string comparison.
This would be good also.
In terms of 'the controlType' - is that the property name we'd want... What are the other options? 'class', 'type', 'kind'... (This should really return the 'type' of the object, so you'd want it for stacks/cards/aclips/vclips and those aren't controls - technically at least).
Re: resolved object comparison
Posted: Thu Nov 14, 2013 1:04 pm
by monte
OK, I'll add refers to to the todo list
I think class works although there was some discussion of reverse domain class names for everything in the custom control stuff that didn't make 6. I use that in lcVCS actually "com.runrev.engine.button" etc... I only thought of controlType because it's CT_... type works too I guess:
Code: Select all
if the type of <controlRef> is button then
Re: resolved object comparison
Posted: Thu Nov 14, 2013 6:58 pm
by jacque
I like "type". It's more natural. "Class" is geeky.