Regarding Interfaces

[torrie]

I've been looking at the interfaces in Jade with a view to removing some of the code duplication (effectively the same methods on two or more classes) and wondering if they could be made more flexible. Specifically whether the interfaces could

1. Allow methods on the interface to be mapped to properties on real classes (effectively a Get method)
2. Allow methods to be written on the interface (rather than just mapping to existing methods on real classes)

For example consider a form that is used to record a production run for a bill of materials (e.g. making a bike from it's components.) It's likely that transients are used to store the details of the run prior to the user saving it and that the system would calculate the details of the stock used for the run to display to the user (e.g. 10 bikes would use 10 frames, 20 wheels etc.) A similar piece of code may also exist on the persistent data classes to do the same calculation for a stored run, e.g. what stock was actually used. Similar scenarios may exist for calculating interest on savings or mortgages etc.

I'm wondering if it would be useful to put the calculation method on an interface and then map Get methods on the interface to the underlying data in the persistent and transient structures (obviously the transient and persistent structure would need to be similar.)

An interface used to calculate interest on a mortage may have the following Get methods mapped to the data

• getTerm
• getInterestRate
• getPrinciple

and a calculateInterest method defined on the interface which calls these get methods.

[davidmellow]

Just my two-bobs worth to start a debate (grin)... I can immediately relate to what you're saying as I think that situation of code seeming to belong in an interface arises quite often. It's actually an instance of where multiple inheritance would seem ideal, but across all (?) languages interfaces simply form a contract without themselves implementing any functionality. I've seen quite a bit of argument and explanation of this on the web regarding other languages.

So as far as I can see Jade is fairly well in keeping with C#, VB, I think Java though I don't really use it... interfaces only form a contract without allowing code, and the language also does not allow multiple class inheritance.

One way of skinning the cat that you're describing that I'd probably think about is yes, possibly implement a IProductionRun interface or whatever for your different flavours of similar (transient or otherwise) data, the details of how they expose that data in a consistent manner up to them, then have a singleton transient Calculator (or whatver) class loaded at application level that has a DoProductionRun(IProductionRun) signature, if that makes sense. In other words the consistent data crunching code in that calculator method. Whether that is a good way of doing it depends on your scenario which I can't quite visualise.

In a lot of ways what you're advocating makes logical sense torrie, but it would maybe start breaking the very idea of what an interface is? It's an interesting topic you've raised I think.

[allistar]

Having the ability to add code directly to an interface method would be helpful as it would allow for more reuse of common code and also allow that common code to be put where it belongs - on the interface. For that to work there would have to be limitations in what that interface method could do - e.g. it could only access methods defined on itself and not on other global objects like app etc (as there would be context issues if the interface were to be exported via a package into another schema). Such limiting is already done in Jade in certain places (e.g. when adding condition methods).

So long as these limitations were put in place, I don't see that this would "break" the idea of what an interface is - it would make them more flexible though.

The example of having a Calculator class to provide the implementation of that method would limit the usefulness of interfaces, expecially if that interface is exported via a package to another schema (which is where the power of interfaces becomes apparent).

Slightly off topic, but a much needed enhancement that is available in 6.3.05 is the ability to define cyclic packages imports (so SchemaA imports a package from SchemaB, and SchemaB imports a package from SchemaA). That'll see quite a few cludges in code I have helped develop be removed. Excellent stuff.