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.

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.

On Wed, 25 Jul 2007 18:56:08 +0200, Sanders Kaufman <bucky.DeleteThis@kaufman.net>
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 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. 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.

FYI:
<?php
class A{
var $foo;
function A(){
$this->foo = 'bar';
}
}
class B{
var $foo;
function B(){
$this->init();
}
function init(){
$this->foo = 'bar';
}
}
$start = microtime(true);
for($i = 1;$i<500;$i++){
$void = new A();
}
$middle = microtime(true);
for($i = 1;$i<500;$i++){
$void = new B();
}
$end = 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

Rik wrote:
> On Wed, 25 Jul 2007 18:56:08 +0200, Sanders Kaufman <bucky.RemoveThis@kaufman.net>

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

On Wed, 25 Jul 2007 19:39:04 +0200, Sanders Kaufman <bucky.TakeThisOut@kaufman.net>
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 = 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.

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 you
should probably die()/exit() or redirect to create a somewhat nice degrade.
--
Rik Wasmus

Rik wrote:
> On Wed, 25 Jul 2007 19:39:04 +0200, Sanders Kaufman <bucky.DeleteThis@kaufman.net>

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

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

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.

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

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.

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

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.

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