|
|
|
Next: evaluate code before serving it
|
| Author |
Message |
External

Since: Jan 22, 2007 Posts: 220
|
(Msg. 1) Posted: Tue Jul 24, 2007 6:44 pm
Post subject: Constructor as a "Reset" Button Archived from groups: comp>lang>php (more info?)
|
|
|
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;
} |
|
| Back to top |
|
 |  |
External

Since: Jun 20, 2007 Posts: 141
|
(Msg. 2) Posted: Tue Jul 24, 2007 6:44 pm
Post subject: Re: Constructor as a "Reset" Button Archived from groups: per prev. post (more info?)
|
|
|
On Jul 24, 5:03 pm, Sanders Kaufman <bu... RemoveThis @kaufman.net> 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. |
|
| Back to top |
|
 |  |
External

Since: Apr 04, 2004 Posts: 2788
|
(Msg. 3) Posted: Tue Jul 24, 2007 8:06 pm
Post subject: Re: Constructor as a "Reset" Button Archived from groups: per prev. post (more info?)
|
|
|
On Tue, 24 Jul 2007 18:44:02 GMT, Sanders Kaufman <bucky.TakeThisOut@kaufman.net> 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.TakeThisOut@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool |
|
| Back to top |
|
 |  |
External

Since: Jan 22, 2007 Posts: 220
|
(Msg. 4) Posted: Tue Jul 24, 2007 8:06 pm
Post subject: Re: Constructor as a "Reset" Button Archived from groups: per prev. post (more info?)
|
|
|
Andy Hassall wrote:
> On Tue, 24 Jul 2007 18:44:02 GMT, Sanders Kaufman <bucky.DeleteThis@kaufman.net> 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. |
|
| Back to top |
|
 |  |
External

Since: Jan 22, 2007 Posts: 220
|
(Msg. 5) Posted: Tue Jul 24, 2007 8:06 pm
Post subject: Re: Constructor as a "Reset" Button Archived from groups: per prev. post (more info?)
|
|
|
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. |
|
| Back to top |
|
 |  |
External

Since: Jul 08, 2004 Posts: 3787
|
(Msg. 6) Posted: Tue Jul 24, 2007 8:30 pm
Post subject: Re: Constructor as a "Reset" Button Archived from groups: per prev. post (more info?)
|
|
|
Sanders Kaufman wrote:
> Andy Hassall wrote:
>> On Tue, 24 Jul 2007 18:44:02 GMT, Sanders Kaufman <bucky.DeleteThis@kaufman.net>
>> 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.DeleteThis@attglobal.net
================== |
|
| Back to top |
|
 |  |
External

Since: Nov 12, 2005 Posts: 1141
|
(Msg. 7) Posted: Tue Jul 24, 2007 9:56 pm
Post subject: Re: Constructor as a "Reset" Button Archived from groups: per prev. post (more info?)
|
|
|
..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 |
|
| Back to top |
|
 |  |
External

Since: Jan 22, 2007 Posts: 220
|
(Msg. 8) Posted: Tue Jul 24, 2007 9:56 pm
Post subject: Re: Constructor as a "Reset" Button Archived from groups: per prev. post (more info?)
|
|
|
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.  |
|
| Back to top |
|
 |  |
External

Since: Jul 08, 2004 Posts: 3787
|
(Msg. 9) Posted: Tue Jul 24, 2007 9:56 pm
Post subject: Re: Constructor as a "Reset" Button Archived from groups: per prev. post (more info?)
|
|
|
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 RemoveThis @attglobal.net
================== |
|
| Back to top |
|
 |  |
External

Since: Jan 22, 2007 Posts: 220
|
(Msg. 10) Posted: Tue Jul 24, 2007 11:00 pm
Post subject: Re: Constructor as a "Reset" Button Archived from groups: per prev. post (more info?)
|
|
|
ZeldorBlat wrote:
> On Jul 24, 5:03 pm, Sanders Kaufman <bu....TakeThisOut@kaufman.net> 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. |
|
| Back to top |
|
 |  |
External

Since: Jul 08, 2004 Posts: 3787
|
(Msg. 11) Posted: Tue Jul 24, 2007 11:00 pm
Post subject: Re: Constructor as a "Reset" Button Archived from groups: per prev. post (more info?)
|
|
|
Sanders Kaufman wrote:
> ZeldorBlat wrote:
>> On Jul 24, 5:03 pm, Sanders Kaufman <bu....TakeThisOut@kaufman.net> 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.TakeThisOut@attglobal.net
================== |
|
| Back to top |
|
 |  |
External

Since: Mar 15, 2007 Posts: 229
|
(Msg. 12) Posted: Wed Jul 25, 2007 1:16 am
Post subject: Re: Constructor as a "Reset" Button Archived from groups: per prev. post (more info?)
|
|
|
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
--
----------------------------------
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 |
|
| Back to top |
|
 |  |
External

Since: Jan 22, 2007 Posts: 220
|
(Msg. 13) Posted: Wed Jul 25, 2007 1:34 am
Post subject: Re: Constructor as a "Reset" Button Archived from groups: per prev. post (more info?)
|
|
|
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
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. |
|
| Back to top |
|
 |  |
External

Since: Jan 22, 2007 Posts: 220
|
(Msg. 14) Posted: Wed Jul 25, 2007 1:44 am
Post subject: Re: Constructor as a "Reset" Button Archived from groups: per prev. post (more info?)
|
|
|
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". |
|
| Back to top |
|
 |  |
External

Since: Jul 08, 2004 Posts: 3787
|
(Msg. 15) Posted: Wed Jul 25, 2007 1:44 am
Post subject: Re: Constructor as a "Reset" Button Archived from groups: per prev. post (more info?)
|
|
|
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.DeleteThis@attglobal.net
================== |
|
| Back to top |
|
 |  |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|
|