resolved object comparison

[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?

[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)'.

[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.

[monte]

Oh... I'd also like:

Code: Select all

switch the controlType of <object ref>
   case stack
      ...

[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).

[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

[jacque]

I like "type". It's more natural. "Class" is geeky.