Henk Verhoeven wrote:
[color=blue][color=green]
>> - interfaces[/color]
> How would a "real" interface differ from a class that is clearly
> recognizable as an interface and a comment in every class that
> "implements" the interface that it does so? IOW, what's an interface
> without strong typing?[/color]
Interfaces were Java's "solution" to multiple inheritance. They are useful
in a way that one class may implement one or more interface.
[color=blue][color=green]
>> and/or multiple inheritance;[/color]
> Would'nt multiple inheritance be a little over the top for "the basic of
> the internet"?[/color]
I don't think multiple inheritance would have been over the top at all for
PHP; nobody would be obligated to use or abuse it. PHP is slowly but surely
expanding beyond web uses like non-web scripting and GUI. Last I checked
PHP5 will provide interfaces which is adequate.
[color=blue][color=green]
>> - packages;[/color]
> It is already possible (and advisable) to put classes together into a
> package-like directory. I agree it would be nice (but more
> resource-consuming) to be able to include an entire package. But is is
> entirely possible to write a function that does so. For some reason i
> never needed it enough to write it...[/color]
PHP has no concept of packages at all. What you implement is yours and yours
alone, and nobody is obligated to follow your way.
[color=blue]
> Most interesting is the namespaceing effect of packages in Java, making
> abbreviated class names unique outside their package if they are unique
> inside. If you follow PEAR's class name convention you have the same
> effect, but miss the ability to 'leave out" the package name if you have
> imported the package. The result is a lot of extra typing and harder to
> read code. Personally i prefer to have the same prefix for all classes of
> the same app, and one other prefix for all classes of our reusable
> framework.[/color]
I devised my own way of importing classes and called it ActiveLink IORCA
(it's actually one simple function):
http://www.active-link.com/intranet/software.php
The use is similar to Java's imports. I think it would be beneficial if PHP
provided one simple way of doing this within the environment so that all
packages would be used in a consistent manner; but then again, there's
downsides to this too, so it's a topic for some discussion. I was simply
pointing out that the feature wasn't there.
Related to this, you may want to check out autoload in PHP5, I think that's
a nice new feature for loading only the classes that will be used.
[color=blue][color=green]
>> - ability to destroy objects (and free associated memory);[/color]
> Interesting, did you ever run into memory limitations within a single http
> request?[/color]
Yes, when doing benchmarking. Also, when using PHP for non-web scripting.
[color=blue]
> I would rather like to have a way NOT to have objects destroyed
> at the end of a http request (i do not count serialization in the session
> as very usefull in this respect). But i admit that this would cause all
> kinds of multi-user-multi-threading problems if you do not adhere quite
> strictly to a thread safe programming style, so it would make programming
> php so much more complex that most apps should not use it.[/color]
I guess theoretically, it's possible to come up with a persistent storage
mechanism that will keep PHP objects in their state, and I'm not referring
to serialization either. But I don't know how practical that is at all. My
guess is that it's not very practical.
[color=blue][color=green]
>> - abstract classes.[/color]
> What's wrong with an @abstract comment? Why would anyone want to
> instantiate an abstract class if it is clearly incomplete? And why NOT
> instantiate an "abstract" class if it's clearly complete for the function
> it going to be is used for?[/color]
I don't know if I can explain better than many others already have. Try
this:
http://java.sun.com/docs/books/tutor.../abstract.html
I'm not arguing that abstract classes are a "must-have" in PHP4, but they
are useful in certain situations. Again, last I checked, PHP5 will allow
for abstract classes.
[color=blue][color=green]
>> I'm sure there are few others as well. PHP5 takes care of good deal of[/color]
> this[color=green]
>> type of OO functionality but you asked about PHP4 ;)[/color]
>
> Does php 5 add all this? I did not notice (my fault). I like php 4 very
> much because of it's simplicity (remember the eXtreme Programming motto:
> the simpelest thing that could possibly work?). But php4 has very
> irritating limitations for OOP, which surpisingly no-one here mentioned:
> - the habit op php4 to recursively copy anything that is not passed by
> reference. This got even worse when passing by reference by the caller
> started to cause warnings. It renders functions like array_slice virtually
> useless with (potentially) large arrays of objects[/color]
This is not a strictly OOP-related phenomenon. That's the way PHP4 works
with all variable types.
[color=blue]
> - references to variables instead of references to objects. (It took me a
> while to find the workaround: create a temporary variable in a function,
> put an object into it, then have the funcion return a refernce to the
> temporary variable. As no one else can have a reference to the temporary
> variable unless you pass them one, it pritty much behaves like a referene
> to the object itself).[/color]
I think it's too late for me, but I tried reading this over and over but I
still don't get completely what you were trying to do and what you ended up
doing. Sorry.
[color=blue]
> - no stack trace and no try-catch for exception handling. If you heavily
> reuse code and that code triggers an error you end up with a useless line
> nuber of the trigger_error in the generic code, left guessing which one of
> the many places from which the reused code was called caused the error.[/color]
You are right, but again, this is not an OOP-related issue. You could end up
in the same boat by only [re]using functions and libraries thereof.
