FEATURE_INHERITED_PARENTSCRIPTS

[monte]

sure, it was the general idea not the syntax I was discussing. From memory [myClass isTypeOfClass:@"className"] is objective C...

I'm not convinced on the reverse domain thing either but clearly someone at RunRev likes them and we do need something for namespace issues. I'm not fussed on the prefix thing either even though I obviously use it heavily. What I'm proposing could use any name I think so it could be:

if control X is a "DataGrid" then

Note I put it in quotes because that could be the trigger for the engine to look for a behavior as opposed to a control type... would also be much easier to handle names with whitespace etc. To get the above to work the datagrid behavior button would need to be renamed "DataGrid"...

It would be nice if a behavior could be used as a proper control type though like in your syntax and in:

set the dgText of DataGrid 1 to theText

I imagine this being quite a bit harder to implement though...

[mwieder]

I hesitate to even think about starting on namespaces because I know runrevmark has put a lot of thought into this, so I think we'll have to let him take the lead on that.

The problem of needing quotes around "DataGrid" is somewhat troubling, but I understand the reasoning.

I think ideally I'd like behavior objects to be promoted to first-class objects. Then you could say

Code: Select all

if control x is a button
if control x is a DataGrid
if control x is a newfangledContraption

where the quotes would be confusing - you're not referring to a name exactly, it's not a string literal, it's an object type. So it's one more special-case usage of double-quotes that doesn't fit into the existing rules of where they're necessary unless you really wrap your head around why. And that's a level of whyness that I think users (especially new users) shouldn't have to deal with.

[off the top of my head without looking at the code] I'm sure somewhere in the engine code is an enum list of object types, and it should be possible to dynamically extend that list using the short name of a behavior object.

[monte]

That's where I was going at the end there. There is a chunk_type enum that has all the objects and a heap of other stuff in it: Chunks, containers and ordinals (and dest for Go command).

Possibly add CT_CUSTOM_CONTROL or something which might tell the engine how to search for the control or test a control if it is one...

[mwieder]

I haven't found that enum yet, but in searching for it I came up with this gem

Code: Select all

	struct chunk_t
	{
		chunk_t *previous;
		void *frontier;
		uint4 remaining;
	};

Don't you just love coming across uncommented stuff like this? I may start a separate branch just for comments.

[monte]

parsedef.h is where the enums are defined. lextable.cpp is where those enums are given syntax.

Agh... the comments/docs a major effort. I'm still trying to work out how to add a command... wanted to add:

resolve behaviors of <stack>

This was to be a present for Richard But I think the engine is confused by the of syntax and thinks I'm trying to implement a property... Not sure but whatever I try seems to fail so I gave up for now.

[mwieder]

parsedef.h is where the enums are defined.

Ah. OK - I was looking for "chunk_type" and it's actually "Chunk_term".

[LCMark]

Okay - let me try and cover all the salient points in the discussion so far...

I really couldn't tell you why this code has languished there for so long... I think it was born of an afternoon of frustration with something else, so I distracted myself by implementing it but it never subsequently scheduled for finishing off in a release (I suspect the push to mobile got in the way at some point).

In terms of the state of the code, I do think it is pretty much complete - the only aspect that I think is missing is the ability to get a reference to the current behavior script's object (at the moment you can do 'the behavior of me' since only single level behaviors work). At the time this irked me (I couldn't think of a simple keyword or some such to use), however I don't think this would get used much in practice and so probably isn't worth worrying too much about.

In regards to the other aspects of oop-ness, then it is important to remember that behaviors were never really about general oop - they were about code-sharing (mix-in inheritence I think would be the technical term) so I'd be wary about trying to force their usefulness beyond that. Apart from anything else, their completely dynamic nature is at odds to wanting any sort of 'custom syntax' (which has to be static for a variety of reasons). ( I should point out that the whole refactor / open language thing is the initial stages to tackle some elements that are referenced here but that is perhaps a discussion for another day ).

Of course what adding an inheritence chain like this does do is allow behaviors to share a common set of scripted handlers that could make them more 'traditional' oop-like. So you could have a base 'object' behavior script that defines base-level properties and such that all script's using objects sharing this base script can rely upon - this would be a good place for a (scripted) 'kind' property or some such.

In terms of being able to easily determine what behaviors an object implements then perhaps something like

Code: Select all

tObject behaves like "datagrid"

This could perhaps search the names of the objects in the behavior chain, returning true if it finds one. A simple action like this (of course) leaves any naming issues completely up to protocol and script-level (i.e. out of the engine, which is perhaps the best place for now).

Going back to the quick reference as to why behaviors can only be scripts of buttons... Being used as a behavior has absolutely nothing to do with the control type the script is set on and nor should it - it is just the script that is important (behaviors are just about script). Ideally, at the time, we would have added a script object (which would have been the right thing for backScripts and frontScripts too) but there were issues with doing that (although, it is something we should probably revisit when we sort out the file-format once and for all). So, to reiterate, I've not yet seen a single (good?) reason why you need to reference more than buttons for behaviors given their current functionality, thus I don't see the need to change the current behavior [ I think if we had had a 'script' object at the start for them, I don't think anyone would ever have questioned the fact you needed to use them for behaviors rather than a control - indeed having to reference a control of any type introduces a sort of confusion into the mix, since it might lead you to believe, wrongly, that the control which has the behavior script set on it has something to do with the action of the behavior, which it doesn't. ]

Finally, food for thought, there is a orthogonal addition to behaviors to be considered... Being able to set multiple behaviors on a single object - this would be a simple analog of multiple (mix-in) inheritence. However, this might be something to discuss on a separate thread...

P.S. I'm more than happy to enable FEATURE_INHERITED_PARENTSCRIPTS for the next non-maintenance version unless that wasn't implicitly clear from the above ramblings

[monte]

I'm more than happy to enable FEATURE_INHERITED_PARENTSCRIPTS for the next non-maintenance version unless that wasn't implicitly clear from the above ramblings

Lots to respond to but it's 11PM here and time for bed... this made my day though

[LCMark]

By the way, by us enabling this, it means the custom getProp / setProp changes will need more work

[mwieder]

I've not yet seen a single (good?) reason why you need to reference more than buttons for behaviors

The lack of orthogonality bothers me on a cognitive level, but it's nothing I can't live with for a while longer.

A simple action like this (of course) leaves any naming issues completely up to protocol and script-level

Yes, and I think that's the way it should be, pitfalls and all. If I create a linked-list object and then inherit from that I'd no doubt refer to it as a LinkedList, so I could check "if control xyzzy is a "LinkedList" then... but I think it's equally valid to name it "ListOfObjects" or "Zoo" or whatever. And then it's up to the developer to maintain internal consistency.

[monte]

By the way, by us enabling this, it means the custom getProp / setProp changes will need more work

OK, perhaps you could take a look at my implementation on GitHub and make some notes where it would need to change when you get a second. You may have intended me to implement it a bit differently because I realise now that the Properties in MCHandler really isn't being used... neither was the old boolean I don't think...

Of course what adding an inheritence chain like this does do is allow behaviors to share a common set of scripted handlers that could make them more 'traditional' oop-like. So you could have a base 'object' behavior script that defines base-level properties and such that all script's using objects sharing this base script can rely upon - this would be a good place for a (scripted) 'kind' property or some such.

Right... that's exactly what I want. For instance, at the moment I have a boilerplate template for my custom controls but with this change I can move most of that to a grandparent behavior.

Code: Select all

tObject behaves like "datagrid"

This could perhaps search the names of the objects in the behavior chain, returning true if it finds one. A simple action like this (of course) leaves any naming issues completely up to protocol and script-level (i.e. out of the engine, which is perhaps the best place for now).

I like it...

Finally, food for thought, there is a orthogonal addition to behaviors to be considered... Being able to set multiple behaviors on a single object - this would be a simple analog of multiple (mix-in) inheritence. However, this might be something to discuss on a separate thread...

I'm definitely interested in that. Right now the only way to implement something like that is with a wrapper group with it's own behavior.

[mwieder]

Being able to set multiple behaviors on a single object

If we're talking about multiple behaviors at the same level, rather than inheriting sequentially, then I'm vehemently against it. My experience has been that multiple inheritance has caused nothing but problems in object modeling that then have to be corrected later on in the ALM. It tends to encourage weird message paths that veer around the normal object inheritance and cause spaghetti patches when doing app maintenance down the road.

...of course, if we're talking about something else, just ignore the above rant.

[monte]

I think it is what we are talking about but I also think it depends on how it's implemented as to whether it will cause issues. If it were a case of the behaviors having the same script scope for variables and handlers then euck... messy. But if it's an ordered list of behaviours then it's just another way to add to the inheritance path and saves having to have wrapper groups etc. It will mean we can provide custom controls that a user can add their own behaviors to easily.

[LCMark]

@mwieder : I do share your concerns with multiple inheritance, but only in languages which don't implement it well. It can be a powerful tool if used correctly and in a language that provides the means to specify it properly (e.g. Eiffel, not C++).

However, if you view behaviors as 'mix-ins' and don't try to be clever then it could be quite useful for applying distinct behaviors to a single object. Anyway, there's more to think about there, I only suggested it since it was something I thought about when we first introduced them... Indeed, I think I even made sure the file-format could take a list of behaviors on an object from memory, just in case we implemented it at some point in the future.

[mwieder]

However, if you view behaviors as 'mix-ins' and don't try to be clever then it could be quite useful for applying distinct behaviors to a single object.

That, of course, is the lure of multiple inheritance. I have no experience with Eiffel, so I'll just take your word that there is precedence for well-designed behavior. I do like ruby's approach to mix-ins, so if we could have something like that I think it would mitigate most of the problem areas.