FEATURE_INHERITED_PARENTSCRIPTS

[mwieder]

OK - this is exciting. It handled everything I could throw at it. Breakpoints, runtime errors, dispatches... the error object context and variable scopes were all perfect. Handing control off to PowerDebug (which is where I was more worried about things breaking - I had code in place to handle this coming into play eventually, but obviously never had a chance to test it) went smoothly, and tossing the error context back to the script editor also passed the test.

For me, this is the most exciting thing to happen to LiveCode since getting parentscripts in the first place.

[monte]

It is exciting. I just wonder why runrevmark hasn't enabled it. There may be some performance issue or something that we haven't hit yet???

Re the merge I'm thinking if it were to be merged it would be a case of stripping out all the ifdefs rather than defining it. I'm more than happy to do that if the pull request would be accepted. This is just a quick way to play with the feature

[mwieder]

For the moment I think it's safer to keep the #ifdefs in place, just in case there's something we haven't thought of. It's slightly easier to back out of.
But I can't think of anything we haven't thought of (update: I can't believe I just wrot e that...) - it's doing everything right on the first try, which makes me suspicious

[monte]

I can't think of anything we haven't thought of either But that's why @runrevmark gets the big bucks... to think of the unthinkable...

[mwieder]

Yep - and I'm happy to leave the headaches to him as well.

[mwieder]

I posted something about this in a different thread, but what do you think of the syntax

put the parent of control x
put the children of control x

where "parent" is a synonym for "behavior" or "parentscript" (I wouldn't mind just dumping "parentscript" as a keyword)
and "children" does the opposite (lists the controls that inherit from the parent control)

[monte]

So parent would be a synonym of behavior?

In what context would children be useful? I think to implement that would require a search of all controls in memory because the link is only one way I think. I guess we could add a two way link to implement it.

[monte]

What about the short name of the behavior control being used as a class name so we can isType/Class a control for polymorphism?

[mwieder]

I'd feel better about using the short name if we could guarantee uniqueness. How do you see IsType or IsClass being useful?
Just the fact that it has a behavior qualifies an object as a subclass, and polymorphism should be inherent without needing to check the class type.

"Children" probably isn't necessary. It was just a random thought - the only way to make it useful would be to maintain a doubly-linked list or an array in system memory.

[monte]

In some circumstances you would be iterating objects of unknown type and want to test to see which type it is in order to dispatch the appropriate message to it. This is more likely to happen in an environment with a behavior inheritance hierarchy where there's multiple subclasses that are all all ofClass(grandparent class)

[mwieder]

Hmmm... seems very non-OOPish to have to query an object's pedigree to determine what message to dispatch.

[monte]

well... imagine you have a group that contains many objects that are all different behaviors. IsTypeOfClass would be a way to work out which type they are before doing something to them. Querying the type of a class is quite common in OOP where you would often have a method that accepts the grandparent class then test the type and cast so you can work with the child class.

[mwieder]

I'm sorry - I just can't see this being useful...

So in order to send a message to a control (or rather to its grandparent control) you'd first check to see what type of control it is, and then send the message?

Casting a class type would be useful at design time in an OOP environment where you need to cast the object type, but I can't see it have a runtime use.
Can you help me out with a use case for this? I'm coming up blank.

[monte]

Hmm.... basically it's just a way to determine if a behavior is in the inheritance path of the control. I don't know about you but I've written code to test to see if a group is a datagrid. It's not that hard to check to see if word -1 of the behavior is "revDataGridLibrary" but what if someone has added an extra behaviour into the path... it's still a datagrid but to test for it you need to loop through all the behaviors to work it out. So what I'm talking about here you would give a behavior a unique name (probably reverse domain like RunRev are proposing for custom control stacks) and then you could have an isTypeOfClass function.

[mwieder]

Well, I'm not opposed to the idea in general, but... so if I've got this right, you're proposing an engine-level function that would iterate through the behavior links and return a boolean saying whether there's a match with the string argument that is a reverse-domain class name?

OK - I can see that having some usefulness - if you want to set the dgText of a control you'd want to make sure it's subclassed from a DataGrid. But...

I really don't like the whole reverse-domain thing. Didn't like it when it showed up in java, haven't liked it since. I realize it's not your decision, just sayin'. It's very not-natural-language, doesn't fit into the whole ease-of-use approach to programming.

I don't think I like the IsTypeOfClass name either. Same sort of reason: too wordy and makes the developer do non-LC thinking. I don't have a better name right now, but I think I'd like to see an extension of the "is a" syntax, as in

Code: Select all

if control "xyzzy" is a DataGrid then

where the "is a" operator would do the behavior iteration behind the scenes.