Base class for Expression Owners

Coordinator
Aug 17, 2007 at 2:31 AM
Should all expression owners be required to derive from an ExpressionOwner class? Right now, an expression owner can be any object. If I force all expression owners to derive from a specific base class, then I can add fields to the base class for internal use to implement things like dynamic variables.

What are your guys thoughts on this? Is there any reason why doing this would limit usability?

Thanks.
Aug 17, 2007 at 12:38 PM
Maybe you can have both worlds, i think you should keep the full liberty of pass any object and also have some AdvancedExpressionOwner class for more complex things.

Anyway great tool.

Aug 21, 2007 at 2:51 AM
I agree with efrreyra.

The option to have any object own the expression is great, but it would be really nice to implement advanced functionality by creating a specialized owner. Since the owner may already be a business object that derives from something, a base class may not work. You could, however, create an interface ("IOwnExpressionsAndImSmartAboutIt") that advanced owners could implement.

Better yet, create a bunch of interfaces that each support sets of functionality.

"IOwnExpressionsAndCanLookupVariables"
"ICanEmitMyOwnIL"
"IPreparseExpressions"
etc.

Advanced owners can implement one of more of these. Obviously, the names will have changed to protect the innocent :)
Coordinator
Aug 21, 2007 at 2:41 PM
Yeah, it looks like allowing the owner to be any object is the way to go. Like you said, I can always define interfaces to allow the owner to have special functionality. Also, allowing the owner to be any object also lets you access non-public members of .NET types without the reflection performance hit.
Sep 3, 2007 at 2:55 PM
Edited Sep 3, 2007 at 2:55 PM
Being able to submit just an arbitrary object is very convenient, so I definitely am happy with that. However, if you want to get more fancy, I'd suggest attributes rather than interfaces:

public class MyOwnerClass
{
//decorating fields makes it easy for flee to determine variables, and also
//provides means to submit further meta information
[SomeFleeAttribute(SomeProperty = true)]
private int x;
}

Cheers,
Philipp
Coordinator
Sep 3, 2007 at 7:18 PM
I think in the end, I'll wind up using both. For example: with the calc engine, I have to use an interface since I need the owner to implement a property to allow me to store the calcEngine instance and then retrieve it during evaluation.