Code readability vs. execution time

Hi there,

Again a question with no simple yes or no answer at least, opinions
will probably be scattered so no unanimous yes or no answer ;)

What would you think is the best of the following to options given
that it is more likely that the databaseConnection is set?


SomeClass {

[.............]

/**
* Sets the connection to the database in use.
*
* @return DatabaseFactory
*/
private function __getDatabaseConnection(){
if (isset($this->__databaseConnection)) {
return($this->__databaseConnection);
} else {
$this->__databaseConnection = new DatabaseFactory();
$this->__databaseConnection->create();
return($this->__databaseConnection);
};
}
}

Or

SomeClass {

[.............]


/**
* Sets the connection to the database in use.
*
* @return DatabaseFactory
*/
private function __getDatabaseConnection(){
if (!$this->__databaseConnection) {
$this->__databaseConnection = new DatabaseFactory();
};
return($this->__databaseConnection);
}
}

The second option definitely has less repetitive code but does that
really make it the better option given the fact that the
databaseConnection property is probably set?

By the way, another small convention question: Should you terminate
control structures with a semicolon?

Thanks

Marijn

Re: Code readability vs. execution time

Marijn wrote:

> private function __getDatabaseConnection(){
> if (!$this->__databaseConnection) {
> $this->__databaseConnection = new DatabaseFactory();
> };
> return($this->__databaseConnection);
> }
> }

I certainly prefer this.

> By the way, another small convention question: Should you terminate
> control structures with a semicolon?

No. In fact, in this particular case, you don't even need the braces.
Using my own preferred coding style, it would be:

private function __getDatabaseConnection ()
{
if (!isset($this->__databaseConnection))
$this->__databaseConnection = new DatabaseFactory();

return $this->__databaseConnection;
}

By the way, you shouldn't name your functions with a double-underscore.
Functions that start with a double-underscore are reserved for future use
as "magic" functions (e.g. __construct, __call, __get, __autoload, etc).

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.12-12mdksmp, up 75 days, 11:36.]

TrivialEncoder/0.2
http://tobyinkster.co.uk/blog/2007/08/19/trivial-encoder/

Re: Code readability vs. execution time

On 4 sep, 10:02, Toby A Inkster
wrote:
> Marijn wrote:
> > private function __getDatabaseConnection(){
> > if (!$this->__databaseConnection) {
> > $this->__databaseConnection = new DatabaseFactory();
> > };
> > return($this->__databaseConnection);
> > }
> > }
>
> I certainly prefer this.

But because it's faster or..?

>
> > By the way, another small convention question: Should you terminate
> > control structures with a semicolon?
>
> No. In fact, in this particular case, you don't even need the braces.
> Using my own preferred coding style, it would be:

I do prefer the braces. Really makes my code more readable


> private function __getDatabaseConnection ()
> {
> if (!isset($this->__databaseConnection))
> $this->__databaseConnection = new DatabaseFactory();
>
> return $this->__databaseConnection;
> }
>
> By the way, you shouldn't name your functions with a double-underscore.
> Functions that start with a double-underscore are reserved for future use
> as "magic" functions (e.g. __construct, __call, __get, __autoload, etc).
>

I know it is for reserverd magic functions BUT this way i serarate
public (no underscore) from (protected one underscore) from (private
(two underscores)

I really prefer a difference in my code for private and protected
methods.

Plus everybody with a bit of experience knows that ther is __call,
__autoload, __desctruct ...etc.

Re: Code readability vs. execution time

..oO(Marijn)

>On 4 sep, 10:02, Toby A Inkster
>wrote:
>> Marijn wrote:
>> > private function __getDatabaseConnection(){
>> > if (!$this->__databaseConnection) {
>> > $this->__databaseConnection = new DatabaseFactory();
>> > };
>> > return($this->__databaseConnection);
>> > }
>> > }
>>
>> I certainly prefer this.
>
>But because it's faster or..?

Not really, just shorter code. I also prefer this variant.

>> By the way, you shouldn't name your functions with a double-underscore.
>> Functions that start with a double-underscore are reserved for future use
>> as "magic" functions (e.g. __construct, __call, __get, __autoload, etc).
>
>I know it is for reserverd magic functions BUT this way i serarate
>public (no underscore) from (protected one underscore) from (private
>(two underscores)
>
>I really prefer a difference in my code for private and protected
>methods.

But why?

Micha

Re: Code readability vs. execution time

Marijn wrote:
> On 4 sep, 10:02, Toby A Inkster
> wrote:
>> Marijn wrote:
>>> private function __getDatabaseConnection(){
>>> if (!$this->__databaseConnection) {
>>> $this->__databaseConnection = new DatabaseFactory();
>>> };
>>> return($this->__databaseConnection);
>>> }
>>> }
>> I certainly prefer this.
>
> But because it's faster or..?
>
>>> By the way, another small convention question: Should you terminate
>>> control structures with a semicolon?
>> No. In fact, in this particular case, you don't even need the braces.
>> Using my own preferred coding style, it would be:
>
> I do prefer the braces. Really makes my code more readable
>
>
>> private function __getDatabaseConnection ()
>> {
>> if (!isset($this->__databaseConnection))
>> $this->__databaseConnection = new DatabaseFactory();
>>
>> return $this->__databaseConnection;
>> }
>>
>> By the way, you shouldn't name your functions with a double-underscore.
>> Functions that start with a double-underscore are reserved for future use
>> as "magic" functions (e.g. __construct, __call, __get, __autoload, etc).
>>
>
> I know it is for reserverd magic functions BUT this way i serarate
> public (no underscore) from (protected one underscore) from (private
> (two underscores)
>
> I really prefer a difference in my code for private and protected
> methods.
>
> Plus everybody with a bit of experience knows that ther is __call,
> __autoload, __desctruct ...etc.
>

But Toby is correct. Double underscores are reserved for PHP "magic"
functions.

Someone else looks at your code, and they will think these are supposed
to be PHP functions. And/or, sooner or later, you will run afoul of a
PHP function added when you upgrade PHP.

I'd really suggest you find another way to do it. But it's easy for me
- I have no public variables, and very few protected ones.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Re: Code readability vs. execution time

Marijn wrote:
> Hi there,
>
> Again a question with no simple yes or no answer at least, opinions
> will probably be scattered so no unanimous yes or no answer ;)
>
> What would you think is the best of the following to options given
> that it is more likely that the databaseConnection is set?
>
>
> SomeClass {
>
> [.............]
>
> /**
> * Sets the connection to the database in use.
> *
> * @return DatabaseFactory
> */
> private function __getDatabaseConnection(){
> if (isset($this->__databaseConnection)) {
> return($this->__databaseConnection);
> } else {
> $this->__databaseConnection = new DatabaseFactory();
> $this->__databaseConnection->create();
> return($this->__databaseConnection);
> };
> }
> }
>
> Or
>
> SomeClass {
>
> [.............]
>
>
> /**
> * Sets the connection to the database in use.
> *
> * @return DatabaseFactory
> */
> private function __getDatabaseConnection(){
> if (!$this->__databaseConnection) {
> $this->__databaseConnection = new DatabaseFactory();
> };
> return($this->__databaseConnection);
> }
> }
>
> The second option definitely has less repetitive code but does that
> really make it the better option given the fact that the
> databaseConnection property is probably set?
>
> By the way, another small convention question: Should you terminate
> control structures with a semicolon?
>
> Thanks
>
> Marijn
>

I agree with the others - the first one. Why would you be creating a
DatabaseFactory if you aren't going to create a DatabaseConnection?

Now if you needed to do some things before creating the connection (and
couldn't do them in the constructor for the factory), you need to use
the second version.

But if you don't need this, let the factory create the connection
without unnecessary calls.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Re: Code readability vs. execution time

Post removed (X-No-Archive: yes)

Re: Code readability vs. execution time

Gary L. Burnore wrote:
> On Tue, 04 Sep 2007 03:11:38 -0700, Marijn
> wrote:
>
>> On 4 sep, 10:02, Toby A Inkster
>> wrote:
>
>>> By the way, you shouldn't name your functions with a double-underscore.
>>> Functions that start with a double-underscore are reserved for future use
>>> as "magic" functions (e.g. __construct, __call, __get, __autoload, etc).
>>>
>> I know it is for reserverd magic functions BUT this way i serarate
>> public (no underscore) from (protected one underscore) from (private
>> (two underscores)
>>
>> I really prefer a difference in my code for private and protected
>> methods.
>>
>> Plus everybody with a bit of experience knows that ther is __call,
>> __autoload, __desctruct ...etc.
>
> So you think it's ok to mix YOUR functions with reserved functions
> just so your functions look different?
>
> how about pu_ pv_ and pr_ (or no for public, pv for private and pr
> for protected).
>
> Of course, it's your coding skills that'd be called into question if
> someone who knew better looked at it so that's up to you.
anyone who looks into old Unix source code will find huge areas of code
written by someone who hated writing english, and appeared to have
confused even themselves.

My favorite comment is an I have used it myself

/* If you can't understand the next bit, leave it alone. Trust me it
just WORKS, No I am not sure why, either */

Re: Code readability vs. execution time

On Sep 4, 2:40 am, Marijn wrote:
> Hi there,
>
> Again a question with no simple yes or no answer at least, opinions
> will probably be scattered so no unanimous yes or no answer ;)
>
> What would you think is the best of the following to options given
> that it is more likely that the databaseConnection is set?
>
> SomeClass {
>
> [.............]
>
> /**
> * Sets the connection to the database in use.
> *
> * @return DatabaseFactory
> */
> private function __getDatabaseConnection(){
> if (isset($this->__databaseConnection)) {
> return($this->__databaseConnection);
> } else {
> $this->__databaseConnection = new DatabaseFactory();
> $this->__databaseConnection->create();
> return($this->__databaseConnection);
> };
> }
>
> }
>
> Or
>
> SomeClass {
>
> [.............]
>
> /**
> * Sets the connection to the database in use.
> *
> * @return DatabaseFactory
> */
> private function __getDatabaseConnection(){
> if (!$this->__databaseConnection) {
> $this->__databaseConnection = new DatabaseFactory();
> };
> return($this->__databaseConnection);
> }
>
> }
>
> The second option definitely has less repetitive code but does that
> really make it the better option given the fact that the
> databaseConnection property is probably set?
>
> By the way, another small convention question: Should you terminate
> control structures with a semicolon?
>
> Thanks
>
> Marijn

>From looking at your code, it looks like you intend to put this
connection function in all of your classes that need to talk to the
database. Your code looks like it wants a singleton pattern.

You're on the right path with your code, but why not abstract that
logic to a class of its own (I assume mysql):

class db {
static private $_instance;
public $connection;

private __construct () {
//do database initiation, such as loading config data and the like
$this->connection = mysql_connect(...);
//exception handling
mysql_select_db($schema, $this->connection);
//exception handling
}

public static function getInstance() {
if (is_null(self::$_instance)) {
self::$_instance = new db();
}
return self::$_instance;
}
} // end db class


now, in your other classes, you simply type:

class someClass {

public function someMethod() {
//just putting this in a generic method, but you could put it in
the constructor, if you wish
$db = db::getInstance();
//and you connection handle is $db->connection
}

A lot less code in your classes, and a bit easier to understand in my
opinion. Also has the advantages of encapsulation to the db
connection so you can do fun things like centralizing exception
handling and/or create some generic functions to handle your query
formats, etc.

Re: Code readability vs. execution time

On Sep 4, 9:26 am, The Natural Philosopher wrote:
> Gary L. Burnore wrote:
> > On Tue, 04 Sep 2007 03:11:38 -0700, Marijn
> > wrote:
>
> >> On 4 sep, 10:02, Toby A Inkster
> >> wrote:
>
> >>> By the way, you shouldn't name your functions with a double-underscore.
> >>> Functions that start with a double-underscore are reserved for future use
> >>> as "magic" functions (e.g. __construct, __call, __get, __autoload, etc).
>
> >> I know it is for reserverd magic functions BUT this way i serarate
> >> public (no underscore) from (protected one underscore) from (private
> >> (two underscores)
>
> >> I really prefer a difference in my code for private and protected
> >> methods.
>
> >> Plus everybody with a bit of experience knows that ther is __call,
> >> __autoload, __desctruct ...etc.
>
> > So you think it's ok to mix YOUR functions with reserved functions
> > just so your functions look different?
>
> > how about pu_ pv_ and pr_ (or no for public, pv for private and pr
> > for protected).
>
> > Of course, it's your coding skills that'd be called into question if
> > someone who knew better looked at it so that's up to you.
>
> anyone who looks into old Unix source code will find huge areas of code
> written by someone who hated writing english, and appeared to have
> confused even themselves.
>
> My favorite comment is an I have used it myself
>
> /* If you can't understand the next bit, leave it alone. Trust me it
> just WORKS, No I am not sure why, either */

I'm sure we all wrote code like this at one point...until we had to
rework our own code later on. You do need to be clever at times to be
a programmer, but a good programmer is always more appreciated than a
clever programmer.

Re: Code readability vs. execution time

ELINTPimp wrote:
> On Sep 4, 9:26 am, The Natural Philosopher wrote:
>> Gary L. Burnore wrote:
>>> On Tue, 04 Sep 2007 03:11:38 -0700, Marijn
>>> wrote:
>>>> On 4 sep, 10:02, Toby A Inkster
>>>> wrote:
>>>>> By the way, you shouldn't name your functions with a double-underscore.
>>>>> Functions that start with a double-underscore are reserved for future use
>>>>> as "magic" functions (e.g. __construct, __call, __get, __autoload, etc).
>>>> I know it is for reserverd magic functions BUT this way i serarate
>>>> public (no underscore) from (protected one underscore) from (private
>>>> (two underscores)
>>>> I really prefer a difference in my code for private and protected
>>>> methods.
>>>> Plus everybody with a bit of experience knows that ther is __call,
>>>> __autoload, __desctruct ...etc.
>>> So you think it's ok to mix YOUR functions with reserved functions
>>> just so your functions look different?
>>> how about pu_ pv_ and pr_ (or no for public, pv for private and pr
>>> for protected).
>>> Of course, it's your coding skills that'd be called into question if
>>> someone who knew better looked at it so that's up to you.
>> anyone who looks into old Unix source code will find huge areas of code
>> written by someone who hated writing english, and appeared to have
>> confused even themselves.
>>
>> My favorite comment is an I have used it myself
>>
>> /* If you can't understand the next bit, leave it alone. Trust me it
>> just WORKS, No I am not sure why, either */
>
> I'm sure we all wrote code like this at one point...until we had to
> rework our own code later on. You do need to be clever at times to be
> a programmer, but a good programmer is always more appreciated than a
> clever programmer.
>
Indeed.
That's a last resort.

In the days before optimising compilers and with edlin over a 300 bps
link as your only input, and probably handwritten on paper code just
typed in..there was some excuse for things like..

((t=a->p[b].c)->index)==(a->p[0].sel))?t->data:FALSE;

with no explanations..

These days you see code like that coming out of 'application generators'
not humans.

Using twenty lines of commented code that breaks the above down into
steps, with loads of intermediate variables probably results in the same
output code anyway.

Gone are the days when it took 100K of well commented ASCII assembler to
generate 2k of PROM :-)

IIRC we had a rule that comments to code was about 1:1 in terms of block
hearders, and you always wrote that FIRST. And what followed was
commented pretty much every line or two as well.

PHP is in some respects retrograde: Its too much like BASIC in that you
can 'hack it till it works' too easily.

Re: Code readability vs. execution time

ELINTPimp wrote:
> On Sep 4, 2:40 am, Marijn wrote:
>> Hi there,
>>
>> Again a question with no simple yes or no answer at least, opinions
>> will probably be scattered so no unanimous yes or no answer ;)
>>
>> What would you think is the best of the following to options given
>> that it is more likely that the databaseConnection is set?
>>
>> SomeClass {
>>
>> [.............]
>>
>> /**
>> * Sets the connection to the database in use.
>> *
>> * @return DatabaseFactory
>> */
>> private function __getDatabaseConnection(){
>> if (isset($this->__databaseConnection)) {
>> return($this->__databaseConnection);
>> } else {
>> $this->__databaseConnection = new DatabaseFactory();
>> $this->__databaseConnection->create();
>> return($this->__databaseConnection);
>> };
>> }
>>
>> }
>>
>> Or
>>
>> SomeClass {
>>
>> [.............]
>>
>> /**
>> * Sets the connection to the database in use.
>> *
>> * @return DatabaseFactory
>> */
>> private function __getDatabaseConnection(){
>> if (!$this->__databaseConnection) {
>> $this->__databaseConnection = new DatabaseFactory();
>> };
>> return($this->__databaseConnection);
>> }
>>
>> }
>>
>> The second option definitely has less repetitive code but does that
>> really make it the better option given the fact that the
>> databaseConnection property is probably set?
>>
>> By the way, another small convention question: Should you terminate
>> control structures with a semicolon?
>>
>> Thanks
>>
>> Marijn
>
>>From looking at your code, it looks like you intend to put this
> connection function in all of your classes that need to talk to the
> database. Your code looks like it wants a singleton pattern.
>
> You're on the right path with your code, but why not abstract that
> logic to a class of its own (I assume mysql):
>
> class db {
> static private $_instance;
> public $connection;
>
> private __construct () {
> //do database initiation, such as loading config data and the like
> $this->connection = mysql_connect(...);
> //exception handling
> mysql_select_db($schema, $this->connection);
> //exception handling
> }
>
> public static function getInstance() {
> if (is_null(self::$_instance)) {
> self::$_instance = new db();
> }
> return self::$_instance;
> }
> } // end db class
>
>
> now, in your other classes, you simply type:
>
> class someClass {
>
> public function someMethod() {
> //just putting this in a generic method, but you could put it in
> the constructor, if you wish
> $db = db::getInstance();
> //and you connection handle is $db->connection
> }
>
> A lot less code in your classes, and a bit easier to understand in my
> opinion. Also has the advantages of encapsulation to the db
> connection so you can do fun things like centralizing exception
> handling and/or create some generic functions to handle your query
> formats, etc.
>
>

I do something very similar in my classes, and find it easier to use.

However, there is a whole design concept around the Factory class, and
some people prefer it. It helps when you need to pass parameters to the
Factory, for instance, before actually creating the object.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Re: Code readability vs. execution time

> PHP is in some respects retrograde: Its too much like BASIC in that you
> can 'hack it till it works' too easily.

Agreed, but that's why test driven development has such an important
place in our world...but that is just another form of programmer
introduced standard. Just like PHP's loosely typed aspect, it's a
double edge sword...but I wouldn't have it any other way =).

Re: Code readability vs. execution time

ELINTPimp wrote:
>> PHP is in some respects retrograde: Its too much like BASIC in that you
>> can 'hack it till it works' too easily.
>
> Agreed, but that's why test driven development has such an important
> place in our world...but that is just another form of programmer
> introduced standard. Just like PHP's loosely typed aspect, it's a
> double edge sword...but I wouldn't have it any other way =).
>
coming from strictly typed C I find it awful.

When I want to cast a string to an integer, I'd rather do it explicitly..

I mean

$int="0"

If($int==0) echo "true";
if($int) echo "its non zero"

I am still not sure WHAT that last statement means, 0 means unsassigned,
non zero, or what...

At least in C you could be sure it meant 'the numerical value of
whatever $int is supposed to be, when cast to an integer, is tested for
zero)

And I used to LIKE my compilers giving me hell about

foo{return ('c');}

char p=foo();

and making me type it either as

char foo{return ('c');}

or char p=(char)foo();

Fussy, but it did pick up some errors all right.

Re: Code readability vs. execution time

..oO(The Natural Philosopher)

>ELINTPimp wrote:
>>> PHP is in some respects retrograde: Its too much like BASIC in that you
>>> can 'hack it till it works' too easily.
>>
>> Agreed, but that's why test driven development has such an important
>> place in our world...but that is just another form of programmer
>> introduced standard. Just like PHP's loosely typed aspect, it's a
>> double edge sword...but I wouldn't have it any other way =).
>>
>coming from strictly typed C I find it awful.

Loose typing in scripting languages is not a bug, but a feature, even if
many people seem to have a problem with that. JavaScript for example has
the same feature, but surprisingly nobody complains about it there. It's
always just PHP which is blamed.

>When I want to cast a string to an integer, I'd rather do it explicitly..
>
>I mean
>
>$int="0"
>
>If($int==0) echo "true";
>if($int) echo "its non zero"
>
>I am still not sure WHAT that last statement means, 0 means unsassigned,
>non zero, or what...

The second statement simply means that the value of $int, whatever it
may be, evaluates to FALSE.

Micha

Re: Code readability vs. execution time

> $int="0"
>
> If($int==0) echo "true";
> if($int) echo "its non zero"
>
> I am still not sure WHAT that last statement means, 0 means unsassigned,
> non zero, or what...
>
> At least in C you could be sure it meant 'the numerical value of whatever
> $int is supposed to be, when cast to an integer, is tested for zero)

just remember that php is NOT c...and that your 'if ($var)' is covered in
the manual in depth *and* occassions where === are required. btw, nothing
prohibits you from type casting or checking in php.

> And I used to LIKE my compilers giving me hell about
>
> foo{return ('c');}
>
> char p=foo();
>
> and making me type it either as
>
> char foo{return ('c');}
>
> or char p=(char)foo();
>
> Fussy, but it did pick up some errors all right.

so cast it or check it. whatever the case is, i love having the ability to
return a specific type of result when things go well inside a function call
but returning 'false' if things weren't agreeable. as for c, the function
would either have to take a byref arg for the return data and check for
true/false as the function's return...or vice-versa...i hated that construct
but understood that it had to be that way to retain typing. i love php for
its many facets of flexibility including the above.

but, maybe that's just me.

Re: Code readability vs. execution time

Michael Fesser wrote:
> .oO(The Natural Philosopher)
>
>> ELINTPimp wrote:
>>>> PHP is in some respects retrograde: Its too much like BASIC in that you
>>>> can 'hack it till it works' too easily.
>>> Agreed, but that's why test driven development has such an important
>>> place in our world...but that is just another form of programmer
>>> introduced standard. Just like PHP's loosely typed aspect, it's a
>>> double edge sword...but I wouldn't have it any other way =).
>>>
>> coming from strictly typed C I find it awful.
>
> Loose typing in scripting languages is not a bug, but a feature, even if
> many people seem to have a problem with that. JavaScript for example has
> the same feature, but surprisingly nobody complains about it there. It's
> always just PHP which is blamed.
>

I find it even worse frankly. Still one has to adapt to what is there.
Ive seen perfectly respectable 10000 customer SOP systems coded in
interpreted BASC before now, and if its dine to a standard its no worse
than anting else.


>> When I want to cast a string to an integer, I'd rather do it explicitly..
>>
>> I mean
>>
>> $int="0"
>>
>> If($int==0) echo "true";
>> if($int) echo "its non zero"
>>
>> I am still not sure WHAT that last statement means, 0 means unsassigned,
>> non zero, or what...
>
> The second statement simply means that the value of $int, whatever it
> may be, evaluates to FALSE.
>
but what is "false", in this context? Null length string? string
containing "0" Magic value?

> Micha

Re: Code readability vs. execution time

..oO(The Natural Philosopher)

>Michael Fesser wrote:
>>
>> The second statement simply means that the value of $int, whatever it
>> may be, evaluates to FALSE.
>>
>but what is "false", in this context?

The result after the type cast?

>Null length string? string
>containing "0" Magic value?

If you write

if ($int) {...}

then there's no other way for PHP than to cast the $int variable to a
boolean, because that's what the 'if' statement expects. The manual
explains in detail how this type casting works and which values evaluate
to FALSE:

Converting to boolean
http://www.php.net/manual/en/language.types.boolean.php#lang uage.types.boolean.casting

If you don't want that, then you should not rely on the automatic type
juggling, but better explain to PHP what you actually want to test for:

if ($int != 0) {...}

Micha

Re: Code readability vs. execution time

On Sep 4, 4:52 pm, Jerry Stuckle wrote:
> ELINTPimp wrote:
> > On Sep 4, 2:40 am, Marijn wrote:
> >> Hi there,
>
> >> Again a question with no simple yes or no answer at least, opinions
> >> will probably be scattered so no unanimous yes or no answer ;)
>
> >> What would you think is the best of the following to options given
> >> that it is more likely that the databaseConnection is set?
>
> >> SomeClass {
>
> >> [.............]
>
> >> /**
> >> * Sets the connection to the database in use.
> >> *
> >> * @return DatabaseFactory
> >> */
> >> private function __getDatabaseConnection(){
> >> if (isset($this->__databaseConnection)) {
> >> return($this->__databaseConnection);
> >> } else {
> >> $this->__databaseConnection = new DatabaseFactory();
> >> $this->__databaseConnection->create();
> >> return($this->__databaseConnection);
> >> };
> >> }
>
> >> }
>
> >> Or
>
> >> SomeClass {
>
> >> [.............]
>
> >> /**
> >> * Sets the connection to the database in use.
> >> *
> >> * @return DatabaseFactory
> >> */
> >> private function __getDatabaseConnection(){
> >> if (!$this->__databaseConnection) {
> >> $this->__databaseConnection = new DatabaseFactory();
> >> };
> >> return($this->__databaseConnection);
> >> }
>
> >> }
>
> >> The second option definitely has less repetitive code but does that
> >> really make it the better option given the fact that the
> >> databaseConnection property is probably set?
>
> >> By the way, another small convention question: Should you terminate
> >> control structures with a semicolon?
>
> >> Thanks
>
> >> Marijn
>
> >>From looking at your code, it looks like you intend to put this
> > connection function in all of your classes that need to talk to the
> > database. Your code looks like it wants a singleton pattern.
>
> > You're on the right path with your code, but why not abstract that
> > logic to a class of its own (I assume mysql):
>
> > class db {
> > static private $_instance;
> > public $connection;
>
> > private __construct () {
> > //do database initiation, such as loading config data and the like
> > $this->connection = mysql_connect(...);
> > //exception handling
> > mysql_select_db($schema, $this->connection);
> > //exception handling
> > }
>
> > public static function getInstance() {
> > if (is_null(self::$_instance)) {
> > self::$_instance = new db();
> > }
> > return self::$_instance;
> > }
> > } // end db class
>
> > now, in your other classes, you simply type:
>
> > class someClass {
>
> > public function someMethod() {
> > //just putting this in a generic method, but you could put it in
> > the constructor, if you wish
> > $db = db::getInstance();
> > //and you connection handle is $db->connection
> > }
>
> > A lot less code in your classes, and a bit easier to understand in my
> > opinion. Also has the advantages of encapsulation to the db
> > connection so you can do fun things like centralizing exception
> > handling and/or create some generic functions to handle your query
> > formats, etc.
>
> I do something very similar in my classes, and find it easier to use.
>
> However, there is a whole design concept around the Factory class, and
> some people prefer it. It helps when you need to pass parameters to the
> Factory, for instance, before actually creating the object.
>
> --
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> JDS Computer Training Corp.
> jstuck...@attglobal.net
> ==================

Just returned from the office, boy did this get of topic ;)

First My DatabaseFactory returns a singleton of a MySQL class (later
on i can easily support other databases if i would prefer). I am
thinking of making the DatabaseFactory itself a Singleton so that the
Singleton logic does not need to be repeated in every database
implementation.

The reason why i have this function is that it is used in an abstract
class for implementation of database objects in php. By extending the
abstract class i easily can create a implementation of the database
data with it's own methods. But i don't want to create the database
connection before actualy using it.

To solve the problem I will move my connection of the database from
the database constructor to another function. The database resource
can be created and only if a query method is called it will check if
it is connected. If not connected connect else connect and query.

Still i feel like people misunderstood my first question: What is
better:

if ($mostLikelyValue) {
break;
} else {
performSomeAction();
}
theRequiredAction();

OR

if (!mostLikelyValue) {
performSomeAction();
}
theRequiredAction();

Where in my opinion the second one is more readable and the first one
probably faster (?)

On the naming conventions regarding access types:

OK say i will go for my own path of naming variables, properties and
parameters and there access type. Is that really more straightforward?
I would rather have seen reserved normal function names for methods
like __call() and __get and the
no underscore for public, one underscore for protected and two
underscores for private (or some other distinguishing character).

Is there really no commonly used way (accept for the one that bluntly
ignores protected)

I really do like the way everybody mixes in and gets involved in a
good way in these types of discussions. Thanks for that, love to hear
more from you guys.

Re: Code readability vs. execution time

On Sep 4, 2:14 pm, Marijn wrote:
> On Sep 4, 4:52 pm, Jerry Stuckle wrote:
>
>
>
> > ELINTPimp wrote:
> > > On Sep 4, 2:40 am, Marijn wrote:
> > >> Hi there,
>
> > >> Again a question with no simple yes or no answer at least, opinions
> > >> will probably be scattered so no unanimous yes or no answer ;)
>
> > >> What would you think is the best of the following to options given
> > >> that it is more likely that the databaseConnection is set?
>
> > >> SomeClass {
>
> > >> [.............]
>
> > >> /**
> > >> * Sets the connection to the database in use.
> > >> *
> > >> * @return DatabaseFactory
> > >> */
> > >> private function __getDatabaseConnection(){
> > >> if (isset($this->__databaseConnection)) {
> > >> return($this->__databaseConnection);
> > >> } else {
> > >> $this->__databaseConnection = new DatabaseFactory();
> > >> $this->__databaseConnection->create();
> > >> return($this->__databaseConnection);
> > >> };
> > >> }
>
> > >> }
>
> > >> Or
>
> > >> SomeClass {
>
> > >> [.............]
>
> > >> /**
> > >> * Sets the connection to the database in use.
> > >> *
> > >> * @return DatabaseFactory
> > >> */
> > >> private function __getDatabaseConnection(){
> > >> if (!$this->__databaseConnection) {
> > >> $this->__databaseConnection = new DatabaseFactory();
> > >> };
> > >> return($this->__databaseConnection);
> > >> }
>
> > >> }
>
> > >> The second option definitely has less repetitive code but does that
> > >> really make it the better option given the fact that the
> > >> databaseConnection property is probably set?
>
> > >> By the way, another small convention question: Should you terminate
> > >> control structures with a semicolon?
>
> > >> Thanks
>
> > >> Marijn
>
> > >>From looking at your code, it looks like you intend to put this
> > > connection function in all of your classes that need to talk to the
> > > database. Your code looks like it wants a singleton pattern.
>
> > > You're on the right path with your code, but why not abstract that
> > > logic to a class of its own (I assume mysql):
>
> > > class db {
> > > static private $_instance;
> > > public $connection;
>
> > > private __construct () {
> > > //do database initiation, such as loading config data and the like
> > > $this->connection = mysql_connect(...);
> > > //exception handling
> > > mysql_select_db($schema, $this->connection);
> > > //exception handling
> > > }
>
> > > public static function getInstance() {
> > > if (is_null(self::$_instance)) {
> > > self::$_instance = new db();
> > > }
> > > return self::$_instance;
> > > }
> > > } // end db class
>
> > > now, in your other classes, you simply type:
>
> > > class someClass {
>
> > > public function someMethod() {
> > > //just putting this in a generic method, but you could put it in
> > > the constructor, if you wish
> > > $db = db::getInstance();
> > > //and you connection handle is $db->connection
> > > }
>
> > > A lot less code in your classes, and a bit easier to understand in my
> > > opinion. Also has the advantages of encapsulation to the db
> > > connection so you can do fun things like centralizing exception
> > > handling and/or create some generic functions to handle your query
> > > formats, etc.
>
> > I do something very similar in my classes, and find it easier to use.
>
> > However, there is a whole design concept around the Factory class, and
> > some people prefer it. It helps when you need to pass parameters to the
> > Factory, for instance, before actually creating the object.
>
> > --
> > ==================
> > Remove the "x" from my email address
> > Jerry Stuckle
> > JDS Computer Training Corp.
> > jstuck...@attglobal.net
> > ==================
>
> Just returned from the office, boy did this get of topic ;)
>
> First My DatabaseFactory returns a singleton of a MySQL class (later
> on i can easily support other databases if i would prefer). I am
> thinking of making the DatabaseFactory itself a Singleton so that the
> Singleton logic does not need to be repeated in every database
> implementation.
>
> The reason why i have this function is that it is used in an abstract
> class for implementation of database objects in php. By extending the
> abstract class i easily can create a implementation of the database
> data with it's own methods. But i don't want to create the database
> connection before actualy using it.
>
> To solve the problem I will move my connection of the database from
> the database constructor to another function. The database resource
> can be created and only if a query method is called it will check if
> it is connected. If not connected connect else connect and query.
>
> Still i feel like people misunderstood my first question: What is
> better:
>
> if ($mostLikelyValue) {
> break;
> } else {
> performSomeAction();
> }
> theRequiredAction();
>
> OR
>
> if (!mostLikelyValue) {
> performSomeAction();
> }
> theRequiredAction();
>
> Where in my opinion the second one is more readable and the first one
> probably faster (?)
>
> On the naming conventions regarding access types:
>
> OK say i will go for my own path of naming variables, properties and
> parameters and there access type. Is that really more straightforward?
> I would rather have seen reserved normal function names for methods
> like __call() and __get and the
> no underscore for public, one underscore for protected and two
> underscores for private (or some other distinguishing character).
>
> Is there really no commonly used way (accept for the one that bluntly
> ignores protected)
>
> I really do like the way everybody mixes in and gets involved in a
> good way in these types of discussions. Thanks for that, love to hear
> more from you guys.

I don't think that there is a performance increase one way or
another. In this case, I would say shorter is better.

Re: Code readability vs. execution time

> if (!mostLikelyValue) {
> performSomeAction();
> }
> theRequiredAction();
>
> Where in my opinion the second one is more readable and the first one
> probably faster (?)

the one shown above is the format i like, esp. if all you do is 'break;' in
the if/else struct. as for faster...they perform the same...exactly the
same. and if you get this technical over the code, you're doomed to never
finish an application...at least on time that is.

as a rule, i stay away from if/else constructs as much as possible. well, i
don't 'stay away'...i simply think out a problem and work out its solution
in different terms than most...and i don't find myself using
if/else...generally, i just 'if' and 'switch' (but i don't do a whole run of
branching logic in those either). that's just me and it involves a whole
other approach to programming that i can't just dive right into and discuss
coherently.

Re: Code readability vs. execution time

On Tue, 04 Sep 2007 19:33:00 +0200, Michael Fesser wrot=
e:
> .oO(The Natural Philosopher)
>> Michael Fesser wrote:
>>>
>>> The second statement simply means that the value of $int, whatever i=
t
>>> may be, evaluates to FALSE.
>>>
>> but what is "false", in this context?
>
> The result after the type cast?

Yup.

>> Null length string? string
>> containing "0" Magic value?
>
> If you write
>
> if ($int) {...}
>
> then there's no other way for PHP than to cast the $int variable to a
> boolean, because that's what the 'if' statement expects. The manual
> explains in detail how this type casting works and which values evalua=
te
> to FALSE:
>
> Converting to boolean
> http://www.php.net/manual/en/language.types.boolean.php#lang uage.types=
..boolean.casting
>
> If you don't want that, then you should not rely on the automatic type=

> juggling, but better explain to PHP what you actually want to test for=
:
>
> if ($int !=3D 0) {...}

Indeed (allthough: $int !== 0). The cost of loose types is indeed a =
more =

strict comparison if needed (which is quite natural and simple once you =
=

get used to it).
-- =

Rik Wasmus

Re: Code readability vs. execution time

Marijn wrote:
> On Sep 4, 4:52 pm, Jerry Stuckle wrote:
>> ELINTPimp wrote:
>>> On Sep 4, 2:40 am, Marijn wrote:
>>>> Hi there,
>>>> Again a question with no simple yes or no answer at least, opinions
>>>> will probably be scattered so no unanimous yes or no answer ;)
>>>> What would you think is the best of the following to options given
>>>> that it is more likely that the databaseConnection is set?
>>>> SomeClass {
>>>> [.............]
>>>> /**
>>>> * Sets the connection to the database in use.
>>>> *
>>>> * @return DatabaseFactory
>>>> */
>>>> private function __getDatabaseConnection(){
>>>> if (isset($this->__databaseConnection)) {
>>>> return($this->__databaseConnection);
>>>> } else {
>>>> $this->__databaseConnection = new DatabaseFactory();
>>>> $this->__databaseConnection->create();
>>>> return($this->__databaseConnection);
>>>> };
>>>> }
>>>> }
>>>> Or
>>>> SomeClass {
>>>> [.............]
>>>> /**
>>>> * Sets the connection to the database in use.
>>>> *
>>>> * @return DatabaseFactory
>>>> */
>>>> private function __getDatabaseConnection(){
>>>> if (!$this->__databaseConnection) {
>>>> $this->__databaseConnection = new DatabaseFactory();
>>>> };
>>>> return($this->__databaseConnection);
>>>> }
>>>> }
>>>> The second option definitely has less repetitive code but does that
>>>> really make it the better option given the fact that the
>>>> databaseConnection property is probably set?
>>>> By the way, another small convention question: Should you terminate
>>>> control structures with a semicolon?
>>>> Thanks
>>>> Marijn
>>> >From looking at your code, it looks like you intend to put this
>>> connection function in all of your classes that need to talk to the
>>> database. Your code looks like it wants a singleton pattern.
>>> You're on the right path with your code, but why not abstract that
>>> logic to a class of its own (I assume mysql):
>>> class db {
>>> static private $_instance;
>>> public $connection;
>>> private __construct () {
>>> //do database initiation, such as loading config data and the like
>>> $this->connection = mysql_connect(...);
>>> //exception handling
>>> mysql_select_db($schema, $this->connection);
>>> //exception handling
>>> }
>>> public static function getInstance() {
>>> if (is_null(self::$_instance)) {
>>> self::$_instance = new db();
>>> }
>>> return self::$_instance;
>>> }
>>> } // end db class
>>> now, in your other classes, you simply type:
>>> class someClass {
>>> public function someMethod() {
>>> //just putting this in a generic method, but you could put it in
>>> the constructor, if you wish
>>> $db = db::getInstance();
>>> //and you connection handle is $db->connection
>>> }
>>> A lot less code in your classes, and a bit easier to understand in my
>>> opinion. Also has the advantages of encapsulation to the db
>>> connection so you can do fun things like centralizing exception
>>> handling and/or create some generic functions to handle your query
>>> formats, etc.
>> I do something very similar in my classes, and find it easier to use.
>>
>> However, there is a whole design concept around the Factory class, and
>> some people prefer it. It helps when you need to pass parameters to the
>> Factory, for instance, before actually creating the object.
>>
>> --
>> ==================
>> Remove the "x" from my email address
>> Jerry Stuckle
>> JDS Computer Training Corp.
>> jstuck...@attglobal.net
>> ==================
>
> Just returned from the office, boy did this get of topic ;)
>
> First My DatabaseFactory returns a singleton of a MySQL class (later
> on i can easily support other databases if i would prefer). I am
> thinking of making the DatabaseFactory itself a Singleton so that the
> Singleton logic does not need to be repeated in every database
> implementation.
>
> The reason why i have this function is that it is used in an abstract
> class for implementation of database objects in php. By extending the
> abstract class i easily can create a implementation of the database
> data with it's own methods. But i don't want to create the database
> connection before actualy using it.
>
> To solve the problem I will move my connection of the database from
> the database constructor to another function. The database resource
> can be created and only if a query method is called it will check if
> it is connected. If not connected connect else connect and query.
>
> Still i feel like people misunderstood my first question: What is
> better:
>
> if ($mostLikelyValue) {
> break;
> } else {
> performSomeAction();
> }
> theRequiredAction();
>

This has a side effect - if you're in a loop, it exits the loop. I think
you mean;

if ($mostLikelyValue) {
;
} else {


> OR
>
> if (!mostLikelyValue) {
> performSomeAction();
> }
> theRequiredAction();
>

Which I find much more readable.

> Where in my opinion the second one is more readable and the first one
> probably faster (?)
>

Speed difference will not be noticeable.

> On the naming conventions regarding access types:
>
> OK say i will go for my own path of naming variables, properties and
> parameters and there access type. Is that really more straightforward?
> I would rather have seen reserved normal function names for methods
> like __call() and __get and the
> no underscore for public, one underscore for protected and two
> underscores for private (or some other distinguishing character).
>

Don't use double underscores for anything. They should be reserved PHP
magic functions only. If you do use them, you will regret it later.

> Is there really no commonly used way (accept for the one that bluntly
> ignores protected)
>
> I really do like the way everybody mixes in and gets involved in a
> good way in these types of discussions. Thanks for that, love to hear
> more from you guys.
>

I don't worry about it. I don't have public variables, and very few
protected ones. And if I do have a protected variable, I'm looking at
the base class when developing the derived class, anyway.h

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================