Hello. ^^
I just wanted to ask, if there is a singleton implementation? The current one is rather „hackish“, by using a static property, initializer and a function to itneract with it all. Sadly, I can not put a patch together myself - because I am not good with YACC and Flex yet, or with the php vm - but i would have a concept for an implementation o.o
Kind regards, Ingwie
Hello. ^^
I just wanted to ask, if there is a singleton implementation? The current
one is rather „hackish“, by using a static property, initializer and a
function to itneract with it all. Sadly, I can not put a patch together
myself - because I am not good with YACC and Flex yet, or with the php vm -
but i would have a concept for an implementation o.o
Hi Kevin,
I don't think that standardizing a well known anti-pattern in core is a
good idea.
The current static property approach is quite fine and safe to use (if you
really need it, which is "no" in 99.9999% of cases), and not hackish at all.
Cheers,
Marco Pivetta
2014-02-05 Marco Pivetta ocramius@gmail.com:
On 5 February 2014 11:19, Kevin Ingwersen ingwie2000@googlemail.com
wrote:Hello. ^^
I just wanted to ask, if there is a singleton implementation? The current
one is rather "hackish", by using a static property, initializer and a
function to itneract with it all. Sadly, I can not put a patch together
myself - because I am not good with YACC and Flex yet, or with the php
vm -
but i would have a concept for an implementation o.oHi Kevin,
I don't think that standardizing a well known anti-pattern in core is a
good idea.
The current static property approach is quite fine and safe to use (if you
really need it, which is "no" in 99.9999% of cases), and not hackish at
all.
Beside this: Thats how it works in all me known languages. I don't know any
language, where a pattern (in any form) is part of the core.
Cheers,
Marco Pivetta
Beside this: Thats how it works in all me known languages. I don't know any
language, where a pattern (in any form) is part of the core.
You mean like PHP which i.e. ships Observer pattern?
http://php.net/splobserver
That said: We won't add singleton. Creating a trait in userspace is
trivial for the ones who really want to use it.
johannes
2014-02-05 Johannes Schlüter johannes@schlueters.de:
Beside this: Thats how it works in all me known languages. I don't know
any
language, where a pattern (in any form) is part of the core.You mean like PHP which i.e. ships Observer pattern?
http://php.net/splobserver
OK, it's in the core, but not part of the language (somehow). You know,
what I meant ;)
That said: We won't add singleton. Creating a trait in userspace is
trivial for the ones who really want to use it.johannes
Johannes Schlüter wrote (on 05/02/2014):
Beside this: Thats how it works in all me known languages. I don't know any
language, where a pattern (in any form) is part of the core.
You mean like PHP which i.e. ships Observer pattern?
http://php.net/splobserver
Personally, I've never really understood what the point of those
interfaces is; I guess just for standardisation, which could (now) be
better achieved in a standardisation body like FIG.
I wonder if anyone actually uses them...
Rowan Collins
[IMSoP]
Johannes Schlüter wrote (on 05/02/2014):
Beside this: Thats how it works in all me known languages. I don't
know any
language, where a pattern (in any form) is part of the core.
You mean like PHP which i.e. ships Observer pattern?
http://php.net/splobserverPersonally, I've never really understood what the point of those
interfaces is; I guess just for standardisation, which could (now) be
better achieved in a standardisation body like FIG.I wonder if anyone actually uses them...
Yes, I used them (and ArrayObject) on some occassions. I see no conflict
between having them in core and FIG agreeing on their usage or something
different.
But that's nothing about singletons, which I haven't used since php4 era.
--
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang@b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Ralf Lang wrote (on 05/02/2014):
Yes, I used them (and ArrayObject) on some occassions. I see no conflict
between having them in core and FIG agreeing on their usage or something
different.
ArrayObject includes actual implementation, and the interfaces it
implements activate special behaviour in the core.
SplObserver and SplSubject appear, unless I'm much mistaken, are
equivalent to about 4 lines of userland PHP each defining 2 very simple
interfaces. That's exactly the kind of thing FIG is working on, e.g. a
Logger interface. I can't think of any reason, now that FIG and Composer
exist, that those interfaces would need to be compiled into a PHP extension.
Not that I'd argue for their removal, now they do exist, but I see them
as an old experiment in pushing coding standards using the core of PHP,
and not a useful model for anything new.
Rowan Collins
[IMSoP]
Forgive me, what is FIG?
On Wed, Feb 5, 2014 at 6:58 AM, Rowan Collins rowan.collins@gmail.comwrote:
Ralf Lang wrote (on 05/02/2014):
Yes, I used them (and ArrayObject) on some occassions. I see no conflict
between having them in core and FIG agreeing on their usage or something
different.ArrayObject includes actual implementation, and the interfaces it
implements activate special behaviour in the core.SplObserver and SplSubject appear, unless I'm much mistaken, are
equivalent to about 4 lines of userland PHP each defining 2 very simple
interfaces. That's exactly the kind of thing FIG is working on, e.g. a
Logger interface. I can't think of any reason, now that FIG and Composer
exist, that those interfaces would need to be compiled into a PHP extension.Not that I'd argue for their removal, now they do exist, but I see them as
an old experiment in pushing coding standards using the core of PHP, and
not a useful model for anything new.--
Rowan Collins
[IMSoP]
Nevermind, I see it. DOH!
Forgive me, what is FIG?
On Wed, Feb 5, 2014 at 6:58 AM, Rowan Collins rowan.collins@gmail.comwrote:
Ralf Lang wrote (on 05/02/2014):
Yes, I used them (and ArrayObject) on some occassions. I see no conflict
between having them in core and FIG agreeing on their usage or something
different.ArrayObject includes actual implementation, and the interfaces it
implements activate special behaviour in the core.SplObserver and SplSubject appear, unless I'm much mistaken, are
equivalent to about 4 lines of userland PHP each defining 2 very simple
interfaces. That's exactly the kind of thing FIG is working on, e.g. a
Logger interface. I can't think of any reason, now that FIG and Composer
exist, that those interfaces would need to be compiled into a PHP extension.Not that I'd argue for their removal, now they do exist, but I see them
as an old experiment in pushing coding standards using the core of PHP, and
not a useful model for anything new.--
Rowan Collins
[IMSoP]
The point (at least in Java) is two fold- one is to separate behavior from
implementation to achieve better separation of concerns (I really want to
say "swapability", kinda in the flavor of an ObjectFactory). In php this
works a little different than Java since php does not have a strong type
system so I suppose it does boil down to standardization of methods.
The other (which is really just an application of number one) is using them
to group together different classes under a similar banner (again, in Java
this is really a type issue). You could use this in cases where you do not
want to define an abstract class for instance but still want some
uniformity.
I currently use them in my code to standardize some things like some of my
Controllers but for the most part I rely more heavily on Abstract Classes.
I know a friend of mine up North is a big fan of traits which from what I
can tell are basically an extension of interfaces (please correct me if I
am wrong- I have not used them).
The whole idea here, in my mind, is to gain some of the benefits of
multiple inheritance without selling your soul to the devil and wrecking
your code. I understand traits get you even closer to that.
On Wed, Feb 5, 2014 at 6:33 AM, Rowan Collins rowan.collins@gmail.comwrote:
Johannes Schlüter wrote (on 05/02/2014):
Beside this: Thats how it works in all me known languages. I don't know
any
language, where a pattern (in any form) is part of the core.You mean like PHP which i.e. ships Observer pattern?
http://php.net/splobserverPersonally, I've never really understood what the point of those
interfaces is; I guess just for standardisation, which could (now) be
better achieved in a standardisation body like FIG.I wonder if anyone actually uses them...
Rowan Collins
[IMSoP]
George Wilson wrote (on 05/02/2014):
The point (at least in Java) is two fold- one is to separate behavior from
implementation to achieve better separation of concerns
[...]
The other (which is really just an application of number one) is using them
to group together different classes under a similar banner (again, in Java
this is really a type issue). You could use this in cases where you do not
want to define an abstract class for instance but still want some
uniformity.
This sounds like a good description of why to use Interfaces in general,
but doesn't really explain why it is the language's responsibility to
define those interfaces for you, rather than some framework.
Obviously, there is a benefit to using the same Interfaces in multiple
projects, and this is what groups like FIG are working on. A similar
role in the Java world might be the various Apache Foundation groups
working on interoperable tools, but not contributing to the Sun/Oracle
JDK directly.
I know a friend of mine up North is a big fan of traits which from what I
can tell are basically an extension of interfaces (please correct me if I
am wrong- I have not used them).
Traits are a slightly different concept, sometimes referred to as
"horizontal reuse". They don't create any kind of inheritance
relationship between two classes, just allow you to write some code once
and use it in several places. Essentially, they are an automated
copy-and-paste.
[PS: Please reply below, rather than above, other people's posts,
preferably trimming the quote to the relevant part as I've done here.]
Regards,
Rowan Collins
[IMSoP]