T_INTERFACE and T_ABSTRACT as valid class names

The following is just an opinion from an user and should be considered as
such.

You should consider that the PEAR way of naming classes was the nasty
workaround that the namespaces is trying to solve. Therefore, just trying to
make the language fit your needs so you can still use that nasty workaround
into the new feature is not smart. It's like moving one step forward, two
backward.

You have namespaces now, and you want to use them? Forget about PEAR style
and refactor the damn framework if necessary. It's more consistent and
elegant if you use the right name for a class (Abstract or Interface is just
too vague):

namespace Zend::Db;
class AbstractDb { ... }

namespace Zend::Db::Adapter;
class AdapterInterface { ... }

2007/10/20, Lars Strojny lars@strojny.net:

Hi,

I've already opened a feature request (#43048) but I feel, that there
need to be a discussion on that topic. The problem is, that the current
pseudo-namespacing used by a huge number of projects (PEAR-style, with
underscores and the related file organisation), could not be easily
ported to namespaces, as the name "Interface" and "Abstract" is not a
valid classname. So something like ...

namespace Zend::Db;
class Abstract {...}

... will not work. Same for ...

namespace Zend::Db::Adapter;
interface Interface {...}

Nevertheless it would break some syntax highlighting libraries or maybe
the tokenizer extension, I would propose to allow at least "Abstract"
and "Interface" as a class/interface name. This would make porting to
the namespace methodology much easier (I see it quite plainly, a lot of
people would develop cripple names like Intrfce or Abstrct just to make
the PHP parser happy).

cu, Lars