Re: Classes vs functions

From: Zurab Davitiani (agt_at_mindless.com)
Date: 12/15/03 

Date: Mon, 15 Dec 2003 11:25:23 GMT

Henk Verhoeven wrote:

>> - interfaces
> 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?

Interfaces were Java's "solution" to multiple inheritance. They are useful
in a way that one class may implement one or more interface.

>> and/or multiple inheritance;
> Would'nt multiple inheritance be a little over the top for "the basic of
> the internet"?

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.

>> - packages;
> 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...

PHP has no concept of packages at all. What you implement is yours and yours
alone, and nobody is obligated to follow your way.

> 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.

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.

>> - ability to destroy objects (and free associated memory);
> Interesting, did you ever run into memory limitations within a single http
> request?

Yes, when doing benchmarking. Also, when using PHP for non-web scripting.

> 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.

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.

>> - abstract classes.
> 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?

I don't know if I can explain better than many others already have. Try
this:
http://java.sun.com/docs/books/tutorial/java/javaOO/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.

>> I'm sure there are few others as well. PHP5 takes care of good deal of
> this
>> type of OO functionality but you asked about PHP4 ;)
>
> 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

This is not a strictly OOP-related phenomenon. That's the way PHP4 works
with all variable types.

> - 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).

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.

> - 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.

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.

Relevant Pages

  • RE: No more access to characters in strings in PHP 6
    ... Multiple inheritance is often used to implement interface in C++ true ... PHP: an object and its interfaces are one and the same. ... happen when a second iteration is initiated before the first one ...
    (comp.lang.php)
  • Re: Separate Compilation in Programming Languages
    ... within one package body. ... all, separate or otherwise. ... OK, so you like having textually separate spec and body, ... Clients of an interface do not depend ...
    (comp.lang.ada)
  • Re: Global variables
    ... I have a litte OT question: how do you initialize the Repository? ... first class triggered the Starter class. ... principle of object orientation is to design towards an interface, ... Starter class must not reside in the interface respository package. ...
    (comp.object)
  • Re: static or not?
    ... > Thus, for example, controller.Driver will register its Controller ... then I can strip away an interface from this ... and have it register that interface in the Registry. ... if this is done from class foo, what's foo's package? ...
    (comp.lang.java.help)
  • [Full-disclosure] [ MDKSA-2006:122 ] - Updated php packages fix multiple vulnerabilities
    ... Package: php ... malformed image files that trigger the overflows due to improper calls ... PHP, as packaged in Mandriva Linux, contains an embedded copy of the ...
    (Full-Disclosure)