On Mon, 17 May 2004, Sara Golemon wrote:
var_dump($someobject); shows only public properties (as I'd expect), but
print_r($someobject) shows all properties (explicitly identifying
protected/private props).
Am I wrong in thinking that's not right?
I think the current way is perfectly
Hello Andrey,
if we change something then we prevent all those function from showing
private and protected values. The current situation is ok for me though.
marcus
Tuesday, May 18, 2004, 10:01:12 AM, you wrote:
Sara Golemon wrote:
var_dump($someobject); shows only public properties (as I'd
AZLet me add to this: isn't this what open source is about? The bug
AZdid not manifest itself on my system (FreeBSD). You pointed out the
AZissue. I fixed it. Cooperation prevailed. What's the big deal?
Well, the big deal is that sometimes - probably, not this time, but
sometimes - small changes
Sara Golemon wrote:
var_dump($someobject); shows only public properties (as I'd expect), but
print_r($someobject) shows all properties (explicitly identifying
protected/private props).
I agree with Derick and Andrey in that if anything should be changed it
is var_dump.
Reasoning: PPP is there to
On Tue, 18 May 2004, Christian Schneider wrote:
Sara Golemon wrote:
var_dump($someobject); shows only public properties (as I'd expect), but
print_r($someobject) shows all properties (explicitly identifying
protected/private props).
I agree with Derick and Andrey in that if anything
Hallo Marcus,
then will you cut the protected/private functionality from print_r() (so the
engine). Probably not :) . IMO var_dump() has been always superior for usage to
print_r(). During his presentation at the last conference Derick had to change
print_r() in his example to var_dump() to show
Hi All,
When I compiled and ran the php with apache2.0.49 my extensions module
init routines are called twice and even simple script execution keep
happening for 30 seconds and I get Timeout after 30 seconds.
Later I took 5.0.0RC2 everything works fine.
Please do the needful.
With regards
Kamesh
Hi all!
Could somebody explain me why we're setting only LC_CTYPE to it's current value in
main/main.c, line 1368 ?
What is the reason to make all users to call setlocale() explicitly to set LC_ALL ?
Of course, there can be some reasons I'm unaware of, but I'd like to propose following
tiny
On Tuesday 18 May 2004 10:41, Stanislav Malyshev wrote:
Well, the big deal is that sometimes - probably, not this time, but
sometimes - small changes break things that the author didn't even
think about it in some entirely different place.
Exactly. Case and point: loading of php extensions
Hey Antony,
This is most likely due to some issues with serialize/unserialize and floating
point numbers; we don't want the format to change with the locale, since it
should be independent.
Yes, it is a mess :)
--Wez.
-Original Message-
From: Antony Dovgal [mailto:[EMAIL PROTECTED]
Exactly. Case and point: loading of php extensions from
php.ini or via dl()
being broken at the moment due to one of those small changes.
It works fine under windows, so I'm assuming the problem is in non-zts builds
only.
If you load an extension from php.ini or manually using dl(), MINIT
On Tuesday 18 May 2004 15:00, Wez Furlong wrote:
Exactly. Case and point: loading of php extensions from
php.ini or via dl()
being broken at the moment due to one of those small changes.
It works fine under windows, so I'm assuming the problem is in non-zts
builds only.
It does not work
On Tue, 18 May 2004 13:55:18 +0100
Wez Furlong [EMAIL PROTECTED] wrote:
Hey Antony,
This is most likely due to some issues with serialize/unserialize and floating
point numbers; we don't want the format to change with the locale, since it
should be independent.
Yes, it is a mess :)
ok.
Hi,
what is the current status of php5isapi for iis6 under win2003 server?
i couldn't run it.
--
Best regards,
npguy npguy¤websurfer.com.np
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
var_dump($someobject); shows only public properties (as I'd expect), but
print_r($someobject) shows all properties (explicitly identifying
protected/private props).
So, to sum up the responses to the above question:
1) It's okay for print_r/var_dump to expose public/protected members (their
On Tue, 18 May 2004, Sara Golemon wrote:
The next question that brings up then is in relation to bug#27798:
I would think that get_object_vars() should expose private/protected props
when called from within the class itself (as appropriate based on
inheretance of course). Is this
On Tue, 18 May 2004, Stanislav Malyshev wrote:
Well, the big deal is that sometimes - probably, not this time, but
sometimes - small changes break things that the author didn't even
think about it in some entirely different place. And it's always
unexpected and unforeseen. That's why there's
The next question that brings up then is in relation to bug#27798:
I would think that get_object_vars() should expose private/protected
props
when called from within the class itself (as appropriate based on
inheretance of course). Is this assumption true?
yeah, I think that's how it
18 matches
Mail list logo
