Comments on: Strategies For Global Data ( hey it happens… ) http://blog.alanklement.com/2010/02/10/strategies-for-global-data-hey-it-happens/ Software Development Mon, 16 Jan 2012 04:16:26 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Ihsan http://blog.alanklement.com/2010/02/10/strategies-for-global-data-hey-it-happens/#comment-3549 Ihsan Sat, 17 Dec 2011 11:32:18 +0000 http://blog.alanklement.com/?p=501#comment-3549 globals are evil for sloppy programmers. Basic assumption of new (28 yrs into programming) scripting languages are that programmers are a bunch of stupid idiots. That assumption may only hold true for the developers of these languages avoiding globals, table calls gotos and expression evaluators. It's explanation is complete laziness during compiler end runtime environment development thats all. Programming like that becomes sometimes like boxing with your one hand tied to your one foot. We are leaving more than %70 of cpu into spider webs, we are not harnessing the power of the computers just because of this lazy people. I just wrote a vm inside as3 vm just because of this. That solved a lot of problems. If it was not that popular, I would say as3 is just a piece of crap and leave it alone for rot.Remember : OOP and Structural programming are just programming approaches and there are other approaches which may fit to applications. As3 is a very and severely crippled oop.For instance as with the first assumption I indicated in the beginning it does not have support for destructors or onDestroy event propagation. I rewrote a system just to avoid this successfully. But why do I have to do all this? To make as3 work properly. Kick your gc adobe... And a lot of other weirdos in your sloppy code. globals are evil for sloppy programmers. Basic assumption of new (28 yrs into programming) scripting languages are that programmers are a bunch of stupid idiots. That assumption may only hold true for the developers of these languages avoiding globals, table calls gotos and expression evaluators. It’s explanation is complete laziness during compiler end runtime environment development thats all. Programming like that becomes sometimes like boxing with your one hand tied to your one foot. We are leaving more than %70 of cpu into spider webs, we are not harnessing the power of the computers just because of this lazy people. I just wrote a vm inside as3 vm just because of this. That solved a lot of problems. If it was not that popular, I would say as3 is just a piece of crap and leave it alone for rot.Remember : OOP and Structural programming are just programming approaches and there are other approaches which may fit to applications. As3 is a very and severely crippled oop.For instance as with the first assumption I indicated in the beginning it does not have support for destructors or onDestroy event propagation. I rewrote a system just to avoid this successfully. But why do I have to do all this? To make as3 work properly. Kick your gc adobe… And a lot of other weirdos in your sloppy code.

]]> By: Alan http://blog.alanklement.com/2010/02/10/strategies-for-global-data-hey-it-happens/#comment-643 Alan Thu, 11 Feb 2010 17:32:49 +0000 http://blog.alanklement.com/?p=501#comment-643 The purpose of having the routine (method/function) is to allow arguments to be passed in. This allows me to help contain and add some control to when/who modifies the data. Having the data statically typed will help ensure that there is only one instance of it, but that won't help the epic fail that globals can portend. The purpose of having the routine (method/function) is to allow arguments to be passed in. This allows me to help contain and add some control to when/who modifies the data.

Having the data statically typed will help ensure that there is only one instance of it, but that won’t help the epic fail that globals can portend.

]]> By: cm http://blog.alanklement.com/2010/02/10/strategies-for-global-data-hey-it-happens/#comment-642 cm Thu, 11 Feb 2010 16:58:13 +0000 http://blog.alanklement.com/?p=501#comment-642 I'm kinda confused here: So lets say you have a singleton called GLOBAL(.as) Is it better to have a routine (getter/setter) to access the variables than have them staticly typed? E.g. GLOBAL.myVar vs GLOBAL.getVar() I think a good point is "statics are evil... when they puncture encapsulation" I’m kinda confused here:

So lets say you have a singleton called GLOBAL(.as)

Is it better to have a routine (getter/setter) to access the variables than have them staticly typed?

E.g. GLOBAL.myVar vs GLOBAL.getVar()

I think a good point is “statics are evil… when they puncture encapsulation”

]]> By: Robert Penner http://blog.alanklement.com/2010/02/10/strategies-for-global-data-hey-it-happens/#comment-640 Robert Penner Thu, 11 Feb 2010 02:40:04 +0000 http://blog.alanklement.com/?p=501#comment-640 Ok, cool. Ok, cool.

]]> By: Alan http://blog.alanklement.com/2010/02/10/strategies-for-global-data-hey-it-happens/#comment-639 Alan Thu, 11 Feb 2010 01:38:18 +0000 http://blog.alanklement.com/?p=501#comment-639 @robert Sorry, I don't follow the bit about "...add another constant and make a tripleton". The constants I have in the example are just a way to set a naming convention for passing arguments to the accessor method. I think I'm missing something... "This doesn’t scale very well" You're right it doesn't! I think I will go back and reword a bit of the article :) My point was really more of 'you're a coder on an app that *already* uses global data or 'you've come into a project and there needs to be a quick fix.' I see this technique as more of a 'damage control' rather than a best practice. It's NOT meant to be scaled up at all. If anything it's a band-aid before a heavy refactor. @robert
Sorry, I don’t follow the bit about “…add another constant and make a tripleton”. The constants I have in the example are just a way to set a naming convention for passing arguments to the accessor method. I think I’m missing something…

“This doesn’t scale very well”

You’re right it doesn’t! I think I will go back and reword a bit of the article :) My point was really more of ‘you’re a coder on an app that *already* uses global data or ‘you’ve come into a project and there needs to be a quick fix.’

I see this technique as more of a ‘damage control’ rather than a best practice. It’s NOT meant to be scaled up at all. If anything it’s a band-aid before a heavy refactor.

]]> By: Robert Penner http://blog.alanklement.com/2010/02/10/strategies-for-global-data-hey-it-happens/#comment-638 Robert Penner Thu, 11 Feb 2010 01:02:20 +0000 http://blog.alanklement.com/?p=501#comment-638 Guice has singletons per injector, not per virtual machine. Same with injectors used by Robotlegs. You can create as many injectors as you like, each with its own set of singletons. http://groups.google.com/group/google-guice/browse_thread/thread/bf493035d428025b Also, the singletons are not globally accessible. Some people say they are "lower-case" singletons rather than Singletons, which are global. Guice has singletons per injector, not per virtual machine. Same with injectors used by Robotlegs. You can create as many injectors as you like, each with its own set of singletons.

http://groups.google.com/group/google-guice/browse_thread/thread/bf493035d428025b

Also, the singletons are not globally accessible. Some people say they are “lower-case” singletons rather than Singletons, which are global.

]]> By: Robert Penner http://blog.alanklement.com/2010/02/10/strategies-for-global-data-hey-it-happens/#comment-637 Robert Penner Thu, 11 Feb 2010 00:57:04 +0000 http://blog.alanklement.com/?p=501#comment-637 You've made a doubleton. What happens when you want another model? You would add another constant and make a tripleton. This doesn't scale very well. The problem lies in retrieving a model dependency with a static call: var xml:XML = Data_Model.get_xml_formatted_for_images(Data_Model.XML_FORMAT_ONE); This breaks the locality of the context and decreases flexibility. If a component needs data, pass it in. Don't have the component reach out to get it from a static API. Imagine if a Flex List was hard-coded to retrieve its dataProvider from a static function. How would that be to work with? You have a valid point about enums. Anything constant is fine as a static. You’ve made a doubleton. What happens when you want another model? You would add another constant and make a tripleton. This doesn’t scale very well.

The problem lies in retrieving a model dependency with a static call:

var xml:XML = Data_Model.get_xml_formatted_for_images(Data_Model.XML_FORMAT_ONE);

This breaks the locality of the context and decreases flexibility. If a component needs data, pass it in. Don’t have the component reach out to get it from a static API.

Imagine if a Flex List was hard-coded to retrieve its dataProvider from a static function. How would that be to work with?

You have a valid point about enums. Anything constant is fine as a static.

]]> By: Twitted by FlashArtOfWar http://blog.alanklement.com/2010/02/10/strategies-for-global-data-hey-it-happens/#comment-636 Twitted by FlashArtOfWar Wed, 10 Feb 2010 22:07:03 +0000 http://blog.alanklement.com/?p=501#comment-636 [...] This post was Twitted by FlashArtOfWar [...] [...] This post was Twitted by FlashArtOfWar [...]

]]>