Hi, I just made a suggestion to Thilina but I want to validate it with everyone.
I see a lot of $common_functions = PMA_CommonFunctions::getInstance()
inside many functions of the same library. If we know that this library is always called from one script, I believe it would be more efficient to do this instead, inside the functions:
global $common_functions;
and ensure that $common_functions has been defined in the global scope of the calling script.
On 03/07/12 14:34, Marc Delisle wrote:
Hi, I just made a suggestion to Thilina but I want to validate it with everyone.
I see a lot of $common_functions = PMA_CommonFunctions::getInstance()
inside many functions of the same library. If we know that this library is always called from one script, I believe it would be more efficient to do this instead, inside the functions:
global $common_functions;
and ensure that $common_functions has been defined in the global scope of the calling script.
Doesn't that defeat the purpose of having a singleton class?
Bye, Rouslan
Le 2012-07-03 09:38, Rouslan Placella a écrit :
On 03/07/12 14:34, Marc Delisle wrote:
Hi, I just made a suggestion to Thilina but I want to validate it with everyone.
I see a lot of $common_functions = PMA_CommonFunctions::getInstance()
inside many functions of the same library. If we know that this library is always called from one script, I believe it would be more efficient to do this instead, inside the functions:
global $common_functions;
and ensure that $common_functions has been defined in the global scope of the calling script.
Doesn't that defeat the purpose of having a singleton class?
Well, I don't understand the definition of a singleton. From [0], "the singleton pattern is a design pattern that restricts the instantiation of a class to one object"
Does that mean that one such object must exist inside a function, or must exist considering all scopes?
[0] http://en.wikipedia.org/wiki/Singleton_pattern
On 03/07/12 14:51, Marc Delisle wrote:
Le 2012-07-03 09:38, Rouslan Placella a écrit :
On 03/07/12 14:34, Marc Delisle wrote:
Hi, I just made a suggestion to Thilina but I want to validate it with everyone.
I see a lot of $common_functions = PMA_CommonFunctions::getInstance()
inside many functions of the same library. If we know that this library is always called from one script, I believe it would be more efficient to do this instead, inside the functions:
global $common_functions;
and ensure that $common_functions has been defined in the global scope of the calling script.
Doesn't that defeat the purpose of having a singleton class?
Well, I don't understand the definition of a singleton. From [0], "the singleton pattern is a design pattern that restricts the instantiation of a class to one object"
Does that mean that one such object must exist inside a function, or must exist considering all scopes?
There will be only one in all scopes. However I thought that we were trying to reduce the number of globals that we have, since sometimes we get problems with undefined globals. Also, if we have a global reference to the commonFunctions object, then I see no point in restricting the number of instances.
Le 2012-07-03 10:00, Rouslan Placella a écrit :
On 03/07/12 14:51, Marc Delisle wrote:
Le 2012-07-03 09:38, Rouslan Placella a écrit :
On 03/07/12 14:34, Marc Delisle wrote:
Hi, I just made a suggestion to Thilina but I want to validate it with everyone.
I see a lot of $common_functions = PMA_CommonFunctions::getInstance()
inside many functions of the same library. If we know that this library is always called from one script, I believe it would be more efficient to do this instead, inside the functions:
global $common_functions;
and ensure that $common_functions has been defined in the global scope of the calling script.
Doesn't that defeat the purpose of having a singleton class?
Well, I don't understand the definition of a singleton. From [0], "the singleton pattern is a design pattern that restricts the instantiation of a class to one object"
Does that mean that one such object must exist inside a function, or must exist considering all scopes?
There will be only one in all scopes. However I thought that we were trying to reduce the number of globals that we have, since sometimes we get problems with undefined globals. Also, if we have a global reference to the commonFunctions object, then I see no point in restricting the number of instances.
Ok, so what do you think of this code snippet:
$query[] = $insert_command . 'INTO ' . PMA_CommonFunctions::getInstance()->backquote($GLOBALS['db']) . '.' . PMA_CommonFunctions::getInstance()->backquote($GLOBALS['table']) . ' (' . implode(', ', $query_fields) . ') VALUES (' . implode('), (', $value_sets) . ')';
Does this follow the singleton principle?
On 03/07/12 15:05, Marc Delisle wrote:
Le 2012-07-03 10:00, Rouslan Placella a écrit :
On 03/07/12 14:51, Marc Delisle wrote:
Le 2012-07-03 09:38, Rouslan Placella a écrit :
On 03/07/12 14:34, Marc Delisle wrote:
Hi, I just made a suggestion to Thilina but I want to validate it with everyone.
I see a lot of $common_functions = PMA_CommonFunctions::getInstance()
inside many functions of the same library. If we know that this library is always called from one script, I believe it would be more efficient to do this instead, inside the functions:
global $common_functions;
and ensure that $common_functions has been defined in the global scope of the calling script.
Doesn't that defeat the purpose of having a singleton class?
Well, I don't understand the definition of a singleton. From [0], "the singleton pattern is a design pattern that restricts the instantiation of a class to one object"
Does that mean that one such object must exist inside a function, or must exist considering all scopes?
There will be only one in all scopes. However I thought that we were trying to reduce the number of globals that we have, since sometimes we get problems with undefined globals. Also, if we have a global reference to the commonFunctions object, then I see no point in restricting the number of instances.
Ok, so what do you think of this code snippet:
$query[] = $insert_command . 'INTO ' . PMA_CommonFunctions::getInstance()->backquote($GLOBALS['db']) . '.' . PMA_CommonFunctions::getInstance()->backquote($GLOBALS['table']) . ' (' . implode(', ', $query_fields) . ') VALUES (' . implode('), (', $value_sets) . ')';
Does this follow the singleton principle?
I don't know about following the principle, but it looks ugly. There should definitely be a local reference to the commonFunctions object.
$commonFunctions = PMA_CommonFunctions::getInstance(); $query[] = $insert_command . 'INTO ' . $commonFunctions->backquote($GLOBALS['db']) . '.' . $commonFunctions->backquote($GLOBALS['table']) . ' (' . implode(', ', $query_fields) . ') VALUES (' . implode('), (', $value_sets) . ')';
Le 2012-07-03 10:11, Rouslan Placella a écrit :
On 03/07/12 15:05, Marc Delisle wrote:
Le 2012-07-03 10:00, Rouslan Placella a écrit :
On 03/07/12 14:51, Marc Delisle wrote:
Le 2012-07-03 09:38, Rouslan Placella a écrit :
On 03/07/12 14:34, Marc Delisle wrote:
Hi, I just made a suggestion to Thilina but I want to validate it with everyone.
I see a lot of $common_functions = PMA_CommonFunctions::getInstance()
inside many functions of the same library. If we know that this library is always called from one script, I believe it would be more efficient to do this instead, inside the functions:
global $common_functions;
and ensure that $common_functions has been defined in the global scope of the calling script.
Doesn't that defeat the purpose of having a singleton class?
Well, I don't understand the definition of a singleton. From [0], "the singleton pattern is a design pattern that restricts the instantiation of a class to one object"
Does that mean that one such object must exist inside a function, or must exist considering all scopes?
There will be only one in all scopes. However I thought that we were trying to reduce the number of globals that we have, since sometimes we get problems with undefined globals. Also, if we have a global reference to the commonFunctions object, then I see no point in restricting the number of instances.
Ok, so what do you think of this code snippet:
$query[] = $insert_command . 'INTO ' . PMA_CommonFunctions::getInstance()->backquote($GLOBALS['db']) . '.' . PMA_CommonFunctions::getInstance()->backquote($GLOBALS['table']) . ' (' . implode(', ', $query_fields) . ') VALUES (' . implode('), (', $value_sets) . ')';
Does this follow the singleton principle?
I don't know about following the principle, but it looks ugly. There should definitely be a local reference to the commonFunctions object.
$commonFunctions = PMA_CommonFunctions::getInstance(); $query[] = $insert_command . 'INTO ' . $commonFunctions->backquote($GLOBALS['db']) . '.' . $commonFunctions->backquote($GLOBALS['table']) . ' (' . implode(', ', $query_fields) . ') VALUES (' . implode('), (', $value_sets) . ')';
I agree; however, in a previous reply you said "There will be only one in all scopes" so I'm confused. Setting $commonFunctions this way in each function, has for effect that multiple instances of this kind of object will exist in all scopes.
On 03/07/12 15:42, Marc Delisle wrote:
Le 2012-07-03 10:11, Rouslan Placella a écrit :
On 03/07/12 15:05, Marc Delisle wrote:
Le 2012-07-03 10:00, Rouslan Placella a écrit :
On 03/07/12 14:51, Marc Delisle wrote:
Le 2012-07-03 09:38, Rouslan Placella a écrit :
On 03/07/12 14:34, Marc Delisle wrote: > Hi, > I just made a suggestion to Thilina but I want to validate it with > everyone. > > I see a lot of > $common_functions = PMA_CommonFunctions::getInstance() > > inside many functions of the same library. If we know that this library > is always called from one script, I believe it would be more efficient > to do this instead, inside the functions: > > global $common_functions; > > and ensure that $common_functions has been defined in the global scope > of the calling script. >
Doesn't that defeat the purpose of having a singleton class?
Well, I don't understand the definition of a singleton. From [0], "the singleton pattern is a design pattern that restricts the instantiation of a class to one object"
Does that mean that one such object must exist inside a function, or must exist considering all scopes?
There will be only one in all scopes. However I thought that we were trying to reduce the number of globals that we have, since sometimes we get problems with undefined globals. Also, if we have a global reference to the commonFunctions object, then I see no point in restricting the number of instances.
Ok, so what do you think of this code snippet:
$query[] = $insert_command . 'INTO ' . PMA_CommonFunctions::getInstance()->backquote($GLOBALS['db']) . '.' . PMA_CommonFunctions::getInstance()->backquote($GLOBALS['table']) . ' (' . implode(', ', $query_fields) . ') VALUES (' . implode('), (', $value_sets) . ')';
Does this follow the singleton principle?
I don't know about following the principle, but it looks ugly. There should definitely be a local reference to the commonFunctions object.
$commonFunctions = PMA_CommonFunctions::getInstance(); $query[] = $insert_command . 'INTO ' . $commonFunctions->backquote($GLOBALS['db']) . '.' . $commonFunctions->backquote($GLOBALS['table']) . ' (' . implode(', ', $query_fields) . ') VALUES (' . implode('), (', $value_sets) . ')';
I agree; however, in a previous reply you said "There will be only one in all scopes" so I'm confused. Setting $commonFunctions this way in each function, has for effect that multiple instances of this kind of object will exist in all scopes.
The will all be references to the same object. Like pointers in C or C++.
Le 2012-07-03 10:44, Rouslan Placella a écrit :
On 03/07/12 15:42, Marc Delisle wrote:
Le 2012-07-03 10:11, Rouslan Placella a écrit :
On 03/07/12 15:05, Marc Delisle wrote:
Le 2012-07-03 10:00, Rouslan Placella a écrit :
On 03/07/12 14:51, Marc Delisle wrote:
Le 2012-07-03 09:38, Rouslan Placella a écrit : > On 03/07/12 14:34, Marc Delisle wrote: >> Hi, >> I just made a suggestion to Thilina but I want to validate it with >> everyone. >> >> I see a lot of >> $common_functions = PMA_CommonFunctions::getInstance() >> >> inside many functions of the same library. If we know that this library >> is always called from one script, I believe it would be more efficient >> to do this instead, inside the functions: >> >> global $common_functions; >> >> and ensure that $common_functions has been defined in the global scope >> of the calling script. >> > > Doesn't that defeat the purpose of having a singleton class?
Well, I don't understand the definition of a singleton. From [0], "the singleton pattern is a design pattern that restricts the instantiation of a class to one object"
Does that mean that one such object must exist inside a function, or must exist considering all scopes?
There will be only one in all scopes. However I thought that we were trying to reduce the number of globals that we have, since sometimes we get problems with undefined globals. Also, if we have a global reference to the commonFunctions object, then I see no point in restricting the number of instances.
Ok, so what do you think of this code snippet:
$query[] = $insert_command . 'INTO ' . PMA_CommonFunctions::getInstance()->backquote($GLOBALS['db']) . '.' . PMA_CommonFunctions::getInstance()->backquote($GLOBALS['table']) . ' (' . implode(', ', $query_fields) . ') VALUES (' . implode('), (', $value_sets) . ')';
Does this follow the singleton principle?
I don't know about following the principle, but it looks ugly. There should definitely be a local reference to the commonFunctions object.
$commonFunctions = PMA_CommonFunctions::getInstance(); $query[] = $insert_command . 'INTO ' . $commonFunctions->backquote($GLOBALS['db']) . '.' . $commonFunctions->backquote($GLOBALS['table']) . ' (' . implode(', ', $query_fields) . ') VALUES (' . implode('), (', $value_sets) . ')';
I agree; however, in a previous reply you said "There will be only one in all scopes" so I'm confused. Setting $commonFunctions this way in each function, has for effect that multiple instances of this kind of object will exist in all scopes.
The will all be references to the same object. Like pointers in C or C++.
Ok, now I get it. So, let's forget about my suggestion of having a global variable.
Hi Marc,
Ok, so what do you think of this code snippet:
$query[] = $insert_command . 'INTO ' . PMA_CommonFunctions::getInstance()->backquote($GLOBALS['db']) . '.' . PMA_CommonFunctions::getInstance()->backquote($GLOBALS['table']) . ' (' . implode(', ', $query_fields) . ') VALUES (' . implode('), (', $value_sets) . ')';
Does this follow the singleton principle?
As I think this doesn't break the singleton principle since we are not creating two objects. Since the private constructor always give the existing PMA_CommonFunctions object if there exist any, no more objects are created.
Actually why I used that $common_functions variable is, reducing the line length and if there are frequent occurrence inside procedural code or function, its easy to use a variable than this lengthy code. As well we have discussed to reduce the use of globals.
Please make me correct if I did any wrong.
Regards !
Le 2012-07-03 10:46, Chanaka Dharmarathna a écrit :
Hi Marc,
Ok, so what do you think of this code snippet:
$query[] = $insert_command . 'INTO ' . PMA_CommonFunctions::getInstance()->backquote($GLOBALS['db']) . '.' . PMA_CommonFunctions::getInstance()->backquote($GLOBALS['table']) . ' (' . implode(', ', $query_fields) . ') VALUES (' . implode('), (', $value_sets) . ')';
Does this follow the singleton principle?
As I think this doesn't break the singleton principle since we are not creating two objects. Since the private constructor always give the existing PMA_CommonFunctions object if there exist any, no more objects are created.
Actually why I used that $common_functions variable is, reducing the line length and if there are frequent occurrence inside procedural code or function, its easy to use a variable than this lengthy code. As well we have discussed to reduce the use of globals.
Please make me correct if I did any wrong.
Regards !
Thanks Chanaka for the clarification. I think that using a local $common_functions is a good idea and we should use it most (all?) of the times: it makes reading code easier if we have just one way of accessing this object.
-
Chanaka Dharmarathna -
Marc Delisle -
Rouslan Placella