Re: [PHP-DEV] wacky object idea From: Andi Gutmans (andi <email protected>)
Date: 08/28/00

At 01:58 PM 8/28/00 -0400, Chuck Hagenbuch wrote:
>Quoting Andi Gutmans <andi <email protected>>:
>
> > Do I think you should be using a different language? Well it depends what
> > you are looking for. If you are looking for operator overloading I think
> > you should use C++.
>
>Fair enough. I don't want operator overloading. I don't want to use C++.
>
> > If you are looking for a fully object oriented strongly
> > typed programming language you should use Java. If you are looking for a
> > scripting language you should use PHP.
>
>Also both fair enough.
>
>I want a scripting language which allows me to cleanly write re-usable
>components. This is not an OO issue, though some people seem to associate
>components, re-use, and objects for some reason.
>
>It's really a packaging/namespace issue. I've started using objects heavily
>in php because they give me a way I can wrap up a bunch of code, in a way
>that I'm pretty sure it won't conflict with other code, and drop it into
>another application.
>
>Php's current OO support _almost_ provides everything in this regard. It'd
>be great if we could have static class variables, so that you could use a
>class as just a package containing a bunch of functions and still have some
>class variables defined. Right now you can't even set defaults inside a
>class and use them in a static method. It'd also be great to be able to make
>constants part of a class's namespace instead of global.

Static class variables is something which should be quite doable and I
think a good thing.
The namespace issue has been discussed in the past and seems to be quite
problematic. I think you can do most of what you need with a class. If we
implement statics we might need to add some new syntax to refer to them
from static functions.

>Both of those features would just let you keep a little bit more inside of
>the packaging that a class provides - less chance that you will conflict
>with something that a user of your package is already using externally.
>
>The final piece in terms of packaging would be a way to dynamically rename a
>class/package; ie:
>
>import DB as myDB.
>
>This would let you avoid namespace conflicts once and for all, since the
>application author would control what parts of the namespace the packages he
>used took up. However, unless it turns out to be easy and efficient to
>implement, I can live without it.

I think this is not bound to happen. Again there has been a lot of
namespace talk in the past and there are many problems involved.

>Also, I don't particularly care if this features are tied to classes or not.
>If I could declare a namespace, and then have constants, classes, functions,
>and variables exist inside that namespace, that'd be great, and I wouldn't
>worry about static class vars or constants inside classes.
>
> > When dealing with a language there are a zillion of places you can get
> > bitten so we need to think well about how these kind of changes would
> > effect the language on a whole, the spirit of the language, and the
> > performance. When a user wants a feature he is not always aware of what
> > implications the feature could have.
>
>Yes, I completely agree. I've tried to keep my tone in the "is this
>possible?" range; I apologize if I've come across as pushy.
>
> > My opinion: I would probably want to see exceptions instead of this "wacky
> > object idea".
>
>That would be great. I kind of went off-track up above; this would solve my
>original feature request, which had to do with clean error handling, which
>is the other piece I'd like to see php have. And again, I don't particularly
>care if it's done in an object oriented way - although php's current object
>support should work well with it.

I'm going to put my thinking cap on for this one for the next few days.
I think a lot of people would like this.

Andi 

---
Andi Gutmans <andi <email protected>>
http://www.zend.com/

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
For additional commands, e-mail: php-dev-help <email protected>
To contact the list administrators, e-mail: php-list-admin <email protected>