Home » Php » Constructor as a "Reset" Button – PHP

Constructor as a "Reset" Button – PHP

Posted by: admin February 22, 2020 Leave a comment

Q(Question):

I’m having a BLAST writing this app as OOP as PHP allows. It’s one
thing to discuss the dance, but it’s a thing of beauty to see the
performance.

I’m noticing that the constructor is a "reset" switch – just like the
one on the front of my computer. Calling it seems to just dump all of
the old values, free up all of the old resources, and return the object
to a pristine state.

However, I’m a *little* concerned about just using the constructor
willy-nilly like that to reset the object because, several years back, I
had an issue with other programmers who said that my failure to do some
"DIE" commands would result in zombie processes.

The problems never seemed to manifest themselves, but it still caused
the principles to get all up in my grill about it.

Am I setting myself up for zombie processes or other resource-wasting if
I like have a db-connected class and then just BANG reset it with the
constructor. In this particular case, I’m not concerned if "good"
programmers do it this way, but rather – just that I’m not wasting any
resources.

This is the code I use to connect to the database (note the lack of use
of a DIE command):

class bvckvs_database {
//All properties are read-only.
var $Server;
var $DatabaseName;
var $Username;
var $Password;
var $TablePrefix;
var $RecordSQL; // String
var $RecordSet; // Array of Arrays
var $RecordCount; // Integer
var $ErrorMessage; // OK or message
var $oConn; // Database Connection Resource
function bvckvs_database(){
$this->Server=_BVCKVSDBSERVER;
$this->DatabaseName=_BVCKVSDBDATABASE;
$this->Username=_BVCKVSDBUSERNAME;
$this->Password=_BVCKVSDBPASSWORD;
$this->TablePrefix = _BVCKVSUNIQUEPREFIX;
$this->RecordCount = 0;
$this->RecordSet = array();
$this->RecordSQL = "";
$this->ErrorMessage = "OK";
$bVoid = $this->Connect();
}
function Connect(){
$bRetVal = true;
if (!$this->oConn = @mysql_connect($this->Server, $this->Username,
$this->Password)) {
$this->ErrorMessage="Failed to connect to database server.";
$bRetVal = false;
} else {
if (!mysql_selectdb($this->DatabaseName,$this->oConn)) {
$this->ErrorMessage="Failed to select database.";
$bRetVal = false;
} else {
$this->ErrorMessage="OK";
}
}
return $bRetVal;
}

A(Answer):

On Tue, 24 Jul 2007 18:44:02 GMT, Sanders Kaufman <bu***@kaufman.netwrote:

>I’m having a BLAST writing this app as OOP as PHP allows. It’s one
thing to discuss the dance, but it’s a thing of beauty to see the
performance.

I’m noticing that the constructor is a "reset" switch – just like the
one on the front of my computer. Calling it seems to just dump all of
the old values, free up all of the old resources, and return the object
to a pristine state.

Hang on a minute – the constructor is called when creating a new object.
There’s no old values, no old resources – you’re creating a new object.

You may have created other objects of the same class previously – they’ll
probably still be around somewhere.

Perhaps you want a singleton class? This often fits well for databases
resources.


Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

A(Answer):

Andy Hassall wrote:

On Tue, 24 Jul 2007 18:44:02 GMT, Sanders Kaufman <bu***@kaufman.netwrote:

>I’m having a BLAST writing this app as OOP as PHP allows. It’s one
thing to discuss the dance, but it’s a thing of beauty to see the
performance.

I’m noticing that the constructor is a "reset" switch – just like the
one on the front of my computer. Calling it seems to just dump all of
the old values, free up all of the old resources, and return the object
to a pristine state.

Hang on a minute – the constructor is called when creating a new object.
There’s no old values, no old resources – you’re creating a new object.

That’s ONE use for the constructor.

But as Jerry was telling me in the earlier thread (and which proved true
in my implementation), when that class is the parent of another parent
class, only the most childish constructor gets called.

So, suppose I have clsGrandKid, which "extends" clsKid, which in turn is
an extension of "clsMama".

If clsGrandKid has a constructor, then clsKid’s and clsMama’s
constructors don’t get called – not until I manually call them from
within clsGrandKid.

Furthermore, clsGrandKid can call that constructor any time it likes,
and as often as it likes, returning gramma to a pristine state.

It’s just like in real life where a granddaughter just presses a button
and turns her gramma into a little kid again.

Perhaps you want a singleton class? This often fits well for databases
resources.

Singleton’s aren’t really OOP.
They’re great for *simulating* OOP, but it’s just a cheap knock-off.

A(Answer):

..oO(Sanders Kaufman)

>Andy Hassall wrote:

> Hang on a minute – the constructor is called when creating a new object.
There’s no old values, no old resources – you’re creating a new object.

That’s ONE use for the constructor.

It’s the only use. As it’s name suggests – it’s used to create an object
(and a destructor is called while cleaning up, respectively). In PHP the
constructor is more or less just for initialization, in other languages
it’s also used to allocate memory for the new object.

>But as Jerry was telling me in the earlier thread (and which proved true
in my implementation), when that class is the parent of another parent
class, only the most childish constructor gets called.

So, suppose I have clsGrandKid, which "extends" clsKid, which in turn is
an extension of "clsMama".

If clsGrandKid has a constructor, then clsKid’s and clsMama’s
constructors don’t get called – not until I manually call them from
within clsGrandKid.

In PHP, yes. But this doesn’t mean that you’re supposed to call the
parent constructor multiple times or not at all! In PHP you might get
the result you expect, other compilers might kill you for doing that.

> Perhaps you want a singleton class? This often fits well for databases
resources.

Singleton’s aren’t really OOP.

They are perfectly OOP, whenever you have to make sure that there’s
always exactly one (not more, not less) instance of a class. It’s a
quite useful pattern for database objects or – as in my framwork – for
having a global application object. Firstly, it would be fatal if there
would be a second one, secondly, using the Singleton pattern allows
kinda "superglobal" access to the application object from everywhere.

Micha

A(Answer):

Sanders Kaufman wrote:

Andy Hassall wrote:

> Perhaps you want a singleton class? This often fits well for databases
resources.

Singleton’s aren’t really OOP.
They’re great for *simulating* OOP, but it’s just a cheap knock-off.

That was kinda lame for me to say.

Actually, I have a singleton class that is my db class.
It’s aggragated as a property of my abstract base class.

The abstract base class is then used to extend my actual
foundation/framework classes.

A(Answer):

Michael Fesser wrote:

.oO(Sanders Kaufman)

>That’s ONE use for the constructor.

It’s the only use. As it’s name suggests – it’s used to create an object
(and a destructor is called while cleaning up, respectively). In PHP the
constructor is more or less just for initialization, in other languages
it’s also used to allocate memory for the new object.

That was funny.
It took just two sentences for you to contradict yourself.

You’re somewhat correct when you say that it’s "more or less just for
initialization". It is indeed useful for MORE than just initializing
the object. In fact, it’s also pretty good at re-initializing the object.

>If clsGrandKid has a constructor, then clsKid’s and clsMama’s
constructors don’t get called – not until I manually call them from
within clsGrandKid.

In PHP, yes. But this doesn’t mean that you’re supposed to call the
parent constructor multiple times or not at all! In PHP you might get
the result you expect, other compilers might kill you for doing that.

Yeah – that’s why I said in my OP that I’m not concerned, in this
particular case, with how "good" programmers do it. I just need to know
if, in doing so, I’m exposing myself to a threat from something like
Zombie processes.

It’s a
quite useful pattern for database objects or – as in my framwork – for
having a global application object. Firstly, it would be fatal if there
would be a second one, secondly, using the Singleton pattern allows
kinda "superglobal" access to the application object from everywhere.

One of my core design principles at this stage is to avoid having a
global application object. This foundation/framework that I’m building
is to be used to *create* such objects… but not to be one in and of
itself. Also, I maximize its value if I can keep the features atomic
enough to be implemented independent of the framework as a whole.

So building it around a global application object would be a mistake for
this particular project.

I am, however, simultaneously developing a reference model for this
foundation/framework and it IS a global application object.

btw – this project I’m working on is a HIPPA thing. If any of you guys
out there are looking for work – go to the local hospital’s IT
department. There’s some HUGE ka-ching out there!

But don’t do it in Dallas. This is MY turf. 😉

A(Answer):

On Jul 24, 5:03 pm, Sanders Kaufman <bu…@kaufman.netwrote:

Michael Fesser wrote:

.oO(Sanders Kaufman)

That’s ONE use for the constructor.

It’s the only use. As it’s name suggests – it’s used to create an object
(and a destructor is called while cleaning up, respectively). In PHP the
constructor is more or less just for initialization, in other languages
it’s also used to allocate memory for the new object.

That was funny.
It took just two sentences for you to contradict yourself.

You’re somewhat correct when you say that it’s "more or less just for
initialization". It is indeed useful for MORE than just initializing
the object. In fact, it’s also pretty good at re-initializing the object.

So are you suggesting that you call the constructor from elsewhere in
the class (or even explicitly from outside the class)? That’s just
poor form. The constructor should be used for one thing only:
constructing a new instance of a class.

If you want to "reset" the object, then you separate that out into its
own method and call it from the constructor — similar to what you’ve
done with the Connect() method.

I’m firmly with Micha on this one.

A(Answer):

ZeldorBlat wrote:

On Jul 24, 5:03 pm, Sanders Kaufman <bu…@kaufman.netwrote:

>Michael Fesser wrote:

>You’re somewhat correct when you say that it’s "more or less just for
initialization". It is indeed useful for MORE than just initializing
the object. In fact, it’s also pretty good at re-initializing the object.

So are you suggesting that you call the constructor from elsewhere in
the class (or even explicitly from outside the class)? That’s just
poor form. The constructor should be used for one thing only:
constructing a new instance of a class.

Yeah – that’s why, in my original post, I said that for this particular
situation, I’m not concerned with what a "good" programmer would do.

My focus is on if it will result in wasted resources and zombie processes.

If you want to "reset" the object, then you separate that out into its
own method and call it from the constructor — similar to what you’ve
done with the Connect() method.

It ain’t good form to write redundant code.
It’s wasteful, inefficient, and is abhorrent to good OOP architecture.
Indeed – the most powerful reason for using OOP is to be able to write a
process once, and then to use it over and over and over, and in a
variety of creative ways.

Besides and again… my focus here is on not wasting resources
unnecessarily.

A(Answer):

Sanders Kaufman wrote:

>The constructor should be used for one thing only: constructing a new
instance of a class.

Yeah – that’s why, in my original post, I said that for this particular
situation, I’m not concerned with what a "good" programmer would do.

My focus is on if it will result in wasted resources and zombie processes.

No. PHP garbage collector is quite effective.

However, the main problem you’ll be facing is that this feature* may (and
should) be removed from future versions of PHP. Your scripts will start
throwing strange, hard-to-locate errors.

I’m talking from my own experience: once in a time, I did something along
the lines of "$this = unserialize($foo);". The """feature""" of assigning
$this was fixed in PHP5.
* = Other programmers will say that being able to explicitly call the
constructor is a bug in the parser/compiler, and I’m with them.

Indeed – the most powerful reason for using OOP is to be able to write a
process once, and then to use it over and over and over, and in a
variety of creative ways.

Those "creative ways" are called "design patterns". Go read the book.
Seriously. Buy it and read it.

Please don’t neglect being a good programmer.

Besides and again… my focus here is on not wasting resources
unnecessarily.

Go program a CGI in assembler, then 😛


———————————-
Iván Sánchez Ortega -ivansanchez-algarroba-escomposlinux-punto-org-

http://acm.asoc.fi.upm.es/~mr/
Proudly running Debian Linux with 2.6.20-1-amd64 kernel, KDE 3.5.7, and PHP
5.2.3-1+b1 generating this signature.
Uptime: 01:11:13 up 39 days, 8:46, 5 users, load average: 1.11, 1.78,
1.85

A(Answer):

Sanders Kaufman wrote:

Andy Hassall wrote:

>On Tue, 24 Jul 2007 18:44:02 GMT, Sanders Kaufman <bu***@kaufman.net>
wrote:

>>I’m having a BLAST writing this app as OOP as PHP allows. It’s one
thing to discuss the dance, but it’s a thing of beauty to see the
performance.

I’m noticing that the constructor is a "reset" switch – just like the
one on the front of my computer. Calling it seems to just dump all
of the old values, free up all of the old resources, and return the
object to a pristine state.

Hang on a minute – the constructor is called when creating a new object.
There’s no old values, no old resources – you’re creating a new object.

That’s ONE use for the constructor.

As Andy said – that should be the ONLY USE for the constructor. If you
need to reinitialize the object, create a reinitialize() function.

But as Jerry was telling me in the earlier thread (and which proved true
in my implementation), when that class is the parent of another parent
class, only the most childish constructor gets called.

True. But it is the child class’s responsibility to call the parent
class’s constructor – which it should ALWAYS do. Other languages do it
automatically; PHP is lagging in this respect.

So, suppose I have clsGrandKid, which "extends" clsKid, which in turn is
an extension of "clsMama".

If clsGrandKid has a constructor, then clsKid’s and clsMama’s
constructors don’t get called – not until I manually call them from
within clsGrandKid.

But they NEED to get called.

Furthermore, clsGrandKid can call that constructor any time it likes,
and as often as it likes, returning gramma to a pristine state.

No, that’s NOT the purpose of a constructor!

It’s just like in real life where a granddaughter just presses a button
and turns her gramma into a little kid again.

Not at all the same.

>

> Perhaps you want a singleton class? This often fits well for databases
resources.

Singleton’s aren’t really OOP.
They’re great for *simulating* OOP, but it’s just a cheap knock-off.

Yes, singletons are quite OOP.


==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

A(Answer):

Sanders Kaufman wrote:

Michael Fesser wrote:

>.oO(Sanders Kaufman)

>>That’s ONE use for the constructor.

It’s the only use. As it’s name suggests – it’s used to create an object
(and a destructor is called while cleaning up, respectively). In PHP the
constructor is more or less just for initialization, in other languages
it’s also used to allocate memory for the new object.

That was funny.
It took just two sentences for you to contradict yourself.

There was no contradiction in what he said.

You’re somewhat correct when you say that it’s "more or less just for
initialization". It is indeed useful for MORE than just initializing
the object. In fact, it’s also pretty good at re-initializing the object.

As he said – it is the ONLY use.

>

>>If clsGrandKid has a constructor, then clsKid’s and clsMama’s
constructors don’t get called – not until I manually call them from
within clsGrandKid.

In PHP, yes. But this doesn’t mean that you’re supposed to call the
parent constructor multiple times or not at all! In PHP you might get
the result you expect, other compilers might kill you for doing that.

Yeah – that’s why I said in my OP that I’m not concerned, in this
particular case, with how "good" programmers do it. I just need to know
if, in doing so, I’m exposing myself to a threat from something like
Zombie processes.

It’s how ANY programmer should be doing it.

When you use a system function incorrectly, you run into all kinds of
potential problems.

>

>It’s a
quite useful pattern for database objects or – as in my framwork – for
having a global application object. Firstly, it would be fatal if there
would be a second one, secondly, using the Singleton pattern allows
kinda "superglobal" access to the application object from everywhere.

One of my core design principles at this stage is to avoid having a
global application object. This foundation/framework that I’m building
is to be used to *create* such objects… but not to be one in and of
itself. Also, I maximize its value if I can keep the features atomic
enough to be implemented independent of the framework as a whole.

There is nothing wrong with a global application object. It’s not the
same as global variables. Singletons are quite common for things like this.

So building it around a global application object would be a mistake for
this particular project.

Or not building it around a global application object could be a
mistake. It depends on what you’re doing.

I am, however, simultaneously developing a reference model for this
foundation/framework and it IS a global application object.

btw – this project I’m working on is a HIPPA thing. If any of you guys
out there are looking for work – go to the local hospital’s IT
department. There’s some HUGE ka-ching out there!

But don’t do it in Dallas. This is MY turf. 😉

And you have to be HIPPA certified to do it. And HIPPA certification is
not easy – nor is it cheap.


==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

A(Answer):

Sanders Kaufman wrote:

ZeldorBlat wrote:

>On Jul 24, 5:03 pm, Sanders Kaufman <bu…@kaufman.netwrote:

>>Michael Fesser wrote:

>>You’re somewhat correct when you say that it’s "more or less just for
initialization". It is indeed useful for MORE than just initializing
the object. In fact, it’s also pretty good at re-initializing the
object.

So are you suggesting that you call the constructor from elsewhere in
the class (or even explicitly from outside the class)? That’s just
poor form. The constructor should be used for one thing only:
constructing a new instance of a class.

Yeah – that’s why, in my original post, I said that for this particular
situation, I’m not concerned with what a "good" programmer would do.

My focus is on if it will result in wasted resources and zombie processes.

>If you want to "reset" the object, then you separate that out into its
own method and call it from the constructor — similar to what you’ve
done with the Connect() method.

It ain’t good form to write redundant code.
It’s wasteful, inefficient, and is abhorrent to good OOP architecture.
Indeed – the most powerful reason for using OOP is to be able to write a
process once, and then to use it over and over and over, and in a
variety of creative ways.

Besides and again… my focus here is on not wasting resources
unnecessarily.

Read what he said. There is no redundant code.


==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

A(Answer):

Iván Sánchez Ortega wrote:

Sanders Kaufman wrote:

>Besides and again… my focus here is on not wasting resources
unnecessarily.

Go program a CGI in assembler, then 😛

That’s not part of the spec – and would be a HUGE waste of my resources.
But for that – you would have some great advice there.

A(Answer):

Jerry Stuckle wrote:

Sanders Kaufman wrote:

>That’s ONE use for the constructor.

As Andy said – that should be the ONLY USE for the constructor. If you
need to reinitialize the object, create a reinitialize() function.

Why is that?
It seems quite redundant.

True. But it is the child class’s responsibility to call the parent
class’s constructor – which it should ALWAYS do. Other languages do it
automatically; PHP is lagging in this respect.

In not real good about doing things just ’cause people keep saying
"should" a lot. If I was, I’d be toting a 50 cal in Iraq, instead of
drinking cappuccino in Dallas.

>Furthermore, clsGrandKid can call that constructor any time it likes,
and as often as it likes, returning gramma to a pristine state.

No, that’s NOT the purpose of a constructor!

But that is how it works, and doing it that way does seem to simplify
the code.

When I first started coding, a fellow named John Silver, here in Dallas
gave me my first glimpse of OOP when he told me his rule of thumb: "If
you find yourself performing the same procedure more than once, write a
function and use that instead."

It’s GREAT advice and I haven’t found a good reason yet to violate that
rule – unless you count a couple of knowledgable, control-freaks who say
that I "should".

A(Answer):

Jerry Stuckle wrote:

Sanders Kaufman wrote:

>>If you want to "reset" the object, then you separate that out into its
own method and call it from the constructor — similar to what you’ve
done with the Connect() method.

It ain’t good form to write redundant code.
It’s wasteful, inefficient, and is abhorrent to good OOP architecture.
Indeed – the most powerful reason for using OOP is to be able to write
a process once, and then to use it over and over and over, and in a
variety of creative ways.

Besides and again… my focus here is on not wasting resources
unnecessarily.

Read what he said. There is no redundant code.

All the code I need to initialize and reinitialize my class is in the
constructor.

class baseclass {
var $Database;
var $ErrorMessage;
var $RecordSet;
function bvckvs_baseclass(){
$this->RecordSet = array();
$this->Database = new bvckvs_database();
$this->ErrorMessage = $this->Database->ErrorMessage;
return true;
}
}

If I were to write a "reinit()" it would do exactly the same thing.
How is that not redundant?

A(Answer):

Sanders Kaufman wrote:

Jerry Stuckle wrote:

>Sanders Kaufman wrote:

>>>If you want to "reset" the object, then you separate that out into its
own method and call it from the constructor — similar to what you’ve
done with the Connect() method.

It ain’t good form to write redundant code.
It’s wasteful, inefficient, and is abhorrent to good OOP architecture.
Indeed – the most powerful reason for using OOP is to be able to
write a process once, and then to use it over and over and over, and
in a variety of creative ways.

Besides and again… my focus here is on not wasting resources
unnecessarily.

Read what he said. There is no redundant code.

All the code I need to initialize and reinitialize my class is in the
constructor.

class baseclass {
var $Database;
var $ErrorMessage;
var $RecordSet;
function bvckvs_baseclass(){
$this->RecordSet = array();
$this->Database = new bvckvs_database();
$this->ErrorMessage = $this->Database->ErrorMessage;
return true;
}
}

If I were to write a "reinit()" it would do exactly the same thing.
How is that not redundant?

And it is incorrect to do it this way, and will eventually cause you
problems.

What happens, for instance, if PHP changes so that the base class
constructor is called automatically?

There is no replacement for good programming – and no excuse for sloppy
programming.


==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

A(Answer):

Sanders Kaufman wrote:

Jerry Stuckle wrote:

>Sanders Kaufman wrote:

>>That’s ONE use for the constructor.

As Andy said – that should be the ONLY USE for the constructor. If
you need to reinitialize the object, create a reinitialize() function.

Why is that?
It seems quite redundant.

Two different functions for two different purposes.

>

>True. But it is the child class’s responsibility to call the parent
class’s constructor – which it should ALWAYS do. Other languages do
it automatically; PHP is lagging in this respect.

In not real good about doing things just ’cause people keep saying
"should" a lot. If I was, I’d be toting a 50 cal in Iraq, instead of
drinking cappuccino in Dallas.

Then don’t bother asking for any more advice.

>

>>Furthermore, clsGrandKid can call that constructor any time it likes,
and as often as it likes, returning gramma to a pristine state.

No, that’s NOT the purpose of a constructor!

But that is how it works, and doing it that way does seem to simplify
the code.

When I first started coding, a fellow named John Silver, here in Dallas
gave me my first glimpse of OOP when he told me his rule of thumb: "If
you find yourself performing the same procedure more than once, write a
function and use that instead."

It’s GREAT advice and I haven’t found a good reason yet to violate that
rule – unless you count a couple of knowledgable, control-freaks who say
that I "should".

Exactly. And we’re not telling you do do that.


==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

A(Answer):

On Wed, 25 Jul 2007 03:58:49 +0200, Sanders Kaufman <bu***@kaufman.net
wrote:

Jerry Stuckle wrote:

>Sanders Kaufman wrote:

>>>If you want to "reset" the object, then you separate that out into its
own method and call it from the constructor — similar to what you’ve
done with the Connect() method.

It ain’t good form to write redundant code.
It’s wasteful, inefficient, and is abhorrent to good OOP architecture.
Indeed – the most powerful reason for using OOP is to be able to write
a process once, and then to use it over and over and over, and in a
variety of creative ways.

Besides and again… my focus here is on not wasting resources
unnecessarily.

Read what he said. There is no redundant code.

All the code I need to initialize and reinitialize my class is in the
constructor.

class baseclass {
var $Database;
var $ErrorMessage;
var $RecordSet;
function bvckvs_baseclass(){
$this->RecordSet = array();
$this->Database = new bvckvs_database();
$this->ErrorMessage = $this->Database->ErrorMessage;
return true;
}
}

If I were to write a "reinit()" it would do exactly the same thing.
How is that not redundant?

class baseclass{
var $foo;
function baseclass(){
$this->init();
}
function init(){
$this->foo = ‘bar’;
}
}

//instantiating
$obj = new baseclass();
//altering
$obj->foo = ‘foz’;
//reinitializing
$obj->init();

Rik Wasmus

A(Answer):

On Jul 24, 9:58 pm, Sanders Kaufman <bu…@kaufman.netwrote:

Jerry Stuckle wrote:

Sanders Kaufman wrote:

>If you want to "reset" the object, then you separate that out into its
own method and call it from the constructor — similar to what you’ve
done with the Connect() method.

It ain’t good form to write redundant code.
It’s wasteful, inefficient, and is abhorrent to good OOP architecture.
Indeed – the most powerful reason for using OOP is to be able to write
a process once, and then to use it over and over and over, and in a
variety of creative ways.

Besides and again… my focus here is on not wasting resources
unnecessarily.

Read what he said. There is no redundant code.

All the code I need to initialize and reinitialize my class is in the
constructor.

class baseclass {
var $Database;
var $ErrorMessage;
var $RecordSet;
function bvckvs_baseclass(){
$this->RecordSet = array();
$this->Database = new bvckvs_database();
$this->ErrorMessage = $this->Database->ErrorMessage;
return true;
}

}

If I were to write a "reinit()" it would do exactly the same thing.
How is that not redundant?

Because you move don’t duplicate the functionality — you move it to
it’s own method and call that from the constructor. That way you
don’t need to call the constructor to reset things, and you don’t need
to duplicate any code. That’s what we’ve been trying to say all along
— but you haven’t seemed to have caught on.

class baseclass {
var $Database;
var $ErrorMessage;
var $RecordSet;

function bvckvs_baseclass(){
$this->reinit();
}

function reinit() {
$this->RecordSet = array();
$this->Database = new bvckvs_database();
$this->ErrorMessage = $this->Database->ErrorMessage;
}
}

A(Answer):

On Wed, 25 Jul 2007 04:33:22 +0200, ZeldorBlat <ze********@gmail.com>
wrote:

class baseclass {
var $Database;
var $ErrorMessage;
var $RecordSet;

function bvckvs_baseclass(){
$this->reinit();
}

function reinit() {
}
}

Hehe, let’s just say great minds think alike 😛

Rik Wasmus

A(Answer):

Jerry Stuckle wrote:

Sanders Kaufman wrote:

And what happens when your server upgrades to PHP5.2 or PHP6 or
whatever? They’re not going to be on PHP4 forever, you know.

"They" are "me" – and we’v all agreed to develop this in and for PHP4…
since that’s how we all started it.

Later, if it looks like the product is worth its’ while, we’ll all get
together and figure out if and how to port it to PHP5 or PERL or .NET or
whatever else there is.

The best way to please the end user is to write good – not sloppy – code.

Man, do I ever wish THAT was true!

A(Answer):

Rik wrote:

On Wed, 25 Jul 2007 03:58:49 +0200, Sanders Kaufman <bu***@kaufman.net>

>If I were to write a "reinit()" it would do exactly the same thing.
How is that not redundant?

class baseclass{
var $foo;
function baseclass(){
$this->init();
}
function init(){
$this->foo = ‘bar’;
}
}

Yeah – I got that that’s HOW to do it. That’s easy.
I’m wondering WHY to do it.

The best answer came from Jerry when he said it was for purely academic
reasons – to keep tight with the OOP design principles.

And while I do want to keep it as OOPish as is feasible, I don’t want to
introduce any extra functions that are not needed.

Since PHP4 (and apparently 5, as well) doesn’t make the constructor a
private function, I don’t yet see any reason to NOT use it as a
reset-switch for my object; to return it to a pristine state.

I did have a mild concern that it could result in something called a
Zombie process, or that resources would be locked that don’t need to be,
but another poster assured me (and my experience confirms) that the PHP
garbage collection process is very efficient about not letting that happen.

A(Answer):

ZeldorBlat wrote:

Because you move don’t duplicate the functionality — you move it to
it’s own method and call that from the constructor. That way you
don’t need to call the constructor to reset things, and you don’t need
to duplicate any code. That’s what we’ve been trying to say all along
— but you haven’t seemed to have caught on.

Oh, I get it.
I just don’t see a reason to do it that way.

In fact – that particular way actually seems even MORE unnecessarily
complex than the one the other guy provided where my "init()" function
would call the constructor.

In your case, every time my object is initialized, it would make TWO
function calls, instead of one – one to the constructor, and one to the
init().

That violates a core design principle – that it be very scalable; and
that means that it must not use resources unnecessarily.

A(Answer):

..oO(Sanders Kaufman)

>Yeah – I got that that’s HOW to do it. That’s easy.
I’m wondering WHY to do it.

Correctness? Stability? Style? Reliability?

>The best answer came from Jerry when he said it was for purely academic
reasons – to keep tight with the OOP design principles.

And while I do want to keep it as OOPish as is feasible, I don’t want to
introduce any extra functions that are not needed.

Since PHP4 (and apparently 5, as well) doesn’t make the constructor a
private function

In PHP 5 you could make it private if you want.

>I don’t yet see any reason to NOT use it as a
reset-switch for my object; to return it to a pristine state.

A constructor is not a normal method and should not be seen as that.
Do you know for sure what PHP does internally when calling it? I don’t.

"Abusing" it in the way that you do is not only _really_ bad style, but
might also cause problems for simple technical reasons.

>I did have a mild concern that it could result in something called a
Zombie process, or that resources would be locked that don’t need to be,

Why are you always referring to such zombie processes? Forget that.
That’s not an issue here (and shouldn’t be an issue with PHP at all).

Micha

A(Answer):

..oO(Sanders Kaufman)

>Jerry Stuckle wrote:

>True. But it is the child class’s responsibility to call the parent
class’s constructor – which it should ALWAYS do. Other languages do it
automatically; PHP is lagging in this respect.

In not real good about doing things just ’cause people keep saying
"should" a lot.

You could also

* disable error_reporting while developing
* rely on register_globals
* always use @ to supress errors
* don’t check return values of DB functions
* don’t sanitize data before it goes into the DB
* …

Every experienced programmer will tell you that you should not do these
things (of course you’re free to ignore that). Calling a constructor in
a way it’s not meant to be called is just another point on that list.

>No, that’s NOT the purpose of a constructor!

But that is how it works, and doing it that way does seem to simplify
the code.

It _might_ work, but might also open a can of worms. You’re calling for
unpredictable results. If you like that, then go with your "simplified
code".

I’m out of this thread.

EOT
Micha

A(Answer):

Sanders Kaufman wrote:

I’m noticing that the constructor is a "reset" switch – just like the
one on the front of my computer. Calling it seems to just dump all of
the old values, free up all of the old resources, and return the object
to a pristine state.

Yes, you can do this, but it’s a bit of a hack. Better to use something
like:

class Foobar
{
public $var1;
public $var2;

public function __construct ($foo, $bar)
{
$this->reset($foo, $bar);
// Now maybe do some other stuff
}

public function reset ($foo, $bar)
{
$this->var1 = $foo;
$this->var2 = $bar;
}
}


Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.12-12mdksmp, up 34 days, 12:16.]

Cryptography Challenge
http://tobyinkster.co.uk/blog/2007/0…pto-challenge/

A(Answer):

Michael Fesser wrote:

They are perfectly OOP, whenever you have to make sure that there’s
always exactly one (not more, not less) instance of a class.

I agree with Sanders here: they’re inconsistent with OOP theory. They’re
basically just glorified globals wrapped up in a class-oriented syntax.

Of course, they’re useful as hell — just like globals and gotos and all
those other dirty little pleasures that programmers use when no-one’s
watching.


Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.12-12mdksmp, up 34 days, 13:01.]

Cryptography Challenge
http://tobyinkster.co.uk/blog/2007/0…pto-challenge/

A(Answer):

Sanders Kaufman wrote:

If I were to write a "reinit()" it would do exactly the same thing.

You don’t write a "reinit()" and do exactly the same thing in it. You
rename your constructor to "reinit()" and then create a new, one-line
constructor which just does "$this->reinit();".


Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.12-12mdksmp, up 34 days, 13:07.]

Cryptography Challenge
http://tobyinkster.co.uk/blog/2007/0…pto-challenge/

A(Answer):

Sanders Kaufman wrote:

The best answer came from Jerry when he said it was for purely academic
reasons – to keep tight with the OOP design principles.

How about this… what happens when one day you decide that your
constructor should do something over and above what the reset function
does?

For example, your reset function might want to just reset the object to
its initial state, but the constructor might also want to log some
debugging messages to a file.


Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.12-12mdksmp, up 34 days, 13:13.]

Cryptography Challenge
http://tobyinkster.co.uk/blog/2007/0…pto-challenge/

A(Answer):

Sanders Kaufman wrote:

In your case, every time my object is initialized, it would make TWO
function calls, instead of one – one to the constructor, and one to the
init().

http://www.google.co.uk/search?q=premature+optimisation

For heaven’s sake, this is a *database* class. The overhead of an extra
function call is the *least* of your worries.

Whenever you have to choose between code efficiency and readability,
choose readability: development time is more expensive than CPU time.


Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.12-12mdksmp, up 34 days, 13:16.]

Cryptography Challenge
http://tobyinkster.co.uk/blog/2007/0…pto-challenge/

A(Answer):

..oO(Toby A Inkster)

>Michael Fesser wrote:

>They are perfectly OOP, whenever you have to make sure that there’s
always exactly one (not more, not less) instance of a class.

I agree with Sanders here: they’re inconsistent with OOP theory.

OK, but IMHO that’s just a philosophical problem.

Micha

A(Answer):

Michael Fesser wrote:

.oO(Toby A Inkster)

>Michael Fesser wrote:

>>They are perfectly OOP, whenever you have to make sure that there’s
always exactly one (not more, not less) instance of a class.

I agree with Sanders here: they’re inconsistent with OOP theory.

OK, but IMHO that’s just a philosophical problem.

Micha

Yes, it’s a philosophical problem, but I don’t see anything in OOP
theory which rules out singletons. In fact, I think OO helps with
singletons.

After all – a singleton is part of the implementation of that class.
The fact it is a singleton is hidden from the rest of the code. And if
you change the code so that it’s no longer a singleton, it doesn’t
affect any of the rest of the code (as long as you don’t run out of
external resources).


==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

A(Answer):

Toby A Inkster wrote:

Sanders Kaufman wrote:

>I’m noticing that the constructor is a "reset" switch – just like the
one on the front of my computer. Calling it seems to just dump all of
the old values, free up all of the old resources, and return the object
to a pristine state.

Yes, you can do this, but it’s a bit of a hack. Better to use something
like:

class Foobar
{
public $var1;
public $var2;

public function __construct ($foo, $bar)
{
$this->reset($foo, $bar);
// Now maybe do some other stuff
}

public function reset ($foo, $bar)
{
$this->var1 = $foo;
$this->var2 = $bar;
}
}

That is most certainly how I will do it in PHP5 – if it turns out that
the project is worth it’s while.

A(Answer):

Toby A Inkster wrote:

Sanders Kaufman wrote:

>If I were to write a "reinit()" it would do exactly the same thing.

You don’t write a "reinit()" and do exactly the same thing in it. You
rename your constructor to "reinit()" and then create a new, one-line
constructor which just does "$this->reinit();".

That would result in TWO function calls, every time the object is
created – the semi-automatic one to the constructor, and then the
reninit() that’s called BY the constructor.

That violates a core design principle – that it not use resources
unnecessarily.

A(Answer):

Toby A Inkster wrote:

Sanders Kaufman wrote:

>The best answer came from Jerry when he said it was for purely academic
reasons – to keep tight with the OOP design principles.

How about this… what happens when one day you decide that your
constructor should do something over and above what the reset function
does?

For example, your reset function might want to just reset the object to
its initial state, but the constructor might also want to log some
debugging messages to a file.

I think that in that particular case, I would allow both functions to
log the debug messages.

I see what you’re saying – but I don’t forsee a situation where I would
have the two perform in different ways – not with my programming style,
anyway. If that were to change, I’d probably add a boolean "DebugMode"
parameter to the constructor.

A(Answer):

Toby A Inkster wrote:

Sanders Kaufman wrote:

>In your case, every time my object is initialized, it would make TWO
function calls, instead of one – one to the constructor, and one to the
init().

http://www.google.co.uk/search?q=premature+optimisation

For heaven’s sake, this is a *database* class. The overhead of an extra
function call is the *least* of your worries.

Yeah – it’s not the biggest performance hit ever, is it?
But a core design principle is to not use resources unnecessarily – so
calling TWO functions each time an object is created would violate that
principle.

OOP design principles are a *desirable* thing – but performance is an
imperative.

Whenever you have to choose between code efficiency and readability,
choose readability: development time is more expensive than CPU time.

I don’t see it as being LESS readable.

Indeed, by calling it directly – instead of calling a reinit that calls
the constructor (or vice versa) it actually reduces the complexity of
the readability.

A(Answer):

Michael Fesser wrote:

.oO(Toby A Inkster)

>Michael Fesser wrote:

>>They are perfectly OOP, whenever you have to make sure that there’s
always exactly one (not more, not less) instance of a class.

I agree with Sanders here: they’re inconsistent with OOP theory.

OK, but IMHO that’s just a philosophical problem.

Word!
That’s why, in my Original Post, I said that I was not concerned with
how "good" programmers would do it, but rather – if it would result in
wasted resources.

Interestingly, and surprisingly, I find that a great many of the most
expert programmers would choose to waste resources.

A(Answer):

..oO(Sanders Kaufman)

>Negligible – I love that word. Sure, the inefficiency is there, and
sure, it’s small.
Maybe that should be my marketing slogan – "It’s only a *little*
inefficient".

Well, when printing that out, you better use

print ‘It\’s only a *little* inefficient’;

instead of

print "It’s only a *little* inefficient";

because the first is more efficient.

SCNR
Micha

A(Answer):

Michael Fesser wrote:

.oO(Sanders Kaufman)

>Maybe that should be my marketing slogan – "It’s only a *little*
inefficient".

Well, when printing that out, you better use
print ‘It\’s only a *little* inefficient’;
instead of
print "It’s only a *little* inefficient";
because the first is more efficient.

Well, shucks! I know you were being funny, but that’s a darned good
point – and I’m gonna do that from now on.

In fact, I’m gonna go back through my code and make sure I did my
strings that way.

I had the same problem with SQL about a year back. I always used
double-quotes, instead of single-quotes – and I even thought it was
supposed to be that way from the ANSI standard. Then a DBA showed me
just how wrong I was.

Been writing SQL for a couple of decades, and PHP for almost one – but I
still get some of the most fundamental stuff ALL wrong.

Thanks, dude.

A(Answer):

..oO(Sanders Kaufman)

>Interestingly, and surprisingly, I find that a great many of the most
expert programmers would choose to waste resources.

Of course we do. Modern programming is all about "wasting" resources.
The more abstract the concept or paradigm, the more resources are
required to make it working and get it down to the machine level.

But that’s just the one side of the story. The other side is all the
benefits and advantages you’ll get from these "wasted" resources. It
turns out that it’s not a waste at all, since you get much more back
than you have to invest. If not today, then tomorrow.

Micha

A(Answer):

Sanders Kaufman wrote:

>>Besides and again… my focus here is on not wasting resources
unnecessarily.

Go program a CGI in assembler, then 😛

That’s not part of the spec – and would be a HUGE waste of my resources.

On the contrary – assembler is the *only* way to optimize resources to the
maximum.


———————————-
Iván Sánchez Ortega -ivansanchez-algarroba-escomposlinux-punto-org-

Troubled day for virgins over 16 who are beautiful and wealthy and live
in eucalyptus trees.

A(Answer):

Sanders Kaufman wrote:

Since PHP4 (and apparently 5, as well) doesn’t make the constructor a
private function, I don’t yet see any reason to NOT use it as a
reset-switch for my object; to return it to a pristine state.

Declaring the constructor as private prevents the programmer from
instantiating the class outside the class scope. Go read the Singleton
pattern.


———————————-
Iván Sánchez Ortega -ivansanchez-algarroba-escomposlinux-punto-org-

http://acm.asoc.fi.upm.es/~mr/ ; http://acm.asoc.fi.upm.es/~ivan/
MSN:i_*************************@hotmail.com
Jabber:iv*********@jabber.org ; iv*********@kdetalk.net

A(Answer):

Iván Sánchez Ortega wrote:

Sanders Kaufman wrote:

>>>Besides and again… my focus here is on not wasting resources
unnecessarily.
Go program a CGI in assembler, then 😛

That’s not part of the spec – and would be a HUGE waste of my resources.

On the contrary – assembler is the *only* way to optimize resources to the
maximum.

That’s just nuts.

A(Answer):

Iván Sánchez Ortega wrote:

Sanders Kaufman wrote:

>Since PHP4 (and apparently 5, as well) doesn’t make the constructor a
private function, I don’t yet see any reason to NOT use it as a
reset-switch for my object; to return it to a pristine state.

Declaring the constructor as private prevents the programmer from
instantiating the class outside the class scope. Go read the Singleton
pattern.

There is no way to declare a constructor as private in PHP4.

A(Answer):

Sanders Kaufman wrote:

>On the contrary – assembler is the *only* way to optimize resources to
the maximum.

That’s just nuts.

Why?


———————————-
Iván Sánchez Ortega -ivansanchez-algarroba-escomposlinux-punto-org-

Un ordenador no es un televisor ni un microondas, es una herramienta
compleja.

A(Answer):

Jerry Stuckle wrote:

Yes, it’s a philosophical problem, but I don’t see anything in OOP
theory which rules out singletons.

http://code.google.com/p/google-sing…eControversial


Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.12-12mdksmp, up 35 days, 1:01.]

Cryptography Challenge
http://tobyinkster.co.uk/blog/2007/0…pto-challenge/

A(Answer):

Iván Sánchez Ortega wrote:

Sanders Kaufman wrote:

>>On the contrary – assembler is the *only* way to optimize resources to
the maximum.

That’s just nuts.

Why?

Are you familiar with the law of diminishing returns? Your "optimum"
solution ignores the fact that my time is one of the resources.

I can afford to spend a few days chit-chatting about the nuances of OOP,
and still get the project out in a reasonable amount of time.

But I can’t afford to spend a few years on your "optimal" solution.

It lauches past quick and dirty, crests beyond optimal, and diminishes
into the sunset of "someday" and "maybe".

A(Answer):

Toby A Inkster wrote:

Jerry Stuckle wrote:

>Yes, it’s a philosophical problem, but I don’t see anything in OOP
theory which rules out singletons.

http://code.google.com/p/google-sing…eControversial

It seems to me that back in the SmallTalk days, I was in a conversation
with some folks about this.

They were talking about how there’s two kinds of OOP here. One is
Object *Oriented* and the other was something like "object-centric" or
"object-related" or something like that.

It’s like how there’s HTML Strict, and HTML something else.

Anybody know what I’m talking about?

A(Answer):

Toby A Inkster wrote:

Jerry Stuckle wrote:

>Yes, it’s a philosophical problem, but I don’t see anything in OOP
theory which rules out singletons.

http://code.google.com/p/google-sing…eControversial

Hi, Toby,

Yes, I’ve seen such arguments. But none of them indicate a violation of
OOP theory. Rather they are geared more towards poor programming practices.

And I could tear a lot of their arguments apart – i.e.

"When one class uses a singleton (and I’m talking about a classic
singleton, one that enforces it own singularity thorough a static
getInstance() method), the singleton user and the singleton become
inextricably coupled together. It is no longer possible to test the user
without also testing the singleton."

Well, that’s true whether it’s a singleton class or not. If you have a
class MyData which depends on a MyDatabase class, for instance, you will
not be able to test MyData without having MyDatabase available. And you
will be testing MyDatabase also, whether it is a singleton or not.

You can pass an object in the constructor. It does have some
advantages, as noted by others. But it also has the disadvantage that
the code which creates your class must know more about your class’s
implementation, i.e.

$p = new MyData($instanceOfMyDatabase);

So while arguably you have loosened the coupling between MyData and
MyDatabase, there is tighter coupling between MyData and the creator.

There are a lot of other things which could be argued both ways –
because this (and the attached articles) is an opinion on a
philosophical issue.

Now – don’t get me wrong. I’m not saying whether I agree or disagree
with what they say – just that this is a philosophical discussion. It’s
not that much different than global variables in structured programming.
They are frowned upon – but there’s nothing in structured programming
theory which rules them out. And there’s nothing in OO theory which
rules out singletons.


==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

A(Answer):

"Toby A Inkster" <us**********@tobyinkster.co.ukwrote in message
news:tf************@ophelia.g5n.co.uk…

Michael Fesser wrote:

>They are perfectly OOP, whenever you have to make sure that there’s
always exactly one (not more, not less) instance of a class.

I agree with Sanders here: they’re inconsistent with OOP theory. They’re
basically just glorified globals wrapped up in a class-oriented syntax.

Of course, they’re useful as hell — just like globals and gotos and all
those other dirty little pleasures that programmers use when no-one’s
watching.

Amen.
I’m always willing to sacrafice purity in coding for results in production!