# jochem@xxxxxxxxxxxxx / 2007-02-01 15:46:39 +0100:
> Roman Neuhauser wrote:
> > # jochem@xxxxxxxxxxxxx / 2007-02-01 02:26:09 +0100:
> >> Roman Neuhauser wrote:
> >>> # jochem@xxxxxxxxxxxxx / 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)
Sorry, I don't understand this...
> 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.
Singleton in Design Patterns, p. 127:
: Intent
: Ensure a class only has one instance, and provide a global point of
: access to it.
The second part is IMO pretty much what you said.
> > 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
Agreeing on abandoning global variables would save even more headaches.
> > 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.
Originally I wanted to illustrate my point using PHP, but it's much more
code. Sorry if I hurt your feelings.
> > 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?
If PHP was statically typed, global variables would still be a bad
smell. They are bad smell in C++ and Java, for example. It's too easy
to call getfoo() before you have set up $foo. The risk grows
exponentially: as soon as you add another global, $bar, you risk that
you or someone else will use getfoo() inside initbar(), and getbar()
inside initfoo() (or getfoo() inside initfoo()). Of course, it will be
several function calls deep, and quite probably only happen in a code
path that's rarly used (such as error handling).
--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
