{"id":1300,"date":"2012-11-28T09:10:40","date_gmt":"2012-11-27T21:10:40","guid":{"rendered":"https:\/\/www.deltics.co.nz\/blog\/?p=1300"},"modified":"2012-11-28T11:28:07","modified_gmt":"2012-11-27T23:28:07","slug":"whats-in-a-namespace","status":"publish","type":"post","link":"https:\/\/www.deltics.co.nz\/blog\/posts\/1300\/","title":{"rendered":"What’s in a Name(space) ?"},"content":{"rendered":"[Estimated Reading Time: <\/span> 4<\/span> minutes]<\/span><\/span>

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<\/a>.
\n
\nWhen I first read the details of the implementation, my initial reaction was that it “felt a bit backwards”. The essence of the implementation is that it involves a new syntax for a unit, which instead of representing an actual unit, creates a “virtual” unit that effectively acts to collate or aggregate a number of other units into a single name:<\/p>\n

\r\n   unit namespace Foo.Bar;\r\n\r\n   uses\r\n     Foo.Bar.One,\r\n     Foo.Bar.Two;\r\n<\/pre>\n
Then in some other unit you can use both Foo.Bar.One and Foo.Bar.Two by simply using the namespace that is thus declared as using it:<\/p>\n
\r\n  unit MyUnit;\r\n\r\n  uses\r\n    Foo.Bar;   \/\/ uses Foo.Bar.One and Foo.Bar.Two\r\n<\/pre>\n
As I say, whilst useful and powerful, it feels a bit backwards to me.<\/p>\n
That is, you have to declare a namespace and then say what is in it, when it seems more natural to me for a unit to say which namespace it is a part of, itself.  Apart from anything else, it seems to me that using this “this namespace consists of<\/em>” approach (vs “I am part of a namespace<\/em>“) you can end up with two units in two different namespaces, no ?<\/p>\n
e.g. given:<\/p>\n
\r\n   unit namespace Foo.Bar;\r\n\r\n   uses\r\n     Foo.Bar.One,\r\n     Foo.Bar.Two;\r\n<\/pre>\n
and<\/p>\n
\r\n   unit namespace Snafu;\r\n\r\n   uses\r\n     Snafu.One,\r\n     Foo.Bar.One;\r\n<\/pre>\n
Having said that, whilst this might make me a little uncomfortable, is it actually a problem as such ?  If a unit then uses both Foo.Bar<\/strong> and Snafu<\/strong> namespaces, presumably the aggregated unit lists that comprise those namespaces will be reduced to a list of unique units.<\/p>\n
So perhaps not a problem at all.<\/p>\n
In fact, it could be seen as a feature, since it would – presumably – allow you to have a namespace that brings an entire other namespace<\/em> with it.  i.e. Snafu<\/strong> might itself bring in the entire Foo.Bar<\/strong> namespace, so that if your unit then uses Snafu<\/strong>, it is automatically using not just Snafu<\/strong> itself but also the entire Foo.Bar<\/strong> namespace, without having to declare this separately.<\/p>\n
Convenient, certainly, but what is an irritant when creating code (having to declare used units) can often be a boon when it comes to maintenance (being able to see at a glance<\/em> what units are used by any given unit).<\/p>\n
Caveat Scriptor<\/h3>\n
I should add at this point that this post is not intended to critique or suggest an alternative approach for DWScript<\/strong> itself.  Rather it is inspired by thinking about how such a feature would work in an actual, compiled Pascal project – specifically Delphi.<\/p>\n
Looking Forward…<\/h3>\n
So, DWScript<\/strong> has it’s new namespace declaration unit, but I think even that can be made a bit more Delphi-like if it were to be adopted by Delphi itself.<\/p>\n
Delphi already has a module type which acts as – and thus has an appropriate syntax for – a container for other units.  The package<\/strong>.<\/p>\n
We need to change the module keyword, but that’s OK and indeed desirable, since we are now defining an entirely new module type, giving us a great deal more flexibility in devising an appropriate syntax for that module.  But we needn’t work too<\/em> hard, since a lot of the existing package syntax “just fits”:<\/p>\n
\r\n  namespace Foo.Bar;\r\n\r\n  contains\r\n    Foo.Bar.One in '..\\Foo\\Foo.Bar.One.Pas',\r\n    Foo.Bar.Two in '..\\Foo\\Foo.Bar.Two.Pas';\r\n  end.\r\n<\/pre>\n
This syntax allows us to better reflect the “containment” relationship that a namespace has with it’s members, as opposed to the “uses” declaration.  But this still has us declaring a namespace and then identifying it’s contents.  It still “feels backwards”.<\/p>\n
It makes more sense – to me anyway – for a unit to declare it’s namespace and, continuing the theme of recycling existing syntax where it fits, there is just such a syntax that works in this case.  I deliberately invoked that syntax in my “namespace” module example above:<\/p>\n
The in<\/strong> clause.<\/p>\n
We could simply [ \ud83d\ude42 ] add support for that to the module declaration in a unit:<\/p>\n
\r\n   unit Foo.Bar.One in Foo.Bar;\r\n<\/pre>\n
This seems very neat and elegant to me but it has one major problem.  As Andreas Hausladen mentioned in the comments on the DWScript post:  the one-pass compiler in Delphi.<\/p>\n
When the compiler finds a unit that “uses Foo.Bar<\/strong>” it doesn’t know that Foo.Bar<\/strong> is<\/em> a namespace or which units are contained within<\/em> that namespace.  It won’t find out that Foo.Bar.One<\/strong> even exists or that it is part of Foo.Bar<\/strong> unless and until it is asked to reference Foo.Bar.One<\/strong> itself, which sort of defeats the purpose of namespaces, right out of the gate.<\/p>\n
If this could be solved as elegantly as the syntax for declaring the membership of a namespace itself (using this in<\/strong> syntax) then I think we’d have a winner.  \ud83d\ude42<\/p>\n
One way perhaps of resolving the, uh, resolving problem might be to introduce an initial first-pass in the compilation of a Delphi project, specifically to resolve namespaces.  This pass would use the existing uses<\/strong> declarations in the dpr<\/strong> combined with the project (and environment) search path (i.e. the current “unit search” algorithm) to assemble a directory of units and their corresponding namespace ‘containers’, where applicable.<\/p>\n
The bulk of this work – the business of locating a given unit on the search path – is already done by the compiler.  But with a directory of unit locations produced by the first pass, the compiler would be relieved of this effort.  Consequently the “cost” of the first pass would be offset – at least in part – by the removal of this effort from the compiler itself.<\/p>\n
It is also worth mentioning that even the “namespace module” would introduce some problems to be solved in any Delphi compiler implementation, since any namespace implementation creates the possibility, and increases the likelihood, of duplicate references to units in a single uses clause:<\/p>\n
\r\n  uses\r\n    Foo.Bar,       \/\/ uses Foo.Bar.One and Foo.Bar.Two\r\n    Snafu;         \/\/ uses Snafu.One and Foo.Bar.One\r\n<\/pre>\n
Currently, if a unit is referenced more than once in a uses clause (or indeed is referenced in both interface and implementation uses clauses) then a compilation error results.  Either this would have to be relaxed to a warning or ignored entirely, if namespaces are to be implemented.<\/p>\n
This is perhaps less of a potential problem when a unit is confined to a single namespace, as would be the case if namespace membership were a declared aspect of a unit itself.  But still a potential problem.<\/p>\n
The Undiscovered Country<\/h3>\n
Luckily, whilst we might speculate and invent a future namespace feature for Delphi, it doesn’t actually exist as yet (as far as I know).  This means we get to decide how we might like that future to actually look, from among the various options.<\/p>\n
So which would you prefer:<\/p>\n
    \n
  • A namespace module, declaring the units contained in the namespace<\/li>\n
  • An in<\/strong> declaration on a unit, with a name resolution pass added to the compiler<\/li>\n
  • Some other approach ?<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
    [Estimated Reading Time: <\/span> 4<\/span> minutes]<\/span><\/span> 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.<\/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":true,"jetpack_social_options":[]},"categories":[4],"tags":[292,13,185,173],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p1TKYv-kY","jetpack_sharing_enabled":true,"jetpack-related-posts":[{"id":1817,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1817\/","url_meta":{"origin":1300,"position":0},"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 "Android"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":3019,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/3019\/","url_meta":{"origin":1300,"position":1},"title":"What’s in a Name[space] ?","date":"29 Oct 2019","format":false,"excerpt":"A recap of unit aliases and how they relate to namespace prefixes as a prelude to a more interesting examination of Scope Elevation.","rel":"","context":"In "Delphi"","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":3024,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/3024\/","url_meta":{"origin":1300,"position":2},"title":"Scope Elevation: Creating A ‘Pseudo-Namespace’","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 "Delphi"","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":706,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/706\/","url_meta":{"origin":1300,"position":3},"title":"Making a case for Strings, the sane way","date":"02 Dec 2010","format":false,"excerpt":"Lars Fosdal responded to my previous post suggesting a way of implementing string support in a case-like construct (but not actually a case statement) using generics and anonymous methods. All very clever, but way, way too complicated and - if you don't mind me saying so - as ugly as\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":1300,"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":1945,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1945\/","url_meta":{"origin":1300,"position":5},"title":"Unit Aliases and Build Configurations","date":"17 Oct 2013","format":false,"excerpt":"Over on stackoverflow, Ann Gossard had a question about using an $ifdef in the project (DPR) uses list to use one unit in preference over another, specifically in debug builds. In this situation, it immediately occurred to me that unit aliases might be creatively deployed. What follows is a slightly\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/Screen-Shot-2013-10-17-at-15.25.51.png?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]}],"_links":{"self":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/1300"}],"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=1300"}],"version-history":[{"count":9,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/1300\/revisions"}],"predecessor-version":[{"id":1309,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/1300\/revisions\/1309"}],"wp:attachment":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/media?parent=1300"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/categories?post=1300"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/tags?post=1300"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}