scott.mcnaught@synergy8.com wrote in message
news:001101c7630e$0cad1470$0900a8c0@scottnote...Yeah that's the same way that I implement it. You're still using
strings
for referencing class names.So what? Is there an alternative method? Does it have any advantages?
Yes! Moving the singleton functionality into core php. Its an excellent
OOP feature.
Sorry my file didn't get attached when sent to the list.
http://hlrally.net/media/singletonabc.incThe advantages are:
- Speed improvements
Where is your proof?
Think about it. You won't be calling upon php code every time you want
just to return an instance of a class. I'm sure APC (and others) could
run the usage code faster because they are given the ability to store a
class name rather than strings.
- Allows for context sensitive code hinting in IDEs
How is this of benefit?
... ! ... you must use a text editor such as vi or notepad... (not that
theres anything wrong with that)
- Simplicity
I disagree. My method is simpler and more intuitive than yours, and does
not
need any changes in core PHP.
The only difference between my method
(http://hlrally.net/media/singletonabc.inc) and yours is that
- You have a local static variable for your table of instances
- You dont inherit from the singleton class
- You dont enforce a protected constructor (so multiple instances could be
created by noobs) - You have some lame hack to translate the names of 3 of your classes to
files - You allow for an argument to be passed to your constructor (usually
considered bad practise with singletons anyway)
When I said simplicity, I was meaning using the native singleton method,
its easy for the programmer. They dont need to write their own singleton
management class (or research them on tutorial sites). And the usage
(accessing the singleton) can be made simpler as well.
- Encourages good coding practices for amateur programmers
I disagree. What is "good" to you is "not good" to others. There is more
than one way of implementing the singleton pattern, (or any design pattern
for that matter) so trying to enforce one particular method is just too
short sighted for my taste.
You can always still implement the variations using php. All Im proposing
is a simple mechanism for implementing single instance classes. I think
everyone needs to use this.
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org-----Original Message-----
From: Tony Marston [mailto:tony@marston-home.demon.co.uk]
Sent: Saturday, 10 March 2007 9:55 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Native Singleton Implementationscott.mcnaught@synergy8.com wrote in message
news:001a01c762b8$805d6f60$0900a8c0@scottnote...Hi Tony,
I do have a single singleton class to deal with singletons (as you put
it).
I have attached it to this email for your reference.But it's back to my original problem where you either have to:
- Duplicate code for each singleton class ... or ...
- Reference your classes via strings (slower, stops code hinting from
working etc)I see no such problem with my implementation of a single class for
singletons.I use method two as you do and it is not nice. There is no nice way of
implementing singleton in php.I disagree. Take a look at
http://www.tonymarston.net/php-mysql/singleton.html#global.helper.with.loade
rHave a full read of
http://bugs.php.net/bug.php?id=39946Also, with three tiered architecture, there is even more reason to use
singleton. You have yet another layer, filled with classes that need
only
be
instantiated once. I think as a developer that uses tiered
architecture,
you would benefit greatly from this feature.I already have a more-than-adequate method of dealing with singletons
(see
http://www.tonymarston.net/php-mysql/singleton.html#global.helper.with.loade
r)
and I see absolutely no advantage in the method which you propose.
Putting
this into core PHP would be of no benefit to anyone.--
Tony Marston
http://www.tonymarston.net
http://www.radicore.orgScott
-----Original Message-----
From: Tony Marston [mailto:tony@marston-home.demon.co.uk]
Sent: Friday, 9 March 2007 11:39 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Native Singleton Implementationscott.mcnaught@synergy8.com wrote in message
news:001a01c75ffd$fa352520$0900a8c0@scottnote...Hi Greg,
There is no reason why you can't still use the current method to
implement
your variations to the singleton design pattern. But, yes, I am
proposing
that the strict "text book" variety is implemented.There is no strict "text book" implementation of the singleton pattern.
There are different implementations in different languages, so it is
not
possible to decide that one implementation is "pure" while all the
others
are "impure". My personal choice is to avoid a singleton method withn
each
class and have a single singleton class instead, thus avoiding a lot of
codeduplication.
If you haven't had the need to singleton-ize more than 2-3 classes,
you
probably haven't worked with tiered architecture, or haven't thought
to
use
singleton in this situation.I use a single singleton class which can instaniate any number of
database
table objects in my business layer, but I only have a single object in
my
data access layer. This object is instantiated from a class which is
specific to the DBMS being used (MySQL, PstreSQL, or Oracle).The way I work is with two-tiered architecture. I have a presentation
tier
which consists of HTML and php which renders the HTML. I then have a
second
tier which is a data access tier.The 3 Tier Architecture is better - presentation, business (domain) and
dataaccess - as it provides for a beter separation of responsibiities.
In the data access tier, I have one class
for each database table. In these classes there are SQL statements
for
saving, retrieving records, in fact any operation that I do to the
table.
No SQL resides outside of the table's data access class. Each one of
these
classes is a singleton.There are two things that a native singleton implementation would
solve:
At the data access layer, it is nasty to duplicate the singleton
pattern
for each class, (or worse, work with strings for class names).From the presentation layer, it is ugly to work with the data access
singletons.Example: A page in the presentation tier which lists all news posts
<?php foreach(getInstance('content_news_items')->getAll() as $post){
<h1><?php echo($post['news_item_heading']) ?></h1> <p><?php echo($post[' news_item_contents']) ?></p>
?><?php } ?>
It would be nicer (and much more efficient) to be able to go:
<?php foreach(content_news_items->getAll() as $post){ ?>
<h1><?php echo($post['news_item_heading']) ?></h1> <p><?php echo($post[' news_item_contents']) ?></p><?php } ?>
I actually have about 50 singleton classes in my current project, and
trust
me, they are all warranted.If you are complaining that your 50 singleton classes produces too much
duplicated code, then your implementation is wrong. If you have a
single
class to deal wth singletons then there is no code duplication.I do not think it is a good idea to implement a new "feature" into core
PHP
which serves no useful purpose other than to disguise inefficent coding
practices.--
Tony Marston
http://www.tonymarston.net
http://www.radicore.orgI have put a copy of a screen shot of my
eclipse project at:
http://hlrally.net/media/content_pages/gotsingleton.png
I put a blue line next to the singleton classes. The folder
"components"
represents the data access layer. The presentation layer is not seen
in
that shot.Now we all have different programming styles and use different
architectural
principles to each other. Just remember this is not a debate about
what
architecture is better etc. I am just showing an example.Scott
-----Original Message-----
From: Gregory Beaver [mailto:greg@chiaraquartet.net]
Sent: Tuesday, 6 March 2007 4:12 PM
To: toomuchphp-phpdev@yahoo.com
Cc: scott.mcnaught@synergy8.com; 'Guilherme Blanco';
internals@lists.php.net
Subject: Re: [PHP-DEV] Native Singleton ImplementationPeter Hodge wrote:
You should just need to:
- add T_SINGLETON to the parser.
- add an is_singleton flag for class definitions, activated by
T_SINGLETON.- overload the 'new' operator to retrieve from the hash table if the
class
is a
singleton (otherwise call __construct() as normal).- implement some of those helper functions such as
singleton_getobjects().Hi,
This seems both to be excessively magical and inflexible. For
instance,
I have implemented global singletons, singleton per-configuration path
(i.e. for a configuration object with cascading configuration files,
one
singleton per configuration file location), and other models for
singleton that stray on the continuum between singleton and factory.
The proposed implementation allows only the textbook singleton.The benefit of having singleton in the zend engine in my book is zero.
If you have 10 gazillion classes that are all singletons, perhaps
another look at the design is in order? I've never had to
singleton-ize
more than 2-3 classes in even the most complex projects I've been
involved with.Greg
scott.mcnaught@synergy8.com wrote in message
news:36961.127.0.0.1.1173580198.squirrel@synergy8.com...
scott.mcnaught@synergy8.com wrote in message
news:001101c7630e$0cad1470$0900a8c0@scottnote...Yeah that's the same way that I implement it. You're still using
strings
for referencing class names.So what? Is there an alternative method? Does it have any advantages?
Yes! Moving the singleton functionality into core php. Its an excellent
OOP feature.
Does such a feature exist in any other languages?
What is the point of putting just one possible solution into core PHP when
there are plenty of acceptable solutions already out there in userland?
What is the problem with using strings to reference class names?
It sounds like you want core PHP to change just beause there is a problem
with your code. If you changed your code there would be no problem.
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
Sorry my file didn't get attached when sent to the list.
http://hlrally.net/media/singletonabc.incThe advantages are:
- Speed improvements
Where is your proof?
Think about it. You won't be calling upon php code every time you want
just to return an instance of a class. I'm sure APC (and others) could
run the usage code faster because they are given the ability to store a
class name rather than strings.
- Allows for context sensitive code hinting in IDEs
How is this of benefit?
... ! ... you must use a text editor such as vi or notepad... (not that
theres anything wrong with that)
- Simplicity
I disagree. My method is simpler and more intuitive than yours, and does
not
need any changes in core PHP.The only difference between my method
(http://hlrally.net/media/singletonabc.inc) and yours is that
- You have a local static variable for your table of instances
- You dont inherit from the singleton class
- You dont enforce a protected constructor (so multiple instances could be
created by noobs)- You have some lame hack to translate the names of 3 of your classes to
files- You allow for an argument to be passed to your constructor (usually
considered bad practise with singletons anyway)When I said simplicity, I was meaning using the native singleton method,
its easy for the programmer. They dont need to write their own singleton
management class (or research them on tutorial sites). And the usage
(accessing the singleton) can be made simpler as well.
- Encourages good coding practices for amateur programmers
I disagree. What is "good" to you is "not good" to others. There is more
than one way of implementing the singleton pattern, (or any design
pattern
for that matter) so trying to enforce one particular method is just too
short sighted for my taste.You can always still implement the variations using php. All Im proposing
is a simple mechanism for implementing single instance classes. I think
everyone needs to use this.--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org-----Original Message-----
From: Tony Marston [mailto:tony@marston-home.demon.co.uk]
Sent: Saturday, 10 March 2007 9:55 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Native Singleton Implementationscott.mcnaught@synergy8.com wrote in message
news:001a01c762b8$805d6f60$0900a8c0@scottnote...Hi Tony,
I do have a single singleton class to deal with singletons (as you put
it).
I have attached it to this email for your reference.But it's back to my original problem where you either have to:
- Duplicate code for each singleton class ... or ...
- Reference your classes via strings (slower, stops code hinting from
working etc)I see no such problem with my implementation of a single class for
singletons.I use method two as you do and it is not nice. There is no nice way of
implementing singleton in php.I disagree. Take a look at
http://www.tonymarston.net/php-mysql/singleton.html#global.helper.with.loade
rHave a full read of
http://bugs.php.net/bug.php?id=39946Also, with three tiered architecture, there is even more reason to use
singleton. You have yet another layer, filled with classes that need
only
be
instantiated once. I think as a developer that uses tiered
architecture,
you would benefit greatly from this feature.I already have a more-than-adequate method of dealing with singletons
(see
http://www.tonymarston.net/php-mysql/singleton.html#global.helper.with.loade
r)
and I see absolutely no advantage in the method which you propose.
Putting
this into core PHP would be of no benefit to anyone.--
Tony Marston
http://www.tonymarston.net
http://www.radicore.orgScott
-----Original Message-----
From: Tony Marston [mailto:tony@marston-home.demon.co.uk]
Sent: Friday, 9 March 2007 11:39 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Native Singleton Implementationscott.mcnaught@synergy8.com wrote in message
news:001a01c75ffd$fa352520$0900a8c0@scottnote...Hi Greg,
There is no reason why you can't still use the current method to
implement
your variations to the singleton design pattern. But, yes, I am
proposing
that the strict "text book" variety is implemented.There is no strict "text book" implementation of the singleton pattern.
There are different implementations in different languages, so it is
not
possible to decide that one implementation is "pure" while all the
others
are "impure". My personal choice is to avoid a singleton method withn
each
class and have a single singleton class instead, thus avoiding a lot of
codeduplication.
If you haven't had the need to singleton-ize more than 2-3 classes,
you
probably haven't worked with tiered architecture, or haven't thought
to
use
singleton in this situation.I use a single singleton class which can instaniate any number of
database
table objects in my business layer, but I only have a single object in
my
data access layer. This object is instantiated from a class which is
specific to the DBMS being used (MySQL, PstreSQL, or Oracle).The way I work is with two-tiered architecture. I have a presentation
tier
which consists of HTML and php which renders the HTML. I then have a
second
tier which is a data access tier.The 3 Tier Architecture is better - presentation, business (domain) and
dataaccess - as it provides for a beter separation of responsibiities.
In the data access tier, I have one class
for each database table. In these classes there are SQL statements
for
saving, retrieving records, in fact any operation that I do to the
table.
No SQL resides outside of the table's data access class. Each one of
these
classes is a singleton.There are two things that a native singleton implementation would
solve:
At the data access layer, it is nasty to duplicate the singleton
pattern
for each class, (or worse, work with strings for class names).From the presentation layer, it is ugly to work with the data access
singletons.Example: A page in the presentation tier which lists all news posts
<?php foreach(getInstance('content_news_items')->getAll() as $post){
<h1><?php echo($post['news_item_heading']) ?></h1> <p><?php echo($post[' news_item_contents']) ?></p>
?><?php } ?>
It would be nicer (and much more efficient) to be able to go:
<?php foreach(content_news_items->getAll() as $post){ ?>
<h1><?php echo($post['news_item_heading']) ?></h1> <p><?php echo($post[' news_item_contents']) ?></p><?php } ?>
I actually have about 50 singleton classes in my current project, and
trust
me, they are all warranted.If you are complaining that your 50 singleton classes produces too much
duplicated code, then your implementation is wrong. If you have a
single
class to deal wth singletons then there is no code duplication.I do not think it is a good idea to implement a new "feature" into core
PHP
which serves no useful purpose other than to disguise inefficent coding
practices.--
Tony Marston
http://www.tonymarston.net
http://www.radicore.orgI have put a copy of a screen shot of my
eclipse project at:
http://hlrally.net/media/content_pages/gotsingleton.png
I put a blue line next to the singleton classes. The folder
"components"
represents the data access layer. The presentation layer is not seen
in
that shot.Now we all have different programming styles and use different
architectural
principles to each other. Just remember this is not a debate about
what
architecture is better etc. I am just showing an example.Scott
-----Original Message-----
From: Gregory Beaver [mailto:greg@chiaraquartet.net]
Sent: Tuesday, 6 March 2007 4:12 PM
To: toomuchphp-phpdev@yahoo.com
Cc: scott.mcnaught@synergy8.com; 'Guilherme Blanco';
internals@lists.php.net
Subject: Re: [PHP-DEV] Native Singleton ImplementationPeter Hodge wrote:
You should just need to:
- add T_SINGLETON to the parser.
- add an is_singleton flag for class definitions, activated by
T_SINGLETON.- overload the 'new' operator to retrieve from the hash table if the
class
is a
singleton (otherwise call __construct() as normal).- implement some of those helper functions such as
singleton_getobjects().Hi,
This seems both to be excessively magical and inflexible. For
instance,
I have implemented global singletons, singleton per-configuration path
(i.e. for a configuration object with cascading configuration files,
one
singleton per configuration file location), and other models for
singleton that stray on the continuum between singleton and factory.
The proposed implementation allows only the textbook singleton.The benefit of having singleton in the zend engine in my book is zero.
If you have 10 gazillion classes that are all singletons, perhaps
another look at the design is in order? I've never had to
singleton-ize
more than 2-3 classes in even the most complex projects I've been
involved with.Greg
Does such a feature exist in any other languages?
Not that I know of. But does that mean it's a bad idea?
What is the point of putting just one possible solution into core PHP when
there are plenty of acceptable solutions already out there in userland?
That is like saying what's the point in having object oriented programming
with features like inheritance. Why have inheritance in JavaScript when you
can implement it in userland with an internal instance of the objects
parent? Languages have features that help programmers. Don't a lot of
people make a lot of single instance classes? I know I do.
What is the problem with using strings to reference class names?
It's not a problem as such. My code works well (and there's no issue with
speed). But it is annoying.
It sounds like you want core PHP to change just beause there is a problem
with your code. If you changed your code there would be no problem.
I'm not wanting php to change for problems in my code. I am only suggesting
a possible feature to improve how both you and I program.
Scott
Sorry my file didn't get attached when sent to the list.
http://hlrally.net/media/singletonabc.incThe advantages are:
- Speed improvements
Where is your proof?
Think about it. You won't be calling upon php code every time you want
just to return an instance of a class. I'm sure APC (and others) could
run the usage code faster because they are given the ability to store a
class name rather than strings.
- Allows for context sensitive code hinting in IDEs
How is this of benefit?
... ! ... you must use a text editor such as vi or notepad... (not that
theres anything wrong with that)
- Simplicity
I disagree. My method is simpler and more intuitive than yours, and does
not
need any changes in core PHP.The only difference between my method
(http://hlrally.net/media/singletonabc.inc) and yours is that
- You have a local static variable for your table of instances
- You dont inherit from the singleton class
- You dont enforce a protected constructor (so multiple instances could be
created by noobs)- You have some lame hack to translate the names of 3 of your classes to
files- You allow for an argument to be passed to your constructor (usually
considered bad practise with singletons anyway)When I said simplicity, I was meaning using the native singleton method,
its easy for the programmer. They dont need to write their own singleton
management class (or research them on tutorial sites). And the usage
(accessing the singleton) can be made simpler as well.
- Encourages good coding practices for amateur programmers
I disagree. What is "good" to you is "not good" to others. There is more
than one way of implementing the singleton pattern, (or any design
pattern
for that matter) so trying to enforce one particular method is just too
short sighted for my taste.You can always still implement the variations using php. All Im proposing
is a simple mechanism for implementing single instance classes. I think
everyone needs to use this.--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org-----Original Message-----
From: Tony Marston [mailto:tony@marston-home.demon.co.uk]
Sent: Saturday, 10 March 2007 9:55 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Native Singleton Implementationscott.mcnaught@synergy8.com wrote in message
news:001a01c762b8$805d6f60$0900a8c0@scottnote...Hi Tony,
I do have a single singleton class to deal with singletons (as you put
it).
I have attached it to this email for your reference.But it's back to my original problem where you either have to:
- Duplicate code for each singleton class ... or ...
- Reference your classes via strings (slower, stops code hinting from
working etc)I see no such problem with my implementation of a single class for
singletons.I use method two as you do and it is not nice. There is no nice way of
implementing singleton in php.I disagree. Take a look at
http://www.tonymarston.net/php-mysql/singleton.html#global.helper.with.loade
r
Have a full read of
http://bugs.php.net/bug.php?id=39946Also, with three tiered architecture, there is even more reason to use
singleton. You have yet another layer, filled with classes that need
only
be
instantiated once. I think as a developer that uses tiered
architecture,
you would benefit greatly from this feature.I already have a more-than-adequate method of dealing with singletons
(see
http://www.tonymarston.net/php-mysql/singleton.html#global.helper.with.loade
r)
and I see absolutely no advantage in the method which you propose.
Putting
this into core PHP would be of no benefit to anyone.--
Tony Marston
http://www.tonymarston.net
http://www.radicore.orgScott
-----Original Message-----
From: Tony Marston [mailto:tony@marston-home.demon.co.uk]
Sent: Friday, 9 March 2007 11:39 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Native Singleton Implementationscott.mcnaught@synergy8.com wrote in message
news:001a01c75ffd$fa352520$0900a8c0@scottnote...Hi Greg,
There is no reason why you can't still use the current method to
implement
your variations to the singleton design pattern. But, yes, I am
proposing
that the strict "text book" variety is implemented.There is no strict "text book" implementation of the singleton pattern.
There are different implementations in different languages, so it is
not
possible to decide that one implementation is "pure" while all the
others
are "impure". My personal choice is to avoid a singleton method withn
each
class and have a single singleton class instead, thus avoiding a lot of
codeduplication.
If you haven't had the need to singleton-ize more than 2-3 classes,
you
probably haven't worked with tiered architecture, or haven't thought
to
use
singleton in this situation.I use a single singleton class which can instaniate any number of
database
table objects in my business layer, but I only have a single object in
my
data access layer. This object is instantiated from a class which is
specific to the DBMS being used (MySQL, PstreSQL, or Oracle).The way I work is with two-tiered architecture. I have a presentation
tier
which consists of HTML and php which renders the HTML. I then have a
second
tier which is a data access tier.The 3 Tier Architecture is better - presentation, business (domain) and
dataaccess - as it provides for a beter separation of responsibiities.
In the data access tier, I have one class
for each database table. In these classes there are SQL statements
for
saving, retrieving records, in fact any operation that I do to the
table.
No SQL resides outside of the table's data access class. Each one of
these
classes is a singleton.There are two things that a native singleton implementation would
solve:
At the data access layer, it is nasty to duplicate the singleton
pattern
for each class, (or worse, work with strings for class names).From the presentation layer, it is ugly to work with the data access
singletons.Example: A page in the presentation tier which lists all news posts
<?php foreach(getInstance('content_news_items')->getAll() as $post){
<h1><?php echo($post['news_item_heading']) ?></h1> <p><?php echo($post[' news_item_contents']) ?></p>
?><?php } ?>
It would be nicer (and much more efficient) to be able to go:
<?php foreach(content_news_items->getAll() as $post){ ?>
<h1><?php echo($post['news_item_heading']) ?></h1> <p><?php echo($post[' news_item_contents']) ?></p><?php } ?>
I actually have about 50 singleton classes in my current project, and
trust
me, they are all warranted.If you are complaining that your 50 singleton classes produces too much
duplicated code, then your implementation is wrong. If you have a
single
class to deal wth singletons then there is no code duplication.I do not think it is a good idea to implement a new "feature" into core
PHP
which serves no useful purpose other than to disguise inefficent coding
practices.--
Tony Marston
http://www.tonymarston.net
http://www.radicore.orgI have put a copy of a screen shot of my
eclipse project at:
http://hlrally.net/media/content_pages/gotsingleton.png
I put a blue line next to the singleton classes. The folder
"components"
represents the data access layer. The presentation layer is not seen
in
that shot.Now we all have different programming styles and use different
architectural
principles to each other. Just remember this is not a debate about
what
architecture is better etc. I am just showing an example.Scott
-----Original Message-----
From: Gregory Beaver [mailto:greg@chiaraquartet.net]
Sent: Tuesday, 6 March 2007 4:12 PM
To: toomuchphp-phpdev@yahoo.com
Cc: scott.mcnaught@synergy8.com; 'Guilherme Blanco';
internals@lists.php.net
Subject: Re: [PHP-DEV] Native Singleton ImplementationPeter Hodge wrote:
You should just need to:
- add T_SINGLETON to the parser.
- add an is_singleton flag for class definitions, activated by
T_SINGLETON.- overload the 'new' operator to retrieve from the hash table if the
class
is a
singleton (otherwise call __construct() as normal).- implement some of those helper functions such as
singleton_getobjects().Hi,
This seems both to be excessively magical and inflexible. For
instance,
I have implemented global singletons, singleton per-configuration path
(i.e. for a configuration object with cascading configuration files,
one
singleton per configuration file location), and other models for
singleton that stray on the continuum between singleton and factory.
The proposed implementation allows only the textbook singleton.The benefit of having singleton in the zend engine in my book is zero.
If you have 10 gazillion classes that are all singletons, perhaps
another look at the design is in order? I've never had to
singleton-ize
more than 2-3 classes in even the most complex projects I've been
involved with.Greg
scott.mcnaught@synergy8.com wrote:
Yes! Moving the singleton functionality into core php. Its an excellent
OOP feature.
Besides the obvious implementation considerations (should the Singleton
object be unique in a single PHP instance or across "all" PHP instances,
etc.), I am very much against putting reference implementations of
design patterns into a programming language. If you want this, you have
not understood the intention of design patterns (or the difference (in
degrees of freedom) when compared to algorithms).
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
Perhaps I should not call it singleton then. Because I'm not trying to put
a flexible design pattern with large degrees of freedom as such into core
php. All I am trying to achieve is a nice way for people to implement
classes that only ever need one instance.
Can I ask why you are very much against this if you are? It seems that most
people need to do this at some point. I am starting to feel there's a lot
of negativity towards this because it's a different approach.
Good point about the uniqueness across one / all php instances. I was only
thinking of one unique instance for just the current php instance / request.
Definitely something to consider.
-----Original Message-----
From: Sebastian Bergmann [mailto:sb@sebastian-bergmann.de]
Sent: Sunday, 11 March 2007 8:26 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Native Singleton Implementation
scott.mcnaught@synergy8.com wrote:
Yes! Moving the singleton functionality into core php. Its an excellent
OOP feature.
Besides the obvious implementation considerations (should the Singleton
object be unique in a single PHP instance or across "all" PHP instances,
etc.), I am very much against putting reference implementations of
design patterns into a programming language. If you want this, you have
not understood the intention of design patterns (or the difference (in
degrees of freedom) when compared to algorithms).
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
Hello scott,
reason we are agsinst is that you can easily do i already in PHP.
Actually you can even do it in a manner everybody understands without
having to make the language more complex. Or in other words sometimes
it does not hurt doing a few keystrokes more. Instead it helps read-
and maintain-ability.
best regards
marcus
Monday, March 12, 2007, 9:53:52 AM, you wrote:
Perhaps I should not call it singleton then. Because I'm not trying to put
a flexible design pattern with large degrees of freedom as such into core
php. All I am trying to achieve is a nice way for people to implement
classes that only ever need one instance.
Can I ask why you are very much against this if you are? It seems that most
people need to do this at some point. I am starting to feel there's a lot
of negativity towards this because it's a different approach.
Good point about the uniqueness across one / all php instances. I was only
thinking of one unique instance for just the current php instance / request.
Definitely something to consider.
-----Original Message-----
From: Sebastian Bergmann [mailto:sb@sebastian-bergmann.de]
Sent: Sunday, 11 March 2007 8:26 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Native Singleton Implementation
scott.mcnaught@synergy8.com wrote:
Yes! Moving the singleton functionality into core php. Its an excellent
OOP feature.
Besides the obvious implementation considerations (should the Singleton
object be unique in a single PHP instance or across "all" PHP instances,
etc.), I am very much against putting reference implementations of
design patterns into a programming language. If you want this, you have
not understood the intention of design patterns (or the difference (in
degrees of freedom) when compared to algorithms).
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
--
Best regards,
Marcus
Very well. I just thought it would be a nice OOP feature to save time on
some people's behalf.
-----Original Message-----
From: Marcus Boerger [mailto:helly@php.net]
Sent: Wednesday, 14 March 2007 8:41 AM
To: scott.mcnaught@synergy8.com
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Native Singleton Implementation
Hello scott,
reason we are agsinst is that you can easily do i already in PHP.
Actually you can even do it in a manner everybody understands without
having to make the language more complex. Or in other words sometimes
it does not hurt doing a few keystrokes more. Instead it helps read-
and maintain-ability.
best regards
marcus
Monday, March 12, 2007, 9:53:52 AM, you wrote:
Perhaps I should not call it singleton then. Because I'm not trying to
put
a flexible design pattern with large degrees of freedom as such into core
php. All I am trying to achieve is a nice way for people to implement
classes that only ever need one instance.
Can I ask why you are very much against this if you are? It seems that
most
people need to do this at some point. I am starting to feel there's a lot
of negativity towards this because it's a different approach.
Good point about the uniqueness across one / all php instances. I was only
thinking of one unique instance for just the current php instance /
request.
Definitely something to consider.
-----Original Message-----
From: Sebastian Bergmann [mailto:sb@sebastian-bergmann.de]
Sent: Sunday, 11 March 2007 8:26 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Native Singleton Implementation
scott.mcnaught@synergy8.com wrote:
Yes! Moving the singleton functionality into core php. Its an excellent
OOP feature.
Besides the obvious implementation considerations (should the Singleton
object be unique in a single PHP instance or across "all" PHP instances,
etc.), I am very much against putting reference implementations of
design patterns into a programming language. If you want this, you have
not understood the intention of design patterns (or the difference (in
degrees of freedom) when compared to algorithms).
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
--
Best regards,
Marcus