/customers/iconara.net/iconara.net/httpd.www/blog/wp-content/plugins/wp-super-cache/wp-cache-phase1.php Warning: Cannot modify header information - headers already sent by (output started at /customers/4/c/9/iconara.net/httpd.www/blog/wp-content/advanced-cache.php:1) in /customers/4/c/9/iconara.net/httpd.www/blog/wp-includes/feed-rss2-comments.php on line 8 Comments on: Architectural Atrocities, part 11: Not yet another namespace construct http://blog.iconara.net/2009/02/11/architectural-atrocities-part-11-not-yet-another-namespace-construct/ Thu, 05 Jul 2012 13:41:39 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Theo http://blog.iconara.net/2009/02/11/architectural-atrocities-part-11-not-yet-another-namespace-construct/comment-page-1/#comment-7908 Theo Wed, 26 Aug 2009 10:38:54 +0000 http://blog.iconara.net/?p=419#comment-7908 <p>Agreed. It's ugly.</p> <p>It's was enough that Adobe took Cairngorm under its wing, that they now seem to have let the same ideas from that framework seep into Flex is just atrocious.</p> Agreed. It’s ugly.

It’s was enough that Adobe took Cairngorm under its wing, that they now seem to have let the same ideas from that framework seep into Flex is just atrocious.

]]>
By: Marcus Stade http://blog.iconara.net/2009/02/11/architectural-atrocities-part-11-not-yet-another-namespace-construct/comment-page-1/#comment-7907 Marcus Stade Wed, 26 Aug 2009 08:56:38 +0000 http://blog.iconara.net/?p=419#comment-7907 <p>Oh I wholeheartedly agree, it reaks. But for the sake of argument, I still think that having a questionable justification for it's existance doesn't really excuse the blatant disregard for sane principles by making it into a global variable. In addition to that, separating it into a container class whose sole purpose seems to be holding global variables is just adding insult to injury since they probably think that there'll be more "useful" globals around the corner.</p> <p>What annoys me isn't really this particular case though. I can see why someone would do this in a smaller project where testability and maintainability is not really key (prototypes for instance). No, what annoys me is the fact that it's right there in the framework. On the one hand producing articles about best practices and on the other shipping code that violates very basic "rules" if you will. I realise that best practices is little more than a guideline, there's no silver bullet, but you'd think that at least the very basics would be nailed to the ground by now.</p> <p>I guess I'm overreacting a bit, sometimes I just get the feeling that Adobe's more concerned about marketing a high level product than actually producing it. Flex is a good product, but design flaws like this are littered all over the framework making it difficult to gain traction with serious programmers who actually care about making quality software. It hurts.</p> <p>Anyway, sorry for spamming your blog, I'll stop now. I'm really looking forward to hearing more about your current endevours as I always enjoy reading your very insightful posts!</p> Oh I wholeheartedly agree, it reaks. But for the sake of argument, I still think that having a questionable justification for it’s existance doesn’t really excuse the blatant disregard for sane principles by making it into a global variable. In addition to that, separating it into a container class whose sole purpose seems to be holding global variables is just adding insult to injury since they probably think that there’ll be more “useful” globals around the corner.

What annoys me isn’t really this particular case though. I can see why someone would do this in a smaller project where testability and maintainability is not really key (prototypes for instance). No, what annoys me is the fact that it’s right there in the framework. On the one hand producing articles about best practices and on the other shipping code that violates very basic “rules” if you will. I realise that best practices is little more than a guideline, there’s no silver bullet, but you’d think that at least the very basics would be nailed to the ground by now.

I guess I’m overreacting a bit, sometimes I just get the feeling that Adobe’s more concerned about marketing a high level product than actually producing it. Flex is a good product, but design flaws like this are littered all over the framework making it difficult to gain traction with serious programmers who actually care about making quality software. It hurts.

Anyway, sorry for spamming your blog, I’ll stop now. I’m really looking forward to hearing more about your current endevours as I always enjoy reading your very insightful posts!

]]>
By: Theo http://blog.iconara.net/2009/02/11/architectural-atrocities-part-11-not-yet-another-namespace-construct/comment-page-1/#comment-7906 Theo Wed, 26 Aug 2009 08:39:19 +0000 http://blog.iconara.net/?p=419#comment-7906 <p>I'd say that if an arbitrary component needs a reference to the top level application you've got more serious design issues that wether that variable is typed as an interface or a concrete type =) It's just a bad idea to start with (which seems to be more or less what you're saying).</p> <p>It's true I haven't updated the blog for way too long. Part of the reason is that I don't do much Flex development anymore, and the other part is that that work has kept me quite busy (because it's exciting stuff). If or when I get around to start writing this blog will have a very different focus.</p> I’d say that if an arbitrary component needs a reference to the top level application you’ve got more serious design issues that wether that variable is typed as an interface or a concrete type =) It’s just a bad idea to start with (which seems to be more or less what you’re saying).

It’s true I haven’t updated the blog for way too long. Part of the reason is that I don’t do much Flex development anymore, and the other part is that that work has kept me quite busy (because it’s exciting stuff). If or when I get around to start writing this blog will have a very different focus.

]]>
By: Marcus Stade http://blog.iconara.net/2009/02/11/architectural-atrocities-part-11-not-yet-another-namespace-construct/comment-page-1/#comment-7905 Marcus Stade Tue, 25 Aug 2009 20:07:40 +0000 http://blog.iconara.net/?p=419#comment-7905 <p>True, that'll most certainly work (except for, as you do note, Popups) but is unnecessary complex and doesn't solve the typing issue at all.</p> <p>You're still referencing a concrete class instead of an interface. Should your class not inherit from mx.core.Application (ie, spark.components.Application), you're at a loss. Of course, it's probably likely that when developing the application, the Application class is known, but when migrating a code base from say Halo to Spark this may well become an issue. Or when using modules for instance.</p> <p>As Matthew mentioned on the page I linked to above however, the application is already available to UIComponent through the parentApplication property which solves the issue of referencing altogether (too bad it can't be mocked, read only), but not the issue of loose typing. But hey, they've got half'n'half =)</p> <p>I don't care much for his explanation of FlexGlobals existance though, basically justifying it by saying global variables are ok and some sillyness about OO principal zealotry standing in the way of, well, quick'n'dirty access from classes not belonging to the display chain (making the classes lie about their dependancies instead). Oh well.</p> <p>On a totally unrelated sidenote, it's been a while since an update on your blog. I hope you catch the time to update sometime soon, I always enjoy reading your insightful posts!</p> True, that’ll most certainly work (except for, as you do note, Popups) but is unnecessary complex and doesn’t solve the typing issue at all.

You’re still referencing a concrete class instead of an interface. Should your class not inherit from mx.core.Application (ie, spark.components.Application), you’re at a loss. Of course, it’s probably likely that when developing the application, the Application class is known, but when migrating a code base from say Halo to Spark this may well become an issue. Or when using modules for instance.

As Matthew mentioned on the page I linked to above however, the application is already available to UIComponent through the parentApplication property which solves the issue of referencing altogether (too bad it can’t be mocked, read only), but not the issue of loose typing. But hey, they’ve got half’n'half =)

I don’t care much for his explanation of FlexGlobals existance though, basically justifying it by saying global variables are ok and some sillyness about OO principal zealotry standing in the way of, well, quick’n'dirty access from classes not belonging to the display chain (making the classes lie about their dependancies instead). Oh well.

On a totally unrelated sidenote, it’s been a while since an update on your blog. I hope you catch the time to update sometime soon, I always enjoy reading your insightful posts!

]]>
By: Theo http://blog.iconara.net/2009/02/11/architectural-atrocities-part-11-not-yet-another-namespace-construct/comment-page-1/#comment-7904 Theo Tue, 25 Aug 2009 13:33:03 +0000 http://blog.iconara.net/?p=419#comment-7904 <p>@Marcus</p> <p>you wouldn't even need to inject it:</p> <p><pre> <code> protected function get application( ) : Application { var appCandidate : DisplayObject = this;</code></pre></p> <p>while ( ! (appCandidate is Application) && appCandidate.parent != null ) { appCandidate = appCandidate.parent; }</p> <p>if ( appCandidate is Application ) { return appCandidate; } else { return null; } } </p> <p>it doesn't work for pop ups, but I'm sure you can do some magic using <code>stage</code> and working your way down, can't remember which order Flex puts things off the top of my head.</p> <p>I might have screwed up the exact test of the loop.</p> <p>To answer your question: it's just as ugly as it ever was.</p> @Marcus

you wouldn’t even need to inject it:


protected function get application( ) : Application {
  var appCandidate : DisplayObject = this;

while ( ! (appCandidate is Application) && appCandidate.parent != null ) { appCandidate = appCandidate.parent; }

if ( appCandidate is Application ) { return appCandidate; } else { return null; } }

it doesn’t work for pop ups, but I’m sure you can do some magic using stage and working your way down, can’t remember which order Flex puts things off the top of my head.

I might have screwed up the exact test of the loop.

To answer your question: it’s just as ugly as it ever was.

]]>
By: Marcus Stade http://blog.iconara.net/2009/02/11/architectural-atrocities-part-11-not-yet-another-namespace-construct/comment-page-1/#comment-7903 Marcus Stade Tue, 25 Aug 2009 09:55:57 +0000 http://blog.iconara.net/?p=419#comment-7903 <p>Theo, what do you think about Adobe's change of Application.application? http://opensource.adobe.com/wiki/display/flexsdk/Spark+Application</p> <p>While I understand their reasoning that by referencing Application from another Application type incurrs a bytecode size overhead, wouldn't it be better to do away with this global variable altogether and instead provide a reference by injecting it into a property on each display object? Also, why typing it so loosely? Wouldn't it be better to type the property to an interface so that the API is not hidden and so the implementation may change (ie, mocked).</p> <p>I think that Application.application was in itself a bad idea, but moving it to FlexGlobals.topLevelApplication and further justifying it's existance is just adding insult to injury in my mind. Shouldn't Adobe come forth and lead by example?</p> Theo, what do you think about Adobe’s change of Application.application? http://opensource.adobe.com/wiki/display/flexsdk/Spark+Application

While I understand their reasoning that by referencing Application from another Application type incurrs a bytecode size overhead, wouldn’t it be better to do away with this global variable altogether and instead provide a reference by injecting it into a property on each display object? Also, why typing it so loosely? Wouldn’t it be better to type the property to an interface so that the API is not hidden and so the implementation may change (ie, mocked).

I think that Application.application was in itself a bad idea, but moving it to FlexGlobals.topLevelApplication and further justifying it’s existance is just adding insult to injury in my mind. Shouldn’t Adobe come forth and lead by example?

]]>
By: Jay http://blog.iconara.net/2009/02/11/architectural-atrocities-part-11-not-yet-another-namespace-construct/comment-page-1/#comment-7814 Jay Sat, 25 Apr 2009 15:31:16 +0000 http://blog.iconara.net/?p=419#comment-7814 <p>Due to overwhelming community outcry the Fx prefix has been dropped from Flex4.</p> Due to overwhelming community outcry the Fx prefix has been dropped from Flex4.

]]>
By: nwebb http://blog.iconara.net/2009/02/11/architectural-atrocities-part-11-not-yet-another-namespace-construct/comment-page-1/#comment-7768 nwebb Fri, 13 Feb 2009 15:51:38 +0000 http://blog.iconara.net/?p=419#comment-7768 <p>Agreed. Also see:</p> <p>http://manishjethani.com/blog/2009/01/23/strongly-against-the-fx-prefix/</p> <p>and</p> <p>http://www.returnundefined.com/2009/01/share-your-thoughts-on-the-fx-prefixes-in-flex-4</p> Agreed. Also see:

http://manishjethani.com/blog/2009/01/23/strongly-against-the-fx-prefix/

and

http://www.returnundefined.com/2009/01/share-your-thoughts-on-the-fx-prefixes-in-flex-4

]]>
By: Richard Lord http://blog.iconara.net/2009/02/11/architectural-atrocities-part-11-not-yet-another-namespace-construct/comment-page-1/#comment-7767 Richard Lord Thu, 12 Feb 2009 07:39:11 +0000 http://blog.iconara.net/?p=419#comment-7767 <p>I think it's because of css issues - if the classes had the same name and you defined a Button style in css Flex wouldn't know which of the identically named classes you're styling.</p> <p>There is a method for specifying namespaces in the Css3 spec, but unfortunately this won't be in the css spec for Flex 4 - implementing this would have been a better solution.</p> I think it’s because of css issues – if the classes had the same name and you defined a Button style in css Flex wouldn’t know which of the identically named classes you’re styling.

There is a method for specifying namespaces in the Css3 spec, but unfortunately this won’t be in the css spec for Flex 4 – implementing this would have been a better solution.

]]>
By: Ian http://blog.iconara.net/2009/02/11/architectural-atrocities-part-11-not-yet-another-namespace-construct/comment-page-1/#comment-7766 Ian Wed, 11 Feb 2009 20:31:38 +0000 http://blog.iconara.net/?p=419#comment-7766 <p>Sounds like a major pain in the ass.</p> Sounds like a major pain in the ass.

]]>