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

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

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/

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/

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/

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/

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/

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.

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.

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.

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

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

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.