{"id":244,"date":"2008-08-25T22:32:53","date_gmt":"2008-08-25T10:32:53","guid":{"rendered":"https:\/\/www.deltics.co.nz\/blog\/?p=244"},"modified":"2008-08-25T22:51:19","modified_gmt":"2008-08-25T10:51:19","slug":"generic-methods-and-type-inference","status":"publish","type":"post","link":"https:\/\/www.deltics.co.nz\/blog\/posts\/244\/","title":{"rendered":"Generic Methods and Type Inferencing"},"content":{"rendered":"[Estimated Reading Time: <\/span> 7<\/span> minutes]<\/span><\/span>

In the new Delphi forums<\/a> recently, Barry Kelly <\/a>responded to a question about lambda expression syntax in Tibur\u00f3n with this observation:<\/p>\n

This syntax needs type inference. Our compiler was not originally written to support type inference, but work to support type inference is<\/a> orthogonal to supporting anonymous methods. …\u00a0 you’ll need to provide the full declaration type, for now.<\/a><\/p>\n

In other words – as I understand it – Tibur\u00f3n\/Delphi 2009 will not (initially at least) support type inferencing.\u00a0 To my mind this dramatically reduces the attractiveness of Generic Methods.<\/p>\n

<\/p>\n

What Is Type Inferencing?<\/h3>\n

As the term suggests, (in this context at least) it is the ability of the compiler to infer the type of some symbol (variable or parameter etc) from the context or code around it.<\/p>\n

In C# for example, it means that variables can be declared:<\/p>\n

  var a = 10;<\/pre>\n
The compiler will infer from this that the type of variable a<\/strong> is int<\/strong> (you knew that, right?) without this having to be explicitly declared.<\/p>\n
Pop Quiz:<\/strong> What do we think would\/should the type of a<\/strong> be if Delphi were to support this?<\/p>\n
Hint: What type would a<\/strong> be if it were a constant?<\/em><\/p>\n
In general I find this to have dubious value, what, for example, can you deduce about the correct usage of a<\/strong> from this:<\/p>\n
  var a = someRef.DisplayValue;<\/pre>\n
To know the type of a<\/strong> you know need to know the type of someRef<\/strong> in order to in turn know the return type of DisplayValue<\/strong>.\u00a0 If browsing a project with all references intact and Code Insight<\/em>, or equivalent, to deliver this information to you, then all good.\u00a0 But if not, you are going to have a sticky time of it, and either way you still have to trust that the person that wrote the code – which perhaps wasn’t you – also knew those things and didn’t make their own inferencing error.<\/p>\n
But what does type inferencing have to do with Generic Methods?<\/p>\n
To understand that let’s look at why Generic Methods even come into it.<\/p>\n
It all started this evening when I found myself needing to add another overload to my set of Exchange()<\/strong> methods, two of which I show here to give you the idea:<\/p>\n
  procedure Exchange(var A, B: Integer); overload;\r\n  procedure Exchange(var A, B: TObject); overload;<\/pre>\n
(The Exchange<\/strong> procedure exchanges the values of the two passed parameters)<\/em><\/p>\n
My problem was that because the parameters to these procedures are, by necessity, var<\/strong> parameters, the compiler enforces strict type checking, so the second of the above declarations cannot be used with variables of a TObject<\/strong> derived<\/em> type, but only variables explicitly and specifically of TObject<\/strong> type itself:<\/p>\n
  var\r\n    obj1, obj2: TObject;\r\n    form1, form2: TForm;\r\n  begin\r\n    :\r\n    Exchange(obj1, obj2); \/\/ OK - references will be exchanged\r\n    Exchange(form1, form2); \/\/ ERROR: No compatible overload\r\n  end;<\/pre>\n
The second call to Exchange()<\/strong> will not compile because the TForm<\/strong> type parameters are not compatible (from the compiler’s perspective) with the TObject<\/strong> overloaded version of the routine.\u00a0 I have to add another overload with explicitly TForm<\/strong> type parameters.<\/p>\n
Not for the first time recently I found myself thinking “If only I had Delphi 2009 – Generic Methods would make this so much easier!”.\u00a0 Then I remembered reading Barry Kelly’s note about lack of type inferencing in Delphi 2009, and an alarm bell started ringing.<\/p>\n
The Generic Solution<\/h3>\n
A generic implementation of an Exchange()<\/strong> procedure should be simple enough, and would go a little something like this:<\/p>\n
  procedure Exchange<T>(var A, B: T);\r\n  var\r\n    i: T;\r\n  begin\r\n    i := A;\r\n    A := B;\r\n    B := i;\r\n  end;<\/pre>\n
Which is nice and neat and cuts down on all those overloads.  Unfortunately however, using<\/span> this procedure is actually now more cumbersome, not less:<\/p>\n
  var\r\n    obj1, obj2: TObject;\r\n    form1, form2: TForm;\r\n  begin\r\n    :\r\n    Exchange<TObject>(obj1, obj2);\r\n    Exchange<TForm>(form1, form2);\r\n  end;<\/pre>\n
Ouch.<\/p>\n
Frankly for the time it takes to create a new overload of a trivial routine like this, I would rather take those few seconds and reap the rewards later since – in common with most such routines – the code for the procedure will be written only once but code to call it will be written many, many times.<\/p>\n
Voices Off:<\/em> “But lots of overloads will pollute your namespace!”<\/p>\n
You know what?  That bothers me a lot less than creating unnecessary work for myself.  I’m not the sort of developer that is unable to produce a line of code without invoking Code Completion<\/em>.  I may be unusual in this day and age, but I still write<\/span> code faster than I can pick it from drop-down lists.<\/p>\n
And this in Win32 Delphi at least is surely the biggest impact?\u00a0 As far as the code goes,\u00a0 any unused overloads will be pruned out by the linker.\u00a0 In .NET – aiui – a cluttered namespace becomes a public nuisance, so the imperatives are somewhat different perhaps.<\/p>\n
How Would Type Inferencing Help?<\/h3>\n
Well, assuming that any future Delphi type inferencing system could determine the appropriate type from the parameters (as it can in C#) then we could invoke our generic Exchange<T>()<\/strong> method by simply writing:<\/p>\n
  var\r\n    obj1, obj2: TObject;\r\n    form1, form2: TForm;\r\n  begin\r\n    :\r\n   \u00a0Exchange(obj1, obj2);\r\n    Exchange(form1, form2);\r\n  end;<\/pre>\n
i.e. just as we can do with overloads.<\/p>\n
But until this is possible at this stage I was feeling that I would continue with overloads until – at least – type inferencing were available.\u00a0 They are just as type-safe and ironically produce “consumer” code that should be entirely compatible with a future generic methods implementation that is<\/em> bolstered by type inferencing.<\/p>\n
Using generic methods without<\/span> type inferencing (in these sorts of cases at least) will simply create unnecessarily verbose and cumbersome “consumer” code.<\/p>\n
But not being one to give in, I considered some alternative approaches.<\/p>\n
A Truly generic Approach?<\/h3>\n
Alternatively, Delphi already provides a means to implement a truly generic (lower case “g’) Exchange()<\/strong> method – untyped parameters:<\/p>\n
  procedure Exchange(var A, B);\r\n  var\r\n    i: ?\r\n  begin\r\n    i := A;\r\n    A := B;\r\n    B := i;\r\n  end;<\/pre>\n
You will immediately notice of course that this implementation is neither valid nor complete.  The type of i<\/strong> (for “intermediate”, if you were wondering) is not known and indeed not knowable.\u00a0 And furthermore, the compiler simply won’t accept that A := B<\/strong> assignment  since it doesn’t know the types of A<\/strong> and B<\/strong> it cannot know what instructions are needed.\u00a0 For the same reason, the XOR trick<\/a> won’t work either.\u00a0 Those untyped parameters seem to have lead us to a dead end.<\/p>\n
Not quite.\u00a0 (If you are squeamish and\/or don’t like smelly code you might want to avert your gaze about now, or at least pinch your nose):<\/p>\n
  procedure Exchange(var A, B);\r\n  var\r\n    aa: Integer absolute A;\r\n    bb: Integer absolute B;\r\n    i: Integer;\r\n  begin\r\n    i  := aa;\r\n    aa := bb;\r\n    bb := i;\r\n  end;<\/pre>\n
The absolute<\/strong> keyword is not something to be used lightly – it tells the compiler that the variables aa<\/strong> and bb<\/strong> exist at the same location as the parameters A<\/strong> and B<\/strong> – in this case the compiler even takes care of the fact that the parameters are passed by reference.<\/p>\n
Since the variables are typed and the parameters are untyped, how can this be safe?<\/p>\n
Well, frankly it isn’t.<\/p>\n
In practice if the type of A<\/strong> and B<\/strong> is not the same size as an Integer<\/strong> (32-bits) then things are not going to go at all according to plan.<\/p>\n
Equally of course though, if you only ever call this implementation routine with 32-bit sized parameters (which includes strings, object references etc) there won’t be a problem.\u00a0 “IF”.<\/p>\n
I should point out at this stage that I explored this approach as a curiosity.\u00a0 I am certainly NOT recommending it!\u00a0 For one thing it is not “truly generic” at all – it only appears to be but in fact has fairly strict conditions for correct use, and does not benefit from any assistance from the compiler to ensure that you do in fact use it correctly!<\/p>\n
But we have one more trick up our sleeve – there is (at least) one more way to skin this particular cat that is safer than an untyped parameter approach and only a little more cumbersome to use than a non-type-inferenced Generic approach.<\/p>\n
X-Rated Code – Being Explicit<\/h3>\n
A var<\/strong> parameter is syntactic sugar for passing by referencing and allowing modification of the de-referenced value.\u00a0 We can of course achieve the same thing by taking care of the de-referencing aspects ourselves and explicitly passing references to values, rather than the values themselves:<\/p>\n
  type\r\n    PObject = ^TObject;\r\n\r\n   :\r\n\r\n  procedure Exchange(const A, B: PObject);\r\n  var\r\n    i: TObject\r\n  begin\r\n    i  := A^;\r\n    A^ := B^;\r\n    B^ := i;\r\n  end;<\/pre>\n
And to call this:<\/p>\n
  var\r\n    obj1, obj2: TObject;\r\n    form1, form2: TForm;\r\n  begin\r\n    :\r\n   \u00a0Exchange(@obj1, @obj2);\r\n    Exchange(@form1, @form2);\r\n  end;<\/pre>\n
All of which sits happily alongside any other overloaded versions of Exchange()<\/strong>, but which unfortunately requires consumer code that will not be compatible with a future Generic Method implementation of the routine.<\/p>\n
BUT, even this won’t work if we are compiling with Typed @ Operator<\/strong> option enabled.<\/p>\n
So I’m left a little stumped.<\/p>\n
There are many ways to go about this.\u00a0 If it weren’t for the fact that Generic Methods are nearly upon us I would favour the explicit de-referencing approach.\u00a0 But the desire to create code today that will be compatible with impending new language features is quite compelling.\u00a0 Then again, until we also get type inferencing, a Generic Methods based approach isn’t going to be compatible with anything<\/span> we can write today anyway.<\/p>\n
Despite myself, the untyped parameter approach could yet prove too tempting to resist (particularly if I find myself needing yet another class-specific version of Exchange()<\/strong>) since all the types that I’ve ever found myself wanting to Exchange()<\/strong> meet the 32-bit criteria.<\/p>\n
It really hinges on when we might see type inferencing in a Delphi compiler.\u00a0 If that is something we are likely only to see in Commodore<\/a> then worrying about compatability of a few calls to Exchange() could prove somewhat misplaced given the far wider issues likely to arise from the move to a 64-bit compiler.<\/p>\n
A Compromise?<\/h3>\n
In the meantime I wonder whether it would not be possible to have a compiler option to disable such strict type checking on var parameters, ideally on a method-by-method basis.<\/p>\n
After all, we still have such an option for short string var parameters (although having never had cause to use it I don’t know if it works in quite the way I have in mind – i.e. on declarations of rather than calls to, methods).<\/p>\n
In the case of class-type var parameters the more relaxed type checking could allow parameters of any type correctly derived from the formal type:<\/p>\n
  interface\r\n    {$VARSTRICTCLASSTYPE OFF}\r\n    procedure Exchange(var A, B: TObject);\r\n    {$VARSTRICTCLASSTYPE ON}\r\n\r\n  implementation\r\n\r\n    procedure Exchange(var A, B: TObject);\r\n      :\r\n    end;<\/pre>\n
Then again, I can’t think of any other concrete examples where such a capability would have any practical use.\u00a0 But if this were possible to implement more quickly and safely than a comprehensive type inferencing system, I think I’d take it to keep me going.<\/p>\n
\ud83d\ude42<\/p>\n","protected":false},"excerpt":{"rendered":"
[Estimated Reading Time: <\/span> 7<\/span> minutes]<\/span><\/span> In the new Delphi forums recently, Barry Kelly responded to a question about lambda expression syntax in Tibur\u00f3n with this observation: This syntax needs type inference. Our compiler was not originally written to support type inference, but work to support type inference is orthogonal to supporting anonymous methods. …\u00a0 you’ll need to provide the full […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":[]},"categories":[4,7],"tags":[292,21,47],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p1TKYv-3W","jetpack_sharing_enabled":true,"jetpack-related-posts":[{"id":1882,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1882\/","url_meta":{"origin":244,"position":0},"title":"Not Your Grand-Daddy’s Pascal (or Java)","date":"15 Oct 2013","format":false,"excerpt":"I've mentioned some of the cool stuff in the Oxygene language in various posts and thought it would be a good idea to list them again, along with some others that I've not previously mentioned. Oxygene Everywhere First some of the core language features that are available on all supported\u2026","rel":"","context":"In "Android"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":254,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/254\/","url_meta":{"origin":244,"position":1},"title":"An Exchange() For All","date":"26 Aug 2008","format":false,"excerpt":"Following on from yesterday's post, Barry Kelly (CodeGear engineer) kindly clarified a few points, one of which was that Generics support in Delphi 2009 won't extent to unit procedures, only class methods, so speculation about a possible generic implementation of a Swap()\/Exchange() routine was rendered largely academic. Not to be\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":371,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/371\/","url_meta":{"origin":244,"position":2},"title":"Delphi 2009 – CompilerVersion","date":"19 Sep 2008","format":false,"excerpt":"Just a short post this one. Somebody else may already have mentioned this, but I only just figured it out for myself - the CompilerVersion for the Delphi 2009 compiler is not what you might expect (and is not what the documentation says it is!). Both CompilerVersion and RTLVersion have\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":180,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/180\/","url_meta":{"origin":244,"position":3},"title":"Latest Tibur\u00f3n Preview","date":"14 Aug 2008","format":false,"excerpt":"I was a little disappointed that the preview webinar this morning was little more than a re-run of the same content from a little over a week ago, albeit with some downloadable PowerPoint slides this time. It was at least an opportunity for some more Q&A and a couple of\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1207,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1207\/","url_meta":{"origin":244,"position":4},"title":"Adventures in Syntax: Something Old, Something New etc…","date":"20 Sep 2012","format":false,"excerpt":"As the post title says, this will be a brief detour through some features of the Pascal language and a presentation of some (theoretical) alternatives that could have been introduced instead. That is, some are real but little known syntax, others are what I think might be preferable to the\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1300,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1300\/","url_meta":{"origin":244,"position":5},"title":"What’s in a Name(space) ?","date":"28 Nov 2012","format":false,"excerpt":"The ever evolving DWScript project continues to advance the Pascal language at an impressive pace. Just today it was announced that this scripting version of Pascal now has \"namespace\" support. When I first read the details of the implementation, my initial reaction was that it \"felt a bit backwards\". The\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"_links":{"self":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/244"}],"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=244"}],"version-history":[{"count":9,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/244\/revisions"}],"predecessor-version":[{"id":253,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/244\/revisions\/253"}],"wp:attachment":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/media?parent=244"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/categories?post=244"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/tags?post=244"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}