Re: nested, referenced foreach & implicit current array pointer issues

Roman Neuhauser wrote: > # jochem@iamjochem.com / 2007-02-01 02:26:09 +0100: >> Roman Neuhauser wrote: >>> # jochem@iamjochem.com / 2007-01-31 19:41:42 +0100: >>>> instead I would suggest that your better off doing one of 2 things: >>>> >>>> 1. pass in the array to the function explicitly. >>>> 2. use a special function that can be called to retrieve the array >>>> from within your example function. >>>> >>>> bad advice? I'm open to being corrected :-) >>> 2. is only marginally better than "global". >> if you use a function you can make sure it's output is >> consistent and you have a single point of control. >> >> personally I consider that some what more than a marginal gain. > > Singleton is still an antipattern (in most cases). the reliance on persistence being one of the major gripes about Singleton (with regard to testing mostly) - which is kind of funny and sad at the same time - persistence being at once the most basic expectation of an average computer user AND something which apparently CS people on whole do everything to avoid providing. totally besides the point - the second option merely suggests providing a way to create a single source for the data - the source being more reliable than a global named $arr. this is not the same a Singleton pattern. > > If you're affraid that someone will break a convention which says that > the global associative array $foos has string indexes and values must be given an array of data that is used all over a php application then it quite simply saves alot fo headaches down the road to to agree on a convention that says 'we' will use a function to retrieve this data whenever it is needed (regardless > positive integers, or that it needs to be an array at all > ($GLOBALS['foos'] = new sabotage("haha")), you would be better off in > e. g. C++ with > > std::map<std::string, uint32_t> foos; please refrain from the old 'you-should-be-using-language-FOO-look-i'll-show-you-how-clever-I-am' argument it's not really adding anything to this discussion. > > It's not control over data types, it's visibility of access that causes > most of the lossage. Wrapping the global in a function doesn't remove > the structural defect. huh? > > Been there, done that, got the scars. >