I've created an example of an OO pattern in Construct, I came up with that I think maybe useful in organizing event code. I've attached a simple example of this pattern to this post. In this example project I have a simple object hierarchy that looks like this (using pseudo code):
class Ship: abstract
method: DisplayName
class LandedShip: extends Ship
overrides method: DisplayName
class FlyingShip: extends Ship
overrides method: DisplayName
class DeadShip: extends FlyingShip
overrides method: DisplayName
You can call the invoke the action DisplayName function on any picked Ship object and have the correct overridden implementation of DisplayName invoked (see the Layout 1 event sheet for an example).
Ideally if something like this is considered useful we shouldn't have to build it up manually as this pattern is labor intensive, but at least it works.
If an "O is in family X" condition where added to Construct it would make this pattern easier to implement and a little cleaner. Plus such a condition would be useful in other circumstances.
It would also be nice to be able to be able to use Python expression to invoke these functions and pass along the picked objects so that the same pattern could be used in both cases without modifications. Perhaps something like "Function.MyFunction(param1, param2, PickedObjects)" where PickedObjects is not the name of the PickedObjects but a token to let the FunctionObject know that we want to pass the current set of picked objects to MyFunction. The syntax doesn't matter much it could also be something like "Function.Delegate(MyFunction, Param1, Param2)." The picked objects are similar to the object "this" or "self" pointer in this pattern so it would be nice not to have to pass them along as explicit parameters.
What I think I would like to see is some sort of prototype inheritance in Construct that would make this pattern obsolete. I think prototype based inheritance instead of traditional class based inheritance could be a good fit for Construct. I think it could be added to the current ACE programming model in a very natural way extending what is already in place and keeping the simplicity and ease of use.
I don't have the time right now to elaborate to much, but what I think might work is the following:
Every object in Construct has a prototype property this property points to the object that is this object's prototype. New objects start with the prototype object "Object" which is a the root level of all object hierarchies. You can also can also select an object copy it and then select "Paste as Prototype" to create a new object that uses the copied object as its prototype. The prototype property establishes a live link between the new object and its prototype object instance. Unlike a cloned object this new object will inherit the value of any property changed in its prototype object unless that property has been set to a value in the object.
You would also be able to add methods to an object. These methods would work like today's functions but would be associated with an object instead of an event sheet. You could use an event sheet user interface to modify them . Since these methods are additional properties of an object they would follow the same prototype behavior that I described for regular properties. So any new methods added to a prototype object would automatically be seen by any objects that derive from it. And any object that derives from a prototype object is able to override the implementation of a method property and the new overridden implementation is then used for the object.
Everything else in the programming model would stay the same and this would be backwards compatible.
I'll try and clarify things later, if there is any interest in this. If you want to learn more about prototype based inheritance (aka class-less inheritance) do a search on Google for prototype inheritance and JavaScript (JavaScript is the most well known language that uses this approach).
Please let me know what you think. I debated whether I should wait until I had more time to fully document this and think about it, but I decided it was better to share it first before I wasted any more time on it.
Snoop