One must use globals in ones classes

[lawrence]

I get the impression that most people who are using objects in their
PHP projects are mixing them with procedural code. The design, I
think, is one where the procedural code is the client code, and the
classes are a library of utility code.

As such, when I've asked about how to get globals into objects, I've
been told that I should pass them in as the parameters to a method.
Easy enough if you have some procedural code. This answer I've been
given assumes that there is something outside of the object, some
procedural code that can get hold of the global and then hand it to
the object.

However, am I wrong in saying that if you wanted to go pure OO, you'd
have to grab the globals from inside of the objects? You could limit
this to the constructor, and possibly you could limit to just a single
master object that contained all other objects, but still, you'd have
to do pull globals straight into the object, yes?

[James Sleeman]

Re: One must use globals in ones classes

lawrence wrote:[color=blue]
> However, am I wrong in saying that if you wanted to go pure OO, you'd
> have to grab the globals from inside of the objects? You could limit
> this to the constructor, and possibly you could limit to just a single
> master object that contained all other objects, but still, you'd have
> to do pull globals straight into the object, yes?[/color]

Basically, you want to limit the use of globals to bare-minimums, globals
are bad mmkay, just one small step from globals to goto :-)

If you absolutely must use globals, best way would be to use
$GLOBAL['varname'] that way there is no mistaking the fact that you are
accessing something in the global scope.

--
James Sleeman
Gogo:Code, http://www.gogo.co.nz/
PHP & Coldfusion Programming Services
Email domain : gogo.co.nz see user in from header!

[Jochen Daum]

Re: One must use globals in ones classes

Hi Lawrence!
On 14 Jul 2003 13:20:24 -0700, lkrubner@geocit ies.com (lawrence)
wrote:
[color=blue]
>I get the impression that most people who are using objects in their
>PHP projects are mixing them with procedural code. The design, I
>think, is one where the procedural code is the client code, and the
>classes are a library of utility code.
>
>As such, when I've asked about how to get globals into objects, I've
>been told that I should pass them in as the parameters to a method.
>Easy enough if you have some procedural code. This answer I've been
>given assumes that there is something outside of the object, some
>procedural code that can get hold of the global and then hand it to
>the object.
>
>However, am I wrong in saying that if you wanted to go pure OO, you'd
>have to grab the globals from inside of the objects? You could limit
>this to the constructor, and possibly you could limit to just a single
>master object that contained all other objects, but still, you'd have
>to do pull globals straight into the object, yes?[/color]

Yes and no.

If you pass the variables as parameters, you control the scope of the
variables well, but the interfaces to your class get bloated. This
makes it hard to change them and hard to test the functions.

If you use globals, you have no control of the scope, ie. you may
overwrite a different variable in another function, because it is
global.

A solution I use is a mediator object, which is
- a proper OO solution (see the Patterns book by Gamma)
- centralizes the control of the global variables into one class. I
use this to create only one object, which allows me to share the same
information and not create any unnecessary objects

A mediator object goes like this:

class mediator{

function &object_instanc e(){

static $instance;
if (!isset($instan ce)){
$instance = new object();
}

return $instance;
}
}


You can put more functions into the object, if you want.

Instead of

global $object;

in a function you now use

$object =& mediator::objec t_instance();


HTH,

jochen

--
Jochen Daum - CANS Ltd.
PHP DB Edit Toolkit -- PHP scripts for building
database editing interfaces.

http://sourceforge.net/projects/phpdbedittk/

[Quinn]

Re: One must use globals in ones classes

I'm finding this thread useful and interesting because it's touching on a
question I had. I'm not a programmer (except in a very amateur sense) and
have never used objects before. But I've just started.

For one application I have an object representing a project (name, contact
name etc etc). The data for the projects is held in a MySQL database. There
is a method that I've written that requires access to a variable and a
function outside the object, and I had a gut feeling this might be bad
programming.

This method writes the object's properties to the database, and having this
method in the object tidies up and simplifies the main code greatly.
However, the method needs access to the db link variable which I've
established outside the object with mysql_connect (this routine is in an
include file that is kept outside of the public_html path). I don't want to
repeat this routine inside the object as it requires the username, password
etc. Also, I have a function (also in an include file - a standard one that
is included on every page) that handles database errors, and so the object
needs to be able to call this function. That means the object becomes
dependent on these include files - is that bad? And if so, is there an
elegant way around this? I guess I could pull out this whole method and put
it in an include file as a function, but that's a little less tidy.

[Bruno Desthuilliers]

Re: One must use globals in ones classes

Quinn wrote:[color=blue]
> I'm finding this thread useful and interesting because it's touching on a
> question I had. I'm not a programmer (except in a very amateur sense) and
> have never used objects before. But I've just started.
>
> For one application I have an object representing a project (name, contact
> name etc etc). The data for the projects is held in a MySQL database. There
> is a method that I've written that requires access to a variable and a
> function outside the object, and I had a gut feeling this might be bad
> programming.
>[/color]
[color=blue]
> This method writes the object's properties to the database, and having this
> method in the object tidies up and simplifies the main code greatly.
> However, the method needs access to the db link variable which I've
> established outside the object with mysql_connect (this routine is in an
> include file that is kept outside of the public_html path). I don't want to
> repeat this routine inside the object as it requires the username, password
> etc. Also, I have a function (also in an include file - a standard one that
> is included on every page) that handles database errors, and so the object
> needs to be able to call this function. That means the object becomes
> dependent on these include files - is that bad? And if so, is there an
> elegant way around this? I guess I could pull out this whole method and put
> it in an include file as a function, but that's a little less tidy.[/color]

Well... An object is behavior + state.

Functions which are really functions (ie : don't have any side effect)
are stateless, they only relie on their input (arguments) and do not
modify any state (static or global variable). I don't see the point of
having these functions as methods of a class (at least in PHP - in some
110% OOPL's, you may not have the choice !-), so keeping them apart from
the object model is quite ok - at least I do it whithout any guilty
feeling !-)

Yes, it makes the objects using these functions dependent of the
includes. No big deal, you'll always have dome dependency somewhere.


Now for your problem, you have an object that depend on a database
connection, and on some database error handling functions. I don't have
much context here, but I can think of basically two ways to manage this
cleanly :

1/ There aren't any relationships at all between the db connection and
the db error handlers : make the db connection a property of the
'project' object (you pass the db connection as an argument to the
constructor), and keep the functions apart.

2/ There is some 'state' relationship between the db connection and the
error handlers : wrap all this in a class, and pass an instance of that
class to the constructor of the 'project' object. An object can be an
attribute of another object.

Now there is nothing as a one-size-fits-all answer...

HTH
Bruno

[Bruno Desthuilliers]

Re: One must use globals in ones classes

lawrence wrote:[color=blue]
> I get the impression that most people who are using objects in their
> PHP projects are mixing them with procedural code. The design, I
> think, is one where the procedural code is the client code, and the
> classes are a library of utility code.[/color]

Right.
[color=blue]
> As such, when I've asked about how to get globals into objects, I've
> been told that I should pass them in as the parameters to a method.
> Easy enough if you have some procedural code. This answer I've been
> given assumes that there is something outside of the object, some
> procedural code that can get hold of the global and then hand it to
> the object.[/color]

Right also.
[color=blue]
> However, am I wrong in saying that if you wanted to go pure OO,[/color]

Just a point : in PHP, you will at least need 2 lines of procedural
code. Guess why ?-) (answer below)

[color=blue]
> you'd
> have to grab the globals from inside of the objects? You could limit
> this to the constructor, and possibly you could limit to just a single
> master object that contained all other objects,[/color]

Not necessarily 'contain', nor 'all other objects'... It can instanciate
some objects that will instanciate others, pass objects to other objects
etc...
[color=blue]
> but still, you'd have
> to do pull globals straight into the object, yes?[/color]

Right. When you have something 'ugly' to do, do it in just one point.
BTW, the singleton pattern (cf Jochen's post in this thread) might be
useful for this 'master' object.

-- 2 lines of procedural code --
<?php
myMasterObject = new MyMasterClass() ;
myMasterObject->run();
?>

How would your classes etc live without at least these 2 lines ?

HTH
Bruno

[Phil Roberts]

Re: One must use globals in ones classes

With total disregard for any kind of safety measures Bruno
Desthuilliers <bdesth.nospam@ removeme.free.f r> leapt forth and
uttered:
[color=blue]
> How would your classes etc live without at least these 2 lines ?
>
> HTH
> Bruno[/color]

Mine only need one line:

new MyObject;

It would be nice if PHP had an auto-run method similar to main() in
Java/C#/C++/etc though.

--
There is no signature.....

[Bruno Desthuilliers]

Re: One must use globals in ones classes

Phil Roberts wrote:[color=blue]
> With total disregard for any kind of safety measures Bruno
> Desthuilliers <bdesth.nospam@ removeme.free.f r> leapt forth and
> uttered:
>
>[color=green]
>>How would your classes etc live without at least these 2 lines ?
>>
>>HTH
>>Bruno[/color]
>
>
> Mine only need one line:
>
> new MyObject;
>[/color]

Got me !-)

Having this kind of side-effects in a constructor is very ugly, but yes,
it works.

Bruno

[Quinn]

Re: One must use globals in ones classes

On Tue, 15 Jul 2003 12:33:32 +0000, Bruno Desthuilliers wrote:
[color=blue]
> Functions which are really functions (ie : don't have any side effect)
> are stateless, they only relie on their input (arguments) and do not
> modify any state (static or global variable). I don't see the point of
> having these functions as methods of a class (at least in PHP - in some
> 110% OOPL's, you may not have the choice !-), so keeping them apart from
> the object model is quite ok - at least I do it whithout any guilty
> feeling !-)[/color]
[color=blue]
> Yes, it makes the objects using these functions dependent of the
> includes. No big deal, you'll always have dome dependency somewhere.[/color]
[color=blue]
>
> Now for your problem, you have an object that depend on a database
> connection, and on some database error handling functions. I don't have
> much context here, but I can think of basically two ways to manage this
> cleanly :[/color]
[color=blue]
> 1/ There aren't any relationships at all between the db connection and
> the db error handlers : make the db connection a property of the
> 'project' object (you pass the db connection as an argument to the
> constructor), and keep the functions apart.[/color]
[color=blue]
> 2/ There is some 'state' relationship between the db connection and the
> error handlers : wrap all this in a class, and pass an instance of that
> class to the constructor of the 'project' object. An object can be an
> attribute of another object.[/color]
[color=blue]
> Now there is nothing as a one-size-fits-all answer...[/color]
[color=blue]
> HTH
> Bruno[/color]

Thanks for the advice. I guess I could always pass that link into the
object as a parameter to the method (I already pass one, telling the mthod
whether to write a new record or update an existing one, though I think
I've worked out a way to do that automatically).

[lawrence]

Re: One must use globals in ones classes

Bruno Desthuilliers <bdesth.nospam@ removeme.free.f r> wrote in message[color=blue]
>[color=green]
> > However, am I wrong in saying that if you wanted to go pure OO,[/color]
>
> Just a point : in PHP, you will at least need 2 lines of procedural
> code. Guess why ?-) (answer below)[/color]

Right. I guess I was assuming that everyone could figure out that much
on their own, but I should have been more clear. On the last 10
websites I've done, the index page has consisted of these 4 lines:


<?php
include("mcIncl udes/mcConfig.php");
runMainLoop();
?>

[lawrence]

Re: One must use globals in ones classes

Jochen Daum <jochen.daum@ca ns.co.nz> wrote in message[color=blue]
> A solution I use is a mediator object, which is
> - a proper OO solution (see the Patterns book by Gamma)
> - centralizes the control of the global variables into one class. I
> use this to create only one object, which allows me to share the same
> information and not create any unnecessary objects
>
> A mediator object goes like this:
>
> class mediator{
>
> function &object_instanc e(){
>
> static $instance;
> if (!isset($instan ce)){
> $instance = new object();
> }
>
> return $instance;
> }
> }
>[/color]

Without a doubt, this seems the correct way to go.