Re: [PHP-DEV] parent_ctor() From: Andi Gutmans (andi <email protected>)
Date: 07/18/00

At 16:19 18/07/2000 +0200, Kristian Köhntopp wrote:
>Stanislav Malyshev wrote:
> > KK>> As I explained again above, this is not about B&D: Objects are
> > KK>> not hashes. Hashes are hashes and that's why hash and array functions
> > KK>> work on them. And unless my model of PHP4 object internals is
> > KK>> completely off, this is not even necessarily slow.
> >
> > Why would ou want to use array function on object?
>
>When you treat an object as a hash, you should be able to use
>hash functions on it. Otherwise you are just combining disadvantages
>of both.
>
>If an object is not a hash, it should have properties that are
>different from a hash or it is jus a redundant feature. If I
>wanted runtime variable slots, I had used a hash in the first
>place, had I not?
>
> > KK>> [ inherited constructors which were not intended to be ctors ]
> > KK>> If this is not messy, I don't know what. And you cannot tell me
> > KK>> that this is an intentional feature at all - this is what you
> > KK>> get when you hack an extension (constructors) on top of an
> > KK>> extensions (class syntax for hashes) without considering later
> > KK>> use of the resulting system at all.
> >
> > No, that's what you get when you hack class structure without previously
> > designing it.
>
>Perhaps I did not design the superclass at all, but used a component
>from the net and derived my own class from that. In that case the
>scenario I described will become increasingly likely, as the component
>I imported may have any number of public or undocumented private
>methods. The way PHP handles this situation is just unclean, and
>not fault-tolerant in such an environment.
>
>So is its default of allowing previously undeclared instance variables:
>I will not detect an error in my own use of an imported superclass,
>as PHP silently creates the new slot instead of complaining.
>
> > Not at all. If someone is using PHP in real-time environment, that doesn't
> > mean we should rush and rewrite all PHP to adhere to real-time
> > requirements. That only says we are so good that we made PHP be real-time
> > without even thinking about it :)
>
>You made PHP a language with a halfway decent object system accidentally
>and now people are using these features. You'd better fix the other half
>before people start using the feature in earnest, or there will be
>problems of all kinds.
>
> > OK, again: what's your proposal?
>
>Fix the object system:
>
>- Fix the spurious constructor inheritance. The preferred way would
> be fixed constructor names such as __ctor(), but Zeev said he
> will not do this. Then at least make it so that the example I
> cited will not break the language.

I really don't think this is such a big deal. What is wrong with the way it
is now (similar to C++)? If you want us to add code so that parent
functions can't "by mistake" slip in as constructors this is probably quite
doable without having to take the __ctor() approach.

>- There should be a mode so that $o->bla = 17 raises an error
> if $o->bla has not been declared before and that mode should
> be the default.

Well we'd be breaking backwards compatibility big time. And the thing
people love about PHP is being able to define variables on the fly and not
having errors raised on every second line.

>- There should be $super or super:: or whatever in order to
> make superclass references in a normalized fashion.

Zeev implemented parent:: a couple of days ago.

>- Ultimately PHP will need a namespace management mechanism for
> classes similar to what XMLNS does with XML extensions. Or you
> just rename classes on include (e.g.
>
> include("tobias/mail.inc") class Mail as TMail;
> include("kris/mail.inc") class Mail as KMail;

Uhm, I don't quite understand what you want here. At compile-time you don't
actually parse that include() file, so you don't know there's a Mail class
in there so you can't rename it to TMail.

>- and finally serialize references properly so that data structures
> are preserved across pages.

This has nothing to do with the Zend Engine IMO. You have to make the PHP
serializer smarter.

>and get rid of methodless objects (stdClass or whatever) and
>the "object" generic type. Make classes and types identical
>instead. Hope I did not forget something.

I guess I'm missing what you mean here. What is so bad about methodless
objects? It exists in just about any OOP language.

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>