[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