LiveCode Forums.

Reasons not to turn it on? ... er... um... ??? It's a dream come true...

Test 1 - Protocols/Polymorphism
grandparent button: parent button: child button... no code... answers "hello world"

Test 2 - Inheritance ... same code but gradparent and parent code reversed... still answers "hello world"

Test 3 - Overriding ... add a second child and implement test function there: answers "hello awesome feature"

In the choice between sliced bread and this... sliced bread comes second... let's get this out there

I really, really want this, but...

have you looked at the executioncontexts when it's enabled? I realize that the groundwork was done to allow this from the start, but it may well play havoc with the debugger. I've got some code ready in PowerDebug but it hasn't been enabled because I'm not sure yet of the repercussions.

Not that I want to dissuade you from doing this, but I think it's better to ease into this one.

Well from the comments it looks like it was implemented 4 years ago so I guess it has been eased in

Given the feature is already implemented but just not turned on ill let Mark explain the reasoning behind that. If he has his reasons no matter how many pull requests I send it won't make the engine...

Yeah, when we first got behaviors I realized that the mechanism was designed to allow for true inheritance, but I'm not sure yet if the engine can untangle that past the first layer.

so you're worried about not knowing where the code is when there's an error?

Basically, yes. The format of the executionContexts is different when there's a behavior script involved. There's an extra parameter at the end of a line if it's in a behavior script. I assume that if more inheritance layers are involved then there would be additional lines in the executionContexts, and they'd follow the same format. In that case it would just be a matter of working down the chain of stack frames. But I don't know if the engine is ready to handle this, and I can definitely say that the revdebugger script isn't up to it.

ok... I just ran a test causing an execution error in the grandparent and it worked fine including stepping through code from parent to grandparent...

Great! That was my one concern. I take it that the local variables maintained their scope as well. Can you try causing an error in a parent script and make sure that the handoff to the error stack is also done smoothly?

I didn't check variables... I'll do that when I have a chance.

For the second request isn't that what I did? Or is there a difference between causing an error in the grandparent and parent? I also did breakpoint in parent and it stepped into grandparent.

Breakpoints are different from runtime errors. They throw different messages (traceBreak vs errorDialog) and the IDE deals with them differently in that runtime errors are handed off to the stack that displays the error rather than to the debugger.

Hmm.. you want me to do something that causes a runtime error when not in debug mode? Is that it. Debug mode seemed to work fine.

it all appears to work as expected... would be good if you had a play with it though because you would spot issues with error handling I can't see

OK - now that Ian's got the 6.0.1 thing settled I'm able to build against the latest changes. Do you have a branch/commit for this? I'm ready to start testing it.

And while we're at it, is there any reason for parentscripts to be limited to buttons? I realize it's traditional now , and it would make only a minor difference to extend it, but it makes more sense to me with true inheritance to have fields inherit from fields, etc.

...and on thinking more about this... would that be opening the way for "the effective" whatever to be inherited from parent objects as well? We're getting close to css-like abilities in that case.

I've got a branch but it's probably faster for your to make one yourself. Just define FEATURE_INHERITED_PARENTSCRIPTS at the top of parentscript.h

Yeah, OK, I'll do that... I just hate having duplicate paths to merge if not necessary.