Re: Some PEAR remarks

On Fri, 2002-04-19 at 12:48, Vincent Oostindie wrote: > On Thu, 18 Apr 2002 12:36:13 +0200, Stig S. Bakken wrote: > >> Except that PEAR doesn't: no total encapsulation, returning different > >> types from the same method... That's not 'standard' OO, if there ever > >> was such a standard. > > > > PHP is not Java, C++, Python or Smalltalk. Designing PHP code like you > > would with Java will make your application horribly slow. PHP is > > loosely typed, Java has method overloading. Having different types in > > parameters and return values makes perfect sense in PHP, because that's > > what the language is designed for. > > I agree that you should use a language's possibilities if that makes > sense. For example, I have written an object factory system in PHP that > allows dynamic addition of new classes: programmers drop a class in a > directory and give it an alias (e.g. 'foo'), after which the system is able > to create an object of that class, given its alias. It does that something > like this: > > $class = includeClass('foo'); > $object = new $class(); > > The 'new $class()' statement is very specific for PHP, and very useful. > > On the other hand, I also think every language has 'features' that > shouldn't be used. Java and C++ (for example) both support public member > variables. That doesn't mean you should use them though. C++ has operator > overloading, which is often misused. Multiple inheritance can be nice, > but when used it mostly implies a bad design. > > Although passing different types in parameters and returning different > types from methods is possible in PHP, I think there is absolutely no > justification for actually doing it. It only makes code much harder to > read, understand and use. Especially when returning different types from > the same method or function. > > But of course I can be wrong, so please convince me otherwise; I'd really > like to hear your arguments. (But a warning in advance: I don't think the > PEAR error handling is a good example...) In PHP, null is a separate type. Returning "blah or null" is very common in PHP, as is "blah or false". Do you use polymorphy in Java to invoke different method implementations based on what return type is expected? If yes, and you refuse to return different types from PHP functions you will either have to sacrifice functionality (lose the flexibility returning any type gives you) or accept lots of overhead (implementing 3 slightly different methods with different names and return values). I'm not saying that it's a great idea to have a function that may return both a string, integer, object, resource or boolean, but having null or boolean as an alternative very often makes sense in PHP. > > There are general OO principles, and there are techniques that are > > useful and common in specific languages. I have a feeling that what you > > refer to as 'standard' OO is a set of rules that make perfect sense for > > other languages, but not necessarily PHP. > > On the contrary, my personal set of 'standard' OO principles tend to be > 'cross-language'. Basically, I mainly use Design Patterns (Gamma, Helm, > Johnson, Vlissides) and Refactoring (Fowler) to implement my OO programs. > (Note: this is very, very basic!) I found that those techniques work > equally wel in any OO-enabled language. Sure. > Of course it is important to take the notions and quirks of the language > you're working in into account, but I also think that if a > 'cross-language' solution to some problem is available at the same or > only a slightly higher cost - which is almost always the case - you should > always go for that. In my day job, I'm writing PHP code for www.alltheweb.com. We handle between 50 and 100 searches per second, so performance is obviously critical to us. I can not generally not make such sacrifices on that site, because the cost would simply be too high. In real life there are compromises to be made. - Stig