Date: 07/17/00
- Next message: waldschrott: "Re: [PHP-DEV] parent_ctor()"
- Previous message: David Hjortso: "RE: [PHP-DEV] parent_ctor()"
- In reply to: David Hjortso: "RE: [PHP-DEV] parent_ctor()"
- Next in thread: David Hjortso: "RE: [PHP-DEV] parent_ctor()"
- Reply: David Hjortso: "RE: [PHP-DEV] parent_ctor()"
- Reply: Stanislav Malyshev: "RE: [PHP-DEV] parent_ctor()"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
At 17:20 17/07/2000 +0200, =?US-ASCII?Q?David_Hjortso?= wrote:
>Hi,
>
> > There is nothing preventing you from writing clean non-OOP code. And if
> > all you are worried about is encapsulation and code re-use, PHP's existing
> > OOP features have everything you need.
>
>That's true -- nothing is preventing me from writing clean non-OO code,
>except for that fact that it will be extremely difficult to manage vs. OO
>code. It is also much easier (for me) to extend and change different parts
>of this OO "program" than it would be otherwise.
>
>While I do agree that the OO features in PHP are working, and rather nicely,
>there are also many shortcomings, that I see as a problem for developing big
>projects (+10.000 lines of code are imho big projects).
>
>Here's a short list of things, that while only the first one is a serious
>worry for me, are small things that make it hard for me to do what I want to
>do...
>
>References surviving pages (this one has been argued to death, I side with
>Kristian).
I think this might be solvable at some point.
>Using $obj->func()->anotherobj->var instead of having to assign the func()
We are planning on working on this but it will take some time. Right now we
are trying to stabilize PHP 4 & Zend Engine.
>to a var and then continuing.
>Destructors.
Big problem. Main problem is that in PHP for historical reasons (some think
it is more than historical reasons and is the right way) objects aren't
object handlers like in Java but are object themselves. Doing $obj1=$obj2;
creates a complete copy of the object and doesn't make them both point at
the same place. For many such reasons, creating destructors doesn't make
sense and wouldn't work. There is no way of knowing when and when not the
destructor should really run. It is REALLY problematic to support destructors.
>Private functions and variables.
Could be implemented. The question is how. It could be done at compile-time
which would require stricter rules for the coder or at run-time which would
make it more general and PHP-like.
>Some of these can be overcome, some not.
Some are extremely difficult/impossible unless we add incompatibilities
into PHP.
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>
- Next message: waldschrott: "Re: [PHP-DEV] parent_ctor()"
- Previous message: David Hjortso: "RE: [PHP-DEV] parent_ctor()"
- In reply to: David Hjortso: "RE: [PHP-DEV] parent_ctor()"
- Next in thread: David Hjortso: "RE: [PHP-DEV] parent_ctor()"
- Reply: David Hjortso: "RE: [PHP-DEV] parent_ctor()"
- Reply: Stanislav Malyshev: "RE: [PHP-DEV] parent_ctor()"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

