resolved object comparison

Moderators: heatherlaine, Klaus, FourthWorld, kevinmiller, LCMark

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

resolved object comparison

Post by monte » Tue Nov 12, 2013 8:55 pm

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

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 970
Joined: Thu Apr 11, 2013 11:27 am

Re: resolved object comparison

Post by LCMark » Wed Nov 13, 2013 10:27 am

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
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1559
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: resolved object comparison

Post by monte » Wed Nov 13, 2013 9:56 pm

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

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

Re: resolved object comparison

Post by monte » Thu Nov 14, 2013 6:03 am

Oh... I'd also like:

Code: Select all

switch the controlType of <object ref>
   case stack
      ...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 970
Joined: Thu Apr 11, 2013 11:27 am

Re: resolved object comparison

Post by LCMark » Thu Nov 14, 2013 12:21 pm

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
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1559
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: resolved object comparison

Post by monte » Thu Nov 14, 2013 1:04 pm

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

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 4303
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: resolved object comparison

Post by jacque » Thu Nov 14, 2013 6:58 pm

I like "type". It's more natural. "Class" is geeky.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

Post Reply

Return to “Engine Contributors”