Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

lachoy (1663)

lachoy
  chris.winters@gmail.com
http://www.cwinters.com/

I am actually Chris Winters; I am actually living in Pittsburgh, Pennsylvania, USA; I am actually married and have three cats. (Guess what one of them is named?) I am the "OpenInteract" guy, which could be good or bad.

Journal of lachoy (1663)

Wednesday March 20, 2002
12:24 PM

The point of that last one...

[ #3673 ]

(I had to scoot out the door to catch my bus before I could finish that last entry.)

Still thinking out loud here...

Currently we generate about 500+ classes and interfaces, and 600+ deployment descriptors. The amount of generated information is only going to go up as we add more functionality to the system.

The tricky part is how to integrate the generated code and the custom code, particularly in a staticly-typed language like Java. This issue will only get worse as we add more classes and relationships. It's possible to just have custom functionality in a separate file that gets pulled in when the class gets generated, and the user doesn't know the difference. But that's difficult to test and for non-trivial methods, difficult to write.

I feel obliged to mention here that, of course, little of this would be a problem in Perl. But when you're working in a language you need to think in its idioms and patterns.

If I wanted to I could just have all relationship methods return a Object, but then you have to do a cast every time you call something. I consider excessive casts to be one of those "code smells" the XP folks talk about -- it's fine for the Collections API (Lists, Iterators, Maps, etc.) because that's one of the trade-offs (at least until generics/templates come), but not for classes you create unless you have a darned good reason.

In addition to this, I'd like to enable clients to have a simple, unified interface to all functionality a "business object" supports, and enable this interface to support both generated and non-generated code. (Without the code generation wrinkly, this is generically known as a "Business Delegate" in the relevant pattern literature.) Again, with multiple inheritance this wouldn't be an issue: just have the delegate inherit from as many custom and generated classes as necessary.

So instead we need a pseudo-proxy interface, where the delegate gets a request and hands it off to the right place for processing. Not too difficult, except I'm still bitten by the typed return values -- even though it's acting as a proxy the delegate still needs to know the return values of various methods, even if they're generated.

And all the time I'm thinking 'simplify, simplify'... More later, when things are working.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I feel obliged to mention here that, of course, little of this would be a problem in Perl. But when you're working in a language you need to think in its idioms and patterns.

    Mark-Jason Dominus once said something quite true, to the effect that patterns (in the Design Patterns sense, maybe not the sense you mean) are just programs that the programmer has to run in his head, because the language is too stupid to do it for him.