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.DeleteThis@kdetalk.net

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.

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/WhySingletonsA...ontrove

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

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/WhySingletonsA...ontrove

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?

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.

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

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/WhySingletonsA...ontrove
>

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

"Toby A Inkster" <usenet200707.RemoveThis@tobyinkster.co.uk> 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!

"Toby A Inkster" <usenet200707.DeleteThis@tobyinkster.co.uk> 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.

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.

On Wed, 19 Dec 2007 03:39:08 +0100, Sanders Kaufman <bucky.TakeThisOut@kaufman.net>
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

Sanders Kaufman wrote:
> "Toby A Inkster" <usenet200707 DeleteThis @tobyinkster.co.uk> 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 DeleteThis @attglobal.net
==================