[dev] [commits] Horde branch refactor-Notification updated. 3b590095a4312f85639071510adc42d5dc9090fc

Chuck Hagenbuch chuck at horde.org
Sun Nov 1 02:45:34 UTC 2009


Quoting Gunnar Wrobel <p at rdus.de>:

> I think that would be useful. I used decorators at a few places now  
> and sometimes I had to check to determine if it was a "real" class  
> or a decorator. I assume this would mean another subfolder in  
> "Notification/Handler"? As the class names would start to get really  
> long by then I'd tend to use "Notification/Handler/Deco" rather than  
> "Notification/Handler/Decorator".

No :) Deco is just unclear. Horde_Notification_Handler_Decorator is  
indeed long, but eventually we can look at namespaces to help with  
that, people can use editor code completion - there are plenty of ways  
to cope.

>> Also, I don't recall right now if we already discussed whether we  
>> want interfaces to stick more out by using a naming scheme for  
>> those. I would prefer that, to distinguish them from base classes.
>> All this is general Horde CS stuff of course, and has nothing to do  
>> with the Notification refactoring. Meaning that we can always  
>> change this later if don't find an immediate agreement.
>
> "Notification/Handler/Interface.php"? Or  
> "Notification/Interfaces/Handler.php"? Yes, something like that  
> would be good.

I'd go for Notification/Handler/Interface.  
Notification/Interfaces/Handler isn't autoloadable, at least not with  
our naming scheme and not with a sane interface name.

-chuck


More information about the dev mailing list