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@xxxxxxxxxxxxx
==================
.

Quantcast