You can't rely on people prefixing their classes. In libraries, yes, but in applications, don't count on it too much.
- First of all, people use their classes a lot more than PHP core classes, and so prefixing application classes is a big burden compared to prefixing PHP core classes. - Second, with the active record design pattern becoming more popular, database table-names are starting to dictate class names. But I'm not saying PHP core classes should be prefixed. I think there's only one real solution, which is the usage of namespaces, and I'm eagerly awaiting their arrival in PHP. You can't educate the whole world into using prefixes, because people simply won't listen and will be stubborn. It just won't happen. The FUD is in not knowing what classes will be added next and if the user's project will suffer from it. I think these stubborn users are right (so I guess that makes me a stubborn user). With namespaces this problem would not even exist, and so it's PHP that needs to change, not the user approach. -- Ron "Christian Schneider" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Marcus Boerger wrote: > > We had problems with Date, DateTime and Time as all of those are common. > > I'm well aware of this and the discussion around it. > > > Should we name a class that represents data and time info name after say > > 'PhpDateTimeFart' so that there is no problem? Because if you think further > > it might be commone to put Php into class names that deal with php... that > > said wouldn't it be easier for the masses of people, that start using PHP, > > to not having to read the manual each time a date time class is being used? > > I'm willing to bet that the number of PhpDate classes out there is > considerably smaller then the number of Date classes. > [ You could theoretically even add an E_STRICT (or E_DEPRECATED ;-)) > warning if class names starting with Php are used. ] > > But my favourite solution would be to > a) have namespaces handling this issue > b) not introducing (many) more core classes before that > c) and thus not having to educate users to use prefixes (to have less > guidelines is a Good Thing(tm) IMHO) > > I didn't want to restart the whole naming discussion really but point is > that it is still an open issue for the next (major) release and should > better be looked at sooner than later. > > - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
