{"id":273,"date":"2008-08-30T13:33:24","date_gmt":"2008-08-30T01:33:24","guid":{"rendered":"https:\/\/www.deltics.co.nz\/blog\/?p=273"},"modified":"2008-08-31T09:37:56","modified_gmt":"2008-08-30T21:37:56","slug":"class-helpers-on-trial","status":"publish","type":"post","link":"https:\/\/www.deltics.co.nz\/blog\/posts\/273\/","title":{"rendered":"Class Helpers On Trial"},"content":{"rendered":"[Estimated Reading Time: <\/span> 5<\/span> minutes]<\/span><\/span>

Class helpers (introduced in Delphi 2007<\/span> 2006<\/span> 2005 – thanks to Chris and Bruce for the corrections) seem to be cropping up more and more frequently in suggested work-arounds or implementation approaches.\u00a0 I find this worrying given that this language feature has always come with the admonition from CodeGear that it isn’t advisable to use it!<\/p>\n

So why do people seem so keen on using them, and why shouldn’t they?<\/p>\n

<\/p>\n

Class helpers are to be considered “bad” when used in an application because they were never designed for general purpose use. As I understand it, they were devised to workaround a problem (or problems<\/em>) in the VCL that existed for the language (or more accurately, the VCL) implementors, not those who implement code that merely uses<\/span> the VCL.<\/p>\n

The biggest problem with class helpers, from the point of view of using them in your own applications, is the fact that only one<\/strong><\/em> class helper for a given class may be referenced at any time.<\/p>\n

That is, if you have two helpers for a class nominally reachable in your code (e.g. in two separate units both of which are in your uses list), only one of them will actually be “seen” by the compiler. You won’t get any warnings or even hints about any other helpers that exist or may be hidden.<\/p>\n

So you can be happily coding away with your lovingly crafted helper, and then you add some other unit to your uses list that unbeknownst to you contains another helper for the same class and suddenly your code simply stops compiling.<\/p>\n

Since helpers are used – as designed – within the VCL, adding your own helpers for VCL classes is likely to lead to this problem if you also write code that (perhaps unknown to you) relies on the VCL helpers for those classes.<\/p>\n

A Sticky Situation<\/h3>\n

You may be able to fudge your way out of this predicament by fiddling with the order of your units in the uses list (once you’ve figured out what’s going on, which is likely to come after perhaps your 2nd or 3rd restart of the IDE and an experimental reboot or two before you accept that it isn’t just the compiler having “a moment”).<\/p>\n

If you can’t fix it with the uses list – if more than 2 helpers are involved – you might perhaps succeed in moving one or other helper up or down the ancestry of the helped class, assuming you are in control of the source for that helper and hoping that that does not in turn create a conflict with some other<\/span> helper out there, perhaps in some other area of your code.<\/p>\n

But if you can’t wriggle your way out of the situation then you are well and truly stuck, because you can’t even use qualification to forcibly reference the “hidden” helper.<\/p>\n

  TMyHelper(obj).MyMethod;<\/pre>\n
Won’t compile if TMyHelper<\/strong> is “hidden” by some other helper for the class of obj<\/strong> involved. In fact, this code won’t compile anyway because TMyHelper<\/strong> does not exist as a “proper” type, so you can’t even use this style to aid clarity if you wish (i.e. to make it clear that your code is reliant on a helper).<\/p>\n
But Without Class Helpers, What Can We Do?<\/h3>\n
Fortunately there is an alternative, which is not only immune from all these problems but is also in my opinion actually more flexible\/powerful (not least because it works in any Delphi version).<\/p>\n
That is, to use explicit helper-style<\/em> pseudo sub-classes, the “old fashioned” way, where you adhere to the rules for helpers (only accessing public methods, not adding instance data etc etc) but use explicit hard-casting to “add” your methods to an instance.<\/p>\n
  TMyHelper = class(TForm)\r\n    procedure MyMethod;\r\n  end;\r\n\r\n  TMyHelper(form).MyMethod;<\/pre>\n
This is “better” to my mind because:<\/p>\n
a) it is explicit. No magic. No wondering where these undocumented methods came from (for the uninitiated, unaware of the existence of your “helper” class in some obscure unit somewhere).<\/p>\n
b) it is unbreakable. As long as you stick to the rules for implementing the helper itself, nobody else’s helper can “hide” yours or interfere with how it works.<\/p>\n
c) it is more powerful and more flexible – the “helper” subclass is able to access protected<\/em> as well as public<\/em> members.<\/p>\n
There are three downsides – two of which are arguably in fact a further benefit, in some situations at least.<\/p>\n
1) it is necessary to explicitly type-cast in order to invoke your helper functionality.<\/p>\n
2) the compiler will not prevent you from violating some<\/em> of the rules of class helping (not overriding inherited methods).\u00a0 It still isn’t possible to access private members, for example.<\/p>\n
3) protected members are made visible in “consumer” code.<\/p>\n
It is the first and last of these that I could be considered further benefits<\/span>.<\/p>\n
In the case of the first, it is made clear that an instance is being treated as something that, strictly speaking, it isn’t.\u00a0 To my mind the real basis for this complaint is that it involves a little more typing than using a formal helper.<\/p>\n
In the case of the third, gaining access to protected members is quite often the very reason that such a class might have been used in the first place, since some aspects of frameworks – particularly in the case of the VCL – keep some members protected that would most usefully be made public.<\/p>\n
For example, TControl<\/strong> introduces the Color<\/strong> property but only as a protected member, so if you have only a TControl<\/strong> reference to some control whose Color<\/strong> you wish to change (or inspect) you need some way to bring that protected member into visibility.  You could have a complicated type checking and type casting sequence (hoping you catch all the relevant sub-classes), or you could use a “helper”:<\/p>\n
  if ctrl is TEdit then\r\n    TEdit(ctrl).Color := aColor\r\n  else if ctrl is TListbox then\r\n    TListbox(ctrl).Color := aColor\r\n  else....<\/pre>\n
versus:<\/p>\n
  TControlHelper = class(TControl);\r\n\r\n  TControlHelper(ctrl).Color := aColor;<\/pre>\n
Note that this is not even possible with a “proper” class helper, so if you are using a “proper” class helper you will still need this “dirty” alternative to solve this particular problem.<\/p>\n
Why not simply consistently use one approach that meets all needs?<\/p>\n
But It’s Not Type Safe!  TWorld.IsEnding!<\/h3>\n
Type safety is a potential concern of course, with the risk that you may cast to a helper class inappropriate to the object being cast, but this is not a problem unique to class helpers and you can easily code safely with this technique if you prefer:<\/p>\n
  TControlHelper(obj as TControl).Color := aColor;<\/pre>\n
Personally I feel the slight risk (which it is in my power to mitigate and avoid) is worth the comfort of knowing that some-one else’s helper (or perhaps even an ill considered additional helper of my own) is not one day going to break my code.<\/p>\n
So Why Bother WIth Class Helpers At All?<\/h3>\n
Good question.   It is rather curious that the VCL problem was not solved using this alternate approach, for example.  Why spend time implementing a seemingly flawed language feature to solve an problem that can be easily solved some other way?<\/p>\n
I suspect that class helpers might be earmarked for future things… they bear an uncanny resemblance to extension methods in C#, for example, which are key to the syntactic candy floss and lexical gymnastics required to deliver LINQ.<\/p>\n
But until their purpose is fully realised, I personally think it wise to take heed of CodeGear’s advice and steer well clear.<\/p>\n","protected":false},"excerpt":{"rendered":"
[Estimated Reading Time: <\/span>  5<\/span> minutes]<\/span><\/span>Class helpers (introduced in Delphi 2007 2006 2005 – thanks to Chris and Bruce for the corrections) seem to be cropping up more and more frequently in suggested work-arounds or implementation approaches.\u00a0 I find this worrying given that this language feature has always come with the admonition from CodeGear that it isn’t advisable to use […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[4],"tags":[52,292,53],"class_list":["post-273","post","type-post","status-publish","format-standard","hentry","category-delphi","tag-class-helpers","tag-delphi","tag-techniques"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p1TKYv-4p","jetpack_sharing_enabled":true,"jetpack-related-posts":[],"_links":{"self":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/273","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/comments?post=273"}],"version-history":[{"count":8,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/273\/revisions"}],"predecessor-version":[{"id":279,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/273\/revisions\/279"}],"wp:attachment":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/media?parent=273"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/categories?post=273"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/tags?post=273"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}