Roman Neuhauser wrote:
...
>
> 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.
it's completely out of context:
a, there is no suggestion of a class (by me)
b, there is no suggestion that the data returned by the proposed function may
only exist as a single instance.
>
>>> 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.
so what's your solution to data that is shared accross an application? - for
instance
user data - or should every bit of code [re]retrieve the user data from the
database?
and is the database really not just a 'global variable' wrapped up in a couple
of
functions that are used to return data? and where would the 'key' come from that
allows for the retrieval of said user data?
>
>>> 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.
hardly - it's just that this is a php list - C++ examples aren't very useful
on the whole, and the language comparison is never truely orthogonal.
>
>>> 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).
that is just utterly contrived? why does there need to be 2 seperate functions
for init() & get()? doesn't encapsulation suggest that hiding the init()
specifics
within the get()is a good idea - why should the caller of get() have to worry
about the init() at all?
[sounds like unit testing is forcing a very rigid view of how to do things -
given that unit testing 'forces' lego-brick type of code it might be worth
considering that lots of real-world building are built from concrete. - granted
it's a weird analogy]
where does $foo come from and how it is initialized in your world exactly?
and how do you suggest using, accessing, retrieving $foo?
(i'm assuming you have a perfume to battle against all these awfully bad smells)
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
