Date: 08/28/00
- Next message: Zeev Suraski: "Re: [PHP-DEV] Overwriting (internal) functions"
- Previous message: Rasmus Lerdorf: "RE: [PHP-DEV] PHP 4.0 Bug #6401: read_exif_data fails"
- In reply to: thies <email protected>: "Re: [PHP-DEV] wacky object idea"
- Next in thread: Andrei Zmievski: "Re: [PHP-DEV] wacky object idea"
- Reply: Andrei Zmievski: "Re: [PHP-DEV] wacky object idea"
- Reply: Chuck Hagenbuch: "Re: [PHP-DEV] wacky object idea"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
At 17:22 28/08/00 +0200, thies <email protected> wrote:
>On Mon, Aug 28, 2000 at 06:11:16PM +0300, Andi Gutmans wrote:
> > At 11:02 28/08/00 -0400, Chuck Hagenbuch wrote:
> > >Quoting Andi Gutmans <andi <email protected>>:
> > >
> > > > I think this would cause lots of confusion. PHP types aren't always
> that
> > > > obvious and you'll probably get lots of unexpected results. Not sure
> > > things
> > > > will work as consistently as you guys expect.
> > >
> > >Can you elaborate on this at all?
> > >
> > >My idea is that if you specifically define a function inside your class
> > >(following current convention, it'd be __boolean_value), then whenever you
> > >needed to evaluate that object in a boolean context, you'd use the
> result of
> > >that function. Seems like it shouldn't confuse people, since it would only
> > >change current behavior if you actually went ahead and changed your
> code to
> > >define __boolean_value...
> >
> > Yeah but not only would this mean changing lots and lots of the Zend
> Engine
> > it is not trivial that this will work nicely in all cases.
> > We have to think of all the possible contexts we would expect this to work
> > (I'm sure there are not trivial ones) and then see what happens.
>
> unless i'm overseeing something it's quite easy to implement:
>
> simply try to call the methods in the zendi_convert_to_*()
> functions and use the result of the user-function _if_ it has
> the right type - else issue a warning and revert to
> normal-bahaviour.
The problem isn't changing the convert_* functions. The problem is that not
only will we have to change some logic I am not sure if we will end up with
something consistent. I'm not saying it's not doable but things aren't
always as simple as they look. And in this case, before diving into code
and changing it, we have to seriously consider what we want, what the
implications are, what the limitations would be, and then finally if it's
feasible.
> the only question is if we can actually call user code while
> we're in one of those functions. (andi, you can probably
> answer that) - we already have this functionality in
> zend_make_printable_zval().
This is a very isolated place.
> i think it would be really nice it classes could return their
> own bool, double, long, array or string-val.
>
> why not?
Operator overloading is one of the uglier features in C++. Java did things
better. Code is much more readable and maintainable when it uses interfaces
and not "object overloading". You might lose a lot of what PHP is about
when implementing this "cool" feature. You might move PHP coders into
writing unreadable code.
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: Zeev Suraski: "Re: [PHP-DEV] Overwriting (internal) functions"
- Previous message: Rasmus Lerdorf: "RE: [PHP-DEV] PHP 4.0 Bug #6401: read_exif_data fails"
- In reply to: thies <email protected>: "Re: [PHP-DEV] wacky object idea"
- Next in thread: Andrei Zmievski: "Re: [PHP-DEV] wacky object idea"
- Reply: Andrei Zmievski: "Re: [PHP-DEV] wacky object idea"
- Reply: Chuck Hagenbuch: "Re: [PHP-DEV] wacky object idea"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

