I remember we agreed that OO code will have studlyCaps. I don't want to
have this long thread again (I was actually initially opposed but got
convinced/gave in).
You don't want a long thread? Then don't mention the topic.
As I don't have the time right now nor the setup, can someone
On Wed, 21 Jan 2004, Andi Gutmans wrote:
At 08:21 AM 1/21/2004 +0100, Sascha Schumann wrote:
I remember we agreed that OO code will have studlyCaps. I don't want to
have this long thread again (I was actually initially opposed but got
convinced/gave in).
You don't want a long
Hello Sascha,
Wednesday, January 21, 2004, 8:21:30 AM, you wrote:
I remember we agreed that OO code will have studlyCaps. I don't want to
have this long thread again (I was actually initially opposed but got
convinced/gave in).
You don't want a long thread? Then don't mention the
Alright..
I've got a patch sitting here on my laptop that converts all of the OO
syntax in the tidy extension into studlyCaps. I.e.
$tidy = tidy_parse_file();
or
$tidy = new tidy();
$tidy-parse_file();
Will become..
$tidy =
PHP 5 goes itself I don't really have an opinion. I'm willing to apply
this patch, but before I do can I please get a +1 -1 vote on this?
-1
There really is no reason to convert existing code.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
On Wed, Jan 21, 2004 at 03:00:39AM -0500, John Coggeshall wrote:
Although my *personal* preference here is to maintain the current use of
underscores (since it is consistent with the procedural API).. as far as
PHP 5 goes itself I don't really have an opinion. I'm willing to apply
this patch,
At 08:38 AM 1/21/2004 +0100, Sascha Schumann wrote:
On Wed, 21 Jan 2004, Andi Gutmans wrote:
At 08:21 AM 1/21/2004 +0100, Sascha Schumann wrote:
I remember we agreed that OO code will have studlyCaps. I don't want to
have this long thread again (I was actually initially opposed but got
Go ahead with it.
Please commit it.
I hope Sascha will relax with another one of his holy wars.
Andi
At 03:00 AM 1/21/2004 -0500, John Coggeshall wrote:
Alright..
I've got a patch sitting here on my laptop that converts all of the OO
syntax in the tidy extension into studlyCaps. I.e.
Attached is a patch to FINALLY get rid of the deprecated
php.ini option 'gpc_order'. We've had note in the manual
also about it not even existing in PHP4 for ages..
Does anyone have any really good reason why it can NOT be
removed before PHP 5 goes gold?
There
On Wed, 2004-01-21 at 05:04, Andi Gutmans wrote:
Go ahead with it.
Please commit it.
I hope Sascha will relax with another one of his holy wars.
Done.
--
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
John Coggeshall http://www.coggeshall.org/
The PHP
In general, I think casting an object to an array sucks.
I would be all for an E_STRICT message that this is deprecated as we have
real objects now and IMO, and that the behavior might change/go away
sometime in the future.
Andi
At 05:07 PM 1/17/2004 +0100, Andrey Hristov wrote:
Pierre-Alain
I think it's OK. It's very simple and thus shouldn't create any problems.
Andi
At 06:16 PM 1/17/2004 +0100, Andrey Hristov wrote:
Hi internals and Andi,
what do you think about a small exception from the feature freeze for
satisfying feature request http://bugs.php.net/bug.php?id=24258 . The
Hello list,
I find often myself wanting to append a variable to an unknown url. The
problem is that you don't know if you should append the var with ? or
with . Do you think it would be useful to have a builtin function that
would do this automatically?
example code as I do it actually:
?php
I just saw this message now. I'll look into it.
Thanks,
Andi
At 12:56 PM 1/17/2004 -0800, choinet wrote:
--- choinet [EMAIL PROTECTED] wrote:
I was helping a user at my ISP support forums. Using
include on an http:// url generates Warning: main():
stream does not support seeking in
Why not simply make the cast not work?
Can you think of any BC problem with that? :)
--Jani
On Wed, 21 Jan 2004, Andi Gutmans wrote:
In general, I think casting an object to an array sucks.
I would be all for an E_STRICT message that this is deprecated as we have
real
Yeah, because it used to work.
Andi
At 01:19 PM 1/21/2004 +0200, Jani Taskinen wrote:
Why not simply make the cast not work?
Can you think of any BC problem with that? :)
--Jani
On Wed, 21 Jan 2004, Andi Gutmans wrote:
In general, I think casting an object to an array sucks.
I
Generally we don't add functions to replace simple one-line PHP
expressions.
$url .= strstr($url,'?')??foo=$foo:foo=$foo;
-Rasmus
On Wed, 21 Jan 2004, Juan Alonso wrote:
Hello list,
I find often myself wanting to append a variable to an unknown url. The
problem is that you don't know
I don't know if we should get into this. Do we *really* care if we crash on
exit? We are talking about MSHUTDOWN not RSHUTDOWN here. It's not an ideal
situation but I wouldn't want screw things in PHP just for these dumb
shared libraries :)
Andi
At 02:36 PM 1/20/2004 +0100, Ard Biesheuvel
I don't know if we should get into this. Do we *really* care if we crash
on exit?
Are you serious ?? Of course we care about segfaults, don't we, even if
it's 'only' on exit ??
We are talking about MSHUTDOWN not RSHUTDOWN here. It's not an
Depends if you use dl() or load from php.ini. If
Hi,
I am working on porting PHP 5.0 onto NetWare. I would like to start
checking in the changes into the PHP 5.0 source code branch. What is the
project name that I need to check in?
Thanks,
Ananth.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
At 12:42 PM 1/21/2004 +0100, Ard Biesheuvel wrote:
I don't know if we should get into this. Do we *really* care if we crash
on exit?
Are you serious ?? Of course we care about segfaults, don't we, even if
it's 'only' on exit ??
What I'm saying is that if it were to require some ugly hacks in PHP
At 04:48 AM 1/21/2004 -0700, Ananth Kesari wrote:
Hi,
I am working on porting PHP 5.0 onto NetWare. I would like to start
checking in the changes into the PHP 5.0 source code branch. What is the
project name that I need to check in?
Ananth,
We are in a code-freeze now. You are welcome to commit
At 07:53 PM 1/21/2004 +0800, James Devenish wrote:
In message [EMAIL PROTECTED]
on Wed, Jan 21, 2004 at 03:31:08AM -0800, Rasmus Lerdorf wrote:
$url = urlappendvar($_SERVER['HTTP_REFERER'], 'foo', $foo);
Generally we don't add functions to replace simple one-line PHP
expressions.
$url .=
There is some BC issue, because if you configured gpc_order for something
specific and you rely on it, this setting will be silently ignored...
I *think* it's probably not that popular to change it, and that it's
becoming less and less of an issue with the autoglobals. But on the other
hand,
James Devenish wrote:
$url .= strstr($url,'?')??foo=$foo:foo=$foo;
Without wanting to make any comment about the merits of the proposed
function, I would have thought there would be merit in having a set of
generalised URL-manipulation functions (if someone wanted to write them,
that is).
dl() is evil and should be deprecated. Actually that reminds me to add
an E_STRICT about it. Shared libraries should only be loaded via php.ini.
How about setting 'enable_dl' to 'Off' in php.ini-recommended ?
--
Ard
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On Wed, 21 Jan 2004 14:06:55 +0100
Ard Biesheuvel [EMAIL PROTECTED] wrote:
dl() is evil and should be deprecated. Actually that reminds me to
add an E_STRICT about it. Shared libraries should only be loaded via
php.ini.
How about setting 'enable_dl' to 'Off' in php.ini-recommended ?
In message [EMAIL PROTECTED]
on Wed, Jan 21, 2004 at 02:43:57PM +0100, Petras Kudaras wrote:
Shouldn't that go into separate module (available from PEAR) or something?
Sticking as many things into the core as possible seems to be the reason
a lot of people don't like PHP ;)
I don't know what
I agree; we can't deprecate dl().
There are some very common legitimate cases where it is really
useful, such as loading extensions that are not often needed into
a CGI (you don't want those in php.ini as they can slow down
your process startup).
--Wez.
dl() is evil and should be deprecated.
I am so sorry about the last time , I didn't understand good but now its realy very
clear to me, okay
this what we will do :
1- any translations works ( English =}] Arabic )
2-make an arabic interface
3-protect your rights in Jordan , Saudi Arabia and UAE
Wez Furlong wrote:
I agree; we can't deprecate dl().
There are some very common legitimate cases where it is really
useful, such as loading extensions that are not often needed into
a CGI (you don't want those in php.ini as they can slow down
your process startup).
I agree, but perhaps we should
I agree with Rasmus, I don´t believe that it is necessary to add a new
function that can be solved with a simple line in PHP, another thing would
be to be able to make the function your same one and to add it to your PHP.
You can add into ext/standard/string.c your function.
Iván Rodriguez Espada
On Wed, 21 Jan 2004 14:52:57 +0100
Ard Biesheuvel [EMAIL PROTECTED] wrote:
Changing the recommended setting of enable_dl is a first step.
I disagree. Set enable_dl Off in the recommanded php.ini will make it
disabled in many situations. This is not something good. But this
discussions sounds
On Wed, 21 Jan 2004, Andi Gutmans wrote:
In general, I think casting an object to an array sucks.
I would be all for an E_STRICT message that this is deprecated as we have
real objects now and IMO, and that...
...the behavior might change/go away sometime in the future.
Are you saying you
Changing the recommended setting of enable_dl is a first step.
I disagree. Set enable_dl Off in the recommanded php.ini will make it
disabled in many situations. This is not something good. But this
discussions sounds like 'Do we have to educate endusers?'. Wez sample
usage is the perfect
On Wed, 21 Jan 2004, Andi Gutmans wrote:
*see above*. Derick did this without consultation and even if you agree or
don't agree with it, he shouldn't have done it in the first place.
I added it without consultation too, that was wrong, so I corrected it :)
Derick
--
PHP Internals - PHP
On Wed, 21 Jan 2004, Ananth Kesari wrote:
I am working on porting PHP 5.0 onto NetWare. I would like to start
checking in the changes into the PHP 5.0 source code branch. What is the
project name that I need to check in?
Please show us some patches first. I remember from last time that a lot
Do fresh checkout of 'php5' module. You'll get all correct
files then, no need to checkout ZendEngine2 separately..
--Jani
On Wed, 21 Jan 2004, Patrick Welche wrote:
I just cvs update -A a php4 src tree to get php5 (had to checkout ZendEngine2),
and assume that the next
Translating documentation to Russian language.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Andi Gutmans wrote:
Zeev is planning on fixing this.
Cool.
Interfaces should be allowed to extend other interfaces but not
to implement them.
interface Bar extends Foo {}
works already (at least last time I checked). What I need (and meant) is
interface Barbara extends Bar, Foo
Hi Folks:
I'm close to competing major bug fixes and enhancements to PEAR DB. It
would be nice if it can get into the upcoming 4.3.5 release. Is this
still possible? If so, what's the deadline, please?
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
Remind me to remove your Karma :)
At 07:08 PM 1/21/2004 +0100, Derick Rethans wrote:
On Wed, 21 Jan 2004, Andi Gutmans wrote:
*see above*. Derick did this without consultation and even if you agree or
don't agree with it, he shouldn't have done it in the first place.
I added it without
On Wed, 21 Jan 2004, Zeev Suraski wrote:
There is some BC issue, because if you configured gpc_order for something
specific and you rely on it, this setting will be silently ignored...
Well, my patch makes variables_order to default to EGPCS
so it wouldn't mean the variables wouldn't be
Why is PHP the only scripting language that has an issue with loading
binary extensions at run time? :(
Shane
Ard Biesheuvel wrote:
Wez Furlong wrote:
I agree; we can't deprecate dl().
There are some very common legitimate cases where it is really
useful, such as loading extensions that are
44 matches
Mail list logo
