{"id":3019,"date":"2019-10-29T14:06:10","date_gmt":"2019-10-29T02:06:10","guid":{"rendered":"https:\/\/www.deltics.co.nz\/blog\/?p=3019"},"modified":"2019-10-29T14:06:20","modified_gmt":"2019-10-29T02:06:20","slug":"whats-in-a-namespace-2","status":"publish","type":"post","link":"https:\/\/www.deltics.co.nz\/blog\/posts\/3019\/","title":{"rendered":"What&#8217;s in a Name[space] ?"},"content":{"rendered":"<span class=\"rt-reading-time\" style=\"display: block;\"><span class=\"rt-label rt-prefix\">[Estimated Reading Time: <\/span> <span class=\"rt-time\">4<\/span> <span class=\"rt-label rt-postfix\">minutes]<\/span><\/span>\n<p>Namespaces in most modern languages are, in simple terms, a way to organise identifiers to avoid confusion (between those identifiers).  Typically a file will declare (or identify) the namespace for any identifiers it introduces, independently of the filename itself.   Conversely, identifiers in a namespace can be brought into scope where needed by referencing the namespace without needing to know which files contain the declarations for those identifiers.  Unfortunately the <strong>unit<\/strong> module in Pascal\/Delphi predates this by some margin and things are not quite so convenient.  But there are things we can do to improve matters.<\/p>\n\n\n\n<!--more-->\n\n\n\n<p>Namespace prefixes are one obvious tool that can be deployed in this area.<\/p>\n\n\n\n<p>These don&#8217;t quite provide the level of decoupling of files and namespaces that are found in other languages, and it could be argued that they are really just a kludge.<\/p>\n\n\n\n<p>They allow us to have files which contain alternate forms of otherwise identically named identifiers and to effectively &#8220;switch&#8221; between which set of files we wish to use.  Namespace prefixes are really little more than a slightly more complicated version of <strong>unit aliases<\/strong> so let&#8217;s do a quick recap of that.<\/p>\n\n\n\n<p class=\"has-drop-cap\">Unit aliases can be useful when we decide to rename a unit and don&#8217;t wish to have to go through all of our existing code and change the references to the old name to the new one.  We can instead use an alias to let the compiler know that when it sees a reference to the old name treat it as a reference to the new on.<\/p>\n\n\n\n<p>As well as conveniently replacing\/renaming units however, we can also use a unit alias to select at compile-time one of any number of different files containing different, equally current implementations of a class (or other declarations, functions, variables, etc), each with the same name and the same public interface (i.e the same <code>public<\/code> and <code>published<\/code> methods\/properties).  Code that consumes these classes <em>could<\/em> compile with any of those possible units, but we <em>must<\/em> choose just one. <\/p>\n\n\n\n<p>For a simple, contrived example, let&#8217;s imagine we have a <code>TWidgetService<\/code> class with two different implementations, <em>Flavours<\/em> <strong>A<\/strong> and <strong>B<\/strong>.  With a unit alias we would implement different <code>TWidgetService<\/code> classes in each of two files:<\/p>\n\n\n\n<ul><li>WidgetServiceFlavourA.pas<\/li><li>WidgetServiceFlavourB.pas<\/li><\/ul>\n\n\n\n<p>And in a project consuming this service we would declare a unit alias that equates the <em>virtual<\/em> unit <strong>WidgetService<\/strong> to one or other of these, e.g.:<\/p>\n\n\n\n<p><code>WidgetService=&lt;strong&gt;WidgetServiceFlavour&lt;em&gt;A&lt;\/em&gt;&lt;\/strong&gt;<\/code><\/p>\n\n\n\n<p>Then in units (or libraries or programs) which <em>use<\/em> the service we would add the <em>virtual<\/em> unit to the <code>uses<\/code> clause:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">program WidgetConsumerProgram;\n\nuses\n  <strong>WidgetService<\/strong>;\n\nvar\n  widget: TWidgetService;\n\n..<\/pre>\n\n\n\n<p>Since the unit alias is a project level compiler setting, this enables us to &#8216;choose&#8217; which implementation of our service our project will be built against.  In this case the <code>widget<\/code> variable will be a reference to an instance of the <code>TWidgetService<\/code> class provided by the <code>WidgetService&lt;strong&gt;FlavourA&lt;\/strong&gt;<\/code> unit.  To rebuild our project instead with <code>WidgetService&lt;strong&gt;FlavourB&lt;\/strong&gt;<\/code> we simply change the unit alias:<\/p>\n\n\n\n<p><code>WidgetService=<\/code><strong><code>WidgetServiceFlavour&lt;em&gt;B&lt;\/em&gt;<\/code><\/strong><\/p>\n\n\n\n<p>And at a stroke the entire project is now built with the different flavour (B) of our <code>TWidgetService<\/code>.<\/p>\n\n\n\n<p>This is fine for <em>individual<\/em> units, but what if we have a whole host of classes and other identifiers in a framework, spread across multiple units ?  Changing unit aliases for all of the units involved is going to be tedious, not to mention error-prone.  This is where namespace prefixes come in and effectively provide &#8220;bulk unit aliasing&#8221;.<\/p>\n\n\n\n<p class=\"has-drop-cap\">Namespace prefixes work by first assuming that you distinguish between your different flavours of identifiers in a conventional way, by which I mean: following a particular convention.  The convention in question being the use of a consistent unit name prefix for each flavour, separated from the &#8220;real&#8221; unit name by a dot.<\/p>\n\n\n\n<p>i.e. instead of <code>WidgetServiceFlavourA<\/code> and <code>WidgetServiceFlavourB<\/code>, rather:<\/p>\n\n\n\n<p><code>&lt;strong&gt;FlavourA&lt;\/strong&gt;.WidgetService<\/code> and <code>&lt;strong&gt;FlavourB&lt;\/strong&gt;.WidgetService<\/code>.<\/p>\n\n\n\n<p>With the introduction of namespace prefixes, the rules for unit resolution were extended to first look for a unit name that matches the un-prefixed name in a <code>uses<\/code> clause with any filename that corresponds to that name plus a namespace prefix specified in the project compilation options.<\/p>\n\n\n\n<p>So just as with a unit alias, in your consuming code you reference the virtual unit name: <code>WidgetService<\/code>.  The difference here of course is that you may have many, many units for each &#8216;flavour&#8217;.<\/p>\n\n\n\n<p><em>The resolved unit name and the physical filename must still match<\/em>.  The namespace prefix allows us to omit the first part of the unit filename when we reference it in a <code>uses<\/code> clause, as long as a suitable prefix is supplied in the compiler settings to resolve the <em>partial<\/em> unit name to a full, physical unit name somewhere on the search path.  Then if there is a &#8216;mirror&#8217; universe of other units that exist with some other prefix we can switch to those by simply changing the prefix in our compiler settings.<\/p>\n\n\n\n<p>Just like unit aliases.<\/p>\n\n\n\n<p>The most obvious example of this is of course the various units that comprise the <strong>Vcl<\/strong> and <strong>Fmx<\/strong> (FireMonkey) frameworks.  Unit aliases could have been used to manage cross-framework compatibility but it doesn&#8217;t take much imagination to realise how painful this would have been with the large number of unit involved in those frameworks.<\/p>\n\n\n\n<p class=\"has-background has-pale-pink-background-color\">If you look for documentation on namespaces in Delphi you will likely come across information that suggests far more is going on than this pretty blunt unit-aliasing tool, particularly this <a href=\"http:\/\/docs.embarcadero.com\/products\/rad_studio\/delphiAndcpp2009\/HelpUpdate2\/EN\/html\/devcommon\/usingnamespaces_xml.html\">section of the on-line help<\/a>.  As far as I can tell, this is simply hopelessly out-of-date documentation for the ill-fated Delphi.NET compiler.  The biggest clue to this is a reference to <code>dcuil<\/code> in the section on <em>Declaring Namespaces<\/em>.  This is odd as the copyright date on the page indicates it being written in 2009, when Delphi.NET had been axed and replaced by <a href=\"https:\/\/www.elementscompiler.com\/elements\/oxygene\/\">Oxygene<\/a> (branded as Delphi Prism).<\/p>\n\n\n\n<p class=\"has-background has-light-green-cyan-background-color\"><a href=\"https:\/\/www.elementscompiler.com\/elements\/oxygene\/\">Oxygene<\/a> has a completely reworked and explicit namespace syntax and wholly different (and far more straightforward!) namespace rules than those described.<\/p>\n\n\n\n<hr class=\"wp-block-separator\"\/>\n\n\n\n<p>All of this is very interesting but is really just background for what I <em>really<\/em> want to talk about which is a pattern I have established for simplifying the consumption of multi-unit frameworks and libraries, such as <a href=\"https:\/\/github.com\/deltics\/deltics.smoketest\">Smoketest<\/a>.  I call this pattern (rightly or wrongly) <strong><em>Scope Elevation<\/em><\/strong> and I&#8217;ll explain exactly what it entails next time, using some of the new features in the upcoming <em>Smoketest 2.1.x<\/em> to illustrate how I find it useful.<\/p>\n","protected":false},"excerpt":{"rendered":"<p><span class=\"rt-reading-time\" style=\"display: block;\"><span class=\"rt-label rt-prefix\">[Estimated Reading Time: <\/span> <span class=\"rt-time\">4<\/span> <span class=\"rt-label rt-postfix\">minutes]<\/span><\/span> A recap of unit aliases and how they relate to namespace prefixes as a prelude to a more interesting examination of Scope Elevation.<\/p>\n","protected":false},"author":2,"featured_media":3022,"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":true,"jetpack_social_options":[]},"categories":[4,1],"tags":[13,185,351],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/niklaus-wirth-edit.jpg?fit=934%2C362&ssl=1","jetpack_shortlink":"https:\/\/wp.me\/p1TKYv-MH","jetpack_sharing_enabled":true,"jetpack-related-posts":[{"id":3024,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/3024\/","url_meta":{"origin":3019,"position":0},"title":"Scope Elevation: Creating A &#8216;Pseudo-Namespace&#8217;","date":"31 Oct 2019","format":false,"excerpt":"In my previous post I talked about how \"namespaces\" in Delphi really don't exist for any practical purposes normally associated with the concept. Having become familiar with the concept in other languages I found I was missing them, so I devised a way to obtain some of the benefits, despite\u2026","rel":"","context":"In &quot;Delphi&quot;","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/niklaus-wirth-edit.jpg?fit=934%2C362&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":1300,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1300\/","url_meta":{"origin":3019,"position":1},"title":"What&#8217;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 &quot;Delphi&quot;","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":3233,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/3233\/","url_meta":{"origin":3019,"position":2},"title":"Kubernetes @ Home: Dashboard","date":"07 Feb 2022","format":false,"excerpt":"At the end of the previous post in this series, we reached the point where I had my Kubernetes cluster up and running, including a Dashboard service. As I mentioned, this Dashboard is not part of a default installation. Taking a look at how I got this up and running\u2026","rel":"","context":"In &quot;Delphi&quot;","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/kubernetes-banner.png?fit=1171%2C416&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":1477,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1477\/","url_meta":{"origin":3019,"position":3},"title":"A Case of Insensitivity","date":"15 Aug 2013","format":false,"excerpt":"I closed my previous post with an observation that the code for initialising an iOS user interface programmatically, as translated from equivalent Objective-C, contained a potential gotcha. I now have a little more time to expand on that. Loose Ends This is the code we ended up with last time:\u2026","rel":"","context":"In &quot;Delphi&quot;","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1817,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1817\/","url_meta":{"origin":3019,"position":4},"title":"Getting the Battery Level on Android With Delphi","date":"01 Oct 2013","format":false,"excerpt":"Over the past few days I posted a two part series showing how to obtain the current battery level as part of the implementation of an Android AppWidget using Oxygene. As far as I can tell AppWidgets simply aren't possible using Delphi but reading the battery is quite straightforward Android\u2026","rel":"","context":"In &quot;Android&quot;","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1833,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1833\/","url_meta":{"origin":3019,"position":5},"title":"Importing an Android Class For Use in Delphi","date":"03 Oct 2013","format":false,"excerpt":"In a previous post I noted the absence of the BatteryManager class in the AndroidAPI.JNI units. This class contains some constants useful when reading battery information. I showed how to use a suitably massaged literal in place of these missing constants, but in response to observations from Paul and Brian\u2026","rel":"","context":"In &quot;Android&quot;","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"_links":{"self":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/3019"}],"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=3019"}],"version-history":[{"count":3,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/3019\/revisions"}],"predecessor-version":[{"id":3023,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/3019\/revisions\/3023"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/media\/3022"}],"wp:attachment":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/media?parent=3019"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/categories?post=3019"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/tags?post=3019"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}