discussions - Interfaces

[Tyler Wright]

Fair warning: I may be commenting on-list a lot today.

In reviewing possible implementations and our current code base I'd like to propose a change for simplicities sake. The current process for building a Behavior is to identify it's primary state properties (such as 'selected'), create interfaces for these properties (such as ISelectable), and have the Component implement these same interfaces. The Behavior's 'target' is typed as Object, so other properties have to be created for each Interface to gain any benefit from this method. And there is no method currently to validate whether a Component is compatible, no actual list of Interfaces to validate against. And then there's the extra file-size and clutter by adding so many of these 'property interfaces' to consider.

I propose we avoid these almost-arbitrary Interfaces and set up a simpler method, such as:

1) each Behavior implements a metadata-based hard contract with the Component, tagging the properties that are required to be represented by the Component. This would be familiar to the soft contract the Behavior has for the Skin, except that the Behavior throws an error if the contract isn't fulfilled.

2) as we discussed briefly at MAX, Behaviors implement their own data and are completely self-contained. Property implementation on the Component is then optional while a light databinding can connect it with the Behavior where properties do coincide.

I am begining some light implementation of a few known Behaviors in the manner of the self-contained data. This will be easier to build up, test, focus on Behavior functionality, and easy to refactor once we decide a final path.

Tyler

[Ben Stucki]

Hey Tyler,

I'm finishing up some work on the basic Behavior metadata, so hopefully we're not duplicating effort. I think if you want to create a new base class to test out the approach you described below, perhaps we can compare them both in use for a while. Like I mentioned at MAX, I like the idea of having behaviors implement the interfaces they expect on the component in theory (it should make the workflow feel more like real mixins), but I'm worried about the overhead and under-the-hood complexity. In the original model any extra cost is at the time of assigning the behavior. In this one there could be extra cost on every property change. Like I said, nothing to kill it strait off. We might just need to try both for a while. Along those lines, are you up for creating a BehaviorMixin base class or something along those lines to let these live side by side for a bit?

- Ben

[Tyler Wright]

hey Ben!

As for the work I'm doing now I've created a branch where I'm building up individual behavior implementations, adding as little to the base framework as possible. In fact I've dumbed down the branch framework to make things as simple as possible. This way we can focus on designing an overall architecture where behaviors are intelligently constructed for reuse between components. I'll be hardcoding behavior references into corresponding components during this process rather than a composition model, as I anticipate any coupling mechanism we go with now will likely change anyway. We can try a few methods and measure the costs of each.

The work you're doing now is important and I'll keep the behavior R&D branch separate. I'd like to see where you're at and contribute to the main branch of development independently. Just let me know when you commit!

Tyler