Re: [PEPr] Comment on RFC::NotificationCenter

Hi Lukas, Lukas Smith wrote: >Since we dont have multiple inheritance having to inherit from some object >is a no go like Bertrand already mentioned in his reply. You can however >implement multiple interfaces so the interface route seems to make the >most sense. > >So Bertrand the idea behind the Notification center is similar in a way to >ErrorStack. This is a good comparison indeed. >It means that every class that wants to use the Notification >center loads the code and then allows observers to register for that class >(or rather instances). Actually, there is no need for them to require/load the notification center unless they really need it internally. Using "if (class_exists('NotificationCenter'))", our classes can be informed if it is worthless to post a notification. It is users'job to require the notification center in their apps, if they use the notifications in their own code. >This would obviously prevent redundant code. It would provide more I/O >overhead which would however become less relevant expensive per package >the more packages use the notification center. That's only one 'require_once', done by the end-user (unless your own classes rely on notifications to work). >So far we have only done >this for the PEAR base class (something we have gotten a bad name for, >however mainly due to design mistakes we mostly fixed by now). Its a >fundamental descision: Do we want to prevent code redundancy even if that >means that packages need to then require several (error handling, >notification center .. etc) infrastructure packages? Let's say the use of a Notification Center is optional as long as you use "if (class_exists('NotificationCenter'))" before posting. It's not exactly like PEAR_Error which are used everywhere and makes a framework of PEAR. If the end user is not interested in the notifications sent by our classes, no need for them to require/load the notification center. >That is why I proposed the alternative of simply having a common interface >with a reference implementation (or maybe several for different specific >needs) that people essentially cut and paste. I am not so worried about >lines of code here. I am more worried about number of required files. I think the notification center is a lot less intrusive than PEAR, PEAR_Error or even Error_Stack. It is not because you use it that the user has to use it. Furthermore, requiring an interface file per observable packages would take even more time... :D Interfaces would be very good to enforce a common way to add observers to objects. But if you propose only one implementation, it will suit your needs, not everyone's needs. If you propose multiple implementations, it will become a mess. If you change your implementation code, users will have to copy/paste it again, and again, up to when you have done the "perfect" implementation, the one that will never change. IMO, an interface + an implementation defeat the purpose of interfaces. This combinaison looks more like an extension which I would like to avoid. I am aware that my current implementation of the notification center is not optimized but it will be by the time it gets stable. Cheers, Bertrand