{"id":412,"date":"2008-10-01T17:34:49","date_gmt":"2008-10-01T05:34:49","guid":{"rendered":"https:\/\/www.deltics.co.nz\/blog\/?p=412"},"modified":"2008-10-01T17:34:49","modified_gmt":"2008-10-01T05:34:49","slug":"proposal-for-automated-variables","status":"publish","type":"post","link":"https:\/\/www.deltics.co.nz\/blog\/posts\/412\/","title":{"rendered":"Proposal for Automated Variables"},"content":{"rendered":"[Estimated Reading Time: <\/span> 4<\/span> minutes]<\/span><\/span>

Or: <\/strong>“Environmentally Friendly Coding – Recycle Your Keywords<\/em>”<\/p>\n

Yesterday I logged a Quality Central report proposing the addition of support for “automatic variables” to the Delphi language.\u00a0 Not only is it an excellent<\/span> idea (in my humble and utterly objective opinion :)), but there is already a keyword in the language that could be co-opted for this purpose, a keyword that has been at something of a loose-end since it was deprecated (rendered obsolete even) a long, long time ago…<\/p>\n

<\/p>\n

The language keyword in question is automated<\/strong>.\u00a0 This was introduced in Delphi 2.0 as part of the initial implementation to support COM automation and, if memory serves, deprecated in the very next release when “proper” (albeit COM) interfaces were added to the language.<\/p>\n

The functionality that AutoFree()<\/strong> provides is similar to the concept of an auto pointer<\/a> – a specific variant of the general concept of a smart pointer<\/a>.\u00a0 “auto”… “automatic”… “automated”… the similarity in the terms, and the relevance of the semantics, is striking.\u00a0 To me at least.<\/p>\n

The proposal in Quality Central drew inspiration directly from exchanges in the comments on my post on an AutoFree()<\/strong> implementation and a realisation that the required behaviour is very similar to that already implemented for interface references – it would not be entirely alien to the Delphi language.<\/p>\n

Indeed I believe it would be quite easily understood and welcomed by most, if not all, developers.<\/p>\n

The Proposal<\/h2>\n

The automated<\/strong> keyword should be supported as a decoration on variable declarations.\u00a0 That is local variables, member variables and unit variables:<\/p>\n

interface\r\n\r\n  type\r\n    TFoo = class\r\n    private\r\n      fBar: TBar automated;\r\n    end;\r\n\r\nimplementation\r\n\r\n  var\r\n    _Bar: TBar automated;\r\n\r\n  function FooFn;\r\n  var\r\n    bar: TBar automated;\r\n  begin\r\n    :\r\n  end;<\/pre>\n
The rules for the keyword and the effect of it shall be as follows:<\/p>\n
– The automated<\/strong> keyword shall be valid only for pointer and object reference type variables. (*)<\/strong><\/p>\n
– When marked as automated<\/strong> the compiler shall emit code to initialize a variable to NIL<\/strong>. This already occurs for local variables of certain types, most notably interface references, as well as all member variables <\/em>(albeit indirectly in that case)<\/em>, and currently has to be specified directly, if required, for unit variables.<\/em><\/p>\n
– When marked as automated<\/strong> the compiler shall emit code to finalize a variable in a manner appropriate to it’s type.\u00a0 For object references this shall be a call to Free<\/strong>; for pointers a call to FreeMem()<\/strong>.\u00a0 This is directly equivalent to the code already emitted by the compiler to finalize interface references by calling Release()<\/strong>.<\/em><\/p>\n
– automated<\/strong> would not<\/span> be combinable with absolute<\/strong>.<\/p>\n
(*)<\/strong> – it could also be supported on record types with the proviso that the record type in question supports a parameterless constructor<\/strong> (to be called to initialize the record) and a lone destructor<\/strong> (called to finalize the record).\u00a0 But to keep things simple lets stick to object references and pointers, for now at least.
\n<\/em><\/p>\n
The effect on code of the use of this keyword would be to facilitate:<\/p>\n
1. resource protection for temporary objects held in local variables without the need for try..finally<\/strong> blocks.<\/p>\n
2. reliable clean up of dependent objects in object hierarchies without the need for objects to implement a destructor<\/strong> (solely) to free those dependent objects.\u00a0 Destructors may still be necessary for other purposes of course.<\/p>\n
3. reliable clean up of unit (a.k.a “global”) objects without the need for a unit finalization<\/strong>.\u00a0 Again, finalization may still be required for other purposes.<\/p>\n
Note however that it would not prevent these existing techniques from functioning, if required or preferred.<\/p>\n
There is only one possible danger that I foresee, which is that a developer might mark a variable as automated but then dispose of the referenced object\/memory explicitly without re-initializing the variable.\u00a0 e.g.:<\/p>\n
  procedure SomeFn;\r\n  var\r\n    bar: TBar automated;\r\n  begin\r\n    bar := TBar.Create;\r\n    bar.Free;\r\n  end;<\/pre>\n
In this case, when SomeFn<\/strong> exits, the finalization of bar<\/strong> will likely result in an error since bar<\/strong> has been left holding a reference to an object that has already been Free<\/strong>‘d.<\/p>\n
Note that the initialization of bar<\/strong> as NIL (as a consequence of being automated<\/strong>) specifically avoids any problem if bar is only assigned a reference conditionally in the code.<\/p>\n
Note also that explicitly disposing an automated variable is not in and of itself problematic, as long as the variable is also then explicitly re-set to NIL<\/strong>.\u00a0 In the above example, if bar had been NIL<\/strong>‘d once freed, or FreeAndNIL()<\/strong> had been used, then there would not be any problem with the automated behaviour of bar<\/strong>.<\/p>\n
The code below illustrates safe explicit disposal and potentially conditional assignment of an automated reference:<\/p>\n
  procedure SomeFn;\r\n  var\r\n    bar: TBar automated;\r\n  begin\r\n    bar := TBar.Create;\r\n\r\n    \/\/ do some work with \"bar\"\r\n\r\n    FreeAndNIL(bar);\r\n\r\n    if SomeCondition then\r\n    begin\r\n      bar := TBar.Create;\r\n      \/\/ do more work with a new \"bar\"\r\n    end;\r\n  end;<\/pre>\n
This code is perfectly safe, will not result in a runtime error and will not leak a TBar<\/strong>.<\/p>\n
The potential dangers and pitfalls of an automated variable behaviour implemented as described are actually no different to the potential dangers and pitfalls associated with the manual techniques that it could replace.<\/p>\n
I should also mention that I cannot see that the proposal described here would necessarily interfere with, or be interfered with by, the existing, deprecated usage of the automated<\/strong> keyword.<\/p>\n
A final observation is that this implementation “feels very Pascal’ly” to me.\u00a0 In a good<\/span> way.<\/p>\n
Call To Action<\/h2>\n
The Quality Central report # is 67324<\/a>.<\/p>\n
If you feel the idea has merit please vote for it.<\/p>\n
If you feel it needs refining, comment on it (in QC, rather than here).<\/p>\n","protected":false},"excerpt":{"rendered":"
[Estimated Reading Time: <\/span>  4<\/span> minutes]<\/span><\/span>Or: “Environmentally Friendly Coding – Recycle Your Keywords” Yesterday I logged a Quality Central report proposing the addition of support for “automatic variables” to the Delphi language.\u00a0 Not only is it an excellent idea (in my humble and utterly objective opinion :)), but there is already a keyword in the language that could be co-opted […]<\/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":[292,68],"class_list":["post-412","post","type-post","status-publish","format-standard","hentry","category-delphi","tag-delphi","tag-smart-pointers"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p1TKYv-6E","jetpack_sharing_enabled":true,"jetpack-related-posts":[],"_links":{"self":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/412","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=412"}],"version-history":[{"count":5,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/412\/revisions"}],"predecessor-version":[{"id":417,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/412\/revisions\/417"}],"wp:attachment":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/media?parent=412"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/categories?post=412"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/tags?post=412"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}