Re: [PHP] OOP and Future of PHP
Rasmus Lerdorf schrieb: If anyone has any idea, or tricks to hide information in a variables or method in a class, or in other words, make a variable or method a private, I would really like to know. Thanks for any comments. PHP also doesn't have introspection, so there isn't a good way for people to see what is in your API so a bit of obscurity should hide things for you. Hmm, the old, dirty hack print_r($obj). And the new functions: http://www.php.net/manual/en/function.get-class.php http://www.php.net/manual/en/function.get-class-vars.php http://www.php.net/manual/en/function.get-object-vars.php http://www.php.net/manual/en/function.get-class-methods.php ... I'd call these not only debugging function but functions that can be used for introspection. Anyway, people should not use parts of the API your documentation does not mention as public. Whoever does so, should reread the book on OOP. Yes, it could be better, but think of the zillions of PHP scripts that will break and all the beginners - PHP is quite often a beginners language - will ask you, Reuben, for support ;). Ulf -- Neu: PEAR Cache Erweiterung OutputCompression http://www.ulf-wendel.de/php/show_source.php?file=out_cache_com http://www.phpdoc.de -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] OOP and Future of PHP
Yasuo Ohgaki schrieb: I don't use GDB, but it seems it supports traceback. How about Zend Debugger? Does it support? Anyone? http://dd.cron.ru/dbg/ ? Ulf -- Neu: PEAR Cache Erweiterung OutputCompression http://www.ulf-wendel.de/php/show_source.php?file=out_cache_com http://www.phpdoc.de -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] OOP and Future of PHP
Yasuo Ohgaki schrieb: I don't use GDB, but it seems it supports traceback. How about Zend Debugger? Does it support? Anyone? http://dd.cron.ru/dbg/ ? Ulf Thanks for correcting my typo, Ulf. GDB = DBG :) Yasuo Ohgaki -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] OOP and Future of PHP
At 4/26/2001 12:10 PM, Yasuo Ohgaki wrote:
What I *really* like to see in PHP is:
- NAMESPACE
- TRACEBACK INFO
- exception (try-except block)
- $obj-method()-anotherMethod()
- real destructor would be nice, but not extremely important for
the time being, due to the nature of PHP usage in Web pages
I agree, but
$obj-method()-anotherMethod()
works for me. What does not work to be specific?
Hm, I'm using 4.0.4pl1. Perhaps this has been added somewhere in
the 4.0.5RC series? Sorry, haven't got the chance of trying that
(apart from using the PEAR from 4.0.5RC2).
===
class C1 {
function f() { return $this; }
function g() { echo Hi!; }
}
$C=new C;
$C-f()-g();
===
does not work me here.
I don't use GDB, but it seems it supports traceback.
How about Zend Debugger? Does it support? Anyone?
Yes, I've heard that it supports traceback. I guess this means I
have to use a source-level debugger for now. Lacking a stack trace
leads to a rather cumbersome error reporting, since I have to
supply __LINE__, __FILE__, and the name of the function in every
call to the error function.
Regards,
Steve
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] OOP and Future of PHP
At 02:10 PM 4/26/2001 +0900, Yasuo Ohgaki wrote: Steven Haryanto [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 4/25/2001 09:02 PM, Reuben D Budiardja wrote: *SNIP* What I *really* like to see in PHP is: - NAMESPACE - TRACEBACK INFO - exception (try-except block) - $obj-method()-anotherMethod() - real destructor would be nice, but not extremely important for the time being, due to the nature of PHP usage in Web pages I agree, but $obj-method()-anotherMethod() works for me. What does not work to be specific? I don't know how it works for you because it's not supported :) I got it what you and he means. I thought $obj-anotherObj-method(), but it was $obj-method()-anotherMethod() He means calling anotherMethod() from a method(), it does not work :) Is there any good supporting this? (and why need this?) -- Yasuo Ohgaki -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] OOP and Future of PHP
Sorry about sloppy reading.
I misunderstood what he means :(
It does not work.
--
Yasuo Ohgaki
- Original Message -
From: Steven Haryanto [EMAIL PROTECTED]
To: Yasuo Ohgaki [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, April 26, 2001 4:22 PM
Subject: Re: [PHP] OOP and Future of PHP
At 4/26/2001 12:10 PM, Yasuo Ohgaki wrote:
What I *really* like to see in PHP is:
- NAMESPACE
- TRACEBACK INFO
- exception (try-except block)
- $obj-method()-anotherMethod()
- real destructor would be nice, but not extremely important for
the time being, due to the nature of PHP usage in Web pages
I agree, but
$obj-method()-anotherMethod()
works for me. What does not work to be specific?
Hm, I'm using 4.0.4pl1. Perhaps this has been added somewhere in
the 4.0.5RC series? Sorry, haven't got the chance of trying that
(apart from using the PEAR from 4.0.5RC2).
===
class C1 {
function f() { return $this; }
function g() { echo Hi!; }
}
$C=new C;
$C-f()-g();
===
does not work me here.
I don't use GDB, but it seems it supports traceback.
How about Zend Debugger? Does it support? Anyone?
Yes, I've heard that it supports traceback. I guess this means I
have to use a source-level debugger for now. Lacking a stack trace
leads to a rather cumbersome error reporting, since I have to
supply __LINE__, __FILE__, and the name of the function in every
call to the error function.
Regards,
Steve
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP] OOP and Future of PHP
The only thing that I feel lack of in PHP is the real Object Oriented stuff, such as information hiding in the object in classes i.e. private and public variables, methods/functions. This in a sene make it really difficult for developer to build an API for other developers that is secure. I myself have this problem. Is there any reasons why PHP was designed like this from the beginning? Is this issue going to be addresses somehow in the future? Anyone has any idea? If anyone has any idea, or tricks to hide information in a variables or method in a class, or in other words, make a variable or method a private, I would really like to know. Thanks for any comments. Reuben D. Budiardja Web Database Application Programmer / Analyst Devcorps, ITS Goshen College, IN 46526 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] OOP and Future of PHP
At 4/25/2001 09:02 PM, Reuben D Budiardja wrote: The only thing that I feel lack of in PHP is the real Object Oriented stuff, such as information hiding in the object in classes i.e. private and public variables, methods/functions. This in a sene make it really difficult for developer to build an API for other developers that is secure. I myself have this problem. Is there any reasons why PHP was designed like this from the beginning? Is this issue going to be addresses somehow in the future? Anyone has any idea? If anyone has any idea, or tricks to hide information in a variables or method in a class, or in other words, make a variable or method a private, I would really like to know. Thanks for any comments. Python also does not do information hiding, but people rarely call Python's OO features as not real. :-) It's a matter of choice, though, I don't see any real hindrance of PHP implementing this in the future version. As Rasmus said, PHP does not have introspection (once again, unlike Python which is very introspective), this is less of a problem, especially with function calls API. What I *really* like to see in PHP is: - NAMESPACE - TRACEBACK INFO - exception (try-except block) - $obj-method()-anotherMethod() - real destructor would be nice, but not extremely important for the time being, due to the nature of PHP usage in Web pages Please tell me it's on the top'ish of the TODO list :-) Steve -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] OOP and Future of PHP
Steven Haryanto [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 4/25/2001 09:02 PM, Reuben D Budiardja wrote: *SNIP* What I *really* like to see in PHP is: - NAMESPACE - TRACEBACK INFO - exception (try-except block) - $obj-method()-anotherMethod() - real destructor would be nice, but not extremely important for the time being, due to the nature of PHP usage in Web pages I agree, but $obj-method()-anotherMethod() works for me. What does not work to be specific? I don't use GDB, but it seems it supports traceback. How about Zend Debugger? Does it support? Anyone? Regards, -- Yasuo Ohgaki -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
