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

[Athos Ribeiro]

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?

https://github.com/php/php-src/pull/575


Kind regards,
 Stefan




Just to make it clear:
To make it into 5.6.0 the RFC should have been voted and accepted, and the
patch finished and merged before the release of the first beta.
None of that happened in time, so now there is no chance to be in 5.6.0.


Hi,

sorry for reviving this old thread.

Is there still interest in pushing the related RFC [1] forward?

This thead started few years ago at [2] and has not seen much activity
since the proposed change [3] stalled due to issues with test failures.

I also found a couple old bugs [4,5] which also requested adding the
related feature but they also have not seen any activity since then.

I have a first implementation of the feature at [6], but it does have a
few points which would need discussion (most likely should go in the
RFC). Namely,

- the new suffix arg mimics the prefix arg when path separators are
  present in the string (goes through basename, using only the last part
  of the provided path);

- the suffix gets truncated if its length is longer than 64 characters
  (also matching the prefix behavior); and

- the current proposed patch does not include a windows implementation.

I could not find the historical reasons behind the prefix behavior
described in the first two points. Then, I was unsure if they should be
kept for the suffix. I then took a conservative approach and kept them
just to match the prefix arg behavior here.

As for not including windows support, the reason lies in the underlying
function (and API) used to generate temporary files, which do not
provide means to set a suffix and also include a .TMP extension to the
files, which AFAICT, does matter in windows systems. I also found a
related discussion in an old bug at [7].

I am Ccing the original author here to make sure they get this message
so I can understand if they are willing to move forward with the RFC or
if I should file a new one (as per the first note in [8]).

Finally, as per past discussions on this thread, I understand it is too
late to include this change in 8.3, and given the api change, this
should be deferred to 8.4 in case an RFC is accepted.

[1] https://wiki.php.net/rfc/tempnam-suffix
[2] https://marc.info/?l=php-internals=138946779304541
[3] https://github.com/php/php-src/pull/575
[4] https://bugs.php.net/bug.php?id=37613
[5] https://bugs.php.net/bug.php?id=43898
[6] https://github.com/php/php-src/pull/11685
[7] https://bugs.php.net/bug.php?id=44222
[8] https://wiki.php.net/rfc/howto

--
Athos Ribeiro

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Côme Chilliet]

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.

This means using array_merge semantic, as ['a' => 1, 'a' => 2] evaluates to
['a' => 2].

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Christian Schneider]

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...@example.org', ...$template],
> ];

You can already easily enough do this with
$db_rows = [
['name' => 'Alice', 'email' => 'al...@example.org'] + $template,
['name' => 'Bob', 'email' => 'b...@example.org']+ $template,
];
so I'm not sure if it is really needed.
But then again I'm used to the +-operator for associative arrays and wouldn't 
expect to be able to use the spread operator instead. Someone learning PHP now 
might see things differently.

Side-note:
For the ...$template syntax I would assume that later values win (like ['foo' 
=> "bar", 'foo' => "qux"] will result in ['foo' => "qux"]) so the exact 
equivalent for your example would probably be
$template + ['name' => 'Alice', 'email' => 'al...@example.org'],
but in reality one often wants to be able to override template values, that's 
why I wrote [ ... ] + $template and your example would be
[...$template, 'name' => 'Alice', 'email' => 'al...@example.org'],

- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Josh Bruce]

> 
> 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 array_merge()
> semantics. But due to contention was left out.
> 
> Best regards,
> 
> George P. Banyard

Does the loose interpretation of an array also play into this??

[“string” => true, 10 => false]

Another new-to-internals questions, does the check only look at if the keys 
contain one that is a string, that they’re all integers (not float), that 
they’re all sequential??

Cheers,
Josh
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Chuck Adams]

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 the only one that makes sense.  Addition of positional
arrays is nonsensical:
[1,2,3] + [4,5,6]  ===> [1,2,3]

As for named keys, every other language with a similar construct
(perl, python, javascript) uses array_merge semantics.  Truth is I'm
sorely disappointed that + works like it does, but there's no fixing
it now.

--c

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[G. P. B.]

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($a, $b) {
>   return $a + $b;
> }
> $test = [1, 2];
> php56(...$test) === 3;
>
> Then, with PHP 7.4, the spread operator was also introduced for array
> literal syntax:
>
> $parts = ['apple', 'banana'];
> $fruits = ['strawberry', ...$parts, 'grape'];
> $fruits == ['strawberry', 'apple', 'banana', 'grape'];
>
> The RFC back then explicitly excluded [1] string keys, to make the
> functioning of the spread operator consistent with how it's used for
> function arguments.
>
> Now, in PHP8 we can do:
>
> function php8(int $a, int $b): int {
>   return $a + $b;
> }
> $test = ['b' => 40, 'a' => 2];
> php8(...$test) === 42;
>
> However, string keys in array literals are still not possible. So the
> limitation that once was introduced for consistency now led to an
> inconsistency.
>
> 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...@example.org', ...$template],
> ];
>
> What's your feedback on that? Do you see any obvious problems with that
> approach? I searched through the archives and couldn't find this problem
> being mentioned before.
>
> -Florian
>
> [1]: https://wiki.php.net/rfc/spread_operator_for_array#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 array_merge()
semantics. But due to contention was left out.

Best regards,

George P. Banyard

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

[Florian Stascheck]

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;

Then, with PHP 7.4, the spread operator was also introduced for array
literal syntax:

$parts = ['apple', 'banana'];
$fruits = ['strawberry', ...$parts, 'grape'];
$fruits == ['strawberry', 'apple', 'banana', 'grape'];

The RFC back then explicitly excluded [1] string keys, to make the
functioning of the spread operator consistent with how it's used for
function arguments.

Now, in PHP8 we can do:

function php8(int $a, int $b): int {
  return $a + $b;
}
$test = ['b' => 40, 'a' => 2];
php8(...$test) === 42;

However, string keys in array literals are still not possible. So the
limitation that once was introduced for consistency now led to an
inconsistency.

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...@example.org', ...$template],
];

What's your feedback on that? Do you see any obvious problems with that
approach? I searched through the archives and couldn't find this problem
being mentioned before.

-Florian

[1]: https://wiki.php.net/rfc/spread_operator_for_array#string_keys

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

[Claude Pache]

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 
) when I need to split my 
string between “characters” (which means for me “grapheme clusters”, not “code 
points”, so that mb_string functions are useless for me). In particular, 
PREG_OFFSET_CAPTURE does always what I need, even when using the /u flag.

If this is a feature that you want to implement, I suggests adding a flag 
PREG_UTF8_CODEPOINT_OFFSET_CAPTURE.

—Claude

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

[Thomas Landauer]

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 for?
My answer: For *splitting the string* - in some way or the other. Now,
with byte offsets, I can't do such basic things as just `+1` to get to
the next character. Or extract exactly 3 characters.

2: Better performance:
This may sound odd, since cmb said the exact opposite ;-) (sequential
access vs. random access). However, if I need character offsets (see 1),
what can I do? I'm forced to use some workaround on top - as e.g.
https://www.php.net/manual/en/function.preg-match-all.php#71572 - which
is certainly way slower than any native implementation.

3: Consistency with users' expectations:
The current behavior is causing confusion and is perceived as
counter-intuitive, see
https://www.php.net/manual/en/function.preg-match-all.php#61426 and
https://stackoverflow.com/questions/1725227/preg-match-and-utf-8-in-php

So I'm suggesting:

* Either do the BC break, and just return byte offsets if the modifier
`u` is given.
* Or create *new* functions for it: `mb_preg_match_all()` etc.

--

Cheers,
Thomas

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Suggestion Method Constant

[Mark Randall]

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 around function calls.


IMHO directly referencing MyClass::StaticFunction eventually needs to 
return a "Function" class that is directly invokable.


I see 3 contexts that the parser would need to handle:


1. Standard Calling

MyClass::StaticFunction(1, 2, 3);
my_function(1, 2, 3)
$inst->my_function(1234);

Obviously returning a full function object to useland for every call 
would be considered wasteful, so the parser would need to call these as 
before.




2. Returning a native "Function" class, an __invokeable hybrid of 
Callable and Reflection;


$method = MyClass::StaticFunction;
$method(1, 2, 3);

$method = $inst->my_function; /* bind to $inst */
$method(1, 2, 3);

$method->getName();
$method->getArgumentCount();
$method->getBinding();




3. Returning closures when the argument list includes one or more 
late-bound values, so we can finally put the pipe operator to bed at the 
same time as getting a bunch of other power from it.


$method = MyClass::StaticFunction($1, 'Arg 1', 'Arg 3);
$method('Arg 1');

$method = $inst->my_function('Arg 1', 'Arg 2', $1);
$method('Arg 3');

chain(
  'Random String',
  func_1($1, 'Hello', 'World'),
  func_2($1, 'Peace', 'Out'),
  func_3('ThisOneNeeds', 'Arg3ReplacingInstead', $1),
  func_3($1, $1, 'HowAboutOneWhichUsesTheSameArgumentTwice')
);

function chain($start, ... $fns) {
   foreach ($fns as $fncall) {
 $start = $fncall($start);
   }

   return $start;
}


--
Mark Randall




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Suggestion Method Constant

[Mark Randall]

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::StaticFunction eventually needs to 
return a "Function" class that is directly invokable.


I see 3 contexts that the parser would need to handle:



1. Standard Calling

MyClass::StaticFunction(1, 2, 3);
my_function(1, 2, 3)
$inst->my_function(1234);

Obviously returning a full function object to useland for every call 
would be considered wasteful, so the parser would need to call these as 
before.




2. Returning a native "Function" class, an __invokeable hybrid of 
Callable and Reflection;


$method = MyClass::StaticFunction;
$method(1, 2, 3);

$method = $inst->my_function; /* bind to $inst */
$method(1, 2, 3);

$method->getName();
$method->getArgumentCount();
$method->getBinding();




3. Returning closures when the argument list includes one or more 
late-bound values, so we can finally put the pipe operator to bed at the 
same time as getting a bunch of other power from it.


$method = MyClass::StaticFunction($1, 'Arg 1', 'Arg 3);
$method('Arg 1');

$method = $inst->my_function('Arg 1', 'Arg 2', $1);
$method('Arg 3');

chain(
  'Random String',
  func_1($1, 'Hello', 'World'),
  func_2($1, 'Peace', 'Out'),
  func_3('ThisOneNeeds', 'Arg3ReplacingInstead', $1),
  func_3($1, $1, 'HowAboutOneWhichUsesTheSameArgumentTwice')
);

function chain($start, ... $fns) {
   foreach ($fns as $fncall) {
 $start = $fncall($start);
   }

   return $start;
}


--
Mark Randall



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Suggestion Method Constant

[Niklas Keller]

>
> 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

[Mathias Grimm]

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 method references?
> >
> Given the discussion we had around the namespace separator (and why we
> DIDN'T go with ::), there may be similar issues here.  Maybe not,
> given the final component is specifically T_METHOD, but it should be
> prototyped to be sure.
>
> As to what such a reference would evaluate to:   Foo::bar::method -> [
> Foo::class, 'bar' ] as Michael Döhler suggests seems the obvious
> answer, but (Foo::class.'::bar') may be what some would expect.
> Ideally we'd have first-class references to functions.
>
> -Sara
>

Re: [PHP-DEV] Suggestion Method Constant

[Sara Golemon]

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.  Maybe not,
given the final component is specifically T_METHOD, but it should be
prototyped to be sure.

As to what such a reference would evaluate to:   Foo::bar::method -> [
Foo::class, 'bar' ] as Michael Döhler suggests seems the obvious
answer, but (Foo::class.'::bar') may be what some would expect.
Ideally we'd have first-class references to functions.

-Sara

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Suggestion Method Constant

[Michael Döhler]

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 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, 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, IDE usage and completes the code 
>> as configuration approach for PHP.
>> 
>> Thanks
>> Michael
>> 
>> > Am 12.10.2017 um 19:43 schrieb Mathias Grimm :
>> >
>> > 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.
>> >
>> > Cheers,
> 

Re: [PHP-DEV] Suggestion Method Constant

[Michael Döhler]

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, IDE usage and completes the code as 
configuration approach for PHP.

Thanks
Michael

> Am 12.10.2017 um 19:43 schrieb Mathias Grimm :
> 
> 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.
> 
> Cheers,

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Suggestion Method Constant

[Mathias Grimm]

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, 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, IDE usage and completes the
> code as configuration approach for PHP.
>
> Thanks
> Michael
>
> > Am 12.10.2017 um 19:43 schrieb Mathias Grimm :
> >
> > 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.
> >
> > Cheers,
>

[PHP-DEV] Suggestion Method Constant

[Mathias Grimm]

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.

Cheers,

Re: [PHP-DEV] Suggestion

[Rowan Collins]

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 abomination are you working on?


I think this conversation is going nowhere. We can equally ask 
hypothetical questions the other way:


- Why do you find the word "function" so hard to type? Are you in a 
super-hurry?
- Why are your function declarations so long that you need to save 8 
characters? What kind of abomination are you working on?


etc
etc

There really isn't that much to say either way: some people like having 
the keyword introduce each declaration, some people don't. Can we just 
agree that it's a matter of style?


If we were designing a new language, we could vote on what consistent 
style we wanted to create. With 20 years of existing language history, 
there's always going to be a bias towards keeping things as they are.


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Suggestion

[Marco Pivetta]

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.
>
> It may be time to consider simplifying things.
>
>
> Perhaps, but I would typically be doing something like this when I’ve
> opened a PHP file in a basic text editor and am trying to find where a
> function is declared rather than used. The tokenizer is of no help in this
> use-case. Plus, I happen to like having a consistent item to lock onto
> visually — always hated missing that in languages that don’t have it. (For
> the same reason, I much prefer the function’s return type at the end rather
> than at the beginning of the line.)
>
> --
> Bob Williams
>


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 abomination are you working on?

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] Suggestion

[Robert Williams]

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, but I would typically be doing something like this when I’ve opened a 
PHP file in a basic text editor and am trying to find where a function is 
declared rather than used. The tokenizer is of no help in this use-case. Plus, 
I happen to like having a consistent item to lock onto visually — always hated 
missing that in languages that don’t have it. (For the same reason, I much 
prefer the function’s return type at the end rather than at the beginning of 
the line.)

--
Bob Williams


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] Suggestion

[Yasuo Ohgaki]

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, languages that keep options of doing the same thing low.

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.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Suggestion

[Arvids Godjuks]

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, 29 Aug 2016, 16:16 Mathias Grimm,  wrote:

> 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 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 on internals 2 years ago, back when PHP7 was being
> > designed:
> > http://marc.info/?t=14123534493=1=2
> >
> >
> >
> > --
> > regards,
> >
> > Kalle Sommer Nielsen
> > ka...@php.net
> >
>

Re: [PHP-DEV] Suggestion

[Mathias Grimm]

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 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 on internals 2 years ago, back when PHP7 was being
> designed:
> http://marc.info/?t=14123534493=1=2
>
>
>
> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net
>

Re: [PHP-DEV] Suggestion

[Kalle Sommer Nielsen]

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 on internals 2 years ago, back when PHP7 was being designed:
http://marc.info/?t=14123534493=1=2



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Suggestion

[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.

Cheers,
Mathias Grimm

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

[Daniel Persson]

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 POST
so we get populated globals with data we could later filter and use.

Most of the frameworks work around this limitation in the core so I thought
it might be in place to suggest we allow these request methods.

On Mon, Sep 14, 2015 at 11:38 PM, Ryan Pallas  wrote:

>
>
> 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/pull/1519
>>
>> Summary:
>>
>> Added support for request methods with the smallest change possible.
>> History:
>>
>> HTTP 1.0 had only support for GET, POST and HEAD.
>> In June of 1999 HTTP 1.1 added the verbs PUT and DELETE and later in 2010
>> RFC5789 (https://tools.ietf.org/html/rfc5789) added PATCH.
>> Pull request explaination:
>>
>> In this pull request I try to add put, patch and delete with changing as
>> few functions as possible. I simply handle the new verbs as POST. As
>> defined in HTTP 1.1 they are similar in input data requirements and differ
>> only in usage.
>>
>
> +1 from me, would love to see the verbs supported more fully. (though my
> approval means quite literally nothing). How does this affect something
> like the ini settings for variable order? IE. does GPC change from GET ->
> POST -> COOKIE to GET -> PARSED_INPUT -> COOKIE? Since only a single verb
> is available for any single request, this makes the most sense for me.
>
>
>>
>> More work I could do is add new globals for $_PUT, $_PATCH and $_DELETE
>> but
>> I think this might be more confusing. Or we could move from $_POST to a
>> new
>> global not tied to a verb. Example $_PARSED_INPUT
>
>
> As for having a new $_PARSED_INPUT, I'm not sure I like this for 2 reasons
> a) the name is 2 words, all other super globals are single words (unless
> there's one I do not know of) and b) It feels like too long a name, sure in
> an IDE it will auto-complete for us, but for quick edits in vim for
> example, this name would suck. But my only problem with it is on a name
> level, about about just $_INPUT or does this seem to conflict with
> $_REQUEST which holds multiple super globals worth of data already.
>

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

[S.A.N]

+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

[Ryan Pallas]

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/pull/1519
>
> Summary:
>
> Added support for request methods with the smallest change possible.
> History:
>
> HTTP 1.0 had only support for GET, POST and HEAD.
> In June of 1999 HTTP 1.1 added the verbs PUT and DELETE and later in 2010
> RFC5789 (https://tools.ietf.org/html/rfc5789) added PATCH.
> Pull request explaination:
>
> In this pull request I try to add put, patch and delete with changing as
> few functions as possible. I simply handle the new verbs as POST. As
> defined in HTTP 1.1 they are similar in input data requirements and differ
> only in usage.
>

+1 from me, would love to see the verbs supported more fully. (though my
approval means quite literally nothing). How does this affect something
like the ini settings for variable order? IE. does GPC change from GET ->
POST -> COOKIE to GET -> PARSED_INPUT -> COOKIE? Since only a single verb
is available for any single request, this makes the most sense for me.


>
> More work I could do is add new globals for $_PUT, $_PATCH and $_DELETE but
> I think this might be more confusing. Or we could move from $_POST to a new
> global not tied to a verb. Example $_PARSED_INPUT


As for having a new $_PARSED_INPUT, I'm not sure I like this for 2 reasons
a) the name is 2 words, all other super globals are single words (unless
there's one I do not know of) and b) It feels like too long a name, sure in
an IDE it will auto-complete for us, but for quick edits in vim for
example, this name would suck. But my only problem with it is on a name
level, about about just $_INPUT or does this seem to conflict with
$_REQUEST which holds multiple super globals worth of data already.

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

[Daniel Persson]

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 change possible.
History:

HTTP 1.0 had only support for GET, POST and HEAD.
In June of 1999 HTTP 1.1 added the verbs PUT and DELETE and later in 2010
RFC5789 (https://tools.ietf.org/html/rfc5789) added PATCH.
Pull request explaination:

In this pull request I try to add put, patch and delete with changing as
few functions as possible. I simply handle the new verbs as POST. As
defined in HTTP 1.1 they are similar in input data requirements and differ
only in usage.

More work I could do is add new globals for $_PUT, $_PATCH and $_DELETE but
I think this might be more confusing. Or we could move from $_POST to a new
global not tied to a verb. Example $_PARSED_INPUT

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

[Harrison Yuan]

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 like an
unrefined edge in the PHP syntax because in this case $tmp is a
completely throwaway variable.

While coding I had always wished PHP could have echo
function(var)[0] and would like to help make this possible. Are there
any good reasons currently why the RFCs for this aren't getting
accepted?

- Harrison

On Sat, Jun 5, 2010 at 6:47 PM, Harrison Yuan newrevoluti...@gmail.com wrote:

 I don't understand what is holding PHP back from having this syntax.

 Tig said:
 ?
  $tmp = getimagesize('./path/to/image');
  echo $tmp[1];
 ?

 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 syntax  
 semantics rules?

 I am new here but would be interested in helping with a patch (+ hopefully 
 another RFC) for this. What exactly are the specific arguments against array 
 dereferencing?

 - Harrison

 On Fri, Jun 4, 2010 at 4:19 PM, mathieu.suen mathieu.s...@easyflirt.com 
 wrote:

 On 06/04/2010 10:00 AM, Richard Quadling wrote:

 On 4 June 2010 08:18, mathieu.suenmathieu.s...@easyflirt.com  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-method();
 ValueNode::sMethod();
 ValueNode[];
 foo(ValueNode);
 echo ValueNode;
 $e = ValueNode;
 ...

 And a ValueNode could be define as:

 ValueNode :

      NewStatement
    | FunctionCall
    | PrimitiveValue
    | '(' ValueNode ')'
    | ...;

 This would allow all this syntax:

 (new A())-foo();
 foo(new A());
 foo-bar()[1];
 foo()[5];

 and many others.


 On 06/04/2010 03:19 AM, Kalle Sommer Nielsen wrote:


 Hi Tig

 2010/6/4 Tigtigger...@gmail.com:



 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/functionarraydereferencing
 [2] http://wiki.php.net/summits/pdmnotesmay09#php_6 (see point #13)




 --Mathieu Suen






 Not an expert in this area, but does this mechanism limit you to using
 single dimensional arrays?



 Of course not as soon as you add array access to a ValueNode

 ValueNode

    ..
    | ArrayAccess
    ...;

 This is very simple and it can refactor greatly the parser.

 -- Mathieu Suen





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Felipe Pena]

Hi all,

2010/6/5 Felipe Pena felipe...@gmail.com

 Hi!

 2010/6/4 Stas Malyshev smalys...@sugarcrm.com

 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 careful with refcounts
 so that the returned result could be freed properly and without hurting the
 referred element.


 I wrote a patch, but I cannot test all cases, so I'm not sure if is okay at
 all.

 What about this approach: http://felipe.ath.cx/diff/array_dereference.diff?


I've updated the patch, now it works with method call as well.

Example:
?php

class foo {
public $x = 10;

public function bar() {
$x = array();
$x[] = 3;
$x[] = array(1, 5);
$x[] = new foo;
return $x;
}
}

$foo = new foo;
var_dump($foo-bar()[2]-bar()[0]); // 3
var_dump($foo-bar()[2]-bar()[1]); // array(0 = 1, 1 = 5)
var_dump($foo-bar()[2]-bar()[1][1]); // 5
var_dump($foo-bar()[2]-bar()[2]-x); // 10

function test($arr) {
$x = $arr;
return $x;
}

$array = array(1, new foo);
var_dump(test($array)[0]); // 1
var_dump(test($array)[1]-bar()[0]); // 3
var_dump(test($array)[1]-bar()[2]); // object(foo)


http://felipe.ath.cx/diff/array_dereference.diff


Thanks.

-- 
Regards,
Felipe Pena

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

[Harrison Yuan]

I don't understand what is holding PHP back from having this syntax.

Tig said:
?
 $tmp = getimagesize('./path/to/image');
 echo $tmp[1];
?

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 syntax 
semantics rules?

I am new here but would be interested in helping with a patch (+ hopefully
another RFC) for this. What exactly are the specific arguments against array
dereferencing?

- Harrison

On Fri, Jun 4, 2010 at 4:19 PM, mathieu.suen mathieu.s...@easyflirt.comwrote:

 On 06/04/2010 10:00 AM, Richard Quadling wrote:

 On 4 June 2010 08:18, mathieu.suenmathieu.s...@easyflirt.com  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-method();
 ValueNode::sMethod();
 ValueNode[];
 foo(ValueNode);
 echo ValueNode;
 $e = ValueNode;
 ...

 And a ValueNode could be define as:

 ValueNode :

  NewStatement
| FunctionCall
| PrimitiveValue
| '(' ValueNode ')'
| ...;

 This would allow all this syntax:

 (new A())-foo();
 foo(new A());
 foo-bar()[1];
 foo()[5];

 and many others.


 On 06/04/2010 03:19 AM, Kalle Sommer Nielsen wrote:


 Hi Tig

 2010/6/4 Tigtigger...@gmail.com:



 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/functionarraydereferencing
 [2] http://wiki.php.net/summits/pdmnotesmay09#php_6 (see point #13)





 --Mathieu Suen






 Not an expert in this area, but does this mechanism limit you to using
 single dimensional arrays?




 Of course not as soon as you add array access to a ValueNode

 ValueNode

..
| ArrayAccess
...;

 This is very simple and it can refactor greatly the parser.

 -- Mathieu Suen

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

[Felipe Pena]

Hi!

2010/6/4 Stas Malyshev smalys...@sugarcrm.com

 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 careful with refcounts
 so that the returned result could be freed properly and without hurting the
 referred element.


I wrote a patch, but I cannot test all cases, so I'm not sure if is okay at
all.

What about this approach: http://felipe.ath.cx/diff/array_dereference.diff ?

-- 
Regards,
Felipe Pena

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

[mathieu.suen]

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);
echo ValueNode;
$e = ValueNode;
...

And a ValueNode could be define as:

ValueNode :

  NewStatement
| FunctionCall
| PrimitiveValue
| '(' ValueNode ')'
| ...;

This would allow all this syntax:

(new A())-foo();
foo(new A());
foo-bar()[1];
foo()[5];

and many others.


On 06/04/2010 03:19 AM, Kalle Sommer Nielsen wrote:

Hi Tig

2010/6/4 Tigtigger...@gmail.com:
   

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/functionarraydereferencing
[2] http://wiki.php.net/summits/pdmnotesmay09#php_6 (see point #13)

   



--Mathieu Suen

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

[Richard Quadling]

On 4 June 2010 08:18, mathieu.suen mathieu.s...@easyflirt.com 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-method();
 ValueNode::sMethod();
 ValueNode[];
 foo(ValueNode);
 echo ValueNode;
 $e = ValueNode;
 ...

 And a ValueNode could be define as:

 ValueNode :

      NewStatement
    | FunctionCall
    | PrimitiveValue
    | '(' ValueNode ')'
    | ...;

 This would allow all this syntax:

 (new A())-foo();
 foo(new A());
 foo-bar()[1];
 foo()[5];

 and many others.


 On 06/04/2010 03:19 AM, Kalle Sommer Nielsen wrote:

 Hi Tig

 2010/6/4 Tigtigger...@gmail.com:


 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/functionarraydereferencing
 [2] http://wiki.php.net/summits/pdmnotesmay09#php_6 (see point #13)




 --Mathieu Suen





Not an expert in this area, but does this mechanism limit you to using
single dimensional arrays?

-- 
-
Richard Quadling
Standing on the shoulders of some very clever giants!
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[mathieu.suen]

On 06/04/2010 10:00 AM, Richard Quadling wrote:

On 4 June 2010 08:18, mathieu.suenmathieu.s...@easyflirt.com  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-method();
ValueNode::sMethod();
ValueNode[];
foo(ValueNode);
echo ValueNode;
$e = ValueNode;
...

And a ValueNode could be define as:

ValueNode :

  NewStatement
| FunctionCall
| PrimitiveValue
| '(' ValueNode ')'
| ...;

This would allow all this syntax:

(new A())-foo();
foo(new A());
foo-bar()[1];
foo()[5];

and many others.


On 06/04/2010 03:19 AM, Kalle Sommer Nielsen wrote:
 

Hi Tig

2010/6/4 Tigtigger...@gmail.com:

   

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/functionarraydereferencing
[2] http://wiki.php.net/summits/pdmnotesmay09#php_6 (see point #13)


   


--Mathieu Suen




 

Not an expert in this area, but does this mechanism limit you to using
single dimensional arrays?

   


Of course not as soon as you add array access to a ValueNode

ValueNode

..
| ArrayAccess
...;

This is very simple and it can refactor greatly the parser.

-- Mathieu Suen

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

[Tig]

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/to/image')[1];
?

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:

?
 $tmp = getimagesize('./path/to/image');
 echo $tmp[1];
?

Anyway, just an idea.

-Tig

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Kalle Sommer Nielsen]

Hi Tig

2010/6/4 Tig tigger...@gmail.com:
 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/functionarraydereferencing
[2] http://wiki.php.net/summits/pdmnotesmay09#php_6 (see point #13)

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Tig]

On Fri, Jun 4, 2010 at 11:19 AM, Kalle Sommer Nielsen ka...@php.net wrote:
 Hi Tig

 2010/6/4 Tig tigger...@gmail.com:
 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/functionarraydereferencing
 [2] http://wiki.php.net/summits/pdmnotesmay09#php_6 (see point #13)


Thanks Kalle, I had no idea what it would be called, so I had a hard
time searching for it :]

I noticed that it has been 'declined'  - Date: May 01, 2009
(declined), http://wiki.php.net/rfc/functionarraydereferencing

but, as pointed out at point 13 on
http://wiki.php.net/summits/pdmnotesmay09#php_6

function call chaining (f()() if f() returns function), and array
dereferencing (f()[0]) - (Stas)

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.

Again, thanks.

-Tig

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Jonathan Wage]

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 tigger...@gmail.com wrote:

 On Fri, Jun 4, 2010 at 11:19 AM, Kalle Sommer Nielsen ka...@php.net
 wrote:
  Hi Tig
 
  2010/6/4 Tig tigger...@gmail.com:
  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/functionarraydereferencing
  [2] http://wiki.php.net/summits/pdmnotesmay09#php_6 (see point #13)
 

 Thanks Kalle, I had no idea what it would be called, so I had a hard
 time searching for it :]

 I noticed that it has been 'declined'  - Date: May 01, 2009
 (declined), http://wiki.php.net/rfc/functionarraydereferencing

 but, as pointed out at point 13 on
 http://wiki.php.net/summits/pdmnotesmay09#php_6

 function call chaining (f()() if f() returns function), and array
 dereferencing (f()[0]) - (Stas)

 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.

 Again, thanks.

 -Tig

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php




-- 
Jonathan H. Wage (+1 415 992 5468)
Open Source Software Developer  Evangelist
sensiolabs.com | jwage.com | doctrine-project.org | symfony-project.org

You should follow me on Twitter: http://www.twitter.com/jwage

You can contact Jonathan about Doctrine, Symfony and Open-Source or for
training, consulting, application development, or business related questions
at jonathan.w...@sensio.com

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

[Jonathan Wage]

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 tigger...@gmail.com 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/to/image')[1];
 ?

 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:

 ?
  $tmp = getimagesize('./path/to/image');
  echo $tmp[1];
 ?

 Anyway, just an idea.

 -Tig

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php




-- 
Jonathan H. Wage (+1 415 992 5468)
Open Source Software Developer  Evangelist
sensiolabs.com | jwage.com | doctrine-project.org | symfony-project.org

You should follow me on Twitter: http://www.twitter.com/jwage

You can contact Jonathan about Doctrine, Symfony and Open-Source or for
training, consulting, application development, or business related questions
at jonathan.w...@sensio.com

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

[Kalle Sommer Nielsen]

2010/6/4 Tig tigger...@gmail.com:
 On Fri, Jun 4, 2010 at 11:19 AM, Kalle Sommer Nielsen ka...@php.net 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 the
mailing lists, its always been declined (hence why its not in the core
by now). For the PDT I belive it was decided to add both array
dereferencing and call chaining.

I have CC'd stas, perhaps he can give some light on this subject


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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 not be too hard to do, one just has to be careful with 
refcounts so that the returned result could be freed properly and 
without hurting the referred element.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] suggestion about ternary operator

[Lukas Kahwe Smith]

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 return the first where empty evaluates as
 false.
 
 Like empty, filled would not throw notices for undefined variables.
 This is not the same as the ifsetor debate because filled is opposite
 empty and cares not about isset.
 did you even read the RFC?
 
 Yes I did, and all I see is this in the References section:
 
  Suggestion to leave an empty() variant out of the picture since
   this  feature can be implemented in userland, though this of
   course not provide the full functionality of empty() which
   does not trigger notices for missing variables
 
 I didn't see my proposal listed in it anywhere.  See this recommendation  
 from 3 1/2 years ago:
 
  - May 03, 2006
http://www.mail-archive.com/internals@lists.php.net/msg21617.html


Maybe I am then misunderstanding your proposal, as to me it is clearly covered 
and deemed not possible:
http://wiki.php.net/rfc/ifsetor#rejected_features

$var = ifsetor($var, $var2, admin);
However this is currently not possible to be implemented without major 
slowdowns to the engine.

regards,
Lukas Kahwe Smith
m...@pooteeweet.org




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] suggestion about ternary operator

[Lukas Kahwe Smith]

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 function 
 like that :
 
 function getIssetVar($var, $default) { return ((isset($var)) ? $var : 
 $default); }
 
 So is it possible to make a little improvement on this operator or 
 introduce a new operator or a core function which do that ? What's your 
 feeling about it ?


this feature request has already been discussed and declined:
http://wiki.php.net/rfc/ifsetor

please review this rfc before continuing this thread.

regards,
Lukas Kahwe Smith
m...@pooteeweet.org




-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] suggestion about ternary operator

[Alban]

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 clear. Since i use PHP, I always
 have in my 'common function file' a function like that :
 
 function getIssetVar($var, $default) { return ((isset($var)) ? $var :
 $default); }
 
 So is it possible to make a little improvement on this operator or
 introduce a new operator or a core function which do that ? What's your
 feeling about it ?
 
 
 this feature request has already been discussed and declined:
 http://wiki.php.net/rfc/ifsetor
 
 please review this rfc before continuing this thread.
 
 regards,
 Lukas Kahwe Smith
 m...@pooteeweet.org

Thanks for the link to the RFC :)

Excuse me, but I'll be little hard in this post. This for insult the 
community but I want the community really think about the decision it 
made and the reason why.  

I also read why it have been refused here : 
http://www.php.net/~derick/meeting-notes.html#ifsetor-as-replacement-for-
foo-isset-foo-foo-something-else

Is it serious ? 

«
The name for this new operator is heavily disputed and we could not agree 
on a decent name for it.
»

Tomorrow I will not send food to the association for children who are 
hungry because I can not choose between offering Thai or basmati rice.

Stop sarcasm, seriously, this is not an honorable response from people 
making decisions. Take your responsibility and make a vote or impose a 
name, just do it. 

« 
  Instead of implementing ifsetor() we remove the 
  requirement for the middle parameter to the ?: operator. 
»

That's not people wants and that's not do their need.
So that not a correct answer of the php developper demand.

« 
  In combination with the new input_filter extension 
  you then reach the original goal of setting a default 
  value to a non-set input variable with:

  $blahblah = input_filter_get(GET, 'foo', FL_INT) ?: 42;
»

I don't see how do that with the actual filter extension. Even if it is 
possible, this is not a pretty short and easier solution than :

$var = (isset($var)) ? $var : 'default';

Why not add a simple new operator who do the job, this is not needing a 
name :

// set a default value if $var is not set
$var ?= 'default';

// equalivalent to :
$var = (isset($var)) ? $var : 'default';


-- 
Alban Leroux s...@paradoxal.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] suggestion about ternary operator

[Rasmus Lerdorf]

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 be be lighter and clear. Since i use PHP, I always
 have in my 'common function file' a function like that :

 function getIssetVar($var, $default) { return ((isset($var)) ? $var :
 $default); }

 So is it possible to make a little improvement on this operator or
 introduce a new operator or a core function which do that ? What's your
 feeling about it ?

 this feature request has already been discussed and declined:
 http://wiki.php.net/rfc/ifsetor

 please review this rfc before continuing this thread.

 regards,
 Lukas Kahwe Smith
 m...@pooteeweet.org
 
 Thanks for the link to the RFC :)
 
 Excuse me, but I'll be little hard in this post. This for insult the 
 community but I want the community really think about the decision it 
 made and the reason why.  
 
 I also read why it have been refused here : 
 http://www.php.net/~derick/meeting-notes.html#ifsetor-as-replacement-for-
 foo-isset-foo-foo-something-else
 
 Is it serious ? 
 
 «
 The name for this new operator is heavily disputed and we could not agree 
 on a decent name for it.
 »
 
 Tomorrow I will not send food to the association for children who are 
 hungry because I can not choose between offering Thai or basmati rice.
 
 Stop sarcasm, seriously, this is not an honorable response from people 
 making decisions. Take your responsibility and make a vote or impose a 
 name, just do it. 
 
 « 
   Instead of implementing ifsetor() we remove the 
   requirement for the middle parameter to the ?: operator. 
 »
 
 That's not people wants and that's not do their need.
 So that not a correct answer of the php developper demand.
 
 « 
   In combination with the new input_filter extension 
   you then reach the original goal of setting a default 
   value to a non-set input variable with:
 
   $blahblah = input_filter_get(GET, 'foo', FL_INT) ?: 42;
 »
 
 I don't see how do that with the actual filter extension. Even if it is 
 possible, this is not a pretty short and easier solution than :
 
 $var = (isset($var)) ? $var : 'default';

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 $_POST and we definitely don't want people doing:

  $var = $_GET['foo'] ?: 42;

It would be an XSS disaster.  Hence the suggestion to use input_filter
there, or a similar user-supplied filtering function in which case the
ternary, as it is currently implemented, is perfectly suitable.

-Rasmus


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] suggestion about ternary operator

[mm w]

More interesting behaviors to dig are there:

variable = value1 ?? value2;

variable = value0 ?  value4 : value1 ?? value2;

or a la javascript

variable = value1 || value2;

Best,

On Sat, Nov 21, 2009 at 10:21 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
 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 be be lighter and clear. Since i use PHP, I always
 have in my 'common function file' a function like that :

 function getIssetVar($var, $default) { return ((isset($var)) ? $var :
 $default); }

 So is it possible to make a little improvement on this operator or
 introduce a new operator or a core function which do that ? What's your
 feeling about it ?

 this feature request has already been discussed and declined:
 http://wiki.php.net/rfc/ifsetor

 please review this rfc before continuing this thread.

 regards,
 Lukas Kahwe Smith
 m...@pooteeweet.org

 Thanks for the link to the RFC :)

 Excuse me, but I'll be little hard in this post. This for insult the
 community but I want the community really think about the decision it
 made and the reason why.

 I also read why it have been refused here :
 http://www.php.net/~derick/meeting-notes.html#ifsetor-as-replacement-for-
 foo-isset-foo-foo-something-else

 Is it serious ?

 «
 The name for this new operator is heavily disputed and we could not agree
 on a decent name for it.
 »

 Tomorrow I will not send food to the association for children who are
 hungry because I can not choose between offering Thai or basmati rice.

 Stop sarcasm, seriously, this is not an honorable response from people
 making decisions. Take your responsibility and make a vote or impose a
 name, just do it.

 «
   Instead of implementing ifsetor() we remove the
   requirement for the middle parameter to the ?: operator.
 »

 That's not people wants and that's not do their need.
 So that not a correct answer of the php developper demand.

 «
   In combination with the new input_filter extension
   you then reach the original goal of setting a default
   value to a non-set input variable with:

   $blahblah = input_filter_get(GET, 'foo', FL_INT) ?: 42;
 »

 I don't see how do that with the actual filter extension. Even if it is
 possible, this is not a pretty short and easier solution than :

 $var = (isset($var)) ? $var : 'default';

 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 $_POST and we definitely don't want people doing:

  $var = $_GET['foo'] ?: 42;

 It would be an XSS disaster.  Hence the suggestion to use input_filter
 there, or a similar user-supplied filtering function in which case the
 ternary, as it is currently implemented, is perfectly suitable.

 -Rasmus


 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] suggestion about ternary operator

[Dante Lorenso]

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 as the ifsetor debate because filled is opposite
empty and cares not about isset.

-- dante

On 11/21/09, Rasmus Lerdorf ras...@lerdorf.com wrote:
 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 be be lighter and clear. Since i use PHP, I always
 have in my 'common function file' a function like that :

 function getIssetVar($var, $default) { return ((isset($var)) ? $var :
 $default); }

 So is it possible to make a little improvement on this operator or
 introduce a new operator or a core function which do that ? What's your
 feeling about it ?

 this feature request has already been discussed and declined:
 http://wiki.php.net/rfc/ifsetor

 please review this rfc before continuing this thread.

 regards,
 Lukas Kahwe Smith
 m...@pooteeweet.org

 Thanks for the link to the RFC :)

 Excuse me, but I'll be little hard in this post. This for insult the
 community but I want the community really think about the decision it
 made and the reason why.

 I also read why it have been refused here :
 http://www.php.net/~derick/meeting-notes.html#ifsetor-as-replacement-for-
 foo-isset-foo-foo-something-else

 Is it serious ?

 «
 The name for this new operator is heavily disputed and we could not agree
 on a decent name for it.
 »

 Tomorrow I will not send food to the association for children who are
 hungry because I can not choose between offering Thai or basmati rice.

 Stop sarcasm, seriously, this is not an honorable response from people
 making decisions. Take your responsibility and make a vote or impose a
 name, just do it.

 «
   Instead of implementing ifsetor() we remove the
   requirement for the middle parameter to the ?: operator.
 »

 That's not people wants and that's not do their need.
 So that not a correct answer of the php developper demand.

 «
   In combination with the new input_filter extension
   you then reach the original goal of setting a default
   value to a non-set input variable with:

   $blahblah = input_filter_get(GET, 'foo', FL_INT) ?: 42;
 »

 I don't see how do that with the actual filter extension. Even if it is
 possible, this is not a pretty short and easier solution than :

 $var = (isset($var)) ? $var : 'default';

 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 $_POST and we definitely don't want people doing:

   $var = $_GET['foo'] ?: 42;

 It would be an XSS disaster.  Hence the suggestion to use input_filter
 there, or a similar user-supplied filtering function in which case the
 ternary, as it is currently implemented, is perfectly suitable.

 -Rasmus


 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php



-- 
Sent from my mobile device

D. Dante Lorenso
da...@lorenso.com
972-333-4139

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] suggestion about ternary operator

[Lukas Kahwe Smith]

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 throw notices for undefined variables.
 This is not the same as the ifsetor debate because filled is opposite
 empty and cares not about isset.


did you even read the RFC?

regards,
Lukas Kahwe Smith
m...@pooteeweet.org




-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] suggestion about ternary operator

[D. Dante Lorenso]

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, filled would not throw notices for undefined variables.
This is not the same as the ifsetor debate because filled is opposite
empty and cares not about isset.



did you even read the RFC?


Yes I did, and all I see is this in the References section:

  Suggestion to leave an empty() variant out of the picture since
   this  feature can be implemented in userland, though this of
   course not provide the full functionality of empty() which
   does not trigger notices for missing variables

I didn't see my proposal listed in it anywhere.  See this recommendation 
 from 3 1/2 years ago:


  - May 03, 2006
http://www.mail-archive.com/internals@lists.php.net/msg21617.html

Can someone please add the 'filled' proposal to the RFC?  I find 
'filled' way more useful than 'ifsetor' because in everyday code, I am 
constantly wanting to assign default values to variables that don't have 
values for a variety of reasons.  The assignment of a default value 
happens before input filtering.


  $email = filled(
$_REQUEST['email'],
$CONFIG-email_default,
$class_email,
'defa...@domain'
  );

Give me the first non-empty value and don't throw NOTICE warnings about 
it.  Otherwise, I need all this:


   $email = !empty($_REQUEST['email']) ? $_REQUEST['email'] : (
!empty($CONFIG-email_default) ? $CONFIG-email_default : (
!empty($class_email) ? $class_email : 'defa...@domain'
   ));

Yuck.

-- Dante

--
D. Dante Lorenso
da...@lorenso.com
972-333-4139

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] suggestion about ternary operator

[Alban]

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 $_POST and we definitely don't want people doing:
 
   $var = $_GET['foo'] ?: 42;
 
 It would be an XSS disaster.  Hence the suggestion to use input_filter
 there, or a similar user-supplied filtering function in which case the
 ternary, as it is currently implemented, is perfectly suitable.
 
 -Rasmus

Sure ! Developpers should filter variables contents !

Generaly there are 3 step for treat incoming variable : 
1- checking existance of the variable. 
2- set a default value if it not exists or empty. 
3- filtering the variable content.

Generaly, we combine step 1 and 2 in one.
I don't recommand using empty() because this method has some side effect 
like '0' or 'off' which are interpreted as empty values. I prefer use 
isset() method.

Every time, we need to check existance of variable. Checking if var is 
empty to fill it with a default value is optionnal, this step differs 
depending on the program behaviour.

For the third step, filter extension for example are perfect.

So, PHP provides an excellent short syntax to fill empty variable with 
the ternary operator.
But there is a lack for the most common case which is check if variable 
is set.

Perhaps I've made a mistake by suggesting a ternary operator improvement.

The real needing is :
I want a pretty and short syntax like the ternary operator for checking 
if a variable is set and set a default value if it not set.

I have one for array with union opertor.

$_POST += array(
 'foo' = '',
 'bar' = '',
 'baz' = '',
);

And having something like that would be nice :

$var ?= 'default';

// this can work too for array
$_GET['foo'] ?= 'default';

I am aware that I am repeating myself and that I seem insistant. It is 
difficult to express ideas clearly when one is not very comfortable with 
English and I apologize for that :)

-- 
Alban Leroux s...@paradoxal.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] suggestion about ternary operator

[Rasmus Lerdorf]

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
 via $_GET or $_POST and we definitely don't want people doing:

   $var = $_GET['foo'] ?: 42;

 It would be an XSS disaster.  Hence the suggestion to use input_filter
 there, or a similar user-supplied filtering function in which case the
 ternary, as it is currently implemented, is perfectly suitable.

 -Rasmus
 
 Sure ! Developpers should filter variables contents !
 
 Generaly there are 3 step for treat incoming variable : 
 1- checking existance of the variable. 
 2- set a default value if it not exists or empty. 
 3- filtering the variable content.

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 clean.

-Rasmus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] suggestion about ternary operator

[Alban]

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 clean.
 
 -Rasmus

Yes, as you say, simple and clean !

Have I miss something like that in php ?

-- 
Alban Leroux

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] suggestion about ternary operator

[Alban]

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 expr3 otherwise.

I think it is not very usefull because most of the time, in PHP, we need 
to check the existance only of a var or return a default value.

$foo = isset($myArray['foo']) ? $myArray['foo'] : 'default';

I can't use the new syntax for that :

// raise a warning if $myArray['foo'] not exists and return 'default'
$foo = $myArray['foo'] ?: 'default'; 

// return 'default' if $myArray['foo'] not exists or equals '', 0, false, 
null 
$foo = @$myArray['foo'] ?: 'default';  

// return true or 'default' 
$foo = isset($myArray['foo']) ?: 'default';

This is the same thing like using if (isset($var)) instead of if ($var), 
developpers always use isset() because they known that cause a warning 
with array and this can be evaluated to false. 
If they want test if $var equals 0, '' or null, they use empty().

I don't know about you, but personnaly, I use certainly 99 % of the time 
isset() and 1% empty(). So if the short ternary operator would be more 
usefull if it just test the existance of a variable.

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 function 
like that :

function getIssetVar($var, $default) { return ((isset($var)) ? $var : 
$default); }
 
So is it possible to make a little improvement on this operator or 
introduce a new operator or a core function which do that ? What's your 
feeling about it ?

-- 
Alban Leroux s...@paradoxal.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] suggestion about ternary operator

[Larry Garfield]

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, but if you are checking 
for the existence of a bunch of keys in an associative array and setting 
defaults if they are not set, the following will be considerably faster and 
easier to read:

$my_array += array(
  'a' = 'A',
  'b' = 'B',
  'c' = 'C',
);

That will set $my_array['a'] to A iff it doesn't exist, ['b'] to B iff it 
doesn't exist, etc.  That is far nicer to read than a bunch of ternaries, 
short-circuited or no.  You can even stick the defaults array into a function 
and call it from various places to ensure your array always has the same sane 
defaults.

-- 
Larry Garfield
la...@garfieldtech.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] suggestion about ternary operator

[Alban]

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 lighter and clear.
 
 I cannot comment on the rest of your post right now, but if you are
 checking for the existence of a bunch of keys in an associative array
 and setting defaults if they are not set, the following will be
 considerably faster and easier to read:
 
 $my_array += array(
   'a' = 'A',
   'b' = 'B',
   'c' = 'C',
 );
 
 That will set $my_array['a'] to A iff it doesn't exist, ['b'] to B iff
 it doesn't exist, etc.  That is far nicer to read than a bunch of
 ternaries, short-circuited or no.  You can even stick the defaults array
 into a function and call it from various places to ensure your array
 always has the same sane defaults.

Yes, union operator is a pretty solution for arrays.

-- 
Alban Leroux s...@paradoxal.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Robin Fernandes]

2009/5/16 Jingcheng Zhang dio...@gmail.com:

 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 think the current behaviour is as expected.
In that example, there is a single static field which is shared
between classes static_a, static_b and static_c. Because there is just
one value of $name, the class through which you access the value makes
no difference. On the other hand, in the case of classes dynamic_a,
dynamic_b and dynamic_c, by the nature of instance properties, each
instance has its own value of $name. So changing the value in one
instance does not affect the others. This behaviour is similar to many
other OO languages, including Java, C++ and C#.

Perhaps a closer equivalent of the Javascript code you provided is as
follows, where the static field is re-declared in subclasses, and
therefore exists as a separate entity in each class. Again, this
distinction between inherited static fields and re-declared static
fields also applies to other languages such as Java, C++ and C#.

?php
class static_a {
public static function change($name) {
static::$name = $name;
}
public static $name = 'a';
}
class static_c extends static_a {
public static $name;
}
class static_d extends static_a {
public static $name;
}

echo static_a::$name; // a
static_c::change('c');
echo static_a::$name; // a
static_d::change('d');
echo static_a::$name; // a
?

What do you think?

Regards,
Robin

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Suggestion on static field inheritance

[Jingcheng Zhang]

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:

?php
class static_a {
public static function change($name) {
self::$name = $name;
}
public static $name = 'a';
}
class static_c extends static_a {}
class static_d extends static_a {}

echo static_a::$name; // a
static_c::change('c');
echo static_a::$name; // c
static_d::change('d');
echo static_a::$name; // d


class dynamic_a {
public function change($name) {
$this-name = $name;
}
public $name = 'a';
}
class dynamic_c extends dynamic_a {}
class dynamic_d extends dynamic_a {}

$a = new dynamic_a();
$c = new dynamic_c();
$d = new dynamic_d();
echo $a-name; // a
$c-change('c');
echo $a-name; // a
$d-change('d');
echo $a-name; // a
?

The result of static inheritance test can be meaningful on some
way(especially on class-based programming perspective), but when considering
the static class as object in prototype-based programming(which I doubt is
some people's favourite who comes from prototype-based OOP community), this
result can be confusing. On JavaScript, this example can be:

script type=text/javascript
function extends(parent) {
var T = function () {};
T.prototype = parent;
return new T();
}
var static_a = {
name: 'a',
change: function (name) {
this.name = name;
}
};
var static_c = extends(static_a);
var static_d = extends(static_a);

alert(static_a.name); // a
static_c.change('c');
alert(static_a.name); // a
static_d.change('d');
alert(static_a.name); // a
/script

This looks more meaningful. So my suggestion is, could PHP's static
inheritance rule follow the dynamic inheritance rule ( $this on dynamic, or
prototype delegation on JavaScript) ?
Thanks :-)

-- 
Best regards,
Jingcheng Zhang
P.R.China

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

[Rodrigo Saboya]

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/4397

But right now I'll have to go back to add some scheduled support, and
I was afraid to fall into the same situation again, and I messaged the
list.

@Derick: If this is a xdebug specific, is there a way to you increase
this number?


Regards,


Why? Running xdebug in production environments is not something people 
(should) do. And anyone using xdebug is probably smart enough to change 
a .ini setting to avoid what you are suggesting. Just add an entry to 
your FAQ / Manual about it.


--
Rodrigo Saboya

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Derick Rethans]

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 infinite recursion and crashes. Change the 
xdebug.max_nesting_level setting to something higher and you'd be good 
to go.

regards,
Derick
-- 
HEAD before 5_3!: http://tinyurl.com/6d2esb
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Scott MacVicar]

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

Guilherme Blanco wrote:
 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 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 infinite recursion and crashes. Change the
 xdebug.max_nesting_level setting to something higher and you'd be good
 to go.

 regards,
 Derick
 --
 HEAD before 5_3!: http://tinyurl.com/6d2esb
 http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org

 
 
 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Guilherme Blanco]

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 have to go back to add some scheduled support, and
I was afraid to fall into the same situation again, and I messaged the
list.

@Derick: If this is a xdebug specific, is there a way to you increase
this number?


Regards,

On Tue, Sep 9, 2008 at 10:19 AM, Scott MacVicar [EMAIL PROTECTED] wrote:
 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

 Guilherme Blanco wrote:
 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 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 infinite recursion and crashes. Change the
 xdebug.max_nesting_level setting to something higher and you'd be good
 to go.

 regards,
 Derick
 --
 HEAD before 5_3!: http://tinyurl.com/6d2esb
 http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org








-- 
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9166-6902
MSN: [EMAIL PROTECTED]
URL: http://blog.bisna.com
Rio de Janeiro - RJ/Brazil

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Guilherme Blanco]

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 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 infinite recursion and crashes. Change the
 xdebug.max_nesting_level setting to something higher and you'd be good
 to go.

 regards,
 Derick
 --
 HEAD before 5_3!: http://tinyurl.com/6d2esb
 http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org




-- 
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9166-6902
MSN: [EMAIL PROTECTED]
URL: http://blog.bisna.com
Rio de Janeiro - RJ/Brazil

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Suggestion to increase the max_input_nesting_level

[Guilherme Blanco]

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 Query Language) compiler, which processes our SQL-similar
language and convert it into a valid SQL statement for the driver
being used.
If you want a comparative, our approach is inspired in known OQL, like
JPQL of Hibernate in Java.
One example:

SELECT u FROM User u

It'll be converted into something like:

SELECT u.id AS u__id, u.name AS u__name, u.passwd AS u_passwd, u.email
AS u__email FROM user u

Please notice this is a very simple example, but highlights how does it work.

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.
With all these optimizations, it currently reaches ~70.
I made a lot of tests and the queries usually reaches 103... some
complex ones reached ~140 nested calls.
I know PHP was not structured to build compilers, and also I know this
property can be overrided (many users do not have access to it), but I
think for this situation it worth a consideration.
Also, it's not a simple change for only one user, since our code usage
is very large.

My suggestion is to increase to something like 180, available since PHP 5.3.
I'd like to know your thoughts about this subject.

Thanks in advance,


Best regards,

-- 
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9166-6902
MSN: [EMAIL PROTECTED]
URL: http://blog.bisna.com
Rio de Janeiro - RJ/Brazil

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Stanislav Malyshev]

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'm not sure I understand - how this compiler is related to input 
nesting level? What exactly you do there that requires 150+ levels of 
nesting on input?


--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]   http://www.zend.com/
(408)253-8829   MSN: [EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Guilherme Blanco]

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 to you.

Regards,

On Mon, Sep 8, 2008 at 10:14 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
 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'm not sure I understand - how this compiler is related to input nesting
 level? What exactly you do there that requires 150+ levels of nesting on
 input?

 --
 Stanislav Malyshev, Zend Software Architect
 [EMAIL PROTECTED]   http://www.zend.com/
 (408)253-8829   MSN: [EMAIL PROTECTED]




-- 
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9166-6902
MSN: [EMAIL PROTECTED]
URL: http://blog.bisna.com
Rio de Janeiro - RJ/Brazil

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Stan Vassilev | FM]

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 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'm not sure I understand - how this compiler is related to input nesting 
level? What exactly you do there that requires 150+ levels of nesting on 
input? 



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Guilherme Blanco]

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 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 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'm not sure I understand - how this compiler is related to input nesting
 level? What exactly you do there that requires 150+ levels of nesting on
 input?


 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php





-- 
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9166-6902
MSN: [EMAIL PROTECTED]
URL: http://blog.bisna.com
Rio de Janeiro - RJ/Brazil

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Suggestion for get_headers

[Justin Martin]

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 unencoded. Due to this, any request with special 
characters (i.e. a space), will return 400 BAD REQUEST. My suggestion to 
remedy this, would be to internally apply the function urlencode to 
the $url parameter. This would automatically encode any provided URL, 
while remaining transparent.


Any comments?

Thanks,
Justin Martin

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Suggestion: Namespace implementation

[Larry Garfield]

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 and because of already being
 able to group variables, constants and functions in static classes i see
 no reason for namespaces to affect the resolution of the previously
 mentioned elements. Instead, they should only affect classes enabling
 the coder to tie packages and use or provide libraries.

Libraries are generally class libraries is both wrong and very limiting.  
There is nothing wrong with functions.  Thousands of professional web sites 
run on systems that have not a single class in them quite successfully.  
There are plenty of situations where going all OO is not a good thing, and 
results in more code complexity, not less.

A complete namespace implementation supports both classes and functions 
equally.

-- 
Larry Garfield  AIM: LOLG42
[EMAIL PROTECTED]   ICQ: 6817012

If nature has made any one thing less susceptible than all others of 
exclusive property, it is the action of the thinking power called an idea, 
which an individual may exclusively possess as long as he keeps it to 
himself; but the moment it is divulged, it forces itself into the possession 
of every one, and the receiver cannot dispossess himself of it.  -- Thomas 
Jefferson

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Suggestion: Namespace implementation

[Hans Moog]

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.

 

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 and because of already being
able to group variables, constants and functions in static classes i see
no reason for namespaces to affect the resolution of the previously
mentioned elements. Instead, they should only affect classes enabling
the coder to tie packages and use or provide libraries.

 

 

By the way ... why should it be possible to write something like this:

 

?php

namespace Array;

 

define('CALL_MODIFIER1', 1);

 

function merge() {

  /* ... code ... */

}

?

 

to express Array::merge().

 

If we are already able to express the same thing by writing something
like this:

 

?php 

class Array {

  const CALL_MODIFIER = 1;

 

  public static function merge() {

  }

}

?

 

even leaving us the opportunity to later group the static classes into
an additional package by additionally defining a namespace in the file.

If we decide to limit namespaces to classes, we are able to define some
very easy rules that are able to be applied during compile time without
having any runtime evaluation, making namespaces really fast:

 

 

If there is a namespace declaration in the current file {

  1. all classes defined in this file are prefixed with the namespace.

  2. all classes without an additional namespace prefix (meaning
everything with X::method|variable|constant) which were not imported
are prefixed with the defined namespace.

  3. all classes with a name that was imported get resolved by replacing
the imported alias with the imported path.

  4. all other classes (especially Y::X::method|variable|constant)
that were not imported are resolved as beeing full paths (remaining
unmodified)

} else {

  1. all classes defined in this file are not prefixed with a namespace

  2. all classes without an additional namespace prefix (meaning
everything with X::method|variable|constant) which were not imported
are NOT prefixed.

  3. all classes with a name that was imported get resolved by replacing
the imported alias with the imported path.

  4. all other classes (especially Y::X::method|variable|constant)
that were not imported are resolved as beeing full paths (remaining
unmodified)

}

 

 

 

Example with a namespace declaration:

 

?php

 

namespace framework::email;

 

use framework::database; // import other package

use ArrayAccess;   // import global class

 

class MailServer implements ArrayAccess {

  public function connect() {

$database = database::DBFactory::getInstance();

$protocol = new Pop3Protocol();

 

if(...) {

  throw new Exception('message', 0);

} else {

  throw new ::Exception('message', 0);

}

  }

}

 

class Exception extends ::Exception {

}

 

?

 

will be compiled to:

 

?php

 

class framework::email::MailServer implements ArrayAccess {

  public function connect() {

$database = framework::database::DBFactory::getInstance();

$protocol = new framework::email::Pop3Protocol();

 

if(...) {

  throw new framework::email::Exception('message', 0);

} else {

  throw new Exception('message', 0);

}

  }

}

 

class framework::email::Exception extends Exception {

}

 

?

 

 

 

 

Example without a namespace declaration:

 

?php

 

use framework::database; // import other package

use ArrayAccess;   // import global class (useless)

 

class MailServer implements ArrayAccess {

  public function connect() {

$database = database::DBFactory::getInstance();

$protocol = new Pop3Protocol();

 

if(...) {

  throw new Exception('message', 0);

} else {

  throw new ::Exception('message', 0);

}

  }

}

 

class MailException extends ::Exception {

}

 

?

 

will be compiled to:

 

?php

 

class MailServer implements ArrayAccess {

  public function connect() {

$database = framework::database::DBFactory::getInstance();

$protocol = new Pop3Protocol();

 

if(...) {

  throw new Exception('message', 0);

} else {

  throw new Exception('message', 0);

}

  }

}

 

class MailException extends Exception {

}

 

?

 

 

So ... we would be able have short names without being scared of naming
conflicts with core functions or breaking backward compatibility. And we
would still be able to express the same things as if we would allow
namespace for functions, variables and constants by declaring them in
static classes.

 

 

PS: Just a suggestion so don't kill me :o)

[PHP-DEV] Suggestion: Namespace implementation

[Hans Moog]

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.

 

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 and because of already being
able to group variables, constants and functions in static classes i see
no reason for namespaces to affect the resolution of the previously
mentioned elements. Instead, they should only affect classes enabling
the coder to tie packages and use or provide libraries.

 

 

By the way ... why should it be possible to write something like this:

 

?php

namespace Array;

 

define('CALL_MODIFIER1', 1);

 

function merge() {

  /* ... code ... */

}

?

 

to express Array::merge().

 

If we are already able to express the same thing by writing something
like this:

 

?php 

class Array {

  const CALL_MODIFIER = 1;

 

  public static function merge() {

  }

}

?

 

even leaving us the opportunity to later group the static classes into
an additional package by additionally defining a namespace in the file.

If we decide to limit namespaces to classes, we are able to define some
very easy rules that are able to be applied during compile time without
having any runtime evaluation, making namespaces really fast:

 

 

If there is a namespace declaration in the current file {

  1. all classes defined in this file are prefixed with the namespace.

  2. all classes without an additional namespace prefix (meaning
everything with X::method|variable|constant) which were not imported
are prefixed with the defined namespace.

  3. all classes with a name that was imported get resolved by replacing
the imported alias with the imported path.

  4. all other classes (especially Y::X::method|variable|constant)
that were not imported are resolved as beeing full paths (remaining
unmodified)

} else {

  1. all classes defined in this file are not prefixed with a namespace

  2. all classes without an additional namespace prefix (meaning
everything with X::method|variable|constant) which were not imported
are NOT prefixed.

  3. all classes with a name that was imported get resolved by replacing
the imported alias with the imported path.

  4. all other classes (especially Y::X::method|variable|constant)
that were not imported are resolved as beeing full paths (remaining
unmodified)

}

 

 

 

Example with a namespace declaration:

 

?php

 

namespace framework::email;

 

use framework::database; // import other package

use ArrayAccess;   // import global class

 

class MailServer implements ArrayAccess {

  public function connect() {

$database = database::DBFactory::getInstance();

$protocol = new Pop3Protocol();

 

if(...) {

  throw new Exception('message', 0);

} else {

  throw new ::Exception('message', 0);

}

  }

}

 

class Exception extends ::Exception {

}

 

?

 

will be compiled to:

 

?php

 

class framework::email::MailServer implements ArrayAccess {

  public function connect() {

$database = framework::database::DBFactory::getInstance();

$protocol = new framework::email::Pop3Protocol();

 

if(...) {

  throw new framework::email::Exception('message', 0);

} else {

  throw new Exception('message', 0);

}

  }

}

 

class framework::email::Exception extends Exception {

}

 

?

 

 

 

 

Example without a namespace declaration:

 

?php

 

use framework::database; // import other package

use ArrayAccess;   // import global class (useless)

 

class MailServer implements ArrayAccess {

  public function connect() {

$database = database::DBFactory::getInstance();

$protocol = new Pop3Protocol();

 

if(...) {

  throw new Exception('message', 0);

} else {

  throw new ::Exception('message', 0);

}

  }

}

 

class MailException extends ::Exception {

}

 

?

 

will be compiled to:

 

?php

 

class MailServer implements ArrayAccess {

  public function connect() {

$database = framework::database::DBFactory::getInstance();

$protocol = new Pop3Protocol();

 

if(...) {

  throw new Exception('message', 0);

} else {

  throw new Exception('message', 0);

}

  }

}

 

class MailException extends Exception {

}

 

?

 

 

So ... we would be able have short names without being scared of naming
conflicts with core functions or breaking backward compatibility. And we
would still be able to express the same things as if we would allow
namespace for functions, variables and constants by declaring them in
static classes.

 

 

PS: Just a suggestion so don't kill me :o)

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

[Tzachi Tager]

The reason I'm doing this is because it seems that Windows parser looks for an 
odd number of '' before the escaping, otherwise the escaping character is 
included in the outcome, for example:

string(25) md test ^ echo ^%foo^%  == will output a directory called 
test ^ echo ^%foo^%

While:
string(31) md test ^ echo ^%foo^% == will output a directory called 
test  echo %foo%

(I changed the php code and ran again, these are not 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: [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 with ^char.

I think you are not entirely correct here. What the quote means is that 
if you want foobar, you should do either foobar or foo^bar - not 
replace  with ^.
-- 
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]   http://www.zend.com/
(408)253-8829   MSN: [EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Stanislav Malyshev]

/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 with ^char.


I think you are not entirely correct here. What the quote means is that 
if you want foobar, you should do either foobar or foo^bar - not 
replace  with ^.

--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]   http://www.zend.com/
(408)253-8829   MSN: [EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Frode E. Moe]

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 escaping method
 for command line in Windows. Therefore I'm guessing no one really use
 escapeshellarg() or escapeshellcmd() on Windows. And in order to change
 this  I suggest to use the command line escaping that does exists
 (although looking a bit ugly), as you can see for example here:
 http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs
 /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 with ^char.
 So this is the diff file that I suggest to use- it for sure fix the
 above bug and may improve windows escapeshellcmd():

Hi, I'm the guy who reported the bug originally.

When I read your post now, I just realized that maybe there should be a
different set of escaping functions for win32 (escapewin32arg or
escapecmdarg?), so that the behaviour of escapeshellarg() does not change 
across platforms. (What if you want to dynamically generate a downloadable 
unix shell script, for example.)

Your patch was a bit difficult to read (too little context and not in
unidiff format), so I'll leave the commenting for those more familiar 
with the C source.

Thanks for working on the problem, anyway!

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Suggestion for fixing Bug #40928

[Tzachi Tager]

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 one really use
escapeshellarg() or escapeshellcmd() on Windows. And in order to change
this  I suggest to use the command line escaping that does exists
(although looking a bit ugly), as you can see for example here:
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs
/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 with ^char.
So this is the diff file that I suggest to use- it for sure fix the
above bug and may improve windows escapeshellcmd():

cvs diff -- exec.c (in directory C:\php-src\ext\standard\)
Index: exec.c
===
RCS file: /repository/php-src/ext/standard/exec.c,v
retrieving revision 1.113.2.3.2.1
diff -r1.113.2.3.2.1 exec.c
275d274
   case '\'':
276a276,277
   case '\'':
 #endif
281a283
 #ifndef PHP_WIN32
282a285,289
 #else
   cmd[y++] = '';
   cmd[y++] = '^';
   cmd[y++] = str[x];
 #endif
286,287d292
 #endif
   case '#': /* This is character-set independent
*/
289,290d293
   case ';':
   case '`':
292,294d294
   case '*':
   case '?':
   case '~':
299a300,313
 #ifdef PHP_WIN32
   case '%':
   cmd[y++] = '';
   cmd[y++] = '^';
   cmd[y++] = str[x];
   cmd[y++] = ''; 
   break;
 #endif
   case '#': /* This is character-set independent
*/
   case ';':
   case '`': 
   case '*':
   case '?':
   case '~':   
305d318
   case '\\':
309,310c322
   /* since Windows does not allow us to escape
these chars, just remove them */
   case '%':
---
   /* since Windows does not allow us to
escape these chars, just remove them */
313a326
   case '\\':
347d359
   case '%':

Comments will be greatly appreciated.
All the best,
Tzachi Tager.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] suggestion SplFileInfo

[Pierre]

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 it is a good idea to add glob:// stream support. What
does it have to do with custom streams? Will we add pcre:// too?

DirectoryIteratorPattern/Glob($pattern) make much more sense to me. I
did not test it but how does it work when used with other protocols?
like: ftp://some/path/?

It may be more useful to add streams support to our glob functions.
But it can bring more troubles than expected.

--Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] suggestion SplFileInfo

[Pierre]

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 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 pattern implementation being 100% the same (using
 pcre or bsd's glob)

So instead of discussing here you should take the glob code of win32
directory, check the license and either make otwork as you want or reqrite
it.


I don't get what you are trying to say here.


Having that stuff in zip makes absolutely no sense at all. Especially
when it is already there. It is always better to reuse then to provide new
errors...


Is it not what I just said?


 You miss/drop my point, I don't like the glob:// wrapper addition. It
 makes no sense as it has no meaning from a URI point of view.

Then don't use it.


That's a comment I will keep in mind.


 To have the pattern matching functions (something like fnmatch for
 example) always available and exported is indeed a good thing. Many
 extensions can use it. That does not mean we cannot rely on the system
 versions when available (for the local file operations at least).

  Another thing is that doing so would only make
 the glob implementation itself profit from this. Providing the other way
 makes anything profit from glob support.

 Correct me if I'm wrong but a Iterator+filter can do the same thing
 without having this ugly glob://

 $iter = new DirectoryIteratorPattern(/dir1/*.jpeg);
 $iter = new DirectoryIteratorPattern(zip://my.zip/dir1/*.jpeg);
 $iter = new DirectoryIteratorPattern(ftp://my.zip/dir1/*.jpeg;);

It would be much slower. And still glob offers more. It works like your
system does.


It is certainly not slower and you still did not tell me why a glob://
is required.


 Given that the stream wrapper provides the minimum set of ops to do it.

What stream wrapper are we talking of now? The pcre filter stream you are
going to implement?


Ok, a pcre URI wrapper is as insane as this glob://.


The wrapper that is there right now is glob and yes,
that one provides the minimum that is needed.


I'm talking about the other wrapper like phar or zip, if they don't
provide all required functions, how will you access the directory
contents? Or know whether a path is a directory or not?


 We might even think of adding
 support for opening files through glob:// by having it open the first
 returned file when used for file opening.

 I suppose we'll need other functions to move the cursor? Or make it
 move forward magically on each fopen call? That's ugly.  ;-)

Exactly, Hence glob only does what it can do.


Why a new URI then? Please tell why you need a URI.



 No other language implements blog or fnmatch support in such way but
 using iterators and filters (in one form or another). Such magic
 behaviors are always confusing.

No other lanaguage has an Iterator implementation of the power PHP offers.
So shall we drop that? And guess what languages are different. For example
no other language has ternary implemented in the way PHP has.


 take #4

I'm talking about the new *GLOB://* URI not about glob support in
Iterator. One has nothing to do with the other. URI are not PHP
specific, there is some conventions for them. But we tend to ignore
them.


 Damn, it apprears we have different taste :-)

 It is not about taste. A glob is not a URI-like data. It is a filter.
 I hope you understand my point now (for better glob support but no
 glob://), let see what the other developers think about that.

Just in case you didn't notice. Glob is for directory listing. And the glob
stream does exactly that in a portable way that can easily be used form
anything that works on directories. Plain file directories that is because
glob does not understand anything.


That's why I said it makes sense to have a glob op, a glob URI makes no sense.


 And should you work on it as described
above then anything using glob stream will automagically profit from that.
And this cooperation is the reason we have streams in the first place. If
you feel i left out zip - which is what your complain sounds like.


It is not about zip, it is not a complain, it is a discussion about
your (wild) addition to the core stream.

To make it clear: I don't like the new glob:// URI. I'm not talking
about iterators goodies or anything else, period.


Then I
suppose you go the route I laid down to solve that. It is not of my concern.
I for one did something that a user brought up, which made perfectly sense
to me and which already helped me. That is all I need to know.


Before bloating the general wrapper names space with something like
that, you may consider to discuss it on this list before.

Anyway, we are running (again) in circle, you see my comments as
personal attacks and 

Re: [PHP-DEV] suggestion SplFileInfo

[Pierre]

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 you don't understand. AA.


I suppose that ends the dialog. So be it.

I will take another way to understand why one can add URI wrappers in
the core stream implementation without discussing it and even worst,
without allowing any discussion about his choice.

--Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] suggestion SplFileInfo

[Marcus Boerger]

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. The flags are passed to any 
 fileinfo object created.
 In case we need flags this will be added to the constructor or as
 seperate getter/setter. My preference is actually the latter.
 Sure that works just as well, but it would be useful if the flags are
 passed down. That way you can also use it on a DirectoryIterator.
DirectoryIterator extends SplFileInfo, so it would work just fine.


  - Add flags FOLLOW_LINK_ALWAYS, FOLLOW_LINK_EXISTS, FOLLOW_LINK_NEVER
 for the constructor. Functions as getPerms and getOwner will look at 
 this setting.
 I will need to check whether I Can do that. If so I will add flags as well.
 Until then you can overwrite hasChildren() to return parent::hasChildren()
  !this-isLink() to solve the third flag. The second flag also needs to
 verify the target by using getLinkTarget() (see below). Finally the first
 flag is simplywhat we have right now
 I believe that there is a bit of miscommunication here. The flags should 
 determine if stat or lstat is used to get the properties of the files. 
 Currently spl always uses stat. Perhaps the names I came up with aren't 
 perfect.
That makes more sense then. However we need to have isLink() operate on
stat always and not have it suddenly operate on the link target. The problem
here however is that we need to extend streams api so it supports lstat.
Right now it doesn't.


  - Add getBasename, to get the basename of either a dir or file.
 Did you overlook this? or don't you like it.
Oopsadded that as well now.


  - Function isHidden, to check wether a file is hidden
 I don't think we have support for windows' hidden flag, do we? Under
 *nix as I just reminded you can simply check whether thefilename starts
 with a dot.
 Yes that true, but it would be nice to have a function which returns a
 boolean and work for both windows and unix. Perhaps a workaround can be 
 thought off for windows.
Right now the underlying api's have absolutely no support for windows file
attributes. So we'd need to add a lot of stuff. Which won't happen. So the
only thing we can do is adding isHidden for non windows where we would
simply check for first char being '.'.


  - Functions getTypeInfo and getMime, to get info of the file using libmagic
 there are getType and getMTime, that should be enough no?
 No the name are almost the same, but the output isn't. I'm talking about
 integrating the features provided by fileinfo 
 (http://www.php.net/fileinfo). Perhaps the names aren't chosen well.
If we ever have fileinfo as a core component to php which cannot be disabled
you should remind me again. Until then it should be a user solution like
with the posix stuff for getting owner/group name.


  - Function setDirInfoClass, set a info class specially for directories
 What I could do is providing a slow mechanism that actually does a stat
 call and checks the dir flag. Then internally add a pointer for the
 directory info class and a getter/setter for that. It would be initialized
 to null and thegetter would see the normal info class as long as it is
 null. That way the directory info is bound to the standard info class
 until you explicitly split it. Would this solve your problem?
 Maybe for PHP 5.3 there should be a stat cache to speeed things up.
 Yes that would be perfect.
 PS. Currently looping with a DirectoryIterator returns a 
 DirectoryIterator for each child, dirs as well as files, instead of the 
 class set using setInfoClass(). Is this correct? It wasn't what I 
 expected. RecursiveDirectoryIterator work like I expected.
DirectoryIterator is much easier then the recursive one. That way it is
faster but cannot do all the recursive one can do.


 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 directories,
 creating an object for each file gives a huge overhead. Glob has a 
 directory only flag, may that feature can be used.
Problem is we don't use glob here. The advantage of using streams is
also direclty its disadvantage. Streams directory functionality works
for anythign that can be treated as a directory. But only in forward
mode. The way out would be to provide a new glob stream. For instance:

$dir = new DirectoryIterator(glob//:~/*.php);

Only problem here is where to put the flags.


  - Function getFileCount
 That would require to loop through the directory which is not what we want.
 If you need the count after usingthe elements you can for example loop
 through a CachingIterator which ha sa newly introduced count method that
 will give you the number of elements used.
 Isn't there a way you 

Re: [PHP-DEV] suggestion SplFileInfo

[Marcus Boerger]

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 Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[P]

 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 directories, 
 creating an object for each file gives a huge overhead. Glob has a 
 directory only flag, may that feature can be used.

One more argument for a PHP internal implementation of glob()/fnmatch(),
as GLOB_ONLYDIR is not portable (probably not posix-compliant). We could
also add a flag to exclude broken symbolic links, and globbing support 
in stream wrappers (would allow a syntax like wget's 'ftp://dir/*').

I have written a feature request listing glob()-related problems 6 
months ago (http://bugs.php.net/bug.php?id=38022). If somebody is interested,
it could be time to reactivate it (unfortunately, I won't have enough free
time to work on it).

Regards

Francois

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] suggestion SplFileInfo

[Arnold Daniels]

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 parameter $flags to constructor. The flags are passed to any 
fileinfo object created.
- Add flags FOLLOW_LINK_ALWAYS, FOLLOW_LINK_EXISTS, FOLLOW_LINK_NEVER 
for the constructor. Functions as getPerms and getOwner will look at 
this setting.

- Add getBasename, to get the basename of either a dir or file.
- Function getLinkTarget, does readlink($this-getPathname())
- Function getRealpath, does realpath($this-getPathname())
- Function getOwnerName and getGroupName
- Function isHidden, to check wether a file is hidden
- Functions getTypeInfo and getMime, to get info of the file using libmagic
- Function setDirInfoClass, set a info class specially for directories

DirectoryIteratorRecursive:
- Add flag DIRS_ONLY for the constructor, to only loop through directories
- Add flag WITHOUT_HIDDEN_FILES for the constructor, not to loop 
through hidden files

- Function getFileCount

If you like these features, but don't have time to implement them, I can 
see if I can write a patch. I'm quite new at writing PHP extensions, but 
I know the basics.


Best regards,
Arnolds

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] suggestion SplFileInfo

[Marcus Boerger]

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 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 parameter $flags to constructor. The flags are passed to any 
 fileinfo object created.
In case we need flags this will be added to the constructor or as
seperate getter/setter. My preference is actually the latter.

  - Add flags FOLLOW_LINK_ALWAYS, FOLLOW_LINK_EXISTS, FOLLOW_LINK_NEVER 
 for the constructor. Functions as getPerms and getOwner will look at 
 this setting.
I will need to check whether I Can do that. If so I will add flags as well.
Until then you can overwrite hasChildren() to return parent::hasChildren()
 !this-isLink() to solve the third flag. The second flag also needs to
verify the target by using getLinkTarget() (see below). Finally the first
flag is simplywhat we have right now.

  - Add getBasename, to get the basename of either a dir or file.
  - Function getLinkTarget, does readlink($this-getPathname())
added in HEAD as getLinkTarget()

  - Function getRealpath, does realpath($this-getPathname())
added in HEAD as getRealPath()

  - Function getOwnerName and getGroupName
Use posix_getpwuid() and posix_getgrgid() *if available*. I prefer not to
have them in SPL.

  - Function isHidden, to check wether a file is hidden
I don't think we have support for windows' hidden flag, do we? Under
*nix as I just reminded you can simply check whether thefilename starts
with a dot.

  - Functions getTypeInfo and getMime, to get info of the file using libmagic
there are getType and getMTime, that should be enough no?

  - Function setDirInfoClass, set a info class specially for directories
What I could do is providing a slow mechanism that actually does a stat
call and checks the dir flag. Then internally add a pointer for the
directory info class and a getter/setter for that. It would be initialized
to null and thegetter would see the normal info class as long as it is
null. That way the directory info is bound to the standard info class
until you explicitly split it. Would this solve your problem?

Maybe for PHP 5.3 there should be a stat cache tospeeed things up.

 DirectoryIteratorRecursive:
  - Add flag DIRS_ONLY for the constructor, to only loop through directories
This is achieved by a FilterIterator: ParentIterator

  - Add flag WITHOUT_HIDDEN_FILES for the constructor, not to loop
 through hidden files
Can be done easily by providing a filter.

  - Function getFileCount
That would require to loop through the directory which is not what we want.
If you need the count after usingthe elements you can for example loop
through a CachingIterator which ha sa newly introduced count method that
will give you the number of elements used.

 If you like these features, but don't have time to implement them, I can 
 see if I can write a patch. I'm quite new at writing PHP extensions, but 
 I know the basics.

 Best regards,
 Arnolds




Best regards,
 Marcus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] suggestion SplFileInfo

[Arnold Daniels]

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 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 parameter $flags to constructor. The flags are passed to any 
fileinfo object created.


In case we need flags this will be added to the constructor or as
seperate getter/setter. My preference is actually the latter.
  
Sure that works just as well, but it would be useful if the flags are 
passed down. That way you can also use it on a DirectoryIterator.
  
 - Add flags FOLLOW_LINK_ALWAYS, FOLLOW_LINK_EXISTS, FOLLOW_LINK_NEVER 
for the constructor. Functions as getPerms and getOwner will look at 
this setting.


I will need to check whether I Can do that. If so I will add flags as well.
Until then you can overwrite hasChildren() to return parent::hasChildren()
 !this-isLink() to solve the third flag. The second flag also needs to
verify the target by using getLinkTarget() (see below). Finally the first
flag is simplywhat we have right now
I believe that there is a bit of miscommunication here. The flags should 
determine if stat or lstat is used to get the properties of the files. 
Currently spl always uses stat. Perhaps the names I came up with aren't 
perfect.

.

  

 - Add getBasename, to get the basename of either a dir or file.


Did you overlook this? or don't you like it.


 - Function getLinkTarget, does readlink($this-getPathname())


added in HEAD as getLinkTarget()
  

Perfect
  

 - Function getRealpath, does realpath($this-getPathname())


added in HEAD as getRealPath()
  

Excellent
  

 - Function getOwnerName and getGroupName


Use posix_getpwuid() and posix_getgrgid() *if available*. I prefer not to
have them in SPL.
  

Ok very well
  

 - Function isHidden, to check wether a file is hidden


I don't think we have support for windows' hidden flag, do we? Under
*nix as I just reminded you can simply check whether thefilename starts
with a dot.
  
Yes that true, but it would be nice to have a function which returns a 
boolean and work for both windows and unix. Perhaps a workaround can be 
thought off for windows.
  

 - Functions getTypeInfo and getMime, to get info of the file using libmagic


there are getType and getMTime, that should be enough no?
  
No the name are almost the same, but the output isn't. I'm talking about 
integrating the features provided by fileinfo 
(http://www.php.net/fileinfo). Perhaps the names aren't chosen well.
  

 - Function setDirInfoClass, set a info class specially for directories


What I could do is providing a slow mechanism that actually does a stat
call and checks the dir flag. Then internally add a pointer for the
directory info class and a getter/setter for that. It would be initialized
to null and thegetter would see the normal info class as long as it is
null. That way the directory info is bound to the standard info class
until you explicitly split it. Would this solve your problem?

Maybe for PHP 5.3 there should be a stat cache tospeeed things up.
  

Yes that would be perfect.
PS. Currently looping with a DirectoryIterator returns a 
DirectoryIterator for each child, dirs as well as files, instead of the 
class set using setInfoClass(). Is this correct? It wasn't what I 
expected. RecursiveDirectoryIterator work like I expected.
  

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 directories, 
creating an object for each file gives a huge overhead. Glob has a 
directory only flag, may that feature can be used.
  

 - Add flag WITHOUT_HIDDEN_FILES for the constructor, not to loop
through hidden files


Can be done easily by providing a filter.
  

Ok that is fine.
  

 - Function getFileCount


That would require to loop through the directory which is not what we want.
If you need the count after usingthe elements you can for example loop
through a CachingIterator which ha sa newly introduced count method that
will give you the number of elements used.
  
Isn't there a way you can easily get this information from the system? 
Anyhow I much rather have a loop in c through a set of filenames, than 
looping in php using the iterator. I believe having the ability to give 
the number of files of a directory is really useful, even if you don't 
want to do anything with the files from the dir. For example: gnome 
nautilus displays the number files for each dir instead of the filesize.
  

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

[Richard Lynch]

[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 rely
on a
 specific code being a specific level? Out of curiousity: I wouldn't
even
 know why someone would do something like that, perhaps you have a
good example.

 Anyway, that's a BC break I find worth doing but I'm fully aware
that you will disagree.

Anybody on shared hosting who wants to log their errors somewhere out
of the morass of system logs without dinking around with .htaccess is
going to use set_error_handler.

For that matter, if .htaccess is off, and you can't edit php.ini,
set_error_handler is just about your only option for reasonable error
handling.

I think you will find that a LOT of distributed applications use this
to avoid splatting PHP error messages out.  Or, at least, they should
be using it, as there's no other way without using something you can't
rely on if your code is widely distributed in unknown environments.

I know *I* have used it more than a few times.

Once you decide to use set_error_handler, of course you are going to
treat E_ERROR, E_NOTICE, E_USER_ERROR differently.  You want to just
halt your script for E_ERROR, but probably just tell yourself to fix
the buglet of an E_NOTICE.

You may even put them in separate logs, or perhaps even email yourself
E_ERROR, but only log E_NOTICE.

I *know* I have switch() statements on the error level in my error
handlers, and you are going to break them.

I can understand why the purist / anal-retentive camp wants
un-initiliazed varaibles as E_STRICT rather than E_NOTICE, but does it
really make that much difference?

And, honestly, there *ARE* bugs that can be introduced if somebody
makes a typo that results in using an unitialized variable.

Though the PHP auto-initialization to '' (or 0 or false or whatever is
suitable after type-juggling) works 99% of the time, imagine something
like this:

?php
  /* lots of code */
  $foo = 42;
  /* lots of code */
  if ($foo === 42) echo foo!;
?

Now imagine that somebody deletes all the lots of code and also
accidentally deletes the initialization.

The thing you believe should be E_STRICT is, in fact, an E_NOTICE
worthy issue.

Not only CAN this happen, it HAS happened to me, and the E_NOTICE made
it patently obvious what had happened as soon as I ran my tests.

Therefore, I believe the uninitialized variables should NOT be moved
to E_STRICT.

-- 
Some people have a gift link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?



-- 
Some people have a gift link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Richard Lynch]

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 read, as the spam filter just junks it...
:-v

 you can see, the only change needed is in a throw-able error
 (Undefined
 variable), which does a second look-up in the symbolTable.Doing
 this, you do not need to use $GLOBALS nevermore! And also, global
 can

 You didn't grasp two of the major PHP features (not bugs!):
 1. Every variable you access inside a function is local unless
 explicitely imported (through $GLOBALS, global or superglobals) from
 the
 global scope.

And that's the way it should be, unless you really like tracking down
obscure bugs from totally unrelated code messing with your variables.

 2. Accessing undefined variables is normal and not an error (not
 everybody agrees here but lots of people consider this a big plus).

Actually, it's not at all normal, and PHP throws an E_NOTICE.

It's your own fault if you haven't turned that on in your
error_reporting.

-- 
Some people have a gift link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Derick Rethans]

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Suggestion: global variables being accessed in local scope

[Guilherme Blanco]

Hello PHP maintainers,During this week, I spoke with Sara Golemon about the 
possibility to change one current behavior of PHP.My first suggestion, as you 
can see in my blog post: http://blog.bisna.com/archives/32#comments was a new 
function called register_superglobal.While talking with her, I found that it'll 
be easier to be implemented another thing.Currently, when we deal with objects 
and functions in a PHP application, to access most common variables, we have to 
do one of these things:function m() {global $DB; // ...}Another 
one:function m() {$DB = Database::getInstance();  // ...}Or:function m() {  
  $DB = Registry::get(DB);  // ...}And finally... via Factory:function m() {  
  $DB = Env::getDatabaseConnection();  // ...}We can also specify via runkit a 
superglobal variable (DB), and use it.While all those solutions have some 
costs, maybe there is a possibility to change the structure and simplify all 
those lines of code.As I already said, my first idea was a function, 
register_superglobal, which you register it and access it in a local scope 
without using none of the examples I listed.Sara told me about superglobals and 
etc, but I suggested her about the possibility to change the idea a little. 
Here is the comment I describe 2 possible ideas:The perfect behavior should be 
(inside a function), if a variable
does not exist, try to access a global (without doing via $GLOBALS or
global). If it doesn’t exist in the second try, then throw a fatal
error. With this, you do not need to think in superglobal variable or
anything else. Maybe this suggestion is currently too much difficult to achieve.
The workaround can be done using normal variables. But, as I
mentioned before, when the statement uses a variable, it checks for the
local variables declarations hash table; the idea is different here… if
the variable does not exist in local, look in the hash table I
mentioned (which stores the subscribed variables to behavior like
superglobal) and, if found, grab the variable from the global variable
declarations hash table.
As you can see, there will be only one performance impact (in normal
variable), doing a hash table checking. You do not need to change
autoglobal or static variables. In an average system, the needed time
to do this checking will be an advantage than the currently best
approach (Registry). You lose in one side, but receive more in the
other.She agreed with my idea (That’s all doable, and with autoglobals being 
CVs now, it’s even doable
without too much performance impact on the global fetches themselves…), BUT 
she said I will have to convince engine team to accept this idea too. Also, she 
said that will be a too much added complexity for too little. I disagree with 
her, since currently there are much more processment retrieving one object from 
a Registry or using a global accessor than another compiler hash checking. The 
performance impact is almost irrelevant (cannot be measured) and the final 
solution is cleaner than all the others. If you look at real world large 
applications, you can experience these workarounds. And, as I checked with my 
contact list (around 600), it'll be a great improvement of PHP.Now I am leaving 
this suggestion to internals list, and I hope you look affectionately at 
it.Best regards,Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9166-6902
URL: http://blog.bisna.com
MSN: [EMAIL PROTECTED]
São Carlos - SP/Brazil
_
O Windows Live Spaces está aqui! Descubra como é fácil criar seu espaço na Web 
e sua rede amigos.
http://spaces.live.com/signup.aspx

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

[Brian Moon]

Well, this was a little hard to read, but, let me see if I understand 
one thing.  You would have PHP look in the local scope and then also in 
the global scope?  If so, I would never support that idea.  I remember 
an email from Rasmus about why PHP's scoping is the way it is. 
Something to do with chasing down a scope issue in a C app for days.


I wrote an extension to do this about 4 years ago.  I submitted it to 
the, then pear-dev list.


http://marc.theaimsgroup.com/?l=pear-devm=104534556711383w=2

It was not received well, so I did not pursue it.  To see all the 
replies look at 
http://marc.theaimsgroup.com/?l=pear-devw=2r=48s=New+PHP+extensionq=b 
and read the ones titled New PHP Extension.  MARC did not thread the 
discussion well.


My extension did not have a function, but required php.ini settings to 
declare the variable names.  It also required they start with and under 
score if I remember correctly.


Now the bad news.  The code was lost in a hard drive crash.  I am not 
sure it would work now though.  I am sure a lot has changed in 4 years.



Guilherme Blanco wrote:
Hello PHP maintainers,During this week, I spoke with Sara Golemon about the possibility to change one current behavior of PHP.My first suggestion, as you can see in my blog post: http://blog.bisna.com/archives/32#comments was a new function called register_superglobal.While talking with her, I found that it'll be easier to be implemented another thing.Currently, when we deal with objects and functions in a PHP application, to access most common variables, we have to do one of these things:function m() {global $DB; // ...}Another one:function m() {$DB = Database::getInstance();  // ...}Or:function m() {$DB = Registry::get(DB);  // ...}And finally... via Factory:function m() {$DB = Env::getDatabaseConnection();  // ...}We can also specify via runkit a superglobal variable (DB), and use it.While all those solutions have some costs, maybe there is a possibility to change the structure and simplify all those lines of code.As I already said, my first idea was a 

function, register_superglobal, which you register it and access it in a local scope 
without using none of the examples I listed.Sara told me about superglobals and etc, 
but I suggested her about the possibility to change the idea a little. Here is the 
comment I describe 2 possible ideas:The perfect behavior should be (inside a 
function), if a variable

does not exist, try to access a global (without doing via $GLOBALS or
global). If it doesn’t exist in the second try, then throw a fatal
error. With this, you do not need to think in superglobal variable or
anything else. Maybe this suggestion is currently too much difficult to achieve.
The workaround can be done using normal variables. But, as I
mentioned before, when the statement uses a variable, it checks for the
local variables declarations hash table; the idea is different here… if
the variable does not exist in local, look in the hash table I
mentioned (which stores the subscribed variables to behavior like
superglobal) and, if found, grab the variable from the global variable
declarations hash table.
As you can see, there will be only one performance impact (in normal
variable), doing a hash table checking. You do not need to change
autoglobal or static variables. In an average system, the needed time
to do this checking will be an advantage than the currently best
approach (Registry). You lose in one side, but receive more in the
other.She agreed with my idea (That’s all doable, and with autoglobals being 
CVs now, it’s even doable
without too much performance impact on the global fetches themselves…), BUT 
she said I will have to convince engine team to accept this idea too. Also, she said 
that will be a too much added complexity for too little. I disagree with her, since 
currently there are much more processment retrieving one object from a Registry or 
using a global accessor than another compiler hash checking. The performance impact 
is almost irrelevant (cannot be measured) and the final solution is cleaner than all 
the others. If you look at real world large applications, you can experience these 
workarounds. And, as I checked with my contact list (around 600), it'll be a great 
improvement of PHP.Now I am leaving this suggestion to internals list, and I hope 
you look affectionately at it.Best regards,Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9166-6902
URL: http://blog.bisna.com
MSN: [EMAIL PROTECTED]
São Carlos - SP/Brazil
_
O Windows Live Spaces está aqui! Descubra como é fácil criar seu espaço na Web 
e sua rede amigos.
http://spaces.live.com/signup.aspx


--

Brian Moon
-
http://dealnews.com/
It's good to be cheap =)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Suggestion: global variables being accessed in local scope

[Guilherme Blanco]

Brian,I am sorry about the message indentation... Seems PHP-Internals list does 
not like M$ Live(r) Mail! roflI wrote it carefully indented... =\I
read your extension messages, but you idea was different from mine.
What you suggested in that post is exactly what runkit does today.My
idea is a little bit different. If possible, the idea is something like
this (sorry, but my C skill are not so good and I'll write in Java):I extracted 
the source from a Krakatoa compiler I wrote (Krakatoa = C)...Currently, PHP 
tries to access a local variable usage/assignment with this (Compiler class 
scope):// Retrieve variable from local scopeVariable v = (Variable ) 
this.symbolTable.getInLocal( this.lexer.getStringValue() );if ( v == null ) {   
 // Variable does not exist in local scope, throw a fatal error.
this.error.show(FATAL ERROR: Undefined Variable  + 
this.lexer.getStringValue(), CompilerError.FATAL_ERROR);}The best approach that 
I suggested eliminates the need of global keyword and also the $GLOBALS 
autoglobal array.The source code I have to do what I suggest is this:// 
Retrieve variable from local scope
Variable v = (Variable ) this.symbolTable.getInLocal( 
this.lexer.getStringValue() );

if ( v == null ) {// Try to retrieve the variable from global scopev = 
(Variable ) this.symbolTable.getInGlobal( this.lexer.getStringValue() );
if ( v == null ) {// Variable does not exist in local nor in global 
scope, throw a fatal error.
this.error.show(FATAL ERROR: Undefined Variable  + 
this.lexer.getStringValue(), CompilerError.FATAL_ERROR);}
}As
you can see, the only change needed is in a throw-able error (Undefined
variable), which does a second look-up in the symbolTable.Doing
this, you do not need to use $GLOBALS nevermore! And also, global can
be extinct too, since the compiler recognizes the variable in global
scope alone.I know the PHP source is not well commented and
structured, but I think this is not an impossible change to be done,
and will bring a lot of benefits to all PHP developers.I wish God come here and 
make my message indented until it reaches the PHP-Internals list =DBest 
regards,Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9166-6902
URL: http://blog.bisna.com
MSN: [EMAIL PROTECTED]
São Carlos - SP/Brazil Date: Thu, 8 Feb 2007 12:07:23 -0600 From: [EMAIL 
PROTECTED] To: [EMAIL PROTECTED] CC: internals@lists.php.net Subject: Re: 
[PHP-DEV] Suggestion: global variables being accessed in local scope  Well, 
this was a little hard to read, but, let me see if I understand  one thing.  
You would have PHP look in the local scope and then also in  the global scope? 
 If so, I would never support that idea.  I remember  an email from Rasmus 
about why PHP's scoping is the way it is.  Something to do with chasing down a 
scope issue in a C app for days.  I wrote an extension to do this about 4 
years ago.  I submitted it to  the, then pear-dev list.  
http://marc.theaimsgroup.com/?l=pear-devm=104534556711383w=2  It was not 
received well, so I did not pursue it.  To see all the  replies look at  
http://marc.theaimsgroup.com/?l=pear-devw=2r=48s=New+PHP+extensionq=b  and 
read the ones titled New PHP Extension.  MARC did not thread the  discussion 
well.  My extension did not have a function, but required php.ini settings to 
 declare the variable names.  It also required they start with and under  
score if I remember correctly.  Now the bad news.  The code was lost in a 
hard drive crash.  I am not  sure it would work now though.  I am sure a lot 
has changed in 4 years.   Guilherme Blanco wrote:  Hello PHP 
maintainers,During this week, I spoke with Sara Golemon about the possibility 
to change one current behavior of PHP.My first suggestion, as you can see in my 
blog post: http://blog.bisna.com/archives/32#comments was a new function called 
register_superglobal.While talking with her, I found that it'll be easier to be 
implemented another thing.Currently, when we deal with objects and functions in 
a PHP application, to access most common variables, we have to do one of these 
things:function m() {global $DB; // ...}Another one:function m() {$DB = 
Database::getInstance();  // ...}Or:function m() {$DB = 
Registry::get(DB);  // ...}And finally... via Factory:function m() {$DB = 
Env::getDatabaseConnection();  // ...}We can also specify via runkit a 
superglobal variable (DB), and use it.While all those solutions have some 
costs, maybe there is a possibility to change the structure and simplify all 
those lines of code.As I already said, my first idea was a  function, 
register_superglobal, which you register it and access it in a local scope 
without using none of the examples I listed.Sara told me about superglobals and 
etc, but I suggested her about the possibility to change the idea a little. 
Here is the comment I describe 2 possible ideas:The perfect behavior should be 
(inside

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

[Christian Schneider]

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.



you can see, the only change needed is in a throw-able error (Undefined
variable), which does a second look-up in the symbolTable.Doing
this, you do not need to use $GLOBALS nevermore! And also, global can


You didn't grasp two of the major PHP features (not bugs!):
1. Every variable you access inside a function is local unless 
explicitely imported (through $GLOBALS, global or superglobals) from the 
global scope.
2. Accessing undefined variables is normal and not an error (not 
everybody agrees here but lots of people consider this a big plus).


Changing this would turn PHP into a completely different language so 
it's simply not going to happen. If you don't like these basic concepts 
it's probably a good idea to switch language.


Regards,
- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Guilherme Blanco]

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 function is local unless
explicitely imported (through $GLOBALS, global or superglobals) from the
global scope.
2. Accessing undefined variables is normal and not an error (not
everybody agrees here but lots of people consider this a big plus).

Changing this would turn PHP into a completely different language so
it's simply not going to happen. If you don't like these basic concepts
it's probably a good idea to switch language.


First of all, I sleep with PHP codes printed everyday... I can't live
without PHP =D Forget about your suggestion to switch the
language!

Exactly. And I also commented it in my blog (Maybe this suggestion is
currently too much difficult to achieve.)... this is a drastic
change!
I suggested a similar change, that does the same thing. My suggestion:

Implement a register_superglobal function, that add the variable in a
HashTable... something like this (remember... Compiler class scope):

function register_superglobal( $varName ) {
   global $$varName;

   $this-symbolTable-registered_superg-hash[ $varName ] = $$varName;
}


And then... in your variable retrieval (I wrote the code in PHP now...
you scared me about that language switch!)... instead of the current
implementation (I removed the fatal error, based on your comment:
Accessing undefined variables is normal and not an error):

// Retrieve variable from local scope
$v = $this-symbolTable-getInLocal( $this-lexer-getStringValue() );

if ( $v === null ) {
   // ...
}


To something like this:

// Retrieve variable from local scope
$v = $this-symbolTable-getInLocal( $this-lexer-getStringValue() );

if ( $v === null ) {
   // Try to retrieve the variable from registered superglobal hash
   $v = $this-symbolTable-registered_superg-hash[
$this-lexer-getStringValue() ];

   if ( $v === null ) {
   // ...
   }
}


As you can see... just a little change, and now I do not change the
whole PHP behavior!
And I enabled the possibility to add the function I suggested. The
performance impact is minimal (almost 0).

If you do not accept my idea, I'll understand. I am just trying to
help PHP to be a better and language and also help lots of PHP
developer like to make code easier to write. =)


Best regards,

--
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9166-6902
MSN: [EMAIL PROTECTED]
URL: http://blog.bisna.com
São Carlos - SP/Brazil

[PHP-DEV] Suggestion: If URL Loads Initially, then stop

[Ryan Hemelaar]

Hi there,

I don't know if this is the place to do it, but anyway. I have a suggestion 
for a new function that PHP could have:

It will be similar to fopen, but instead of actually loading the URL, it 
starts loading the page, then once PHP knows that it's started loading, it 
will stop it before it's finished; then it would set the variable in the 
function's brackets as true. eg: Functname($URL;$trueorfalse).

This could be used to check if a site is up without having to download the 
whole page.

Regards,


Ryan 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Suggestion: If URL Loads Initially, then stop

[David Zülke]

http://www.php.net/manual/en/function.get-headers.php

- David


 -Original Message-
 From: Ryan Hemelaar [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, April 13, 2005 2:55 PM
 To: internals@lists.php.net
 Subject: [PHP-DEV] Suggestion: If URL Loads Initially, then stop
 
 Hi there,
 
 I don't know if this is the place to do it, but anyway. I have a
 suggestion
 for a new function that PHP could have:
 
 It will be similar to fopen, but instead of actually loading the URL, it
 starts loading the page, then once PHP knows that it's started loading, it
 will stop it before it's finished; then it would set the variable in the
 function's brackets as true. eg: Functname($URL;$trueorfalse).
 
 This could be used to check if a site is up without having to download the
 whole page.
 
 Regards,
 
 
 Ryan
 
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Suggestion: If URL Loads Initially, then stop

[Xuefer]

use HEAD request

On 4/13/05, Ryan Hemelaar [EMAIL PROTECTED] wrote:
 Hi there,
 
 I don't know if this is the place to do it, but anyway. I have a suggestion
 for a new function that PHP could have:
 
 It will be similar to fopen, but instead of actually loading the URL, it
 starts loading the page, then once PHP knows that it's started loading, it
 will stop it before it's finished; then it would set the variable in the
 function's brackets as true. eg: Functname($URL;$trueorfalse).
 
 This could be used to check if a site is up without having to download the
 whole page.
 
 Regards,
 
 Ryan
 
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] suggestion: empty() with infinite parameters like isset()

[Ron Korving]

I'm not really anxcious to have an anyempty() function, but I do think
empty() should behalve like an allempty() just like isset() behaves like an
areallset(). I guess the weirdness is in the fact that isset() will give a
positive reply when something exists, while empty() gives a negative reply
when something exists. I guess this creates the confusion and would make the
allempty() functionality less likely to be used often. I guess people will
want to check more often if all their vars are set, and therefor an or
situation instead of and would be more suitable, because then you could
do: if (empty($var1, $var2, $var3)) echo there's an empty var;
I'd personally prefer the and situation, but it's a fact that this would
make it far less useful than the or. So I can see the confusion and the
reason to just stick with 1 parameter.

I guess there should just be a function like isset() which returns !empty().
Maybe it should be called isval() or something. Then it could be used for
several vars without confusion:
if (!isval($var1, $var2, $var3)) return there's an empty var;

This would make sense to everybody I think, because like isset() it would be
an and situation.

Ron


Jevon Wright [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
 How about anyempty($var1, $var2, $var3, ...) ?

 Jevon

 - Original Message - 
 From: Ron Korving [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Thursday, October 21, 2004 12:21 AM
 Subject: Re: [PHP-DEV] suggestion: empty() with infinite parameters like
 isset()


  Maybe it was a bad example. Writing data missing I was thinking that
at
  least one variable should be set.
 
  Ron
 
  Derick Rethans [EMAIL PROTECTED] schreef in bericht
  news:[EMAIL PROTECTED]
   On Wed, 20 Oct 2004, Ron Korving wrote:
  
Okay, I don't wanna make remarks that may have already been made
  earlier,
but I think it should be all should be empty, because it works
 exactly
  the
same for isset(), and apparently, a decision was made to give
isset()
  that
feature.
  
   Right, but then your example would already no longer have worked:
  
   if (empty($var1, $var2, $var3)) echo data missing;
  
   so there is no point in adding it like that.
  
   Derick
  
   -- 
   Derick Rethans
   http://derickrethans.nl | http://ez.no | http://xdebug.org
 
  -- 
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 
 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] suggestion: empty() with infinite parameters like isset()

[Ron Korving]

You're right, the only right way would be to introduce a new function like
the isval() I suggested in my reply to Jevon.

Ron

Andi Gutmans [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
 There is a big difference between isset() and empty() and it was discussed
 a lot in the past.
 You'll see both sides to the coin after reading the archives. It's really
a
 problem make a call on this one.

 Andi

 At 01:13 PM 10/20/2004 +0200, Ron Korving wrote:
 Okay, I don't wanna make remarks that may have already been made earlier,
 but I think it should be all should be empty, because it works exactly
the
 same for isset(), and apparently, a decision was made to give isset()
that
 feature.
 
 Ron
 
 
 Derick Rethans [EMAIL PROTECTED] schreef in bericht
 news:[EMAIL PROTECTED]
   On Wed, 20 Oct 2004, Ron Korving wrote:
  
I think it would be a good idea to apply the idea of infinite
parameters
that's been used with isset(), so one can test multiple variables:
   
if (empty($var1, $var2, $var3)) echo data missing;
  
   We discussed this before and we didn't want to agree if it should
behave
   like each one should be empty or all should be empty. So we will
not
   add it.
  
   Derick
  
   --
   Derick Rethans
   http://derickrethans.nl | http://ez.no | http://xdebug.org
 
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php