Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:20080
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: internals@lists.php.net
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ozRpamhK3S4h4VltTreM"
Organization: deworks
Date: Wed, 16 Nov 2005 21:26:19 +0100
Message-ID: <1132172779.12863.17.camel@localhost.localdomain>
Mime-Version: 1.0
Subject: Concerning SplSubject and SplObserver
From: joh@deworks.net ("Johannes H. Jensen")

--=-ozRpamhK3S4h4VltTreM
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Hello,

There has already been a discussion about this with the subject "Subject
and Observer Interfaces" opened by Jeff Moore. I must say that I
completely agree with Marcus Boerger on this subject.

It is not difficult to extend Subject and Observer so you can pass
additional information to the Observers, just design it so that it's
compatible with Observers too. This can be done by introducing optional
method arguments. Something like:

interface KeySubject extends Subject {
	function attach(Observer $observer, $key =3D null);
	function detach(Observer $observer, $key =3D null);
	function notify($key =3D null);
}

This interface is a Subject which will notify only Observers which are
registered at a specific key (useful for configuration classes where
only one part of the program has to be notified about one part of the
configuration.)
The implementing class should treat keys with a null value as attaching
a key-wide/global observer which should be notified of *any* change.

This is backwards-compatible with the Subject interface, as well as
introducing some new Subject functionality.

First of all, I must say that I'm disappointed about the renaming of the
Subject and Observer interfaces to SplSubject and SplObserver. The whole
POINT of SPL is to be a STANDARD PHP Library. It already provides other
interfaces with very generic names like Iterator, generic Exceptions,
etc. In my opinion, those interfaces are complete and fully extendable,
and should be treated as STANDARD interfaces, as SPL suggests.

I'm not sure why this renaming was done, either because of Andi Gutmans'
comment, or something else. Please clarify, Marcus!

Regards,
--=20
Johannes H. Jensen <joh@deworks.net>
deworks

--=-ozRpamhK3S4h4VltTreM
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBDe5Xr3qI8abXZ8HcRArGfAJ9DtyRoBnP+TPZoGS38vVnh2e5+fgCgiFLm
HesDIYH1tPzvvn1jCIwLDiQ=
=p9pZ
-----END PGP SIGNATURE-----

--=-ozRpamhK3S4h4VltTreM--