views:

169

answers:

2

I'm using Delphi 2009. Is it possible to write a class helper for a generic class, i.e. for TQueue . The obvious

TQueueHelper <T> = class helper of TQueue <T>
  ...
end;

does not work, nor does

TQueueHelper = class helper of TQueue
  ...
end;
+1  A: 

As near as I can tell, there's no way to put a class helper on a generic class and have it compile. You ought to report that to QC as a bug.

Mason Wheeler
Whoever downvoted this answer: could you please explain why?
Smasher
Yeah, I'd kinda like to know that myself... ;)
Mason Wheeler
It wasn't me, but I imagine it was because if it's by design then it isn't a bug. Just as the class helper implementation was originally "incomplete" in comparison with the Delphi.NET equivalent. Some considered that a bug, but CodeGear's official response was "by design" - the fact that class helpers don't support things they aren't intended to be used for isn't "a bug". Asking for them to do more than they are currently designed for is an *enhancement request*. :)
Deltics
+3  A: 

As documented in the Delphi help, class helpers are not designed for general purpose use and they are incorrectly perceived as having a number of limitations or even bugs as a result.

nevertheless there is a perception - incorrect and dangerous in my view - that these are a legitimate tool in the general purpose "toolkit". I have blogged about why this is wrong and subsequently about how you can go some way to mitigate the dangers by following a socially responsible coding pattern (although even this isn't bullet proof).

You can achieve much the effect of a class helper without any of these bugs or limitations or (most importantly) risks by using a hard cast to a "pseudo" class derived from the class you are trying to extend. i.e instead of:

TFooHelper = class helper for TFoo
  procedure MyHelperMethod;
end;

use

TFooHelper = class(TFoo)
  procedure MyHelperMethod;
end;

Just like with a "formal" helper, you never instantiate this TFooHelper class, you use it solely to mutate the TFoo class, except in this case you have to be explicit. In your code when you need to use some instance of a TFoo using your "helper" methods you then have to hard cast:

   TFooHelper(someFoo).MyHelperMethod;

Downsides:

  1. you have to stick to the same rules that apply to helpers - no member data etc (not really a downside at all, except that the compiler won't "remind you").

  2. you have to explicitly cast to use your helper

  3. If using a helper to expose protected members you have to declare the helper in the same unit that you use it (unless you expose a public method which exposes the required protected members)

Advantages:

  1. Absolutely NO risk that your helper will break if you start using some other code that "helps" the same base class

  2. The explicit typecasting makes it clear in your "consumer" code that you are working with the class in a way that is not directly supported by the class itself, rather than fudging and hiding that fact behind some syntactic sugar.

It's not as "clean" as a class helper, but in this case the "cleaner" approach is actually just sweeping the mess under the rug and if someone disturbs the rug you end up with a bigger mess than you started with.

Deltics
+1 Interesting. Perhaps I was too enthusiastic about them. It seemed very elegant to put your own helper functions into the VCL stuff. The cast makes it less elegant and readable unfortunately.
Smasher
To me "readable" is as much - if not *more* - about being able to clearly see what is going on as it is about reducing the amount of typing. When I see a hard cast being applied using some class "TxxxHelper" then I know that a bit of monkey business is afoot. Monkey business that I absolutely may need to be aware of if not now then in the future when I've perhaps forgotten that "MyMethod" is not part of the class that it appears to be and can't figure out why some other code that tries to use it won't compile (i.e. I don't have the right helper in scope or is being "obscured" by another).
Deltics