{"id":2470,"date":"2016-11-25T17:46:03","date_gmt":"2016-11-25T05:46:03","guid":{"rendered":"https:\/\/www.deltics.co.nz\/blog\/?p=2470"},"modified":"2016-12-08T07:22:45","modified_gmt":"2016-12-07T19:22:45","slug":"mix-in-unified-and-segregated-syntax-an-extended-example","status":"publish","type":"post","link":"https:\/\/www.deltics.co.nz\/blog\/posts\/2470\/","title":{"rendered":"Mix-in Unified and Segregated Syntax: An (Extended) Example"},"content":{"rendered":"[Estimated Reading Time: <\/span> 5<\/span> minutes]<\/span><\/span>

Yesterday I initially posted<\/a> that you couldn’t mix Unified Syntax<\/strong> with “traditional” interface<\/strong> and implementation<\/strong> sections. Or what I am now calling Segregated Syntax<\/strong>.<\/p>\n

As sometimes happens, shortly after writing what I thought I knew to be true I discovered it wasn’t ! Sorry about that. \ud83d\ude42<\/p>\n

I promised to illustrate the scenario where I found it both possible and useful, and here it is.<\/p>\n

<\/p>\n

As I mentioned, I’m working an ASP.NET MVC\/WebApi project using Oxygene<\/strong>.<\/p>\n

The project employs ASP.NET Identity<\/strong> with Entity Framework<\/strong> for an auth server component in the project. As part of the implementation I am incorporating OAuth<\/strong> middleware with an ‘api\/Account<\/em>‘ end-point in my REST Api<\/strong> to support auth flows including external logins.<\/p>\n

Here’s my AccountController<\/strong> declaration:<\/p>\n

\r\n\r\ninterface\r\n\r\n  type\r\n    AccountController = public class(ApiController)\r\n    private\r\n      property Authentication: IAuthenticationManager read Request.GetOwinContext.Authentication;\r\n      property UserRepo: UserRepository := new UserRepository; readonly;\r\n    private\r\n      method GetErrorResult(identityResult: IdentityResult): IHttpActionResult;\r\n      method ValidateClientAndRedirectUri(request: HttpRequestMessage; var redirectUri: String): String;\r\n    protected\r\n      method Dispose(disposing: Boolean); override;\r\n    public\r\n      method ExternalLoginAsync(provider: String; error: nullable String := nil): Task<IHttpActionResult>;\r\n      method RegisterAsync(user: UserModel): Task<IHttpActionResult>;\r\n    end;\r\n\r\n\r\nimplementation\r\n  \r\n   \/\/ the donkey-work is down here as 'usual'\r\n\r\n<\/pre>\n
As you can see, although by no means massive, this is still quite a “busy” controller.  The implementation details aren’t really relevant to the example.  All you really need to know is that a couple of those methods have quite extensive implementations so to keep things clearer I chose in this case to use interface<\/strong> and implementation<\/strong> sections to keep things organised.<\/p>\n
One effect this has (and you could argue this as a Good<\/em> or a Bad<\/em> thing I guess) is that any attributes on the method implementations are no longer apparent from \/ cluttering up (depending on your point of view) the class declaration.  Using Unified Syntax<\/strong> any such attributes have<\/em> to appear in the declaration since there is nowhere else for them to go.<\/p>\n
Before we move on though, there are a couple of things worth pointing out for people not familiar with Oxygene<\/strong>, specifically in the declaration of the two properties.<\/p>\n
First, the Authentication<\/strong> property:<\/p>\n
\r\n\r\n   property Authentication: IAuthenticationManager read Request.GetOwinContext.Authentication;\r\n\r\n<\/pre>\n
This demonstrates the use of an expression in the read<\/strong> clause of a property<\/strong>.  In traditional Delphi<\/em> code this would necessitate a separate accessor function.  Not so in Oxygene<\/strong>.  This has been supported since the very early days of Oxygene<\/strong> (I think as far back as when it was known as Chrome<\/strong> in fact) but in retrospect has a lot in common with the new Unified Syntax<\/strong> now more generally available.<\/p>\n
Next up, the UserRepo<\/strong> property:<\/p>\n
\r\n\r\n      property UserRepo: UserRepository := new UserRepository; readonly;\r\n\r\n<\/pre>\n
Admittedly this isn’t very modern of me.  If I was being fashionable I might be using Ninject<\/strong> or some other IoC framework.  Then again, given the small size of this auth project, I might not.  But that’s a separate discussion.<\/p>\n
For now, let’s just focus on this property as written, and in that two things are a bit odd.<\/p>\n
The Curious Case of the Read-Only Property That Was Written<\/h2>\n
First, instead of a read<\/strong> accessor the property is being directly assigned to<\/em> in the declaration.  And secondly, it is also marked readonly<\/strong>.<\/p>\n
The result is that I have a UserRepo<\/strong> property which absolutely is read-only as far as the consumers of my controller class are concerned.  Without that readonly<\/strong> directive, the property would be read\/write.<\/p>\n
To make readonly<\/strong> properties useful there has to be an exception that allows the property to be initialised and in Oxygene<\/strong> that includes a declared initialization (as in this case) or an assignment allowed in any ctor<\/strong> of the class.  Both approaches will perhaps be familiar to C# developers.<\/p>\n
The Delphi<\/strong> equivalent would involve a member variable and a ctor<\/strong> in addition to the property:<\/p>\n
\r\n\r\n   \/\/ ...\r\n   private\r\n     fUserRepo: UserRepository;\r\n   public\r\n     property UserRepo: UserRepository read fUserRepo;\r\n     constructor Create;  \/\/ with implementation somewhere down below to initialise fUserRepo;\r\n   \/\/ ...\r\n\r\n<\/pre>\n
You can of course do effectively the same thing in C#, but there you also have some alternatives.  Unfortunately (for C# developers) those alternatives could be something of a minefield since it was decided that the readonly<\/strong> directive can be applied only to member fields<\/em> not properties.<\/p>\n
You could<\/em> avoid the need for a separate property declaration by using an initialised, readonly<\/strong> field:<\/p>\n
\r\n\r\n   public readonly UserRepository UserRepo = new UserRepository;\r\n\r\n<\/pre>\n
This is very<\/em> close to Oxygene<\/strong>‘s read only properties, except that the resulting member is a field<\/em>, not a property<\/em>.<\/p>\n
It may be a moot difference in the case of read-only<\/em> fields, but it is<\/em> still a difference and doing this sets you up nicely for some lengthy debates about whether this constitutes a valid exception to the House Rules rules regarding exposure and naming of member fields as well as landing you in the clutches of code-analysis tools that will castigate you for directly exposing a member field.<\/p>\n
To avoid such wrangles you could of course introduce a property<\/strong> so you can push the member field explicitly back into the private<\/strong> sphere where it belongs, accessed by an implicitly<\/em> read-only public property (with only a get<\/strong>ter) keeping your coding standards police off your back and the code analysis tools quiet.<\/p>\n
For the purposes of this exercise I am going to expand the indentation of those braces, just to show how “noisy” this really is:<\/p>\n
\r\n\r\n   private UserRepository _userRepo = new UserRepository(); readonly;\r\n   public property UserRepository UserRepo\r\n   {\r\n       get\r\n           {\r\n               return _userRepo;\r\n           }\r\n   };\r\n\r\n<\/pre>\n
Nobody would do that in real life ?  Au contraire.  I had to contend with a class with a number of such read-only properties declared and laid out in precisely this way only today.  I’m still feeling a little traumatised by the experience.  \ud83d\ude42<\/p>\n
Save for the elimination of the ctor<\/strong> (assuming that a ctor<\/strong> is not needed for other things) this has more than a passing resemblance to the Delphi original; which perhaps isn’t all that surprising remembering that Delphi in many ways directly begat C#<\/a>.<\/p>\n
But, back to the mix-in of Unified<\/strong> and Segregated Syntax<\/strong>.<\/p>\n
Mixing Things Up<\/del> In<\/h2>\n
As part of the implementation of the ExternalLoginAsync()<\/strong> method, I needed a new class to encapsulate some data pertinent to the external login process.  This class would be essentially a POCO<\/a> albeit adorned with a simple factory method.  Significantly, it was to be entirely private to the implementation of the AccountController<\/strong>.<\/p>\n
As such I didn’t see the need for a separate unit and decided to place the new class in the implementation<\/strong> section of the existing AccountController<\/strong> unit.<\/p>\n
But it bothered me that the quite straight-forward factory method was the only code involved in this class and breaking that out into a separate implementation body (in accordance with Segregated Syntax<\/strong>) irked me in this case.<\/p>\n
Fortunately of course, my irk was unfounded and I was able to do this:<\/p>\n
\r\n\r\ninterface\r\n\r\n  \/\/ .. the AccountController declaration is here ..\r\n\r\nimplementation\r\n\r\n  type\r\n    ExternalLoginData = class\r\n    public\r\n      property LoginProvider: String;\r\n      property ProviderKey: String;\r\n      property UserName: String;\r\n      property ExternalAccessToken: String;\r\n\r\n      class method FromIdentity(identity: ClaimsIdentity): ExternalLoginData;\r\n      begin\r\n        \/\/ manufacture happens here...\r\n      end;\r\n    end;\r\n\r\n\r\n  \/\/ .. the AccountController implementation is here...\r\n\r\n\r\nend.\r\n\r\n<\/pre>\n
A bit of further experimentation lead me to also identify that you can mix-in even within the same class<\/em>.<\/p>\n
So in the case of the AccountController<\/strong> itself I could keep the complex implementation details carefully coralled in the implementation<\/strong> section, but bring some of the trivial scaffolding up into the declaration in the interface<\/strong> section.<\/p>\n
The Dispose()<\/strong> method override is a potential candidate for just that:<\/p>\n
\r\n\r\ninterface\r\n\r\n    type\r\n    [Authorize]\r\n    AccountController = public class(ApiController)\r\n    private\r\n      property Authentication: IAuthenticationManager read Request.GetOwinContext.Authentication;\r\n      property UserRepo: UserRepository := new UserRepository; readonly;\r\n    private\r\n      method GetErrorResult(identityResult: IdentityResult): IHttpActionResult;\r\n      method ValidateClientAndRedirectUri(request: HttpRequestMessage; var redirectUri: String): String;\r\n    public\r\n      method ExternalLoginAsync(provider: String; error: nullable String := nil): Task<IHttpActionResult>;\r\n      method RegisterAsync(user: UserModel): Task<IHttpActionResult>;\r\n\r\n    protected\r\n      method Dispose(disposing: Boolean); override;\r\n      begin\r\n        if disposing then\r\n          UserRepo.Dispose;\r\n      end;\r\n    end;\r\n\r\n\r\nimplementation\r\n  \r\n   \/\/ etc etc, including the method bodies for those not implementing in the Unified Syntax\r\n\r\n<\/pre>\n
So there you have it.<\/p>\n
Instead of handing down tablets of syntax and strait-jacketing the developer, Oxygene<\/strong> now grants the freedom to use, ignore or (let’s face it) abuse this particular aspect of the syntax in an impressively flexible and intuitive (or at least very natural-feeling) manner.<\/p>\n
As I said before, although I was initially skeptical of the very idea of Unified Syntax<\/strong> it has very quickly become one of my favorite features of Oxygene<\/strong>.<\/p>\n","protected":false},"excerpt":{"rendered":"
[Estimated Reading Time: <\/span> 5<\/span> minutes]<\/span><\/span> Yesterday I initially posted that you couldn’t mix Unified Syntax with “traditional” interface and implementation sections. Or what I am now calling Segregated Syntax. As sometimes happens, shortly after writing what I thought I knew to be true I discovered it wasn’t ! Sorry about that. \ud83d\ude42 I promised to illustrate the scenario where I […]<\/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":[205,4,242,300,204,180],"tags":[306,181,302],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p1TKYv-DQ","jetpack_sharing_enabled":true,"jetpack-related-posts":[{"id":2460,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2460\/","url_meta":{"origin":2470,"position":0},"title":"The 9th Element","date":"24 Nov 2016","format":false,"excerpt":"In the periodic table of the elements, at #9 we find Fluorine. Curiously though the name \"Fluorine\" is not used (that I am aware of) anywhere in the Elements 9.0 release which dropped this week. But there is plenty of interest in this release, aside from Period Table curios. I'm\u2026","rel":"","context":"In "Cooper"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":2440,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2440\/","url_meta":{"origin":2470,"position":1},"title":"Fantasy Island [a.k.a x86\/x64 Codegen Using Oxygene]","date":"22 May 2016","format":false,"excerpt":"This is a quick follow up post to further tease some of the exciting developments in the world of RemObjects Elements. Yesterday I posted about implementing a Windows version of my trivially simple RandomNumber application. Today, I present another Windows version. But this one doesn't use .NET. First of all,\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":2523,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2523\/","url_meta":{"origin":2470,"position":2},"title":"Anonymous Classes: Anonymous POCO’s","date":"14 Feb 2017","format":false,"excerpt":"There is another use case for anonymous classes, even simpler than that of providing implementations of interfaces: Anonymous POCO's. We're all familiar with the idea of declaring a class that identifies the members that all instances (objects) of that class have, and then creating instances of that class. Anonymous classes,\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/code-completion-java.jpg?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":2252,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2252\/","url_meta":{"origin":2470,"position":3},"title":"Making a Noise About on a Thread","date":"13 Aug 2014","format":false,"excerpt":"I'm working on an Android app at the moment, and for a bit of fun I decided to add a startup sound to brighten the day of every user that launches it. Which gives me another opportunity to present some of the advanced language features in Oxygene that make threading\u2026","rel":"","context":"In "Android"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/Audio-Resource.png?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":2479,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2479\/","url_meta":{"origin":2470,"position":4},"title":"Using Retrofit with Oxygene","date":"07 Dec 2016","format":false,"excerpt":"I've recently been working on a new project involving an Azure hosted ASP.NET MVC WebApi application (actually a pair of them) and native mobile and web applications. Everything is - of course - built using Oxygene. For the Android mobile app I was looking for a REST API client library\u2026","rel":"","context":"In "Android"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1503,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1503\/","url_meta":{"origin":2470,"position":5},"title":"Sharing Code Across Platforms in Oxygene","date":"22 Aug 2013","format":false,"excerpt":"There seems to be a perception among some people that Delphi is in the unique position of allowing developers to share and re-use code across the various platforms that it's compiler can now (and will soon) target. But this is not the case. Oxygene has had this capability right from\u2026","rel":"","context":"In "Cooper"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"_links":{"self":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/2470"}],"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=2470"}],"version-history":[{"count":6,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/2470\/revisions"}],"predecessor-version":[{"id":2476,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/2470\/revisions\/2476"}],"wp:attachment":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/media?parent=2470"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/categories?post=2470"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/tags?post=2470"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}