On Jan 10, 2008 2:02 PM, Philip Thompson <philthathril@xxxxxxxxx> wrote:
> On Jan 10, 2008, at 12:48 PM, Eric Butera wrote:
>
> > On Jan 10, 2008 1:33 PM, <reese@xxxxxxxxxxxxxxxx> wrote:
> >> I have been using define to create a constant for the link resource
> >> returned by mysql
> >> pconnect like so:
> >>
> >> $PL = @mysql_pconnect("localhost", $DBUser, $DBPass);
> >> define("SITE_DB",$PL);
> >>
> >>
> >> Later I use the constant to select my databases.
> >>
> >> mysql_select_db($SrcdbID ,SITE_DB);
> >>
> >> This code seems to be working as I expected and I have many
> >> thousands of llines of code
> >> done over several years using this construct.
> >>
> >> But, I happened to be reading the php doco today and noticed that
> >> you are not supposed to
> >> use define for resources, so question is, is what I am doing safe
> >> or am I going to run into
> >> problems and if so what is the best way to globally pass resources
> >> to multiple classes and
> >> functions, command line scripts etc?
> >>
> >>
> >> Cheers
> >> Charlie Reese
> >>
> >>
> > Hi Charlie!
> >
> > Well a CONSTANT is a value that doesn't change. I don't think that
> > makes sense for a DB connection. The connection command returns a
> > resource that could be different on each request depending on if
> > you've worked on different resources.
> >
> > You could just do this:
> > $GLOBALS['SITE_DB'] = @mysql_pconnect("localhost", $DBUser, $DBPass);
> >
> > Then inside your function reference it like this:
> > mysql_query($sql, $GLOBALS['SITE_DB']);
> >
> > This would be an easy mass find/replace that you could do. Global
> > variables are evil though.
> >
> > I personally use the registry pattern to hold an instance of the
> > database connection that can be lazy loaded whenever I need it. Then
> > inside of my gateway objects I pass that instance in the constructor
> > so they only have to know how to work with its interface. If you're
> > okay with using object that might be a nice road to travel. You could
> > also use the singleton pattern but I would advise against that because
> > what if you wanted 2 instances for different databases? I've never
> > ran across this myself but you never know. Plus it makes unit testing
> > a little tricky since you can't mock it as easily.
> >
> > Hopefully something in all this will help you to an answer.
>
>
> I don't agree that "Global variables are evil." If you have a valid
> purpose for defining a global variable, then go with it. The usual
> argument is that it could accidentally be changed elsewhere (and there
> are several more). However, defining a variable that you KNOW you're
> going to use only for a database connection, IMO, is perfectly fine.
>
> $GLOBALS['SITE_DB'] = @mysql_pconnect("localhost", $DBUser, $DBPass);
>
> If you accidently change $GLOBALS['SITE_DB'] elsewhere, then I think
> you have some bigger issues at hand. =P HTH.
>
> ~Philip
>
> "Personally, most of my web applications do not have to factor 13.7
> billion years of space drift in to the calculations, so PHP's rand
> function has been great for me..." ~S. Johnson
>
> --
>
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Depending on what project I'm working on sometimes I use specific
globals on our older procedural code because:
1) It is our code
2) It does not use outside code
3) I'm the only developer working on it
4) It is very simplistic
By specific globals I mean that I have a "namespaced" entry such as
$GLOBALS['ericonly']['db'] and put things inside of ericonly. I
basically only use this for database connections and a few other very
specific things.
Aside from that I'm not going to argue the merits of globals. Someone
else can do that as I've made up my mind and so have you. :)
But just to prove that I'm right
http://www.google.com/search?hl=en&q=global+variables+are+evil&btnG=Search
:D
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
