Re: [PHP-DEV] Suggestion: Add optional suffix to tempnam()

On Sat, Apr 12, 2014 at 06:33:40AM +, Ferenc Kovacs wrote: On Sat, Apr 12, 2014 at 12:24 AM, Stefan Neufeind wrote: Hi, I'd like to pick up the original discussion about this patch here again. There have some updates on the github-pull. Maybe somebody could have a look into this, please?

Re: [PHP-DEV] Suggestion: Inconsistency: Allow array spread operator to work on string keys

Le Wed, 2 Dec 2020 17:45:47 +, "G. P. B." a écrit : > The reason why this has been deferred is because of which semantics should > be used for duplicate string keys. ['a' => 1, ...['a' => 2]] should be the same as ['a' => 1, 'a' => 2], I do not see how any other way would be justifiable. Th

Re: [PHP-DEV] Suggestion: Inconsistency: Allow array spread operator to work on string keys

Am 02.12.2020 um 18:24 schrieb Florian Stascheck : > I suggest to allow string keys to also be used in array literals: > > $template = ['created_at' => time(), 'is_admin' => 1]; > $db_rows = [ > ['name' => 'Alice', 'email' => 'al...@example.org', ...$template], > ['name' => 'Bob', 'email' => 'b.

Re: [PHP-DEV] Suggestion: Inconsistency: Allow array spread operator to work on string keys

> > The reason why this has been deferred is because of which semantics should > be used for duplicate string keys. > > Do we use the addition between two arrays semantics or the array_merge() > semantics? See: https://3v4l.org/7QbWv > > As the previous RFC you linked initially wanted to use the

Re: [PHP-DEV] Suggestion: Inconsistency: Allow array spread operator to work on string keys

On Wed, Dec 2, 2020 at 10:46 AM G. P. B. wrote: > The reason why this has been deferred is because of which semantics should > be used for duplicate string keys. > > Do we use the addition between two arrays semantics or the array_merge() > semantics? See: https://3v4l.org/7QbWv array_merge is th

Re: [PHP-DEV] Suggestion: Inconsistency: Allow array spread operator to work on string keys

On Wed, 2 Dec 2020 at 17:24, Florian Stascheck wrote: > Hello! > > With PHP8 released and the named arguments RFC being implemented, there's > now an inconsistency in how the spread operator works. > > Historically, the spread operator was first used in PHP 5.6 for arguments: > > function php56($

[PHP-DEV] Suggestion: Inconsistency: Allow array spread operator to work on string keys

Hello! With PHP8 released and the named arguments RFC being implemented, there's now an inconsistency in how the spread operator works. Historically, the spread operator was first used in PHP 5.6 for arguments: function php56($a, $b) { return $a + $b; } $test = [1, 2]; php56(...$test) === 3;

Re: [PHP-DEV] Suggestion: Make all PCRE functions return *character* offsets, rather than *byte* offsets if the modifier `u` (PCRE_UTF8) is given

Hi, Working with UTF-8-encoded strings does not implies working with mb_string functions or with code-point counts. Personnally, I work with standard string functions, plus [Grapheme functions] (https://www.php.net/manual/en/ref.intl.grapheme.php

[PHP-DEV] Suggestion: Make all PCRE functions return *character* offsets, rather than *byte* offsets if the modifier `u` (PCRE_UTF8) is given

Hi, this is a follow-up of a bug I opened, and cmb suggested to continue here: https://bugs.php.net/bug.php?id=80166 Advantages: 1: Easier string manipulation: If somebody does (as in my case) `preg_match_all()` with PREG_OFFSET_CAPTURE, what will they probably use those returned numbers/offsets

Re: [PHP-DEV] Suggestion Method Constant

On 12/10/2017 22:32, Sara Golemon wrote: answer, but (Foo::class.'::bar') may be what some would expect. Ideally we'd have first-class references to functions. -Sara To chime in.. To my mind, references to functions is the holy grail so far as beginning to clean up the entire ecosystem arou

Re: [PHP-DEV] Suggestion Method Constant

On 12/10/2017 22:32, Sara Golemon wrote: > Ideally we'd have first-class references to functions. > -Sara To chime in.. To my mind, references to functions is the holy grail so far as beginning to clean up the entire ecosystem around function calls. IMHO directly referencing MyClass::StaticFu

Re: [PHP-DEV] Suggestion Method Constant

> > I also thought about the same for functions, just to be even more > consistent. > my_func::function I already had the exact same ideas, but didn't propose them yet. $obj::foo::method could be used for instance methods, while Obj::foo::method could be for static methods. Regards, Niklas

Re: [PHP-DEV] Suggestion Method Constant

I also thought about the same for functions, just to be even more consistent. my_func::function On 12 Oct 2017 23:32, "Sara Golemon" wrote: > On Thu, Oct 12, 2017 at 2:33 PM, Michael Döhler > wrote: > > I am open for any approach, but maybe we have to differentiate between > class constants and

Re: [PHP-DEV] Suggestion Method Constant

On Thu, Oct 12, 2017 at 2:33 PM, Michael Döhler wrote: > I am open for any approach, but maybe we have to differentiate between class > constants and method references? > Given the discussion we had around the namespace separator (and why we DIDN'T go with ::), there may be similar issues here.

Re: [PHP-DEV] Suggestion Method Constant

Hi, I am open for any approach, but maybe we have to differentiate between class constants and method references? Michael > Am 12.10.2017 um 20:28 schrieb Mathias Grimm : > > The only problem with the @ symbol is the lack of consistency with the other > constants class constants are also My

Re: [PHP-DEV] Suggestion Method Constant

Hi, Same i have in mind, for example: MyClass@myMethod To make also some method call routing easier, e.g. in userland routers. Transform the current approach: $app->get("/foo", [MyClass::class, "myMethod"]); To: $app->get("/foo", MyClass@myMethod); This will ease a lot, e.g. for refactoring,

Re: [PHP-DEV] Suggestion Method Constant

The only problem with the @ symbol is the lack of consistency with the other constants class constants are also MyClass::MY_CONST, or MyClass::class, so I think it makes sense to also be MyClass::myMethod::method On 12 October 2017 at 20:24, Michael Döhler wrote: > Hi, > > Same i have in mind, f

[PHP-DEV] Suggestion Method Constant

I would like to suggest a method constant that could be used the same way we use the ::class one I don't have a strong personal preference but it could be something like: MyController::myActionMethod::method, no sure about the internals but it would be consistent with the one for the class. Chee

Re: [PHP-DEV] Suggestion

On 01/09/2016 13:12, Marco Pivetta wrote: Yeah, and I would question: 1. why are you editing with a plaintext editor and searching stuff like that? Are you in a super-hurry? Seems like a 0.001% scenario 2. why do you need to search for functions in a class? Just what kind of monstrous abominat

Re: [PHP-DEV] Suggestion

On Thu, Sep 1, 2016 at 3:06 AM, Robert Williams wrote: > On Aug 31, 2016, at 11:49, Yasuo Ohgaki wrote: > > > I remember an argument that "function" is useful to "grep functions". > This is true, but we have tokenizer and tokenizer does better job. > e.g. It excludes functions inside comments. >

Re: [PHP-DEV] Suggestion

On Aug 31, 2016, at 11:49, Yasuo Ohgaki wrote: > > I remember an argument that "function" is useful to "grep functions". > This is true, but we have tokenizer and tokenizer does better job. > e.g. It excludes functions inside comments. > > It may be time to consider simplifying things. Perhaps,

Re: [PHP-DEV] Suggestion

On Mon, Aug 29, 2016 at 10:22 PM, Arvids Godjuks wrote: > As was said, this was debated a lot. Both sides had valid arguments, but > this should not be taken lightly just because there is no "BC break". There > is such thing as too much syntactic sugar, and PHP is one of those, rare > these days,

Re: [PHP-DEV] Suggestion

As was said, this was debated a lot. Both sides had valid arguments, but this should not be taken lightly just because there is no "BC break". There is such thing as too much syntactic sugar, and PHP is one of those, rare these days, languages that keep options of doing the same thing low. On Mon,

Re: [PHP-DEV] Suggestion

Hi, Thanks Seems like is not going to happen very soon :) In fact it is not broken, it's only a cosmetic nice to have. Maybe in the future it will happen. On 29 August 2016 at 14:06, Kalle Sommer Nielsen wrote: > Hi Mathias > > 2016-08-29 15:03 GMT+02:00 Mathias Grimm : > > Hi, > > I have a su

Re: [PHP-DEV] Suggestion

Hi Mathias 2016-08-29 15:03 GMT+02:00 Mathias Grimm : > Hi, > I have a suggestion, maybe many gave it before. > > My suggestion is the optional use of the keyword "function" inside classes, > interfaces and traits. > It would look much more clean while removing the redundancy. This was discussed

[PHP-DEV] Suggestion

Hi, I have a suggestion, maybe many gave it before. My suggestion is the optional use of the keyword "function" inside classes, interfaces and traits. It would look much more clean while removing the redundancy. Cheers, Mathias Grimm

Re: [PHP-DEV] Suggestion: Adding PUT, PATCH and DELETE

+1 Yes, it is useful to have in the PHP core. Possible names: $_BODY, $_DATA, $_INPUT, $_REQUEST -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Suggestion: Adding PUT, PATCH and DELETE

I've read some of the earlier discussion (not all, require sleep will read more tomorrow). To be clear I don't want to start a naming discussion again. If we have a new name for $_POST or not isn't the main focus of this PR. I want to allow PUT, PATCH and DELETE and handle them the same way as PO

Re: [PHP-DEV] Suggestion: Adding PUT, PATCH and DELETE

On Mon, Sep 14, 2015 at 3:22 PM, Daniel Persson wrote: > Hi. > > I've not been a member for too long so I might have missed if this have > been discussed earlier. > > But I've created a small PR to the basic request handling to support PUT, > PATCH and DELETE. > > https://github.com/php/php-src/p

[PHP-DEV] Suggestion: Adding PUT, PATCH and DELETE

Hi. I've not been a member for too long so I might have missed if this have been discussed earlier. But I've created a small PR to the basic request handling to support PUT, PATCH and DELETE. https://github.com/php/php-src/pull/1519 Summary: Added support for request methods with the smallest

Re: [PHP-DEV] Suggestion: echo function(var)[0];

Hi all, 2010/6/5 Felipe Pena > Hi! > > 2010/6/4 Stas Malyshev > > Hi! >> >> >> function call chaining (f()() if f() returns function), and array >>> dereferencing (f()[0]) - (Stas) >>> >> >> I did patch for f()() - it's referenced at >> http://wiki.php.net/rfc/fcallfcall - but not for f()[] -

Re: [PHP-DEV] Suggestion: echo function(var)[0];

Sorry for the ambiguity in my original message, and thanks to Tig for PM-ing me about that. To clarify, I support the syntax for: > echo function(var)[0]; and I believe this syntax: > $tmp = getimagesize('./path/to/image'); > echo $tmp[1]; to be awkward and inconvenient. Furthermore, it feels

Re: [PHP-DEV] Suggestion: echo function(var)[0];

Felipe Pena schreef: > Hi! > > 2010/6/4 Stas Malyshev > >> Hi! >> >> >> function call chaining (f()() if f() returns function), and array >>> dereferencing (f()[0]) - (Stas) >>> >> I did patch for f()() - it's referenced at >> http://wiki.php.net/rfc/fcallfcall - but not for f()[] - didn't have

Re: [PHP-DEV] Suggestion: echo function(var)[0];

Hi! 2010/6/4 Stas Malyshev > Hi! > > > function call chaining (f()() if f() returns function), and array >> dereferencing (f()[0]) - (Stas) >> > > I did patch for f()() - it's referenced at > http://wiki.php.net/rfc/fcallfcall - but not for f()[] - didn't have time > for that yet. > > It should

Re: [PHP-DEV] Suggestion: echo function(var)[0];

I don't understand what is holding PHP back from having this syntax. Tig said: The need to assign the trivial variable $tmp first is completely arbitrary. Is it not a design goal somewhere that languages should allow the greatest degree of literal expression possible, consistent with existing sy

Re: [PHP-DEV] Suggestion: echo function(var)[0];

On 06/04/2010 10:00 AM, Richard Quadling wrote: On 4 June 2010 08:18, mathieu.suen wrote: Hi Why not something more generic. Someone could think of a ValueNode. Then it could be use for object, array, any primitive type ... I will take the ValueNode as a non terminal grammar node. So fir

Re: [PHP-DEV] Suggestion: echo function(var)[0];

On 4 June 2010 08:18, mathieu.suen wrote: > Hi > > Why not something more generic. > Someone could think of a ValueNode. > > Then it could be use for object, array, any primitive type ... > > I will take the ValueNode as a non terminal grammar node. > So first we could do that: > > ValueNode->meth

Re: [PHP-DEV] Suggestion: echo function(var)[0];

Hi Why not something more generic. Someone could think of a ValueNode. Then it could be use for object, array, any primitive type ... I will take the ValueNode as a non terminal grammar node. So first we could do that: ValueNode->method(); ValueNode::sMethod(); ValueNode[]; foo(ValueNode); ech

Re: [PHP-DEV] Suggestion: echo function(var)[0];

Hi! function call chaining (f()() if f() returns function), and array dereferencing (f()[0]) - (Stas) I did patch for f()() - it's referenced at http://wiki.php.net/rfc/fcallfcall - but not for f()[] - didn't have time for that yet. It should not be too hard to do, one just has to be caref

Re: [PHP-DEV] Suggestion: echo function(var)[0];

2010/6/4 Tig : > On Fri, Jun 4, 2010 at 11:19 AM, Kalle Sommer Nielsen wrote: > So does this mean array-dereferencing was original declined but still > a possible for PHP 6? > That is how I'm reading it, but just want to make sure. I belive its because when its been proposed countless times on th

Re: [PHP-DEV] Suggestion: echo function(var)[0];

Hi, I've always wondered the same thing too. Would be a nice improvement. - Jon On Thu, Jun 3, 2010 at 9:12 PM, Tig wrote: > Would be at all possible to implement this kind of shortcut? > > echo function(var)[0]; > > For example, to print the height of an image: > echo getimagesize('./path/t

Re: [PHP-DEV] Suggestion: echo function(var)[0];

Hi, Has anyone attempted a patch for this? Or does anyone have an idea of the feasibility? Is it technically possible in a good/clean way? - Jon On Thu, Jun 3, 2010 at 9:29 PM, Tig wrote: > On Fri, Jun 4, 2010 at 11:19 AM, Kalle Sommer Nielsen > wrote: > > Hi Tig > > > > 2010/6/4 Tig : > >> W

Re: [PHP-DEV] Suggestion: echo function(var)[0];

On Fri, Jun 4, 2010 at 11:19 AM, Kalle Sommer Nielsen wrote: > Hi Tig > > 2010/6/4 Tig : >> Would be at all possible to implement this kind of shortcut? > > Its called array-dereferencing and it was proposed countless times, > including by myself. There is an RFC for this[1] and it was planned on

Re: [PHP-DEV] Suggestion: echo function(var)[0];

Hi Tig 2010/6/4 Tig : > Would be at all possible to implement this kind of shortcut? Its called array-dereferencing and it was proposed countless times, including by myself. There is an RFC for this[1] and it was planned on the old PHP6 todo at the PDT[2]. [1] http://wiki.php.net/rfc/functionarr

[PHP-DEV] Suggestion: echo function(var)[0];

Would be at all possible to implement this kind of shortcut? echo function(var)[0]; For example, to print the height of an image: Sure, if you want more than one of the returned array points, this would not be very efficient, however when you do only need one, it would be a lot nicer than: A

Re: [PHP-DEV] suggestion about ternary operator

On 22.11.2009, at 03:13, D. Dante Lorenso wrote: > Lukas Kahwe Smith wrote: >> On 21.11.2009, at 22:29, Dante Lorenso wrote: >>> I would love to restate my recommendation for the function "filled". >>> Which is the opposite of "empty". Filled would accept a variable >>> number of arguments and r

Re: [PHP-DEV] suggestion about ternary operator

Le Sat, 21 Nov 2009 19:52:30 -0800, Rasmus Lerdorf a écrit : > > Or better yet, have your filter function return false if the variable > doesn't exist and use the ternary to set the default. You can do it all > in a single step then. > > $var = filter_func($_GET,'foo')?:42; > > Simple and clea

Re: [PHP-DEV] suggestion about ternary operator

Alban wrote: > Le Sat, 21 Nov 2009 10:21:18 -0800, Rasmus Lerdorf a écrit : >> The ternary isn't meant to solve the isset thing you are talking about. >> It is simply a shortcut to normal ternary operations. The most common >> case where you don't know if a variable is set is on the initial input

Re: [PHP-DEV] suggestion about ternary operator

Le Sat, 21 Nov 2009 10:21:18 -0800, Rasmus Lerdorf a écrit : > > The ternary isn't meant to solve the isset thing you are talking about. > It is simply a shortcut to normal ternary operations. The most common > case where you don't know if a variable is set is on the initial input > via $_GET or

Re: [PHP-DEV] suggestion about ternary operator

Lukas Kahwe Smith wrote: On 21.11.2009, at 22:29, Dante Lorenso wrote: I would love to restate my recommendation for the function "filled". Which is the opposite of "empty". Filled would accept a variable number of arguments and return the first where empty evaluates as false. Like empty, fil

Re: [PHP-DEV] suggestion about ternary operator

On 21.11.2009, at 22:29, Dante Lorenso wrote: > I would love to restate my recommendation for the function "filled". > Which is the opposite of "empty". Filled would accept a variable > number of arguments and return the first where empty evaluates as > false. > > Like empty, filled would not t

Re: [PHP-DEV] suggestion about ternary operator

I would love to restate my recommendation for the function "filled". Which is the opposite of "empty". Filled would accept a variable number of arguments and return the first where empty evaluates as false. Like empty, filled would not throw notices for undefined variables. This is not the same a

Re: [PHP-DEV] suggestion about ternary operator

More interesting behaviors to dig are there: variable = ?? ; variable = ? : ?? ; or a la javascript variable = || ; Best, On Sat, Nov 21, 2009 at 10:21 AM, Rasmus Lerdorf wrote: > Alban wrote: >> Le Sat, 21 Nov 2009 09:48:10 +0100, Lukas Kahwe Smith a écrit : >> >>> On 21.11.2009, at 0

Re: [PHP-DEV] suggestion about ternary operator

Alban wrote: > Le Sat, 21 Nov 2009 09:48:10 +0100, Lukas Kahwe Smith a écrit : > >> On 21.11.2009, at 06:12, Alban wrote: >> >>> This is not a big problem but if a solution exists, this would be so >>> cool ! Especialy when we have to check existance of twenty or more key >>> in array. Code would

Re: [PHP-DEV] suggestion about ternary operator

Le Sat, 21 Nov 2009 09:48:10 +0100, Lukas Kahwe Smith a écrit : > On 21.11.2009, at 06:12, Alban wrote: > >> This is not a big problem but if a solution exists, this would be so >> cool ! Especialy when we have to check existance of twenty or more key >> in array. Code would be be lighter and cle

Re: [PHP-DEV] suggestion about ternary operator

On 21.11.2009, at 06:12, Alban wrote: > This is not a big problem but if a solution exists, this would be so > cool ! Especialy when we have to check existance of twenty or more key in > array. Code would be be lighter and clear. > Since i use PHP, I always have in my 'common function file' a f

Re: [PHP-DEV] suggestion about ternary operator

Le Fri, 20 Nov 2009 23:28:39 -0600, Larry Garfield a écrit : > On Friday 20 November 2009 11:12:29 pm Alban wrote: > >> This is not a big problem but if a solution exists, this would be so >> cool ! Especialy when we have to check existance of twenty or more key >> in array. Code would be be ligh

Re: [PHP-DEV] suggestion about ternary operator

On Friday 20 November 2009 11:12:29 pm Alban wrote: > This is not a big problem but if a solution exists, this would be so > cool ! Especialy when we have to check existance of twenty or more key in > array. Code would be be lighter and clear. I cannot comment on the rest of your post right now,

[PHP-DEV] suggestion about ternary operator

hi all, Since the new conditionnal operator ternary was introduced in php 5.3, I'm little confuse about it. The documentations says : Since PHP 5.3, it is possible to leave out the middle part of the ternary operator. Expression expr1 ?: expr3 returns expr1 if expr1 evaluates to TRUE, and ex

Re: [PHP-DEV] Suggestion on static field inheritance

Hello Robin, Thanks for your reply :-) The behaviour of "static fields are shared between subclasses" is exactly what I would like to question, since PHP is not a so called "static programming language" like C++, Java and C#. Currently PHP's object model is designed and implemented as class-based

Re: [PHP-DEV] Suggestion on static field inheritance

2009/5/16 Jingcheng Zhang : > > Maybe I have not found its detailed description on PHP's official manual, > but PHP does allow static field inheritance. However there is a little > difference between dynamic field inheritance and static field inheritance, > as the following codes shows: Hi! I thi

[PHP-DEV] Suggestion on static field inheritance

Hello all, Maybe I have not found its detailed description on PHP's official manual, but PHP does allow static field inheritance. However there is a little difference between dynamic field inheritance and static field inheritance, as the following codes shows: name = $name; } public $name

Re: [PHP-DEV] Suggestion to increase the max_input_nesting_level

Guilherme Blanco wrote: Hm... Actually at that time I was not able to reproduce the limit, and I wrote a fix that worked well and reduced the number of nest calls. Maybe the guy that notified me was using it. Here is the changeset I did to fix the issue: http://trac.phpdoctrine.org/changeset/43

Re: [PHP-DEV] Suggestion to increase the max_input_nesting_level

Derick, I do not have xdebug installed here. That's why I thought it was something that could be changed, since it's something too specific and afaik used only by xdebug. Regards, On Tue, Sep 9, 2008 at 3:19 AM, Derick Rethans <[EMAIL PROTECTED]> wrote: > On Mon, 8 Sep 2008, Guilherme Blanco wro

Re: [PHP-DEV] Suggestion to increase the max_input_nesting_level

Hm... Actually at that time I was not able to reproduce the limit, and I wrote a fix that worked well and reduced the number of nest calls. Maybe the guy that notified me was using it. Here is the changeset I did to fix the issue: http://trac.phpdoctrine.org/changeset/4397 But right now I'll hav

Re: [PHP-DEV] Suggestion to increase the max_input_nesting_level

There is no nesting limit, it recurses until it runs out of memory. Derick was saying that XDebug will add one, but other than that there isn't any. dev/php53/sapi/cli/php -r 'function m($m) { echo ++$m . " "; m($m); } m(0); ' I ran that and I got bored when it got to 750,000 levels deep. Scott

Re: [PHP-DEV] Suggestion to increase the max_input_nesting_level

On Mon, 8 Sep 2008, Guilherme Blanco wrote: > Yeah... recursion depth. > > Sorry, I wrongly typed it. > > I think it may be cleaner now... Well, PHP itself doesn't protect against this, but my guess is that you have Xdebug running. Xdebug limits to 100 levels by default in order to prevent in

Re: [PHP-DEV] Suggestion to increase the max_input_nesting_level

Yeah... recursion depth. Sorry, I wrongly typed it. I think it may be cleaner now... On Mon, Sep 8, 2008 at 11:07 PM, Stan Vassilev | FM <[EMAIL PROTECTED]> wrote: > > Hi, > > He means recursion depth, not input nesting depth. 5.3 had a proposed fast > function call algorithm which would avoid t

Re: [PHP-DEV] Suggestion to increase the max_input_nesting_level

Hi, He means recursion depth, not input nesting depth. 5.3 had a proposed fast function call algorithm which would avoid the stack limit and allow deeper recursion, was this accepted and how does it affect the limit of 100 nested calls? Regards, Stan Vassilev Hi! Currently I'm working o

Re: [PHP-DEV] Suggestion to increase the max_input_nesting_level

Each grammar rule may forward calls and subsequent things to build itself. So, ConditionalExpression may forward a call and later call itself again and again, etc. At last, the number of nested function calls can easily reach 100. If you need an example... I can spend some time on it to highlight

Re: [PHP-DEV] Suggestion to increase the max_input_nesting_level

Hi! Currently I'm working on the compiler, which has this BNF: http://trac.doctrine-project.org/browser/trunk/query-language.txt I've done a lot of optimizations to be able to not touch the default nesting input level, but doing that I added a lot of restrictions that now are my bottlenecks. I

[PHP-DEV] Suggestion to increase the max_input_nesting_level

Hi ML, Short version: Increase the default max_input_nesting_level from 100 to something > 150. Extended version: I am working on a Compiler written for PHP. Before you criticize me, let me explain the entire situation. I work for Doctrine project. Currently we're refactoring the DQL (Doctrine Q

[PHP-DEV] Suggestion for get_headers

Hi there, I have a suggestion regarding get_headers, however I do not have a knowledge of C with which to provide a patch. The function get_headers is, as most will know, used to retrieve headers generated by an HTTP request. The primary parameter to this, "string $url", is provided unencode

Re: [PHP-DEV] Suggestion: Namespace implementation

On Thursday 27 December 2007, Hans Moog wrote: > In my oppinion namespaces should only be an additional way of > structering php elements and using short names again without loosing the > abilitiy to avoid naming conflicts with 3rd party libraries. Since > libraries are generally class libraries a

[PHP-DEV] Suggestion: Namespace implementation

Within the last few days i read some of the posts concerning the new namespace implementation and it's alleged problems. And ... I really have to say, that I do not understand whats the problem with namespaces at all. Instead, I suppose that many lost sight of the original goal of namespaces. I

[PHP-DEV] Suggestion: Namespace implementation

Within the last few days i read some of the posts concerning the new namespace implementation and it's alleged problems. And ... I really have to say, that I do not understand whats the problem with namespaces at all. Instead, I suppose that many lost sight of the original goal of namespaces. I

RE: [PHP-DEV] Suggestion for fixing Bug #40928

ot the runs of the cmd.exe which does the escaping internally). Which is what I wanted in the first place (and I know it looks ugly...). Tzachi. -Original Message- From: Stanislav Malyshev [mailto:[EMAIL PROTECTED] Sent: ג 10 יולי 2007 23:51 To: Tzachi Tager Cc: internals@lists.php.net Subject: Re:

Re: [PHP-DEV] Suggestion for fixing Bug #40928

/en-us/ntcmds_shelloverview.mspx?mfr=true , quoting: "You can use most characters as variable values, including white space. If you use the special characters <, >, |, &, or ^, you must precede them with the escape character (^) or quotation marks." - So all special characters will be replaced wit

RE: [PHP-DEV] Suggestion for fixing Bug #40928

/* since Windows does not allow us to escape these chars, just remove them */ cmd[y++] = ' '; break; #endif + case '\\': cmd[y++] = '\\';

Re: [PHP-DEV] Suggestion for fixing Bug #40928

On Fri, Jul 06, 2007 at 01:29:31 +0300, Tzachi Tager wrote: > Hi, > I was looking at Bug #40928 - escapeshellarg() does not quote percent > (%) correctly for cmd.exe. > This bug seems to be because escapeshellarg() in Windows replaces '%' > and '"' with spaces, while assuming there isn't a real es

[PHP-DEV] Suggestion for fixing Bug #40928

Hi, I was looking at Bug #40928 - escapeshellarg() does not quote percent (%) correctly for cmd.exe. This bug seems to be because escapeshellarg() in Windows replaces '%' and '"' with spaces, while assuming there isn't a real escaping method for command line in Windows. Therefore I'm guessing no o

Re: [PHP-DEV] suggestion SplFileInfo

Hi Marcus, On 3/4/07, Marcus Boerger <[EMAIL PROTECTED]> wrote: Damn hell i am just sick of getting complaints without even understanding the matters. As you wrote you don't understand. So just stay calm. Damn it! I don'T see it as personal. It is just fucking stupid that you hook onto stuff y

Re: [PHP-DEV] suggestion SplFileInfo

On 3/4/07, Marcus Boerger <[EMAIL PROTECTED]> wrote: Hello Pierre, Sunday, March 4, 2007, 6:22:03 PM, you wrote: > To make this long story short, I do not understand the reason behind a > glob:// stream wrapper. It makes no sense. But yes, we need a better > glob support in PHP. Many extensions

RE: [PHP-DEV] suggestion SplFileInfo

Hello All, I am new to the php internals mailing list. I am a fairly experienced programmer with a few ideas floating around. I have come from a C++ games development background and have now moved to primarily writing in php. One thing that I used extensively in C++ was the singleton design pat

Re: [PHP-DEV] suggestion SplFileInfo

Hello Pierre, Sunday, March 4, 2007, 6:22:03 PM, you wrote: > To make this long story short, I do not understand the reason behind a > glob:// stream wrapper. It makes no sense. But yes, we need a better > glob support in PHP. Many extensions needs it. For example, I have my > own version for zip

Re: [PHP-DEV] suggestion SplFileInfo

To make this long story short, I do not understand the reason behind a glob:// stream wrapper. It makes no sense. But yes, we need a better glob support in PHP. Many extensions needs it. For example, I have my own version for zip, it is bad as the only difference is how I get the path string, the

Re: [PHP-DEV] suggestion SplFileInfo

Hello Pierre, Sunday, March 4, 2007, 3:29:06 PM, you wrote: >> > It may be more useful to add streams support to our glob functions. >> > But it can bring more troubles than expected. I did not elaborate on this really. So let me do that now. If we were going this way we would need to always over

Re: [PHP-DEV] suggestion SplFileInfo

On 3/4/07, Marcus Boerger <[EMAIL PROTECTED]> wrote: Sunday, March 4, 2007, 1:46:40 PM, you wrote: > On 3/3/07, Marcus Boerger <[EMAIL PROTECTED]> wrote: >> Hello Arnold, >> >> I added glob directory stream support. Now you can do two things: >> >> $d1 = new DirectoryIterator("glob://mydir/*")

Re: [PHP-DEV] suggestion SplFileInfo

Hello Pierre, Sunday, March 4, 2007, 1:46:40 PM, you wrote: > On 3/3/07, Marcus Boerger <[EMAIL PROTECTED]> wrote: >> Hello Arnold, >> >> I added glob directory stream support. Now you can do two things: >> >> $d1 = new DirectoryIterator("glob://mydir/*"); >> $d2 = new DirectoryIterator("mydir/

Re: [PHP-DEV] suggestion SplFileInfo

On 3/3/07, Marcus Boerger <[EMAIL PROTECTED]> wrote: Hello Arnold, I added glob directory stream support. Now you can do two things: $d1 = new DirectoryIterator("glob://mydir/*"); $d2 = new DirectoryIterator("mydir/*", DirectoryIterator::USE_GLOB); count() stuff will follow. I'm not sure i

Re: [PHP-DEV] suggestion SplFileInfo

Hello Arnold, I added glob directory stream support. Now you can do two things: $d1 = new DirectoryIterator("glob://mydir/*"); $d2 = new DirectoryIterator("mydir/*", DirectoryIterator::USE_GLOB); count() stuff will follow. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mai

Re: [PHP-DEV] suggestion SplFileInfo

Hello Arnold, a bunch of new stuff based on your suggestions will be added to 5.2.2. I also added more comments below. Tuesday, February 27, 2007, 1:36:21 AM, you wrote: > Thanks for your response. I've put some new comments below. >>> SplFileInfo: >>> - Add parameter $flags to constructor. T

[PHP-DEV] RE : [PHP-DEV] suggestion SplFileInfo

> From: Arnold Daniels [mailto:[EMAIL PROTECTED] > >> DirectoryIteratorRecursive: > >> - Add flag DIRS_ONLY for the constructor, to only loop through > >> directories > >> > > This is achieved by a FilterIterator: ParentIterator > > > Yes but if you want to loop recursively through the

Re: [PHP-DEV] suggestion SplFileInfo

Hi again, Thanks for your response. I've put some new comments below. Marcus Boerger wrote: Hello Arnold, some interesting ideas indeed. See my comments below. best regards marcus Monday, February 26, 2007, 8:48:32 PM, you wrote: Hi, I've got a few feature suggestions for S

Re: [PHP-DEV] suggestion SplFileInfo

Hello Arnold, some interesting ideas indeed. See my comments below. best regards marcus Monday, February 26, 2007, 8:48:32 PM, you wrote: > Hi, > I've got a few feature suggestions for SplFileInfo and > DirectoryIteratorRecursive. I'm creating yet another php file manager. > I've noticed t

[PHP-DEV] suggestion SplFileInfo

Hi, I've got a few feature suggestions for SplFileInfo and DirectoryIteratorRecursive. I'm creating yet another php file manager. I've noticed that I needed to add quite some code to make it act the way gnome nautilus does. I believe these feature would be a good addition. SplFileInfo: - Add

Re: [PHP-DEV] Suggestion: global variables being accessed in localscope

[Taking this back on-list, as it's my final answer.] On Wed, February 14, 2007 5:30 pm, Christian Schneider wrote: > Richard Lynch wrote: >> But the code that checks for E_NOTICE also has to be altered to check >> for E_STRICT... > > How many applications use error handlers. And how many of them r

Re: [PHP-DEV] Suggestion: global variables being accessed in localscope

On Thu, February 8, 2007 7:43 pm, Christian Schneider wrote: > Guilherme Blanco wrote: >> Brian,I am sorry about the message indentation... Seems >> PHP-Internals >> list does not like M$ Live(r) Mail! > > Please use plain text mail as your messages are a PITA to read, > thanks. Or very easy to re

Re: [PHP-DEV] Suggestion: global variables being accessed in localscope

On Fri, 9 Feb 2007, Guilherme Blanco wrote: > Christian Schneider wrote: > > Please use plain text mail as your messages are a PITA to read, thanks. > > I changed the email to send/recieve messages. Hotmail simply doesn't > accept plain text. hotmail also fucks up threading :I regards, Derick

Re: [PHP-DEV] Suggestion: global variables being accessed in localscope

Christian Schneider wrote: Please use plain text mail as your messages are a PITA to read, thanks. I changed the email to send/recieve messages. Hotmail simply doesn't accept plain text. You didn't grasp two of the major PHP features (not bugs!): 1. Every variable you access inside a functio

  1   2   >