Constructor as a "Reset" Button

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;
}

Re: Constructor as a "Reset" Button

On Tue, 24 Jul 2007 18:44:02 GMT, Sanders Kaufman 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.

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 :: andy@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

Re: Constructor as a "Reset" Button

Andy Hassall wrote:
> On Tue, 24 Jul 2007 18:44:02 GMT, Sanders Kaufman 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.

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.

Re: Constructor as a "Reset" Button

..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

Re: Constructor as a "Reset" Button

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.

Re: Constructor as a "Reset" Button

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. ;)

Re: Constructor as a "Reset" Button

On Jul 24, 5:03 pm, 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.
>
> 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.

Re: Constructor as a "Reset" Button

ZeldorBlat wrote:
> On Jul 24, 5:03 pm, Sanders Kaufman wrote:
>> 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.

Re: Constructor as a "Reset" Button

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 :-P

--
----------------------------------
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

Re: Constructor as a "Reset" Button

Sanders Kaufman wrote:
> Andy Hassall wrote:
>> On Tue, 24 Jul 2007 18:44:02 GMT, Sanders Kaufman
>> 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.
jstucklex@attglobal.net
==================

Re: Constructor as a "Reset" Button

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.
jstucklex@attglobal.net
==================

Re: Constructor as a "Reset" Button

Sanders Kaufman wrote:
> ZeldorBlat wrote:
>> On Jul 24, 5:03 pm, Sanders Kaufman wrote:
>>> 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.
jstucklex@attglobal.net
==================

Re: Constructor as a "Reset" Button

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 :-P

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.

Re: Constructor as a "Reset" Button

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".

Re: Constructor as a "Reset" Button

Jerry Stuckle wrote:
> Sanders Kaufman wrote:


>> 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.

Should, shmould.
I ain't real good at following orders, unless there's a reason.


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

You guys keep making that same vague reference to doom and gloom.
Wassatabout?



>> 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.

Here in Dallas, the Hospitals are SCREAMING for programmers and are more
than willing to send folks to classes.

There's this one fellow who's been a Respiratory Therapist for like 20
years and has absolutely NO computer skills. (He asked me to "install
Microsoft on his mouse!") They just pulled him off the floors, gave him
a raise, and sent him to school to do this - and he was a damn fine RT.

I don't know how he passed the course, but that's what he appears to
have done.

Re: Constructor as a "Reset" Button

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?

Re: Constructor as a "Reset" Button

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.
jstucklex@attglobal.net
==================

Re: Constructor as a "Reset" Button

Sanders Kaufman wrote:
> Jerry Stuckle wrote:
>> Sanders Kaufman wrote:
>
>
>>> 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.
>
> Should, shmould.
> I ain't real good at following orders, unless there's a reason.
>

Then don't bother asking for any more advice.

>
>> When you use a system function incorrectly, you run into all kinds of
>> potential problems.
>
> You guys keep making that same vague reference to doom and gloom.
> Wassatabout?
>
>

Doing things the right way vs. the convenient way.

>
>>> 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.
>
> Here in Dallas, the Hospitals are SCREAMING for programmers and are more
> than willing to send folks to classes.
>
> There's this one fellow who's been a Respiratory Therapist for like 20
> years and has absolutely NO computer skills. (He asked me to "install
> Microsoft on his mouse!") They just pulled him off the floors, gave him
> a raise, and sent him to school to do this - and he was a damn fine RT.
>
> I don't know how he passed the course, but that's what he appears to
> have done.

Last time I looked you don't need computer skills to be a respiratory
therapist. And if they're like most hospitals, hospitals are screaming
for programmers because they don't pay a reasonable rate.

Saw an ad for one in the DC area here a while back - a whole litany of
requirements, which could only be realistically met by someone with 10+
years programming experience. And they were paying less than what a new
programmer would get almost anyplace else.

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

Re: Constructor as a "Reset" Button

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.
jstucklex@attglobal.net
==================

Re: Constructor as a "Reset" Button

Jerry Stuckle wrote:
> Sanders Kaufman wrote:

>> 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 absolutely no chance that the PHP team will change PHP4 to
behave that way.

Look - I'm wanting to do like you guys say, be all correct about not
cutting academic corners. I much prefer doing it right, simply because
it is right.

But this is a PHP application, with some value added by OOP - not the
other way around.

And as y'all full well know, PHP4 ain't a proper OOP language. So no
matter how much I might bend over backwards to treat it that way - it
ain't gonna happen cause it can't.



> There is no replacement for good programming - and no excuse for sloppy
> programming.

Sloppy, in this case, would be to get sidetracked into adding redundant
features in order to program pure OOP - even though the language doesnt
fully support it and the environment doesn't not require it.

I appreciate y'alls help - but I'm here to please the end user, not the
consultants.

And really... about those charities...

Re: Constructor as a "Reset" Button

Jerry Stuckle wrote:
> Sanders Kaufman wrote:

>> Should, shmould.
>> I ain't real good at following orders, unless there's a reason.
>
> Then don't bother asking for any more advice.

I see your blood sugar is running low again.



>> You guys keep making that same vague reference to doom and gloom.
>> Wassatabout?
>
> Doing things the right way vs. the convenient way.

Wow - I never really thought of PHP and OOP development as a MORAL issue.

But GOD knows - you're not the first self-righteous programmer to get
all in a snit about it.

Re: Constructor as a "Reset" Button

Sanders Kaufman wrote:
> Jerry Stuckle wrote:
>> Sanders Kaufman wrote:
>
>>> 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 absolutely no chance that the PHP team will change PHP4 to
> behave that way.
>
> Look - I'm wanting to do like you guys say, be all correct about not
> cutting academic corners. I much prefer doing it right, simply because
> it is right.
>
> But this is a PHP application, with some value added by OOP - not the
> other way around.
>
> And as y'all full well know, PHP4 ain't a proper OOP language. So no
> matter how much I might bend over backwards to treat it that way - it
> ain't gonna happen cause it can't.
>
>
>
>> There is no replacement for good programming - and no excuse for
>> sloppy programming.
>
> Sloppy, in this case, would be to get sidetracked into adding redundant
> features in order to program pure OOP - even though the language doesnt
> fully support it and the environment doesn't not require it.
>
> I appreciate y'alls help - but I'm here to please the end user, not the
> consultants.
>
> And really... about those charities...
>
>

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.

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

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

Re: Constructor as a "Reset" Button

Sanders Kaufman wrote:
> Jerry Stuckle wrote:
>> Sanders Kaufman wrote:
>
>>> Should, shmould.
>>> I ain't real good at following orders, unless there's a reason.
>>
>> Then don't bother asking for any more advice.
>
> I see your blood sugar is running low again.
>
>

Not at all. I just don't like spending my time trying to explain
something to have it ignored. This is volunteer work - and if my
comments are going to be argued with and/or ignored, I'm not going to
bother making any.

>
>>> You guys keep making that same vague reference to doom and gloom.
>>> Wassatabout?
>>
>> Doing things the right way vs. the convenient way.
>
> Wow - I never really thought of PHP and OOP development as a MORAL issue.
>
> But GOD knows - you're not the first self-righteous programmer to get
> all in a snit about it.

It's not a moral issue. It's a programming issue.

And no one ever said to write redundant code. You really need to read
over the suggestions more carefully.

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

Re: Constructor as a "Reset" Button

On Wed, 25 Jul 2007 03:58:49 +0200, 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 architectur=
e.
>>> Indeed - the most powerful reason for using OOP is to be able to wri=
te =

>>> 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 =3D array();
> $this->Database =3D new bvckvs_database();
> $this->ErrorMessage =3D $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 =3D 'bar';
}
}

//instantiating
$obj =3D new baseclass();
//altering
$obj->foo =3D 'foz';
//reinitializing
$obj->init();
-- =

Rik Wasmus

Re: Constructor as a "Reset" Button

On Jul 24, 9:58 pm, 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?

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;
}
}

Re: Constructor as a "Reset" Button

On Wed, 25 Jul 2007 04:33:22 +0200, ZeldorBlat
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 :P
--
Rik Wasmus

Re: Constructor as a "Reset" Button

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!

Re: Constructor as a "Reset" Button

Jerry Stuckle wrote:
> Sanders Kaufman wrote:

>>>> I ain't real good at following orders, unless there's a reason.
>>>
>>> Then don't bother asking for any more advice.
>>
>> I see your blood sugar is running low again.
>
> Not at all. I just don't like spending my time trying to explain
> something to have it ignored. This is volunteer work - and if my
> comments are going to be argued with and/or ignored, I'm not going to
> bother making any.

When you say I should do a thing, without explaining why and then get in
a snit when I ask why, that's not giving advice.

I realize that you in particular have a strong need for validation, and
that having people do what you say without asking why provides you with
a great deal of validation.

But you need to realize that I'm neither your employee, nor your shrink.
I'm just a guy who says "thanks" when you're helpful and dismisses you
when your emotional problems overwhelm your technical expertise.

Re: Constructor as a "Reset" Button

Rik wrote:
> On Wed, 25 Jul 2007 03:58:49 +0200, Sanders Kaufman


>> 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.

Re: Constructor as a "Reset" Button

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.

Re: Constructor as a "Reset" Button

Rik wrote:
> On Wed, 25 Jul 2007 04:33:22 +0200, ZeldorBlat
> 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 :P

.... right up until the last one follows the first one over the cliff.

One of my favorite movies is "A Beautiful Mind".
And what makes it so is the way it expresses the fact that true genius
is the ability to come up with "one original idea", even as others
encourage you to follow the herd.

What you guys are doing here is - you're asking me to make the
application LESS efficient in order to conform to your herd mentality.

Fuck that.

Re: Constructor as a "Reset" Button

..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

Re: Constructor as a "Reset" Button

..oO(Sanders Kaufman)

>What you guys are doing here is - you're asking me to make the
>application LESS efficient in order to conform to your herd mentality.

It is as efficient as yours, but more stable.

Micha

Re: Constructor as a "Reset" Button

..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

Re: Constructor as a "Reset" Button

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/07/24/crypto-challenge/

Re: Constructor as a "Reset" Button

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/07/24/crypto-challenge/

Re: Constructor as a "Reset" Button

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/07/24/crypto-challenge/

Re: Constructor as a "Reset" Button

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/07/24/crypto-challenge/

Re: Constructor as a "Reset" Button

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/07/24/crypto-challenge/

Re: Constructor as a "Reset" Button

Sanders Kaufman wrote:
> Jerry Stuckle wrote:
>> Sanders Kaufman wrote:
>
>>>>> I ain't real good at following orders, unless there's a reason.
>>>>
>>>> Then don't bother asking for any more advice.
>>>
>>> I see your blood sugar is running low again.
>>
>> Not at all. I just don't like spending my time trying to explain
>> something to have it ignored. This is volunteer work - and if my
>> comments are going to be argued with and/or ignored, I'm not going to
>> bother making any.
>
> When you say I should do a thing, without explaining why and then get in
> a snit when I ask why, that's not giving advice.
>
> I realize that you in particular have a strong need for validation, and
> that having people do what you say without asking why provides you with
> a great deal of validation.
>
> But you need to realize that I'm neither your employee, nor your shrink.
> I'm just a guy who says "thanks" when you're helpful and dismisses you
> when your emotional problems overwhelm your technical expertise.
>
>
>

Several people have explained WHY. You just are too set in your mind to
see it.

And no, I have NO need for validation. I'm well beyond that. But I
have no need to put up with your crap, either.

It's interesting - the people most in need of validation are the ones
who claim others do so.

Sorry, I'm no longer your kicking can.


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

Re: Constructor as a "Reset" Button

..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

Re: Constructor as a "Reset" Button

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.
jstucklex@attglobal.net
==================

Re: Constructor as a "Reset" Button

Michael Fesser wrote:
> .oO(Sanders Kaufman)
>
>> What you guys are doing here is - you're asking me to make the
>> application LESS efficient in order to conform to your herd mentality.
>
> It is as efficient as yours, but more stable.

So - making two function calls in PHP uses no more resources than making
one? I don't buy it.

Re: Constructor as a "Reset" Button

On Wed, 25 Jul 2007 18:56:08 +0200, Sanders Kaufman =
=

wrote:

> Michael Fesser wrote:
>> .oO(Sanders Kaufman)
>>
>>> What you guys are doing here is - you're asking me to make the =

>>> application LESS efficient in order to conform to your herd mentalit=
y.
>> It is as efficient as yours, but more stable.
>
> So - making two function calls in PHP uses no more resources than maki=
ng =

> one? I don't buy it.

It is negligable. And it assures compatibility, as stated before: the fa=
ct =

you can call the constructor like a normal method in the present situati=
on =

is not something to be relied upon.

FYI:
class A{
var $foo;
function A(){
$this->foo =3D 'bar';
}
}
class B{
var $foo;
function B(){
$this->init();
}
function init(){
$this->foo =3D 'bar';
}
}
$start =3D microtime(true);
for($i =3D 1;$i<500;$i++){
$void =3D new A();
}
$middle =3D microtime(true);
for($i =3D 1;$i<500;$i++){
$void =3D new B();
}
$end =3D microtime(true);
echo 'A:',($middle-$start),"\n";
echo 'B:',($end-$middle),"\n";
?>

Result:
A:0.001378059387207
B:0.0017580986022949

And that is on my homebox, entirely not optimised for this kind of thing=
.. =

500 instantiations. I really don't care about the difference here..
-- =

Rik Wasmus

Re: Constructor as a "Reset" Button

Michael Fesser wrote:
> .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?

Stability and reliability are not effected.



>> 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.

Now THAT's an interesting point. But the PHP documentation seems to
indicate that it treats it as any other public function.


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

There's nothing in the PHP documentation to indicate that calling this
public function, even though it's a constructor, is inappropriate.


>> 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).

Until a few years ago, I'd always been a Microsloth programmer. When I
went *nix, I wrote an article for CNET about using PHP with MySQL. In
it, I connected to a database with "$x = mysql_connect()" instead of the
way their guys liked, which was "mysql_connect() or die".

Their guys said that it would result in Zombie processes - something I
had to dig around to find out about - and I still don't fully understand
them. Since I'm still a loooong way from being a *nix guru, I've been
hyper-vigilant about not accidentally wasting a bunch of resources.

As it turned out, they were wrong. But, like Jerry, they were sooooo
adamant, it turned into a big broo-ha-ha and I've been a bit gun-shy
about 'em ever since.

Re: Constructor as a "Reset" Button

Michael Fesser wrote:
> .oO(Sanders Kaufman)

> 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.

There's nothing in the PHP documentation to indicate that calling this
public function this way is at all inappropriate.


>>> 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".


There's nothing to indicate that calling the constructor will do
anything "unpredictable". Furthermore, as I'm testing the code, I find
that it works *exactly* as expected.

Beyond that, as Jerry pointed out, after the child (with its own
constructor) is created, it MUST manually call the parent's constructor
to get it to fire.

That's what made me realize that - regardless of what I've done with the
object, calling its public constructor returns it to a pristine state.

Re: Constructor as a "Reset" Button

On Wed, 25 Jul 2007 19:39:04 +0200, Sanders Kaufman =
=

wrote:
>>> 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).=

>
> Until a few years ago, I'd always been a Microsloth programmer. When =
I =

> went *nix, I wrote an article for CNET about using PHP with MySQL. In=
=

> it, I connected to a database with "$x =3D mysql_connect()" instead of=
the =

> way their guys liked, which was "mysql_connect() or die".
>
> Their guys said that it would result in Zombie processes - something I=
=

> had to dig around to find out about - and I still don't fully understa=
nd =

> them. Since I'm still a loooong way from being a *nix guru, I've been=
=

> hyper-vigilant about not accidentally wasting a bunch of resources.
>
> As it turned out, they were wrong. But, like Jerry, they were sooooo =
=

> adamant, it turned into a big broo-ha-ha and I've been a bit gun-shy =

> about 'em ever since.

I could've told you they were wrong. Then again, this is quite clear in =
=

the documentation.

Compare your current use of the constructor with people who used the =

string value of objects: it was an undocumented feature, and it came to =
=

bite them in the ass when things were changed.

Just don't rely on anything db-wise to work later on in the script, so y=
ou =

should probably die()/exit() or redirect to create a somewhat nice degra=
de.
-- =

Rik Wasmus

Re: Constructor as a "Reset" Button

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.

Re: Constructor as a "Reset" Button

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.

Re: Constructor as a "Reset" Button

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.

Re: Constructor as a "Reset" Button

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.

Re: Constructor as a "Reset" Button

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.

Re: Constructor as a "Reset" Button

..oO(Sanders Kaufman)

>Michael Fesser wrote:
>>
>> 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.
>
>Now THAT's an interesting point. But the PHP documentation seems to
>indicate that it treats it as any other public function.

PHP itself indicates that a constructor is a special method, simply
because it starts with two underscores. That's PHP's common notation for
its "magic" functions and methods.

In PHP 5 there's even some more magic for classes in the form of the
interceptor methods __get(), __set(), __call() and some more. Of course
you could call them by hand as well, because they're all public ...

Micha

Re: Constructor as a "Reset" Button

Rik wrote:
> On Wed, 25 Jul 2007 18:56:08 +0200, Sanders Kaufman

>>>> What you guys are doing here is - you're asking me to make the
>>>> application LESS efficient in order to conform to your herd mentality.
>>> It is as efficient as yours, but more stable.
>>
>> So - making two function calls in PHP uses no more resources than
>> making one? I don't buy it.
>
> It is negligable.

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".


> And it assures compatibility, as stated before: the
> fact you can call the constructor like a normal method in the present
> situation is not something to be relied upon.

Compatible is a transitive verb - it needs an object (e.g. - compatible
with...).

Furthemore - there is absolutely NO chance that the PHP folks will
change PHP4 in a way that would break this, so it is completely reliable.

Beyond that, since PHP5 aims to be backwardly compatible, there is very
little chance that it will have a problem with this design pattern, either.

> Result:
> A:0.001378059387207
> B:0.0017580986022949
>
> And that is on my homebox, entirely not optimised for this kind of
> thing. 500 instantiations. I really don't care about the difference here..

That was very cool, and I WELL appreciate seeing the performance hit in
REAL numbers.

Unfortunately, it reaffirms my position that, while the performance hit
is near nil - it's still there.

It's like recycling plastic and glass. I know darned good and well that
throwing my little pop can into the recycle bin helps the environment
very little - but I do it anyway. It's the principle of the thing.

It pops a vision into my head: I'm pitching my app to a web farm, and
standing next to me is a guy who's also pitching his own - each with the
exact same functionality - but mine takes only ONE less CPU cycle.

Then I get the million dollar contract, speaking engagements, the key to
the city, and a pin from the pope - and he gets his parking validated.

It could happen!

Re: Constructor as a "Reset" Button

..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

Re: Constructor as a "Reset" Button

Rik wrote:
> On Wed, 25 Jul 2007 19:39:04 +0200, Sanders Kaufman

>> Their guys said that it would result in Zombie processes - something I
>> had to dig around to find out about - and I still don't fully
>> understand them. Since I'm still a loooong way from being a *nix
>> guru, I've been hyper-vigilant about not accidentally wasting a bunch
>> of resources.
>>
>> As it turned out, they were wrong. But, like Jerry, they were sooooo
>> adamant, it turned into a big broo-ha-ha and I've been a bit gun-shy
>> about 'em ever since.
>
> I could've told you they were wrong. Then again, this is quite clear in
> the documentation.

That's how it finally played out - with one minor exception.
At the time (I don't know if it's still true) there were two ways to
install PHP - MOD and CGI. In one, Zombies could gitcha. In the other,
they couldn't.

Here's the discussion and article on CNET:
http://articles.techrepublic.com.com/5100-22-1045433.html

Be aware when you read it that it was seven years ago, and although I've
got a lot to learn, I've learned a lot since then.



> Compare your current use of the constructor with people who used the
> string value of objects: it was an undocumented feature, and it came to
> bite them in the ass when things were changed.

Calling public functions, even constructors, is NOT an undocumented feature.

Indeed, after Jerry told me about how I *have* to *manually* call the
constructor, I RTFM'd and confirmed that he was right - that it's
*totally* apporpriate to call the manually call constructor.


> Just don't rely on anything db-wise to work later on in the script, so
> you should probably die()/exit() or redirect to create a somewhat nice
> degrade.

Using DIE this way is a great way to write a bad web application.
If your DBMS goes off-line, your users don't get a clean response.
They just get a blank page.

Re: Constructor as a "Reset" Button

Michael Fesser wrote:
> .oO(Sanders Kaufman)
>
>> Michael Fesser wrote:
>>> 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.
>> Now THAT's an interesting point. But the PHP documentation seems to
>> indicate that it treats it as any other public function.
>
> PHP itself indicates that a constructor is a special method, simply
> because it starts with two underscores. That's PHP's common notation for
> its "magic" functions and methods.

Ahhh! See, that's where our disconnect is.
I'm very married to writing this in PHP4.

Later, if the project is worth it's while, I may port it to PHP5 and
..NET. But that's a big "maybe", with an "someday" qualifier.
If that day comes, GOD willing, I'll most certainly change it to take
advantage of the features and functions of those two design paradigms.



> In PHP 5 there's even some more magic for classes in the form of the
> interceptor methods __get(), __set(), __call() and some more. Of course
> you could call them by hand as well, because they're all public ...

I am so chomping at the bit to do this in 5! I can't hardly wait.

I'm hosted on APlus.net - and all I gotta do is check a checkbox to
switch from 4 to 5. Unfortunately, a combination of discipline and
obsessive compulsion prevents me from doing that... yet.

Using PHP4, I feel like a dinosaur; like I might just as well be using
TRS-80 BASIC.

Re: Constructor as a "Reset" Button

..oO(Sanders Kaufman)

>Toby A Inkster wrote:
>>
>> 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?

It's not a hit at all.

>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.

Are you kidding or trolling? Why are you calling multiple methods, if
all could be done in a single one? Why do you use OOP at all? Or PHP?
Why not directly write pure Assembler code?

_Every_ step taken to a higher, more abstract level "wastes" sooo many
resources - millions of CPU cycles just in order to load, parse and
compile your class file, so you can use it! And you're worried about the
time taken for a _single_ method call? Sorry, but that's just absurd.

Micha

Re: Constructor as a "Reset" Button

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.

Re: Constructor as a "Reset" Button

Michael Fesser wrote:
> .oO(Sanders Kaufman)

>> 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.
>
> Are you kidding or trolling? Why are you calling multiple methods, if
> all could be done in a single one? Why do you use OOP at all? Or PHP?
> Why not directly write pure Assembler code?

Because that would violate a core design principle - that the app be
written in PHP4.


> _Every_ step taken to a higher, more abstract level "wastes" sooo many
> resources - millions of CPU cycles just in order to load, parse and
> compile your class file, so you can use it! And you're worried about the
> time taken for a _single_ method call? Sorry, but that's just absurd.

Yeah - but I recycle my plastic and glass, too. I don't see where it's
made my neighborhood any tidier, but it's the principle of the thing.

Re: Constructor as a "Reset" Button

..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

Re: Constructor as a "Reset" Button

Sanders Kaufman wrote:

>>> Besides and again... my focus here is on not wasting resources
>>> unnecessarily.
>>
>> Go program a CGI in assembler, then :-P
>
> 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.

Re: Constructor as a "Reset" Button

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_eat_s_p_a_m_for_breakfast@hotmail.com
Jabber:ivansanchez@jabber.org ; ivansanchez@kdetalk.net

Re: Constructor as a "Reset" Button

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 :-P
>> 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.

Re: Constructor as a "Reset" Button

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.

Re: Constructor as a "Reset" Button

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-singleton-detector/wiki/WhyS ingletonsAreControversial

--
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/07/24/crypto-challenge/

Re: Constructor as a "Reset" Button

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.

Re: Constructor as a "Reset" Button

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".

Re: Constructor as a "Reset" Button

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-singleton-detector/wiki/WhyS ingletonsAreControversial

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?

Re: Constructor as a "Reset" Button

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-singleton-detector/wiki/WhyS ingletonsAreControversial
>

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.
jstucklex@attglobal.net
==================

Re: Constructor as a "Reset" Button

"Toby A Inkster" wrote in message
news:tfhjn4-mvu.ln1@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!

Re: Constructor as a "Reset" Button

"Toby A Inkster" wrote in message
news:73ijn4-mvu.ln1@ophelia.g5n.co.uk...
> 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?

I've been programming since the 1970's.
In my experience, that situation is as rare as a duck that can't swim.

Your point is valid - there's a design consideration that can add a measure
of reusability.
It's like how you *should* use high-octane gas, even though the one a few
points lower works fine.
The difference is negligible - and the shortcut is acceptable.

Re: Constructor as a "Reset" Button

I think my news server recycled this thread.
It shows up as 12/18 but it was a long time ago that we actually had this
conversation.
Ignore my other responses.

Re: Constructor as a "Reset" Button

On Wed, 19 Dec 2007 03:39:08 +0100, Sanders Kaufman
wrote:

> I think my news server recycled this thread.
> It shows up as 12/18 but it was a long time ago that we actually had this
> conversation.
> Ignore my other responses.

Same here, several dozens of 'revived' threads, weird.


--
Rik Wasmus

Re: Constructor as a "Reset" Button

Sanders Kaufman wrote:
> "Toby A Inkster" wrote in message
> news:73ijn4-mvu.ln1@ophelia.g5n.co.uk...
>> 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?
>
> I've been programming since the 1970's.
> In my experience, that situation is as rare as a duck that can't swim.
>

I've been doing OO programming for almost 20 years now (and programming
since the 60's). The situation is more common that you claim -
especially in more complicated classes. But even in relatively basic
ones it can be found - if they're properly designed, that is.

> Your point is valid - there's a design consideration that can add a measure
> of reusability.
> It's like how you *should* use high-octane gas, even though the one a few
> points lower works fine.
> The difference is negligible - and the shortcut is acceptable.
>
>
>
>

The difference is negligible, I agree. So why not do it correctly?

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