Hi,
> >> > 2) error reporting using exceptions.
> >> > I would like it if I could catch PHP-errors and take appropriate
action
> >> > (such as logging it to a database or whatever).
> >>
> >> You can already do that with 5.1 by adding three lines of code.
>
> > Sounds awesome.. is this documented
Hello Ron,
Wednesday, August 31, 2005, 9:02:37 PM, you wrote:
> "Marcus Boerger" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> Hello Ron,
>>
>> Wednesday, August 31, 2005, 3:37:51 PM, you wrote:
>>
>> > 2) error reporting using exceptions.
>> > I would like it if I could catch
"Marcus Boerger" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hello Ron,
>
> Wednesday, August 31, 2005, 3:37:51 PM, you wrote:
>
> > 2) error reporting using exceptions.
> > I would like it if I could catch PHP-errors and take appropriate action
> > (such as logging it to a datab
Hello Ron,
Wednesday, August 31, 2005, 3:37:51 PM, you wrote:
> 2) error reporting using exceptions.
> I would like it if I could catch PHP-errors and take appropriate action
> (such as logging it to a database or whatever).
You can already do that with 5.1 by adding three lines of code.
> 4) i
Michael,
To your question, I don't want to encourage this style of programming.
Andi
At 10:24 PM 8/23/2005, Michael Walter wrote:
Zeev,
On 8/24/05, Michael Walter <[EMAIL PROTECTED]> wrote:
> On 8/23/05, Zeev Suraski <[EMAIL PROTECTED]> wrote:
> > >"Real" anonymous functions (as in, closures)
Zeev,
On 8/24/05, Michael Walter <[EMAIL PROTECTED]> wrote:
> On 8/23/05, Zeev Suraski <[EMAIL PROTECTED]> wrote:
> > >"Real" anonymous functions (as in, closures) should be able to capture
> > >variables from its lexical environment, e.g.:
> >
> > create_function() accepts a string, and that stri
Zeev,
On 8/23/05, Zeev Suraski <[EMAIL PROTECTED]> wrote:
> >"Real" anonymous functions (as in, closures) should be able to capture
> >variables from its lexical environment, e.g.:
>
> create_function() accepts a string, and that string is constructed with
> full access to the lexical scope of th
> From: Michael Walter [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 23, 2005 10:18 AM
> To: Stanislav Malyshev
> Cc: Marcus Boerger; internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: PHP 6.0 Wishlist
>
>
> On 8/22/05, Stanislav Malyshev <[EMAIL PROTECTED]> w
Zeev,
My only gripe with create_function() is the inherent "dirt" involved
in handing a code-containing string to a function. I've been living
in the app development world for some time now, so my example stash
is clean out, but my notion is that, for folks who have a real, novel
applica
At 18:47 23/08/2005, Dmitry Stogov wrote:
> function adder($a) {return function($b) {return $a+$b;}}
> function index($i) {return function($a) {return $a[$i];}}
>
> I'm sure you can think of useful examples.
I like this syntax and expected behavior.
The only problem is implementation.
That
Hello George,
Monday, August 22, 2005, 9:53:02 PM, you wrote:
> On Aug 22, 2005, at 2:08 PM, Stanislav Malyshev wrote:
MB * Anonymous functions. The real stuff, not just some odd string
MB passed to create_function().
MB>>>
MB>>>There were some others already asking for this, maybe we
At 09:18 23/08/2005, Michael Walter wrote:
On 8/22/05, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> MB>>> * Anonymous functions. The real stuff, not just some odd string
> MB>>> passed to create_function().
> MB>>
> MB>>There were some others already asking for this, maybe we should at
least
> -Original Message-
> From: Michael Walter [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 23, 2005 10:18 AM
> To: Stanislav Malyshev
> Cc: Marcus Boerger; internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: PHP 6.0 Wishlist
>
>
> On 8/22/05, Stanislav
On 8/22/05, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> MB>>> * Anonymous functions. The real stuff, not just some odd string
> MB>>> passed to create_function().
> MB>>
> MB>>There were some others already asking for this, maybe we should at least
> MB>>give it a thought if it is doable at all
GS>>1) syntactical: the amount of escaping/funkyjunk you need to do to
GS>>have anonymous functions look like regular functions in their
GS>>declaration is huge (yes, you can use heredocs, but they have their
GS>>(big if you run up against them) limitations as well).
Well, this is right and va
MW>> function adder($a) {return function($b) {return $a+$b;}}
As opposed to:
function adder($a) { return create_function('$b', 'return
'.(integer)$a.'+$b;'); }
Former form may be a bit prettier, but no substantial difference here.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECT
On Mon, 22 Aug 2005, Mikko Rantalainen wrote:
upload *before* it has been completed. Make it possible to handle *big*
uploads without requiring uploaded file to fit the memory. Handle multiple
This was changed in PHP 4.2.0, the file uploading code was rewritten
to not load the whole fi
On Aug 22, 2005, at 2:08 PM, Stanislav Malyshev wrote:
MB>>> * Anonymous functions. The real stuff, not just some odd string
MB>>> passed to create_function().
MB>>
MB>>There were some others already asking for this, maybe we should
at least
MB>>give it a thought if it is doable at all, anyb
l>>i think that create_function() does an eval() at runtime, which is more
l>>expensive. anonymous functions would be handled in the compiler.
Well, since function code is compiled once anyway, it shouldn't matter
much when it is compiled - before first opcode was executed or after that.
--
St
i think that create_function() does an eval() at runtime, which is more
expensive. anonymous functions would be handled in the compiler.
l0t3k
"Stanislav Malyshev" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Just out of curiosity, what's bad in create_function and how "real" on
i think that create_function() does an eval() at runtime, which is more
expensive. anonymous functions would be handled in the compiler.
l0t3k
"Stanislav Malyshev" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Just out of curiosity, what's bad in create_function and how "real"
MB>>> * Anonymous functions. The real stuff, not just some odd string
MB>>> passed to create_function().
MB>>
MB>>There were some others already asking for this, maybe we should at least
MB>>give it a thought if it is doable at all, anybody?
Just out of curiosity, what's bad in create_function an
Hello Mikko,
Monday, August 22, 2005, 4:09:31 PM, you wrote:
> Rasmus Lerdorf wrote:
>> Since we are breaking a lot of stuff in 6.0, at least with
>> Unicode_semantics=On I am wondering if it may not be time to break some
> +100 for Unicode support
>> 1. Remove register_globals completely
> +1
Marcus Boerger wrote:
> to prevent confusion with more readers - i am against an ini option here.
> Either keep the way it is right now or make everything case sensitive.
> And of course i like speed which is support for the latter to be clear.
What about deprecating case-insensitive identifiers
On Sat, 13 Aug 2005, Sara Golemon wrote:
> > > set short_open_tags to off in any sample php.ini we ship.
> >
> > Ah yes, that reminds me:
> >
> > 17. Nuke every "alternative" open tag and only have >
> Agreed (though not so much nuke as default to off).
>
> Whenever open tags comes up, I
On Sat, 13 Aug 2005, Marcus Boerger wrote:
> Hello Derick,
>
> Saturday, August 13, 2005, 2:17:52 PM, you wrote:
>
> > On Fri, 12 Aug 2005, Sara Golemon wrote:
>
> >> > 7. Make identifiers case-sensitive
> >> >
> >> Or perhaps optionally case sensitive? I dunno, I've made my peace with PHP
> >
On Sat, 13 Aug 2005, Joseph Crawford wrote:
> what if i wanted to make sure it was a String, Integer, Boolean, Float,
> etc.. i would like to see that added to the type hinting ;)
This is not going to happen. We've discussed this plenty of times
before.
Derick
--
PHP Internals - PHP Runtime
"Christian Schneider" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> foo(id: 64738, name: "foo");
Oh, I love that syntax ;)
Ron
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Sat, 13 Aug 2005, Sara Golemon wrote:
set short_open_tags to off in any sample php.ini we ship.
Ah yes, that reminds me:
17. Nuke every "alternative" open tag and only have
Agreed (though not so much nuke as default to off).
Whenever open tags comes up, I'll toss
set short_open_tags to off in any sample php.ini we ship.
Ah yes, that reminds me:
17. Nuke every "alternative" open tag and only have
Agreed (though not so much nuke as default to off).
Whenever open tags comes up, I'll toss
Hello Emil,
Sunday, August 14, 2005, 12:49:46 AM, you wrote:
> Talking about type hinting. It would be nice to be able to declare
> variables as a certain type once and for all (like c, although
> optional). I don't if this has been discussed and dismissed before,
> and if that is the case, pleas
Hello Joseph,
Sunday, August 14, 2005, 12:31:42 AM, you wrote:
> I would like to see the Type Hinting expanded in PHP 6. In 5 now you can do
> class Test {
> public function testDatabase( Database $db ) {
> }
> }
> what if i wanted to make sure it was a String, Integer, Boolean, Float,
> etc
On Sat, 13 Aug 2005, Lukas Smith wrote:
Ron Korving wrote:
16. Support for
that reminds me:
set short_open_tags to off in any sample php.ini we ship.
Ah yes, that reminds me:
17. Nuke every "alternative" open tag and only have http://www.php.net/unsub.php
Christian Schneider wrote:
What I don't like about Python at all is that AFAIK you can't call a
method with parameters not declared in the function definition.
Oops, Python does allow this with a *parameter or **parameter. Missed
that part when reading the specs :-)
- Chris
--
PHP Internals
George Schlossnagle wrote:
Huh? Perl doesn't have true support for this anyway, just a simpler
syntax for hashrefs. If you want Perlish named params this is 100%
identical to doing
foo(array('id' => 42, 'name' => 'foo'));
If you are using this a lot then syntactic sugar does make a differ
i agree with the last post, it would be nice for PHP to be a weakly typed
language but allow for the user to program strongly typed if they want to
such as the above suggestion of having the option to declare the type for a
variable.
--
Joseph Crawford Jr.
Codebowl Solutions, Inc.
1-802-671-2
Talking about type hinting. It would be nice to be able to declare
variables as a certain type once and for all (like c, although
optional). I don't if this has been discussed and dismissed before,
and if that is the case, please don't kill me. You're just
brainstorming anyway, right? :)
Emil
--
I would like to see the Type Hinting expanded in PHP 6. In 5 now you can do
class Test {
public function testDatabase( Database $db ) {
}
}
what if i wanted to make sure it was a String, Integer, Boolean, Float,
etc.. i would like to see that added to the type hinting ;)
--
Joseph Crawford J
On Aug 13, 2005, at 5:57 PM, Andrey Hristov wrote:
George Schlossnagle wrote:
On Aug 13, 2005, at 5:49 PM, Andrey Hristov wrote:
George Schlossnagle wrote:
On Aug 13, 2005, at 11:46 AM, Matthew Weier O'Phinney wrote:
* Christian Schneider <[EMAIL PROTECTED]> :
9. Named parameters.
George Schlossnagle wrote:
On Aug 13, 2005, at 5:49 PM, Andrey Hristov wrote:
George Schlossnagle wrote:
On Aug 13, 2005, at 11:46 AM, Matthew Weier O'Phinney wrote:
* Christian Schneider <[EMAIL PROTECTED]> :
9. Named parameters. Preferred way would be via array()-less array
collation
On Aug 13, 2005, at 5:49 PM, Andrey Hristov wrote:
George Schlossnagle wrote:
On Aug 13, 2005, at 11:46 AM, Matthew Weier O'Phinney wrote:
* Christian Schneider <[EMAIL PROTECTED]> :
9. Named parameters. Preferred way would be via array()-less array
collation as we are already using thi
George Schlossnagle wrote:
On Aug 13, 2005, at 11:46 AM, Matthew Weier O'Phinney wrote:
* Christian Schneider <[EMAIL PROTECTED]> :
9. Named parameters. Preferred way would be via array()-less array
collation as we are already using this in our production system ;-) :
foo('id' => 42, 'name'
On Aug 13, 2005, at 11:46 AM, Matthew Weier O'Phinney wrote:
* Christian Schneider <[EMAIL PROTECTED]> :
9. Named parameters. Preferred way would be via array()-less array
collation as we are already using this in our production system ;-) :
foo('id' => 42, 'name' => "foo");
+1 -- this is
I am a bit reluctant to remove the old "functionality" outright, hence
the optional flag. Either way it seems better then what we've got right now.
Ilia
Stefan Esser wrote:
> Hello Ilia,
>
> if you look at the implementation of header() you will realise that
> sending multiple headers is actuall
Hello Ilia,
if you look at the implementation of header() you will realise that
sending multiple headers is actually already abusing how it was designed
to work. Because the internal checks for double headers etc. do not work
at all when you send multiple headers.
Stefan
--
PHP Internals -
How about we do this:
Add a 3rd optional param to header(), if it is unset we remove
everything from a header that contains \r\n or \n after those chars.
However if the developer feels the need to send multiple headers or what
not they can pass 3rd arg as TRUE and "restore" the functionality.
Ilia
Hello internals,
Saturday, August 13, 2005, 2:58:26 PM, you wrote:
> Hello Derick,
> Saturday, August 13, 2005, 2:17:52 PM, you wrote:
>> On Fri, 12 Aug 2005, Sara Golemon wrote:
>>> > 7. Make identifiers case-sensitive
>>> >
>>> Or perhaps optionally case sensitive? I dunno, I've made my pea
On Sat, 13 Aug 2005 14:17:52 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
> On Fri, 12 Aug 2005, Sara Golemon wrote:
>
> > > 7. Make identifiers case-sensitive
> > >
> > Or perhaps optionally case sensitive? I dunno, I've made my
> > peace with PHP being (mostly) case-insensitive.
>
>
Christian Schneider wrote:
Rasmus Lerdorf wrote:
4. Include an opcode cache by default. A lot of work has gone into
pecl/apc recently, but I am not hung up on which one goes in.
Big +1
9. Named parameters. Preferred way would be via array()-less array
collation as we are already using
Hello Derick,
Saturday, August 13, 2005, 2:17:52 PM, you wrote:
> On Fri, 12 Aug 2005, Sara Golemon wrote:
>> > 7. Make identifiers case-sensitive
>> >
>> Or perhaps optionally case sensitive? I dunno, I've made my peace with PHP
>> being (mostly) case-insensitive.
> We can't make it optional.
On Fri, 12 Aug 2005, Sara Golemon wrote:
> > 7. Make identifiers case-sensitive
> >
> Or perhaps optionally case sensitive? I dunno, I've made my peace with PHP
> being (mostly) case-insensitive.
We can't make it optional... that would be just too much problems for
writing portable scripts.
De
Hello,
Minor:
11. HTTP response splitting attack protection: Replace \r and \n with
space in header();
Information and patches implementing this can be found at
http://cschneid.com/php/
Your patches are problematic when a proxy kills overlong header lines
that were not split up by the cl
Hi Davey Shafik!
On 08/12/05 20:56 you wrote:
> As little as it means, +1
Same from here! :)
Cheers!
Toby
--
Tobias Schlitt - Zend Certified Engineer GPG Key: 0xA6529579
a passion for phphttp://www.schlitt.info
Like to say "thank you"?- http://pear.php.ne
On Aug 12, 2005, at 3:33 PM, Lukas Smith wrote:
+1 on all the mentioned items, except for case sensitivity for
identifiers where I am -1 (I dont see the benefit).
Aside from that I wouldnt mind an aggressive function name and
parameter order clean up. We could provide a BC lib via runkit (
We definitely need to start thinking forward and introduct a 64-bit
type. It needn't replace the 32-bit type.
IIRC, Andi promised that we would have this after 5.1, so I think it's
a done deal.
It's especially important now that we have a number of extensions
returning 64-bit data.
And with Visu
On Fri, 12 Aug 2005, Pierre-Alain Joye wrote:
On Sat, 13 Aug 2005 00:21:29 +0300 (EEST)
[EMAIL PROTECTED] (Jani Taskinen) wrote:
Very good idea. We do bundle the thing? :)
I do not think we can use the extern GD2 in the same nice way than
we use ours.
But droping _extern_ gd2 support
On Sat, 13 Aug 2005 00:21:29 +0300 (EEST)
[EMAIL PROTECTED] (Jani Taskinen) wrote:
>
> Very good idea. We do bundle the thing? :)
I do not think we can use the extern GD2 in the same nice way than
we use ours.
But droping _extern_ gd2 support is possible. The only remaining
thing is to che
Very good idea. We do bundle the thing? :)
--Jani
On Fri, 12 Aug 2005, Ilia Alshanetsky wrote:
This is a very good, point we really should drop support for things like
gd1 (no reason anymore, latest versions (including bundled) have GIF
support). These only add a hundreds of ifdefs to
Wez Furlong wrote:
On 8/12/05, Wez Furlong <[EMAIL PROTECTED]> wrote:
A reasonable goal would be to make sure that all our extensions are
full pecl citizens, so that intermediate fixes to any of these so
called "core" extensions could be released via PECL very easily.
One of the biggest gripe
PS: This doesn't necessarily mean that they all need to be physically
unbundled from the main distro.
--Wez.
On 8/12/05, Wez Furlong <[EMAIL PROTECTED]> wrote:
> A reasonable goal would be to make sure that all our extensions are
> full pecl citizens, so that intermediate fixes to any of these so
A reasonable goal would be to make sure that all our extensions are
full pecl citizens, so that intermediate fixes to any of these so
called "core" extensions could be released via PECL very easily.
One of the biggest gripes our SA's have is that if they forget to
enable a core PHP extension and l
Jani and Derick have so far done a very good job doing that, I think
just about all uncommon extensions have been migrated. But, if something
was missed moving it to pecl would be a good idea.
Ilia
Michael Wallner wrote:
> Rasmus Lerdorf wrote:
>
> [lots of reasonable points]
>
> What about mov
Maybe this is too far reaching but what about making function
parameter orders consistent? For example, make in_array() require
in_array(array haystack, mixed needle[...) just as most of the string
functions.
-D
On Aug 12, 2005, at 12:32 PM, Ilia Alshanetsky wrote:
This is a very good, p
This is a very good, point we really should drop support for things like
gd1 (no reason anymore, latest versions (including bundled) have GIF
support). These only add a hundreds of ifdefs to the code or prevent
usage of new(er) functionality.
IMHO we should see what is the lowest possible version
64 matches
Mail list logo
