Re: [PHP-DEV] [RFC][DISCUSSION] Argon2 Password Hash
On Fri, 2016-08-05 at 07:47 -0500, Charles R. Portwood II wrote: > Hello Internals, > > Due to a couple issue with the original RFC's scope, the RFC for > introducing Argon2 as an alternative hashing algorithm for the > password_* > functions was closed shortly after starting on Monday. > > The following details were adjusted. and I would appreciate your > feedback > before re-opening the vote. > > - The RFC scope was reduced to only cover inclusion in 7.2. This > RFC no > longer proposes changes to PASSWORD_DEFAULT in 7.4. > - Argon2d is not suitable for password hashing, and has been > removed to > keep in line with the scope goals of the password_* functions. > - The configure flag was changed to --with-argon2 to > --with-password-argon2 to further clarify the scope of this RFC. > > Further rationale for these items is provided in the RFC itself. > > The RFC is available at: https://wiki.php.net/rfc/argon2_password_has > h. > > Thanks to those who emailed me directly to discuss the matter on > Monday, > and for your feedback on these changes. > > *Charles R. Portwood II* Argon2 also supports keyed hashes and associated data, but seen no mention of either. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New HashTable implementation?
On Thu, 2016-04-28 at 19:04 -0500, Matt Wilmas wrote: > Hi all, > > Last June, it was briefly mentioned about changing PHP's string hash > function [1] (DJB33 *seems* pretty horrible, after all, as far as > collisions...). So 8 months ago I tried almost, if not, a half-dozen > of > them (including Murmur3) that were simple enough to quickly toss in. > > The result? In all cases, I believe, fewer instructions (in > zend_hash_find, > and the hashing function), BUT also a slight-to-small increase in > cache > misses in Wordpress and other scripts... > > And in a test filling an array with a million "string_$i" keys (high > collision pattern for DJB33?), the speed was halved by the *huge* > cache miss > increase. :-/ > > I couldn't quite understand what was happening, where, if there were > fewer > collisions... Misses all spread out in the hash-array? > > So there didn't seem to be anything useful to gain there. > > > Now, after seeing Bogdan's hash optimization idea last month [2], and > reading Nikita's blog post again, I had some ideas I'd like to try -- > assuming nobody else is planning major changes. :-) Besides Nikita, > I'm > addressing Dmitry and Xinchen because your names are on some minor > hash > items on the 7.1 ideas wiki [4]. > > I'm thinking of a Robin Hood implementation with Universal hashing > [5] (of > int keys and the string hashes). I haven't touched any code yet, but > think > I've worked out all the details in my head, and am ready to take a > stab at > it. I think it's fairly simple to get the basics working; and when I > see > how that goes, I can do the additional optimizations I have in mind > that it > allows (including reduced memory, on 64-bit at least). > > Question: Can I use zval.u1.v.reserved ? I guess I'll find out > otherwise. > :-O > > > The string hash function itself is really a separate thing [6], but > fasthash > [7] (not to be confused with "superfast") looks like a good one that > I > missed before... After thinking about things, I think we could even > keep/use a 64-bit hash on 32-bit arch. > > > Well, just wanted to mention it first if anyone has a comment. :- > ) Should > be interesting, but no idea how it'll perform (lookups should be > very, very > fast (upsizing also); but cache factors and inserts/deletes are > wildcards). > Wish me luck!? > > > Thanks, > Matt > > [1] https://marc.info/?l=php-internals=143444845304138=2 > [2] https://marc.info/?t=14574424811=1=2 > [4] https://wiki.php.net/php-7.1-ideas > [5] https://en.wikipedia.org/wiki/Universal_hashing > [6] https://github.com/rurban/smhasher > [7] https://github.com/rurban/smhasher/blob/master/doc/fasthash64 > > Have you taken a look a go's internal hashing function? On platforms supporting AES-NI they use the AESENC instruction to get a fast hash, but with also some protection against collision attacks. https://github.com/golang/go/blob/0104a31b8fbcbe52728a08867b26415d282c3 5d2/src/runtime/asm_amd64.s#L870 Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Discussion] Parser extension API
On Wed, 2015-02-18 at 16:17 +0100, Nikita Popov wrote:
On Wed, Feb 18, 2015 at 4:06 PM, Cesar Rodas ce...@rodas.me wrote:
On 18/02/15 15:59, Nikita Popov wrote:
On Wed, Feb 18, 2015 at 7:22 AM, Dmitry Stogov dmi...@zend.com wrote:
Hi,
On Tue, Feb 17, 2015 at 2:46 PM, Alexander Lisachenko
lisachenko...@gmail.com wrote:
Hello, internals!
I want to introduce a RFC for providing a userland API for accessing an
Abstract Syntax Tree of the source code and to provide userland parser
hooks for source code modification:
https://wiki.php.net/rfc/parser-extension-api
Thanks!
The first part, describing https://github.com/nikic/php-ast , looks
fine.
I see no problems including this extension into PHP-7.0 core
distribution.
May be even making it required (like ext/reflection).
Nikita, what do you think?
The second part looks very interesting, however it has some uncovered
questions.
- API for AST modification
- AST validation (someone may insert break node in parameter-list).
If you have enough experience, I would suggest you to try writing an
external extension that would implement this idea.
If you'll need some modification in PHP core (e.g adding callbacks), we
may consider including them in PHP-7.0.
Thanks. Dmitry.
I agree with Dmitry.
Exporting the AST to userland in PHP 7.0 would be nice. With Dmitry's
work
on assertions we even have a pretty printer for it, which allows us to
convert the AST back to PHP code.
In this matter, how would it be? It'd be awesome if function expects an
AST tree object instead of a value:
function doQuery($table, *$where) {
$where = convert_ast_toSqlWhere($where);
}
doQuery(foobar, $col1 = something AND $col2 == $col3);
Or at least `ast(expr)`, although both would be nice to have.
The problem here is that in most cases we do not actually know what
function will be called at compile time. A very simple example would be to
replace doQuery() with $db-query() and already we don't know what it is
that we're actually calling and whether or not it needs an AST. However
this does not apply to just methods, it's an issue with nearly all calls.
As such PHP cannot know at compile time whether it should issue a normal
call with evaluated arguments or whether it needs to preserve the AST and
pass that. Just keeping the AST around for all calls would be too expensive
(it's a pretty big memory hog).
So rather than having this as a modifier in the function signature, it
would have to be a modifier in the call syntax. E.g. rust uses foo!()
syntax for macros.
Nikita
Wouldn't the trick be to have $col1 be an object instance that uses
operator overloading? So instead of solving the expression, operators
would return the AST.
Was possible with the operator extension
Some old experimental code from 2006
echo query($connection,
array($catalog-Person-id, $catalog-Titles-title. ' ' .
$catalog-Person-name),
new SqlJoin(SqlJoin::TYPE_INNER,
$catalog-Person,
$catalog-Titles,
$catalog-Person-titleId == $catalog-Titles-id),
$catalog-Person-id == 1);
outputs
SELECT Person.id, Titles.title || ' ' || Person.name FROM Person INNER
JOIN Titles ON Person.titleId = Titles.id WHERE Person.id = 1
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] __init magic method
-Original Message-
From: Pete Boere [mailto:p...@the-echoplex.net]
Sent: 22 January 2013 12:30
To: internals@lists.php.net
Subject: [PHP-DEV] __init magic method
Has there ever been any discussion on an __init magic method
for bootstraping static properties on class load?
The usual solution I come up with is manually calling an init
method post class definition, which works, though I'd call it
slighly less than elegant:
class Foo {
static $bar;
static function init () {
// Create $bar with expressions...
self::$bar = $bar;
}
}
Foo:init();
A custom autoloader could of course anticipate this but with
systems like composer that have a shared autoload, it'd be
nicer to use those than rely on a custom loader.
I'd say, that using static at all isn't elegant. There is always a way
to avoid it.
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Arrays which have properties of sets
-Original Message- From: Rasmus Schultz [mailto:ras...@mindplay.dk] Sent: 07 October 2012 02:10 To: internals@lists.php.net Subject: [PHP-DEV] Re: Arrays which have properties of sets First off, let me say - as you pointed out, when the values are unique, they are best represented as keys... however, this of course applies only to value-types, which isn't the problem, and not why I started this conversation in the first place. Objects don't work as keys. And objects do not always have a value that you can use as keys. See SPL's SplObjectStorage. That allows object instances as keys. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Foreach list behaviour
Hi, Just looking at the foreach list behaviour and it does this... $i = [1, 2, 3]; foreach($i as list($a, $b)) var_dump($a, $b); Outputs NULL NULL NULL NULL NULL NULL There is no test I can see covering this, so cannot tell if its expected. To me, $i does not meet the expected format, so should be some sort of error happening. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [VOTE] Generators
-Original Message-
From: Nikita Popov [mailto:nikita@gmail.com]
Sent: 25 August 2012 17:11
To: PHP internals
Subject: [PHP-DEV] [VOTE] Generators
Hi internals!
I think the generators RFC has been discussed thoroughly
enough by now, so I opened the vote:
https://wiki.php.net/rfc/generators#vote
Thanks,
Nikita
Hi,
Just discovered another seg fault.
When iterating over a generator that returns references twice it
causes a seg fault.
function bind(array $keys, array $row)
{
foreach($keys as $key)
yield $key = $row[$key];
}
$row = [];
$it = bind(['a', 'b'], $row);
foreach($it as $key = $ref)
echo $key;
echo \n;
foreach($it as $key = $ref)
echo $key;
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [VOTE] Generators
-Original Message-
From: Hannes Magnusson [mailto:hannes.magnus...@gmail.com]
Sent: 29 August 2012 22:50
To: Derick Rethans
Cc: Nikita Popov; Jared Williams; PHP internals
Subject: Re: [PHP-DEV] [VOTE] Generators
On Wed, Aug 29, 2012 at 10:19 PM, Derick Rethans
der...@php.net wrote:
On Wed, 29 Aug 2012, Nikita Popov wrote:
On Wed, Aug 29, 2012 at 10:10 PM, Derick Rethans
der...@php.net wrote:
On Wed, 29 Aug 2012, Nikita Popov wrote:
function bind(array $keys, array $row) {
foreach($keys as $key)
yield $key = $row[$key]; }
$row = [];
$it = bind(['a', 'b'], $row);
foreach($it as $key = $ref)
echo $key;
echo \n;
foreach($it as $key = $ref)
echo $key;
Thanks, this is now fixed. It'll throw an exception now,
saying
that you can't traverse an already closed generator.
Nothing in the core throws an exception, why would this?!
To my knowledge all iterator-related functionality is supposed to
throw exceptions (as it is a feature related to the object
oriented
part of PHP). At leas this is what a quick search of the code
base
gave me. (See
http://lxr.php.net/xref/PHP_TRUNK/ext/spl/spl_dllist.c#1248
for example).
ext/spl - SPL is not *core* language. The generators are. Don't
throw exceptions from core features!
In general I agree with core language features shouldn't be
throwing exceptions...
But SPL definitely should never have been its own extension
and most of it should have been core language features - and
throwing exceptions in many of those cases makes perfect sense.
We also have the case of IteratorAggregate throwing exception
(which is a *core* language feature, not defined in ext/spl):
$ ./sapi/cli/php -r 'class foo implements IteratorAggregate {
function
getIterator() { return new stdclass; } } foreach(new foo as $bar)
{}'
Fatal error: Uncaught exception 'Exception' with message
'Objects returned by foo::getIterator() must be traversable
or implement interface Iterator' in Command line code:1 Stack trace:
#0 Command line code(1): unknown()
#1 {main}
thrown in Command line code on line 1
Speaking of IteratorAggregates and spl.
I think there should be some discussion about what can be done to get
the spl iterators to handle references.
For instance, you cannot use CachingIterator on a reference yielding
generator.
And think the only method you can get it to work, feels rather kludgy.
class CachingGeneratorIterator implements IteratorAggregate
{
private $it;
function __construct(Generator $it)
{
$this-it = $it;
}
function getIterator()
{
$previousKey = null;
foreach($this-it as $key = $ref) {
if ($previousKey !== null)
yield $previousKey = $previousRef;
$previousKey = $key;
$previousRef = $ref;
}
if ($previousKey !== null)
yield $previousKey = $previousRef;
}
function hasNext() { return $this-it-valid(); }
}
Limitations are that you have to use foreach() rather than current()
to retrieve yielded references, because you can't implement an
iterator with a method signature of current().
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Generators
-Original Message-
From: Nikita Popov [mailto:nikita@gmail.com]
Sent: 20 August 2012 14:12
To: Ángel González
Cc: Rasmus Lerdorf; Stas Malyshev; Derick Rethans; PHP internals
Subject: Re: [PHP-DEV] [RFC] Generators
On Mon, Aug 20, 2012 at 1:56 PM, Ángel González
keis...@gmail.com wrote:
On 20/08/12 02:01, Rasmus Lerdorf wrote:
I would still like to understand what this generator keyword
would
actually do. I don't see how it would work. Would a
function marked
generator somehow not be allowed to return normally or to
finish and
not return anything? How could this be enforced? I am completely
against any keyword that is essentially documentation-only.
-Rasmus
Given that such function could return several times, seems a
different enough function type to have its keyword.
The method signature defines the API, so the caller knows what to
use.
Can we agree on that? In this case it makes absolutely no
difference to the caller whether the function is implemented
using a generator, or whether it returns a custom Iterator
object. The generator
keyword wouldn't document the API, it would document an
implementation-detail.
What would *actually* make sense here are return value typehints.
E.g.
one could have something like `public Iterator getIterator() { ...
}`.
This would provide the caller with information on what the
function returns, but would leave out the implementation
detail that the Iterator was implemented using a generator.
Or, if the generator implementation is actually important
(because it is used as a
coroutine) one could also explicitly typehint against it:
`public Generator getCoroutine() { ... }`.
Yes. Quick example...
interface A
{
function gen();
}
class AImplementation implements A
{
function gen()
{
for($i = 0; $i 10; ++$i)
yield $i;
}
}
class ADecorator implements A
{
private $a;
function __construct(A $a)
{
$this-a = $a;
}
function gen()
{
return $this-a-gen();
}
}
$a = new ADecorator(new AImplementation());
foreach($a-gen() as $v)
echo $v, \n;
Obviously, AImplementation::gen() is a generator, but
ADecorator::gen() isn't, but would want both to adhere to the same
interface.
So only return type hinting makes sense.
But return-value type hints are not directly related to generators.
They are a more general concept. If that's what all of you
want, then I'd recommend opening up a new thread for it.
You could not decorate it and rely instead on the presence of the
yield keyword, but parsers will thank knowing about it from
the start
rather than realising at mid-parsing that the function is a
completely
different beast.
No, parsers don't care about this. It's trivial to detect in
both cases.
Nikita
--
PHP Internals - PHP Runtime Development Mailing List To
unsubscribe, visit: http://www.php.net/unsub.php
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Generators
-Original Message-
From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
Sent: 20 August 2012 00:08
To: Derick Rethans
Cc: Nikita Popov; PHP internals
Subject: Re: [PHP-DEV] [RFC] Generators
Hi!
I am against this. This is even more magic in PHP. Is it
really that
difficult to have to mark the function with a different
keyword, such
as
generator:
You have a point here, but public static final generator
function foo() sounds a bit long-winded to me... Also, we'd
have then to decide which function can be marked generator
and which can't (e.g., interface probably can't, abstract
probably can't, anonymous probably can, etc.) which adds more
complexity.
That'd be return type hinting would it not?
Given that generator functions currently return an instance of class
Generator.
Also anonymous generators would be quite strange
$f = Generator function() { yield 'a'; };
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Generators
-Original Message-
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
Sent: 13 August 2012 03:49
To: Brian Moon
Cc: Nikita Popov; PHP internals
Subject: Re: [PHP-DEV] [RFC] Generators
Brian,
On Sun, Aug 12, 2012 at 4:08 PM, Brian Moon
br...@moonspot.net wrote:
Hi Nikita,
I admit, I have ignored these threads as there was no RFC.
So, some of
this may have been covered.
There was an RFC in those posts... It was just being iterated over.
Do you have a good example usage other than a file? I don't find
fopen/fgets/fclose all that complicated. What are the other
valid use
cases for such a thing?
Here's a quick set of examples:
http://blog.ircmaxell.com/2012/07/what-generators-can-do-for-you.html
Also, not allowing rewinding is unintuitive for something
that is an
iterator in PHP. If I can foreach() it and I can call
next() on it, I
expect to be able to reset() it as well. IMO, you would
need to issue
a FATAL PHP error if that simply is not allowed. Or you
have to have a
second syntax for what to do in that case. At that point, you are
implementing Iterator.
I partially agree. rewinding the generator might be possible,
but it's hard to tell in those cases. It's hard to tell if
resetting it is even possible from the code level. So I'm
pretty much OK with living with that restriction for the time
being...
While I am glad that PHP has borrowed syntax from many languages,
I
find the yield keyword to be very WTF when I first saw it.
It is also
poorly explained in your RFC. You use terms like sending and
receiving. That does not say returns from function
execution to me.
I had to basically figure it out from the code examples.
It's absolutely something that takes getting used to. But
it's also quite intuitive once you think about it. You're not
returning back to the parent scope (exiting your scope),
you're yielding a value to the parent scope, expecting to
continue on later (think of it as a stop light where you let
the other code run for a while until you go to the next one).
Lastly, because you cite needing this for sending data to
PHPUnit, I
think this is a user land problem and not a core problem.
In about 5
minutes I implemented a reusable Generator object that does
exactly what you need.
http://pastebin.com/V336rEpR At least, it does what your
examples show
you need. Again, file IO is very easy and perhaps that example
does
not explain your true need very well.
Well, there's one thing that should be made clear. There's
nothing (and I mean that) that generators provide that you
can't do already. You can build iterators that do exactly the
same thing.
Not true. Iterator::current() cannot return references, but generators
can yield them.
Eg
function map(array $row, array $order)
{
foreach($order as $index)
yield $row[$index];
}
foreach(map($row, [1,3,5,7,9]) as $ref)
Anthony
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Generators in PHP
-Original Message-
From: Nikita Popov [mailto:nikita@gmail.com]
Sent: 22 July 2012 16:53
To: Jared Williams
Cc: Nikita Popov; PHP internals
Subject: Re: [PHP-DEV] Re: Generators in PHP
On Sat, Jul 21, 2012 at 6:31 PM, Jared Williams
jared.willia...@ntlworld.com wrote:
Can't yield a reference to an array item directly.
Eg.
function map(array $row)
{
yield $row[0];
}
Thanks, this is fixed now.
Also seems to be a problem with iterating
foreach(map($row) as $value)
cannot be done without a fatal error
$i = map($row);
foreach($i as $value)
however works.
This was an old foreach restriction that never really made
sense and makes even less sense once generators are in. So I
dropped it. Now everything can be iterated by-reference.
Seems relatively easy to trigger a infinite loop atm.
Typo'd a SQL table name which caused an exception within
PDO inside a
generator function, which then caused an infinite loop.
I forgot to rethrow the exception in the foreach scope.
Should be fixed now.
Thanks for your feedback!
No problem.
Though here is seemingly another problem, though it could be within
spl's MultipleIterator()
function a()
{
yield 'a';
yield 'aa';
}
function b()
{
yield 'b';
yield 'bb';
}
$m = new MultipleIterator();
$m-attachIterator(a());
$m-attachIterator(b());
foreach($m as $v)
{
list($a, $b) = $v;
var_dump($a, $b);
}
causes a seg fault, whereas the vanilla array version
$m = new MultipleIterator();
$m-attachIterator(new ArrayIterator(['a', 'aa']));
$m-attachIterator(new ArrayIterator(['b', 'bb']));
foreach($m as $v)
{
list($a, $b) = $v;
var_dump($a, $b);
}
works fine.
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Generators in PHP
-Original Message-
From: Nikita Popov [mailto:nikita@gmail.com]
Sent: 20 July 2012 21:46
To: Nikita Popov
Cc: PHP internals
Subject: [PHP-DEV] Re: Generators in PHP
On Tue, Jun 5, 2012 at 7:35 PM, Nikita Popov
nikita@googlemail.com wrote:
Hi internals!
In the last few days I've created a proof of concept
implementation
for generators in PHP. It's not yet complete, but the basic
functionality is there:
https://github.com/nikic/php-src/tree/addGeneratorsSupport
The implementation is outlined in the RFC-stub here:
https://wiki.php.net/rfc/generators
A small progress update on this:
* There now is support for yield by reference
Can't yield a reference to an array item directly.
Eg.
function map(array $row)
{
yield $row[0];
}
Also seems to be a problem with iterating
foreach(map($row) as $value)
cannot be done without a fatal error
$i = map($row);
foreach($i as $value)
however works.
* Generators are now automatically detected by the presence of
yield
instead of requiring the * modifier.
The main open point I still have is whether or not generators
should have a throw() method (á la Python). I couldn't yet
find a convincing use case for it, so I'm considering to just
leave it out.
Seems relatively easy to trigger a infinite loop atm.
Typo'd a SQL table name which caused an exception within PDO inside a
generator function, which then caused an infinite loop.
If there is any further feedback on the proposal, I'd love to
hear it :)
Nikita
--
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] Internal iteration API
-Original Message-
From: Nikita Popov [mailto:nikita@gmail.com]
Sent: 11 July 2012 23:17
To: PHP internals
Subject: [PHP-DEV] Internal iteration API
Hi internals!
Currently PHP does not have an internal iteration API that
supports both arrays and Traversable objects. Because of that
it is currently not really possible to write functions (or
language features) that work on arbitrary traversables.
That's probably also the reason why function like array_sum()
currently work only on arrays and arrays only.
So I'd really like to have such an API. One idea for an
implementation would be this:
* Create a zend_create_iterator_from_zval() function, which
returns a zend_object_iterator
* For arrays and plain objects this would create a thin
wrapper around the zend_hash_* iteration functions
* For objects defining get_iterator this would just return
the object_iterator that get_iterator returned
* Usage:
zend_object_iterator *iter =
zend_create_iterator_from_zval(zval);
if (iter-rewind) iter-rewind(iter);
while (iter-valid(iter)) {
zval **value;
iter-get_current_data(iter, value);
// do something
iter-move_forward(iter);
}
iter-dtor(iter);
I like this approach because it reuses the existing
zend_object_iterator API. But I see that this is rather an
abuse than a use :)
Thoughts?
Nikita
I presume this would work with list() too?
function *f()
{
yield 'a';
yield 'b';
}
list($a, $b) = f();
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] List comprehensions and generator expressions for PHP
-Original Message-
From: Nikita Popov [mailto:nikita@gmail.com]
Sent: 28 June 2012 11:49
To: PHP internals
Subject: [PHP-DEV] List comprehensions and generator
expressions for PHP
Hi internals!
Python and several other languages include support for list
comprehensions and generator expressions and I'd like to see
something
similar in PHP too.
I created a hacky proof of concept implementation here:
https://github.com/nikic/php-src/tree/addListComprehensions. It's
really dirty, but it implements both features in about ~150 lines of
code.
Currently I'm using the following syntax:
$firstNames = [foreach ($users as $user) yield
$user-firstName];
This code is roughly equivalent to writing:
$firstNames = [];
foreach ($users as $user) {
$firstNames[] = $user-firstName;
}
You may notice that this particular list comprehension provides the
same functionality as array_column(), just in a little more
generalized way. E.g. you could use all of the following without
having special functions for them all:
$firstNames = [foreach ($users as $user) yield
$user-firstName];
$firstNames = [foreach ($users as $user) yield
$user-getFirstName()];
$firstNames = [foreach ($users as $user) yield
$user['firstName']];
It's also possible to explicitly specify a key:
$firstNames = [foreach ($users as $user) yield $user-id =
$user-firstName];
It is also possible to filter elements using list comprehensions:
$underageUsers = [foreach ($users as $user) if ($user-age 18)
yield $user];
// or just the names
$underageUserNames = [foreach ($users as $user) if ($user-age
18) yield $user-firstName];
It is also possible to nest multiple foreach loops:
$aList = ['A', 'B'];
$bList = [1, 2];
$combinations = [foreach ($aList as $a) foreach ($bList as $b)
yield [$a, $b]];
// gives: [ ['A', 1], ['A', 2], ['B', 1], ['B', 2] ]
All the above are list comprehensions (or in PHP rather array
comprehensions), i.e. they create an array as the result.
If this is not needed it is also possible to compute the values
lazily
using generator expressions, which use () instead of [].
$firstNames = (foreach ($users as $user) yield
$user-firstName);
In this case $firstNames will no longer be an array of first names,
but instead will be a generator producing first names.
This is handy if you only need to iterate the resulting list only
once as it saves you holding the whole list in memory.
Also it allows you to work with infinite lists easily:
function *naturalNumbers() {
for ($i = 0; ; ++$i) {
yield $i;
}
}
// all natural numbers
$numbers = naturalNumbers();
// only the odd ones
$oddNumbers = (foreach ($numbers as $n) if ($n % 2) yield $n);
// ...
(At this point I wonder whether one should include support for
for-loops in list comprehensions. So the naturalNumbers() function
could be replaced with (for ($i = 0;; ++$i) yield $i), etc)
So, what do you think? Do we want something like this in PHP?
No mention of yielding keys in the comprehensions. Presume that would
work?
I would definitely like to see generators in, the amount of
boilerplate
code required for the current Iterator interface is not nice.
Also have been playing with your addGeneratorsSupport branch, trying
to see
If can get any benefits from using asynchronous operations.
The simplest example I could think of using Memcached
(assuming libmemcached fetch() does return as soon as it recieves an
item)
Eg.
function *getMulti(Memcached $memcached, array $keys)
{
if ($memcached-getDelayed($keys)) {
while ($item = $memcached-fetch())
yield $item['key'] = $item['value'];
}
}
foreach(getMulti($memcached, ['foo', 'bar', ... ]) as $key = $value)
{
doSomeWork();
}
So doSomeWork would be called as soon as a single value is available,
rather
than having to wait til all values have returned.
Should in theory work right?
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] fclose(), file_put_contents(), copy() all fail to return false on error
Raised this 5 years ago.. http://marc.info/?l=php-internalsm=113998880315574w=2 Jared -Original Message- From: Tom Boutell [mailto:t...@punkave.com] Sent: 21 October 2011 20:40 To: PHP Internals Subject: [PHP-DEV] fclose(), file_put_contents(), copy() all fail to return false on error It appears that all three of these functions do not return false on error as they should if the stream is not flushed successfully. Yipes! https://bugs.php.net/bug.php?id=60110 Am I missing something here? It's especially bad with, say, an S3 stream wrapper that wants to write the whole thing as one HTTP request, but it could bite you with plain old files too. -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- 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] Activation of IGBinary serialization extension in 5.4 by default
-Original Message- From: Paul Dragoonis [mailto:dragoo...@gmail.com] Sent: 18 August 2011 12:12 To: PHP Internals List Subject: [PHP-DEV] Activation of IGBinary serialization extension in 5.4 by default Hey guys, After a brief discussion with Pierre I'm taking this discussion to here. We have the igbinary pecl extension available [1], however not many of our userbase are familiar that it even exists. Here [2] is the performance boost we get from using igbinary with serialize() and unserialize(). Here we get a great perf boost, and what's more excellent as we don't have to break BC to get there! This seems like a no-brainer and a good investment in the speed increase of PHP by default for the future users of the platform. [1] http://pecl.php.net/package/igbinary [2] http://www.php.net/~pierre/vcqa/apcigninary_perf.png Comments please. Regards, Paul Dragoonis. I think MsgPack ( http://msgpack.org/ ) is a better option, as it is implementated in multiple languages. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Make set_time_limit() timeout a catchable fatal error
Hi, Would pcntl_alarm() work? Jared -Original Message- From: Sebastian Bergmann [mailto:sebast...@php.net] Sent: 08 March 2011 13:06 To: internals@lists.php.net Subject: [PHP-DEV] Make set_time_limit() timeout a catchable fatal error Could set_time_limit() be changed in such a way that it triggers a catchable fatal error instead of a fatal error? Thanks! -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- 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] rfc2616 datetime format?
-Original Message- From: Derick Rethans [mailto:der...@php.net] Sent: 04 October 2010 09:55 To: Stas Malyshev Cc: PHP Internals Subject: Re: [PHP-DEV] rfc2616 datetime format? On Sun, 3 Oct 2010, Stas Malyshev wrote: The reason is that in order to format a DateTime object as GMT, it needs to be converted to GMT... and you can't simply do that with just a constant consisting of a string of format characters. I see what you mean and it makes sense, having constant may imply that you can use it with any date and get proper result... But RFC2616 is the one of the most used formats on the Web - actually, the format that is called COOKIE is not the one that should be used in cookies - RFC2616 should be used instead. COOKIE one uses T, which may or may not be GMT, depending on the date and local system settings. Maybe we should have proper RFC format too, accompanied with appropriate warning that you should use it with GMT dates (or gmdate())? Well, gmdate() is only part of it; the same constants are also used for the DateTime object (which is preferred over timestamps anyway). The problem lays exactly there because we can't just convert the timezone of an object just for formatting. I wanted to prevent adding just a format letter for the whole format as well (which would partially solve it), but we're almost out of letters. Adding a format letter that forces GMT means we would need to loop over the whole format string twice, making things highly more complicated. It is a tricky one, and let's think about whether we can come up with something useful here. cheers, Derick Surely makes better sense to create a function/method for it specifically, rather than adding new formatting letters? Python has something like time.httpdate() Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] [PATCH] New PDO methods for PostgreSQL driver
-Original Message- From: Stanley Sufficool [mailto:ssuffic...@gmail.com] Sent: 13 June 2010 20:10 To: Ilia Alshanetsky Cc: Pierre Joye; Denis Gasparin; Matteo Beccati; internals@lists.php.net; pdo Subject: Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] [PATCH] New PDO methods for PostgreSQL driver On Sat, Jun 12, 2010 at 4:54 AM, Ilia Alshanetsky i...@prohost.org wrote: The concerns you raised about custom methods specific to database drivers were not reflective of the PDO's intent as was clarified by Wez and myself. The code that was introduced was specific to PostgreSQL, the common functionality was introduced in a way that allows each driver to implement. Yet the rest of the copyFrom, copyTo, etc.. could have ben generic as well. I specifically stated that this could be done at the driver level for FreeTDS using the BCP extensions and/or using BULK INSERT . Yet now this is a specific pgsql*** interface that cannot be abstracted for other drivers OR implemented at the driver level. Now if I want a MSSQL / Sybase dump/load method, I need to preface it with dblibCopyFrom, dblibCopyTo. IMHO, every function should be a generic named interface to the driver or statement level and then throw a not implemented if the driver does not support it. This will allow for abstraction at a higher level and give the driver developers an opportunity to implement it. It will also give PDO users a more structured way to deal with unsupported methods with try/catch. I know I am a noob to the PDO development process, however I have used OO for quite awhile and I have never seen it DB abstractions implemented like this. But a complete nonsense for a PDO driver maintainer. If adds one function to a driver, then you have to had add an function to all the rest. A generic copyFrom or copyTo method should only be added when there is enough PDO drivers that behave in exactly the same manner, and to do that, you needed specific implementations to test and compare with. If the dblib methods can't behave the same as the postgres methods, then clearly they shouldn't be named the same. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Type hinting
-Original Message- From: Zeev Suraski [mailto:z...@zend.com] Sent: 09 June 2010 15:17 To: Daniel Convissor Cc: PHP Internals List Subject: Re: [PHP-DEV] Type hinting At 02:59 09/06/2010, Daniel Convissor wrote: Hi Lukas: On Fri, Jun 04, 2010 at 08:28:12AM +0200, Lukas Kahwe Smith wrote: Same deal as E_NOTICE. Either you care about them or you dont. Exactly. The type hinting situation is unique. It is something that applications will frequently want to handle gracefully in order to provide useful error messages. A new error level is needed, as is an API / function to obtain the failed parameter names, desired type and passed type. Daniel, I think having E_TYPE (or whatever), a non-fatal notice that can be either ignored or handled separately from everything else makes sense. I think we may actually want to introduce it at the most basic levels of PHP, so that whenever data loss occurs (except for explicit casts) - an E_TYPE warning will be generated. That will bring consistency between the new type hinting and the rest of PHP. Thoughts? Dmitry prepared a patch that implements auto-converting type hinting with silent data loss. If we combine it with an infrastructure-level E_TYPE upon data loss - I think we have a pretty good solution overall. The patch is available at http://wiki.php.net/rfc/typecheckingstrictandweakhttp://wiki .php.net/rfc/typecheckingstrictandweak Is E_TYPE good enough? If it follows the other E_*, I'd suggest it's not. Just having a single string error message describing the error, and having to unmangle the detailed information* from that doesn't seem that great. * Which parameter, what value, what was expected. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/trunk/ NEWS ext/json/json.c ext/json/php_json.h ext/json/tests/serialize.phpt
-Original Message-
From: Hannes Magnusson [mailto:hannes.magnus...@gmail.com]
Sent: 15 May 2010 13:25
To: Jared Williams
Cc: Johannes Schlüter; Pierre Joye; Stanislav Malyshev; Sara
Golemon; PHP Internals
Subject: Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/trunk/
NEWS ext/json/json.c ext/json/php_json.h
ext/json/tests/serialize.phpt
2010/5/14 Jared Williams jared.willia...@ntlworld.com:
$a = new A();
echo $a-toJSONString(), \n;
$b = new B();
echo $b-toJSONString(), \n;
$array = array(new A,new B,);
// Does not use your toJSONString method echo json_encode($array);
Hi,
Without using traits, and the current implementation...
class A implements JSONSerializable
{
public $a = 1;
protected $d = 2;
private $c = 3;
// have to implement this in every class
function jsonSerialize()
{
return get_object_vars($this);
}
}
With using traits, don't have to provide an implementation
of jsonSerialize() unless want to customise the behaviour,
but the current implementation will require having to
implement JSONSerializable.
trait Json
{
function toJSONString() { return
json_encode($this-jsonSerialize()); }
function jsonSerialize() { return get_object_vars($this); }
}
class A implements JSONSerializable
{
use Json;
public $a = 1;
protected $d = 2;
private $c = 3;
}
class B implements JSONSerializable
{
use Json;
public $a = 1;
protected $d = 2;
private $c = 3;
function jsonSerialize()
{
return array('a' = $this-a, 'd' = 4);
}
}
$r = new array(new A(), new B(), );
echo json_encode($r), \n;
But the JSONSerialiable interface doesn't really provide no
benefits over the trait, imo, so it could be eliminated
leaving...
trait Json
{
function toJSONString() { return
json_encode($this-jsonSerialize()); }
function jsonSerialize() { return get_object_vars($this); }
}
class A
{
use Json;
public $a = 1;
protected $d = 2;
private $c = 3;
}
class B
{
use Json;
public $a = 1;
protected $d = 2;
private $c = 3;
function jsonSerialize()
{
return array('a' = $this-a, 'd' = 4);
}
}
$r = new array(new A(), new B(), );
echo json_encode($r), \n;
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/trunk/ NEWS ext/json/json.c ext/json/php_json.h ext/json/tests/serialize.phpt
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: 12 May 2010 11:33
To: Stanislav Malyshev
Cc: Sara Golemon; PHP Internals
Subject: Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/trunk/
NEWS ext/json/json.c ext/json/php_json.h
ext/json/tests/serialize.phpt
hi!
On Wed, May 12, 2010 at 4:25 AM, Stanislav Malyshev
s...@zend.com wrote:
Hi!
Add JSON_Serializable interface
Objects implementing JSON_Serializable will have their
-jsonSerialize() method called
Similar to serialize() and __sleep()
Why should we have special mechanism for JSON? I.e., now we
have one
for serialize(), separate one for json, then we'd have separate
one
for storing object as XML or YAML, etc. etc. IMHO it's not
a very good
design - having separate method for every format of data
storage. Why
can't we just use whatever serialize() would see and wrap
it in JSON after that?
Serialize is a different thing but Json seems to be standard
enough to justify a __toJson method. In any case, using _ in
classes name is a no go, as we decided a while back. We can
call JsonSerializable if we keep the interface instead of
moving this feature to __toJson (which I prefer).
Cheers,
--
Pierre
Hi,
Keep thinking with what is in php.next that interfaces seem
overkill?
Doesn't
trait JSON
{
function toJSONString()
{
return json_encode(get_object_vars($this));
}
}
class A
{
use JSON;
public $a = 1;
protected $b = 2;
private $c = 3;
}
$a = new A();
echo $a-toJSONString(), \n;
Make better sense?
Don't have to implement any interfaces, yet I still have freedom to
override it either in a differing trait or in the class.
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/trunk/ NEWS ext/json/json.c ext/json/php_json.h ext/json/tests/serialize.phpt
-Original Message-
From: Johannes Schlüter [mailto:johan...@schlueters.de]
Sent: 13 May 2010 20:47
To: Jared Williams
Cc: 'Pierre Joye'; 'Stanislav Malyshev'; 'Sara Golemon'; 'PHP
Internals'
Subject: RE: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/trunk/
NEWS ext/json/json.c ext/json/php_json.h
ext/json/tests/serialize.phpt
On Thu, 2010-05-13 at 20:27 +0100, Jared Williams wrote:
Hi,
Keep thinking with what is in php.next that interfaces
seem overkill?
Doesn't
trait JSON
{
function toJSONString()
{
return json_encode(get_object_vars($this));
}
}
class A
{
use JSON;
public $a = 1;
protected $b = 2;
private $c = 3;
}
No. The goal is to allow json_encode($foo); to do what makes
sense in the case. You might re-use the implementation by
implementing it using traits, but tha's a different problem
than what this interface solves.
johannes
Still not seeing the point of the interface.
?php
trait Json
{
function toJSONString()
{
return json_encode($this-jsonSerialize());
}
protected function jsonSerialize()
{
return get_object_vars($this);
}
}
class A
{
use Json;
public $a = 1;
protected $b = 2;
private $c = 3;
}
class B
{
use Json;
public $a = 1;
protected $b = 2;
private $c = 3;
protected function jsonSerialize()
{
return array('a' = $this-a, 'd' = 4);
}
}
$a = new A();
echo $a-toJSONString(), \n;
$b = new B();
echo $b-toJSONString(), \n;
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] What is the use of the $replacement property in the RegexIterator class.
-Original Message- From: Richard Quadling [mailto:rquadl...@googlemail.com] Sent: 05 May 2010 17:26 To: PHP internals; PHP Documentation List Subject: [PHP-DEV] What is the use of the $replacement property in the RegexIterator class. Hi. I'm in the process of getting the PHPDoc classes showing the correct inherited properties and methods (public/protected but not private). I picked RecursiveRegexIterator (it has the largest number of xi:includes in the documentation) as a test. Using php --rc I see that the inheritance chain is RecursiveRegexIterator, RegexIterator, FilterIterator and IteratorIterator. The property $replacement is part of RegexIterator. I can see no documentation for this in phpdoc, nor in the Doxygen at http://www.php.net/~helly/php/ext/spl/ In all the examples I've made so far, var_dump()-ing the RegexIterator results in a [replacement]=NULL Assigning a value to $replacement seems to have no bearing on the output. Regards, Richard. Does seem odd public property. Guessing it's a bug. http://www.php.net/~helly/classbrowser/?class=RecursiveRegexIterator Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Performance improvements
Hi
Wondering if there is any plans to for new serialization
method?
One of the things that igbinary does is store strings only
once, and now that the engine supports string interning natively,
seems that serialization and deserialization could benefit.
Though I guess igbinary could be patched to take advantage of
string interning?
-Jared
-Original Message-
From: Dmitry Stogov [mailto:dmi...@zend.com]
Sent: 13 April 2010 14:53
To: internals@lists.php.net
Subject: [PHP-DEV] [RFC] Performance improvements
Hi,
I've published all the patches, their description and
performance evaluation at
http://wiki.php.net/rfc/performanceimprovements
In two words the patches give 0-20% improvement even on
real-life applications.
I'm going to commit them into trunk in a week in case of no
objections.
Of course, they are binary incompatible. Some extensions
(especially VM depended e.g. APC, xdebug, etc) will have to
be modified to support the changes.
Thanks. Dmitry.
Zeev Suraski wrote:
Hi,
Over the last few weeks we've been working on several ideas
we had for
performance enhancements. We've managed to make some good
progress.
Our initial tests show roughly 10% speed improvement on real world
apps. On pure OO code we're seeing as much as 25% improvement (!)
While this still is a work in progress (and not production quality
code
yet) we want to get feedback sooner rather than later. The diff
(available at http://bit.ly/aDPTmv) applies cleanly to
trunk. We'd be
happy for people to try it out and send comments.
What does it contain?
1) Constant operands have been moved from being embedded within
the
opcodes into a separate literal table. In additional to the zval
it
contains pre-calculated hash values for string literals. As
result PHP
uses less memory and doesn't have to recalculate hash values for
constants at run-time.
2) Lazy HashTable buckets allocation - we now only allocate the
buckets array when we actually insert data into the hash
for the first time.
This saves both memory and time as many hash tables do not have
any
data in them.
3) Interned strings (see
http://en.wikipedia.org/wiki/String_interninghttp://en.wikip
edia.org/wiki/String_interning).
Most strings known at compile-time are allocated in a
single copy with
some additional information (pre-calculated hash value,
etc.). We try
to make most incarnations of a given string point to that
same single
version, allowing us to save memory, but more importantly - run
comparisons by comparing pointers instead of comparing strings and
avoid redundant hash value calculations.
A couple of notes:
a. Not all of the strings are interned - which means that if a
pointer comparison fails, we still go through a string comparison;
But if it succeeds - it's good enough.
b. We'd need to add support for this in the bytecode
caches. We'd be
happy to work with the various bytecode cache teams to guide how
to
implement support so that you do not have to intern on each
request.
To get a better feel for what interning actually does, consider
the
following examples:
// Lookup for $arr will not calculate a hash value, and will only
require a pointer comparison in most cases // Lookup for
foo in $arr
will not calculate a hash value, and will only require a pointer
comparison // The string foo will not have to be
allocated as a key
in the Bucket // blah when assigned doesn't have to be
duplicated
$arr[foo] = blah;
$a = b;
if ($a == b) { // pointer comparison only
...
}
Comments welcome!
Zeev
Patch available at: http://bit.ly/aDPTmv
--
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] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_2/NEWS branches/PHP_5_2/ext/filter/logical_filters.c branches/PHP_5_3/NEWS branches/PHP_5_3/ext/filter/logical_filters.c trunk/ext/filter/
-Original Message-
From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
Sent: 03 April 2010 02:44
To: Jared Williams
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/
branches/PHP_5_2/NEWS
branches/PHP_5_2/ext/filter/logical_filters.c
branches/PHP_5_3/NEWS
branches/PHP_5_3/ext/filter/logical_filters.c
trunk/ext/filter/logical_filters.c
On 04/02/2010 06:25 PM, Jared Williams wrote:
-Original Message-
From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
Sent: 03 April 2010 01:20
To: Jared Williams
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/
branches/PHP_5_2/NEWS
branches/PHP_5_2/ext/filter/logical_filters.c
branches/PHP_5_3/NEWS
branches/PHP_5_3/ext/filter/logical_filters.c
trunk/ext/filter/logical_filters.c
On 04/02/2010 04:47 PM, Jared Williams wrote:
Would make sense. Especially considering HTML5's current
validation
rules of emails is something different again.
http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-
the-type-attribute.html#e-mail-state
Having a mismatch in validation between client server
just a recipe
for user frustration.
I actually think this regex is really close to the HTML5
specification.
The main thing it drops are comments and folded
whitespace, both of
which are not supported in this regex either.
That means addresses like the following will all fail even though
they are technically valid:
test
b...@example.com
(with a carriage return after test there)
(hey)rasmus(there)@(go)php.net(woo)
rasmus(Hey
guess what
this is a valid
email address)
@php.net
rasmus.ras...@php.net@php.net
As far as I am concerned I am perfectly ok with rejecting
addresses
like these and I think we should just stick to the
HTML5 definition.
The ABNF for an HTML5 valid email field is:
1*( atext / . ) @ ldh-str 1*( . ldh-str )
which means there must be a . in the domain part, so HTML5
doesn't
think a...@b is valid either. The left-hand side looks wrong
though.
It seems to me it should be:
1*atext *(. 1*atext)
You can't have a trailing . there. rasm...@php.net is not
valid and
if I am reading that HTML5 ABNF correctly it would seem to allow
that.
Interesting, missed the point of the . when initially
looked at this,
Here's the regexp current in webkit
38 static const char emailPattern[] =
39 [a-z0-9!#$%'*+/=?^_`{|}~.-]+ // local part
40 @
41 [a-z0-9-]+(\\.[a-z0-9-]+)+; // domain part
(http://trac.webkit.org/browser/trunk/WebCore/html/ValidityState.cpp)
I am all for disallowing esoteric otherwise valid addresses,
but this trivial regex will allow all sorts of completely
invalid addresses that will never actually route. Some
examples of invalid addresses that passes that regex:
ras...@php.123
ras...@-php.net
ras...@php-.net
ras...@php.net-
.ras...@php.net
rasm...@php.net
rasmus..lerd...@php.net
@php.net
ras...@128.128.128.128
That last one needs to be ras...@[128.128.128.128] to be valid.
It appears the HTML5 spec still allows the pattern attribute on a
input type=email
And seems implemented that way in webkit
http://trac.webkit.org/browser/trunk/WebCore/html/HTMLInputElement.cpp
#L231
So can specify a more restrictive regexp for emails.
Eg...
input type=email
pattern=[-a-zA-Z0-9!#$%\'*+/=?^_`{|}~]+(\.[-a-zA-Z0-9!#$%\'*+/=?^_`
{|}~]+)*...@[a-za-z0-9]+(\.[a-zA-Z0-9]+)+
Or whatever the pattern will be.
Just thinking if might be good to have filter extension expose a HTML5
case insensitive regexp/pattern to PHP, so could insert it into forms,
and not have to worry about it.
Jared
PS, though need to check how the multiple attribute interacts with
pattern validation, input type=email name=list multiple / sends
a comma separated list of email addresses.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php and multithreading (additional arguments)
-Original Message- From: Ferenc Kovacs [mailto:tyr...@gmail.com] Sent: 02 April 2010 08:40 To: Lester Caine Cc: PHP internals Subject: Re: [PHP-DEV] php and multithreading (additional arguments) On Fri, Apr 2, 2010 at 9:30 AM, Lester Caine les...@lsces.co.uk wrote: Jille Timmermans wrote: Op 2-4-2010 7:16, Andi Gutmans schreef I think that if we were ever to implement threading we would be best off to enable spawning worker threads that have their own context with no shared data (and therefore no requirement for locking). We could then have a message passing API between the threads. Advantages: - Real multi-threading. - Simple straightforward approach which doesn't require a comp. sci. degree to use correctly. - Very stable implementation. That sounds like I want threading; because it sounds cool!. What are the advantages of this above multi-process? The systemcall-overhead for message passing? Actually Andi's outline forms a nice simple base for something practical. It simply builds on the 'background' threading required to run asynchronous operations while not creating a unmanageable mess. But I still can't see any need to go beyond perhaps asynchronous SQL queries. Or asynchronous exec, or asynchronous(or at least timout aware) gethostbyaddr, see: http://bugs.php.net/bug.php?id=51306 So any task, that require waiting on external resource could be executed in paralel. http://hu2.php.net/manual/en/mysqli.reap-async-query.php its a good thing, that you can async mysql execution with mysqlnd. Tyrael Curl can execute in parallel with it's curl_multi_*() functions. MemCached can retrieve multiple keys with MemCached::getDelayed*(). The problem is can't mix operations*, and have a single wait on them all. *Unless you completely rewrite the various protocols in PHP. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_2/NEWS branches/PHP_5_2/ext/filter/logical_filters.c branches/PHP_5_3/NEWS branches/PHP_5_3/ext/filter/logical_filters.c trunk/ext/filter/
-Original Message- From: Ferenc Kovacs [mailto:tyr...@gmail.com] Sent: 02 April 2010 23:09 To: Rasmus Lerdorf Cc: Sean Coates; internals@lists.php.net Subject: Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_2/NEWS branches/PHP_5_2/ext/filter/logical_filters.c branches/PHP_5_3/NEWS branches/PHP_5_3/ext/filter/logical_filters.c trunk/ext/filter/logical_filters.c Why not define multiple filters? I did that solution with more than one framework. There are cases when you need to validate the email of your remote users (eg. you want to restrict j...@localhost), and there are some cases, when you want to go all the way: validate the email by format, check the domain for existance, check the MX, and there are cases when you have to handle local addresses as well, but provide some minimal validation for typos. Would make sense. Especially considering HTML5's current validation rules of emails is something different again. http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of- the-type-attribute.html#e-mail-state Having a mismatch in validation between client server just a recipe for user frustration. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_2/NEWS branches/PHP_5_2/ext/filter/logical_filters.c branches/PHP_5_3/NEWS branches/PHP_5_3/ext/filter/logical_filters.c trunk/ext/filter/
-Original Message-
From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
Sent: 03 April 2010 01:20
To: Jared Williams
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/
branches/PHP_5_2/NEWS
branches/PHP_5_2/ext/filter/logical_filters.c
branches/PHP_5_3/NEWS
branches/PHP_5_3/ext/filter/logical_filters.c
trunk/ext/filter/logical_filters.c
On 04/02/2010 04:47 PM, Jared Williams wrote:
Would make sense. Especially considering HTML5's current
validation
rules of emails is something different again.
http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-
the-type-attribute.html#e-mail-state
Having a mismatch in validation between client server
just a recipe
for user frustration.
I actually think this regex is really close to the HTML5
specification.
The main thing it drops are comments and folded whitespace,
both of which are not supported in this regex either.
That means addresses like the following will all fail even
though they are technically valid:
test
b...@example.com
(with a carriage return after test there)
(hey)rasmus(there)@(go)php.net(woo)
rasmus(Hey
guess what
this is a valid
email address)
@php.net
rasmus.ras...@php.net@php.net
As far as I am concerned I am perfectly ok with rejecting
addresses like these and I think we should just stick to the
HTML5 definition.
The ABNF for an HTML5 valid email field is:
1*( atext / . ) @ ldh-str 1*( . ldh-str )
which means there must be a . in the domain part, so HTML5
doesn't think a...@b is valid either. The left-hand side looks
wrong though. It seems to me it should be:
1*atext *(. 1*atext)
You can't have a trailing . there. rasm...@php.net is not
valid and if I am reading that HTML5 ABNF correctly it would
seem to allow that.
Interesting, missed the point of the . when initially looked at this,
Here's the regexp current in webkit
38 static const char emailPattern[] =
39 [a-z0-9!#$%'*+/=?^_`{|}~.-]+ // local part
40 @
41 [a-z0-9-]+(\\.[a-z0-9-]+)+; // domain part
(http://trac.webkit.org/browser/trunk/WebCore/html/ValidityState.cpp)
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] array_seek function
-Original Message- From: Felix De Vliegher [mailto:felix.devlieg...@gmail.com] Sent: 16 March 2010 13:31 To: PHP internals Subject: [PHP-DEV] array_seek function Hi all I recently needed seek functionality in arrays, and couldn't find it in the regular set of array functions, so I wrote a function for it. (Seek = getting an array value based on the position (or offset, if you want to call it like that), and not the key of the item) Basically you can use it like this: $input = array(3, 'bar', 'baz'); echo array_seek($input, 2); // returns 'baz' echo array_seek($input, 0); // returns 3 echo array_seek($input, 5); // returns NULL, emits an out of range warning Remember doing something like this in the past... $input = array(3, 'bar', 'baz'); $iterator = new ArrayIterator($input); $iterator-seek(2); echo $iterator-current(); $iterator-seek(0); echo $iterator-current(); $iterator-seek(5); // throws OutOfBoundsException Though a specific function does make sense, imo. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Intl extension class MessageFormatter instantiation returns NULL
-Original Message-
From: Chris Stockton [mailto:chrisstockto...@gmail.com]
Sent: 09 December 2009 20:39
To: PHP Developers Mailing List
Subject: [PHP-DEV] Intl extension class MessageFormatter
instantiation returns NULL
Hello,
I am trying to use ChoiceFormat in the Intl extension. When I
try to do something like:
$r = new MessageFormatter(en, There are {0?are no files|1?is one
file|1are many files} ok);
// $r is NULL
This may be a incorrect use, but my thought is that
regardless null should not be returned because no error code
or error message can be returned. I also can not think of a
single case off the top of my head when new does not return a
object (aside from a exception being thrown on instantiation).
I am struggling to find documentation on plural usage. There
is no ChoiceFormatter class so it is my assumption that
message formatter parses that format. I would very much
appreciate if someone was able to point me in the right
direction. My apologies if this may have been better suited
on PECL list, but subscribing appears down and I am hastily
in search for a answer.
-Chris
Try...
$fmt = MessageFormatter::create('en_GB', 'There are {0,choice,0#are no
files|1#is one file|1are many files} ok');
echo $fmt-format(array(0)), \n;
echo $fmt-format(array(1)), \n;
echo $fmt-format(array(10101)), \n;
Best place for documentation is tests, or example code I find.
http://userguide.icu-project.org/formatparse/messages/examples
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC: Custom Factories (SPL)
-Original Message- From: Robert Lemke [mailto:rob...@typo3.org] Sent: 18 November 2009 16:07 To: internals@lists.php.net Subject: [PHP-DEV] RFC: Custom Factories (SPL) Hi folks, after discussing the idea with various PHP developers I now felt safe enough that it's not a completely stupid idea to post an RFC for it. The idea is to add support the registration of custom factories which are responsible for instantiating certain classes. Here is the first draft of my RFC: http://wiki.php.net/rfc/customfactories I suggest that we first discuss the implications and usefulness of this feature. In a second step I'd need to find some skilled internals wizard who can implement it, because not being a C developer myself, all I can offer is making suggestions and fine coffee. Looking forward to hearing your comments! Robert -- Robert Lemke Fluent Code Artisan Whilst I am a fan of IoC, I don't think its desirable to add language features just to make legacy code more flexible. Surely the route to take is to refactor the legacy code as and when the extra flexibility is needed. Also seems like a possible whole heap of wtf?! When a seemingly absolute statement $a = new A(); gets mangled behind the scenes. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] reference caller object
-Original Message- From: Stan Vassilev [mailto:sv_for...@fmethod.com] Sent: 19 September 2009 11:33 To: troels knak-nielsen; Ford, Mike Cc: internals@lists.php.net Subject: Re: [PHP-DEV] reference caller object I, for one, am quite happy that it's fairly complicated and convoluted to get the caller of a method, since it could lead to some seriously incomprehensible code in the hands of someone who don't know what they are doing. Requiring the user to use the backtrace is a clear warning sign, and I think that's a good thing. What is the basis for all this. When someone says a feature is ugly and it leading to seriously incomprehensible code, I'd really like this is explained and supported by evidence somehow, than just thrown around without facts. Most OOP languages expose the caller in some fashion. You'll be hard at work to see in which of them it led to masses of convoluted code. It is considered a code smell, using instanceof in conditionals. http://c2.com/cgi/wiki?InstanceofInConditionals And should be refactored with... http://c2.com/cgi/wiki?ReplaceConditionalWithPolymorphism Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] The constant use of isset()
-Original Message-
From: Ólafur Waage [mailto:olaf...@gmail.com]
Sent: 12 May 2009 17:35
To: internals@lists.php.net
Subject: [PHP-DEV] The constant use of isset()
While researching for this suggestion I found this rfc
proposal regarding
ifsetor() (
http://wiki.php.net/rfc/ifsetor?s[]=issethttp://wiki.php.net/
rfc/ifsetor?s%5B%5D=isset)
and it's rejection point was that it was currently not possible (
http://marc.info/?l=php-internalsm=108931281901389w=2 )
But would it be possible to check for a value of a variable
if it is set?
Since I often do (and see others do)
if(isset($_GET[foo]) $_GET[foo] == bar) or even worse
if((isset($_GET[foo]) $_GET[foo] == bar) ||
(isset($_GET[baz]) $_GET[baz] == bat))
to be able to do something like this
if(isset($_GET[foo]) == bar)
or
if(isset($_GET[foo]) == bar || isset($_GET[baz]) == bat)
That isset (or some other language construct) would return
the variable if it were set and false if it was not.
Thanks for your time, i know this has probably been talked to
death in one form or other.
Ólafur Waage
olaf...@gmail.com
Use array_merge to provide default values...
$get = array_merge($_GET, array('foo' = 'bar', 'baz' = 'bat));
If ($get['foo'] == 'bar' || $get['baz'] == 'bat')
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Win32 PECL pre-built binaries.
-Original Message- From: Richard Quadling [mailto:rquadl...@googlemail.com] Sent: 29 April 2009 11:33 To: PHP internals; php-windows Subject: [PHP-DEV] Re: Win32 PECL pre-built binaries. 2009/4/29 Richard Quadling rquadl...@googlemail.com: Hi. What are the plans for providing pre-built Win32 PECL extensions. I've been waiting for http://pecl4win.php.net to become active again. I understand that each extension has to be built MANY times (VC6/VC9, ts/nts, PHP5.0/PHP5.1/PHP5.2/PHP5.3/PHP6.0, etc.) so this is a LOT of effort (20 builds per extension, 40 if debug builds are also performed), but something like this was available a long time ago (http://web.archive.org/web/20071029164203/http://pecl4win.php.net/) Regards, Richard Quadling. -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! And this is what happens when I don't read the phpdoc commits before asking questions! So what was it? Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] json_encode()
-Original Message- From: mike [mailto:mike...@gmail.com] Sent: 15 December 2008 18:10 To: Rasmus Lerdorf Cc: PHP Developers Mailing List Subject: Re: [PHP-DEV] json_encode() On Mon, Dec 15, 2008 at 9:50 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: 1. Document the fact that if you want to strictly conform to the JSON spec and be sure your json_encode output will work in various JSON parsers, you have to pass it a PHP array or object. Instead of json_encode(34) the suggestion would be json_encode(array(34)) ? Seems kind of like a lame thing to require. IMHO the language should do the right thing as far as the consumer (javascript/JSON parser) is concerned. However, Douglas is infinitely more educated than I am here. This is just my $0.02 as a PHP user. Don't think that's what he said... More like... assert(is_object($foo) || is_array($foo)); // ensure strictly conforming $json = json_encode($foo); Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Upgrading to internal DateTime
-Original Message- From: Lester Caine [mailto:[EMAIL PROTECTED] Sent: 05 December 2008 06:24 To: internals@lists.php.net Subject: [PHP-DEV] Upgrading to internal DateTime OK I spent yesterday working trough some of the idiosyncrasies of DateTime and having had a sleep I've finished off this morning. First question. Why are there two different formats for dates with date creation using one format and everything else using strftime formatting? ( Slipping a date through DateTime and returning it DATE_W3C seems to be adding the correct daylight saving details so far and allowing ADOdb date to work ) Second question. What is the current situation on translating dates? I've tried several ways of using setlocale, but at present I've not been able to get anything other than English out of the code. Intl extension has classes/methods for translating dates. http://www.php.net/manual/en/class.intldateformatter.php . Third question In order to get things working I've ended up with date_default_timezone_set() and haven't needed to use DateTimeZone at all ( other than to get a list for the user to select from ). Internally we are working UTC normalized, and then displaying with the user offset if they select 'local'. IS the correct thing to be setting the default for each user? I suspect yes since previous code has always had to fight the server time setting changing things. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] alpha3 or forever hold your peace
-Original Message- From: Lester Caine [mailto:[EMAIL PROTECTED] Sent: 10 November 2008 08:23 To: PHP internals Subject: Re: [PHP-DEV] alpha3 or forever hold your peace Lukas Kahwe Smith wrote: I just wanted to ask everybody to skim over the changes for PHP 5.3 we have in CVS (especially bigger stuff like the addition/removal of an extension etc.). Please bring up any areas you are concerned about that we might have forgotten. However I am not interested in people bringing up a debate again on namespace syntax or resolution orders (I hope to have the final behavior in CVS ASAP). This is just an attempt to ensure we do not forget something. There is still the problems with windows builds of PHP5.3. I've not been able to test anything on new builds since php_interbase is not being compiled. I've not checked what the other dozen or so extensions missing compared with PHP5.2.x are - which is running fine. APC is another missing extension. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] alpha3 or forever hold your peace
But where? pecl4win.php.net hasn't compiled APC since January, and certainly nothing for 5.3 And can't see anything on windows.php.net containing APC compiled for 5.3 Jared -Original Message- From: Lester Caine [mailto:[EMAIL PROTECTED] Sent: 10 November 2008 12:32 To: PHP internals Subject: Re: [PHP-DEV] alpha3 or forever hold your peace Jared Williams wrote: APC is another missing extension. apc is in pecl - so would be provided with the PECL binary. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- 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] alpha3 or forever hold your peace
-Original Message- From: Pierre Joye [mailto:[EMAIL PROTECTED] Sent: 10 November 2008 15:46 To: Jared Williams Cc: Lester Caine; PHP internals Subject: Re: [PHP-DEV] alpha3 or forever hold your peace On Mon, Nov 10, 2008 at 4:43 PM, Jared Williams [EMAIL PROTECTED] wrote: But where? pecl4win.php.net hasn't compiled APC since January, and certainly nothing for 5.3 pecl4win is dead and will not be restored anymore. In the next weeks, pecl.php.net will provide the DLLs based on releases instead of random snapshots, for each active branches (5.2, 5.3 and HEAD). Cheers, thanks. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Iteration tools
Marcus Boerger [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hello Ionut, some remarks about your proposal: 1) You can turn any array into a Traversable using (Recursive)ArrayIterator. Though this solution is still slow. The issue is that the c-level code needs to verify the current pointer every single time it uses it and that means traversing the array from the beginning. That said we might want to: a) Optimize that for cases where we don't have to. Basically when nothing else is pointing to the array (refcount==1) we know when the array can be changed and do not have to verify it always. b) provide a lower level array to traversable mechanism that operates on the current pointer provided by the array itself. That way having no need to verify that pointer at all. That would be nice. Just written some code todo a binary search on keys, using the ArrayIterator::seek(). It was either that or use array_keys() on potentially large array. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] New string functions: str_startswith() and str_endswith()
Surely substr_compare() does both begin end easily enough. Though the fact that it throws warnings is annoying. Jared -Original Message- From: Stan Vassilev | FM [mailto:[EMAIL PROTECTED] Sent: 21 July 2008 13:18 To: internals Subject: Re: [PHP-DEV] New string functions: str_startswith() and str_endswith() Hi, ucfirst() isn't solving a pain point either. But we use it all the time (I do at least). I'm particularly for begins/endswith() function as I do this all over my code and I'd appreciate the simplification and free extra performance. Regards, Stan Vassilev I agree that many existing functions can be implemented with a combination of others, but in this case it is really just one call. The strlen() call is almost free, and in many cases you wouldn't even use it. If you are looking for .php files, for example: if(str_endswith($path,'.php')) vs. if(substr($path,-4)=='.php')) I just don't see that this is solving any real painpoint. -Rasmus Stan Vassilev | FM wrote: Hi, Actually starts with and ends with is a very common case. I see your concerns, but I can see instantly quite a lot of places in my code where I'd use those. And I bet it'll be faster too. Many of the string functions can be replicated with one-liners using other string functions, same for array functions. I still think a very common case should be addressed natively. Regards, Stan Vassilev For the start of the string: substr($haystack,0,strlen($needle)) == $needle And for the end of the string: substr($haystack,-strlen($needle)) == $needle For case-insensitivity, just strtolower both. Writing built-in functions for something that can be done with trivial one-liners isn't something we typically do. -Rasmus Lars Strojny wrote: Hi Martin, first of all, thanks for you work! A few comments below. Am Samstag, den 19.07.2008, 14:55 +0200 schrieb Martin Jansen: Attached you'll find a patch against PHP_5_3 that implements two new string functions: str_startswith(haystack, needle [, case_sensitivity]) That's in my opinion too easy to solve with strpos($haystack, $needle) === 0. checks if haystack starts with needle. The check is performed case-insensitively, but this can be overridden by passing TRUE as the value for the third parameter. The second function str_endswith(haystack, needle [, case_sensitivity]) [...] Suffix checking is indeed a bit harder. But I'm not sure if we should introduce a function for every special case. Suffix verification often is about verifying file extensions. That could be easily solved with pathinfo() (and to make that easier, it would be more helpful to allow the engine to directly access returned arrays like pathinfo($file)['extension']). The other thing I would love to see is something I really love in Ruby: you have various ways to work with substrings[1]. For example you can do foobar[-3,3] == bar to check the suffix. That's in my opinion much easier and flexible. So -1 from me for the new string functions, but +1 for niftier variants to work with offsets. [1] http://pleac.sourceforge.net/pleac_ruby/strings.html cu, Lars -- 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 -- 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] Re: Short syntax for array literals [...]
-Original Message- From: Brian Moon [mailto:[EMAIL PROTECTED] Sent: 28 May 2008 16:21 To: Antony Dovgal Cc: Sebastian Deutsch; internals@lists.php.net Subject: Re: [PHP-DEV] Re: Short syntax for array literals [...] Antony Dovgal wrote: On 28.05.2008 02:58, Sebastian Deutsch wrote: fyi - i added a RFC http://wiki.php.net/rfc/shortsyntaxforarrays please add your votes You do understand that you will not be able to use this syntax in your products for at least next 5 years without rising min required PHP version to the latest one, right? That makes it even more useless. Right, so the sooner the better. =) -- I'm sure there are going to be PHP6 or later applications as soon as 6 is deemed production quality, and I suspect that may happen well (atleast hope) within the next 5 years. So makes the won't be able to use argument kind of pointless, anyway. If you want backwards compatibility there is or will be a whole raft things that you cannot use, like namespaces for instance. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] APC doesn't work on Windows?
-Original Message- From: Edward Z. Yang [mailto:[EMAIL PROTECTED] Sent: 23 May 2008 20:23 To: internals@lists.php.net Subject: [PHP-DEV] APC doesn't work on Windows? I don't really care either way, but if it's a well known fact, might as well stop trying. Does APC work on Windows? I recently submitted a patch to fix the snaps.php.net compilation of APC, but for any non-trivial script (interestingly enough, apc.php and and phpinfo() work fine), APC segfaults or otherwise fatally errors. Some errors I've seen include: [apc-error] Cannot redeclare class simpletest, referer: http://localhost/ on code that works perfectly without APC. I've scanned the bug list and there are quite a few reports of APC not working on Windows--so, is this generally known to be the case? -- I'm running php 5.2.5 NTS with APC 3.1.0-dev. It works, but not without some issues, like occasionally get a FastCGI process crashing which I suspect is APC. More worringly, have a tiny application which consistantly executes the wrong page, when APC is enabled. The index.php opens a frameset, with the left frame requesting browser.php, but instead the output of index.php is sent. Disable APC and the problem goes away. Haven't been enable to write a failing test case to report it. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Unable to unit test code containing *_uploaded_file()
-Original Message- From: Piotr Czachur [mailto:[EMAIL PROTECTED] Sent: 23 April 2008 12:36 To: internals@lists.php.net Subject: [PHP-DEV] Unable to unit test code containing *_uploaded_file() Hello! I use PHPUnit for unit testing of my application (but this issue is independent of PHPUnit). Tests are run from command line so it's not way (that I can imagine) to simulate file upload, because app code uses is_uploaded_file() to check if file was really uploaded. In my opionion some functions for simulation of file upload in command line script would be very handy for unit testing. What I mean is adding a function or a set of functions for setting file upload, for example: do_file_upload( upload_params, upload data). This function would be for use only in testing code, so there would be no need to change existing application code to add unit tests, and what's more important it would not leak to security risk. Regards, Piotr Czachur As of 1.0.1, SimpleTest's WebTester can upload files, I believe. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] short_open_tag
-Original Message- From: Stanislav Malyshev [mailto:[EMAIL PROTECTED] Sent: 26 March 2008 20:28 To: Lukas Kahwe Smith Cc: Derick Rethans; Marcus Boerger; Hannes Magnusson; PHP Internals Subject: Re: [PHP-DEV] short_open_tag Hi! do note that we have increasingly large numbers of way to jump out of the scope (exceptions, recoverable errors). this obviously makes these kinds of cleanups potentially easier to forget. You'd need to catch and process exceptions anyway, and recoverable errors, as far as I understand, are not meant as jumping out of scope (you can run the handler, but the you're back to where the error was, right?). However, exceptions are a good point - actually, the first good objection to this thing. Need to think if this can be solved easily. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- You use a class constructor to change the ini setting, and the destructor to revert it back. That way once the instance is out of scope the change will be automatically reverted? Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] short_open_tag
-Original Message-
From: Stefan Walk [mailto:[EMAIL PROTECTED]
Sent: 23 March 2008 11:08
To: Jared Williams
Cc: 'PHP Internals'
Subject: Re: [PHP-DEV] short_open_tag
Jared Williams schrieb:
ul
? foreach ($items as $item): ?
li?=htmlspecialchars($item)?/li
? endforeach ?
/ul
Well, it's the same as the but i can't validate my php
source with xmllint folks: You're doing it at the wrong
point. Escaping should happen at the point where you assign
the var as a temlate var (in my small template class:
$tpl-assign('items', $some_data) will escape all leaves in
the data $some_data). This way you don't have to type it
everytime, you don't have to read it everytime and - best of
all - you can't forget to do it, so introducing a XSS
vulnerability is much less likely.
Regards,
Stefan
A lot of people don't use templates, just raw PHP. So having a short tag
escaping would decrease XSS vulnerabilities.
I don't understand why need to essentially duplicate all the variables just
to provide proper escaping.
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] short_open_tag
-Original Message- From: Stefan Walk [mailto:[EMAIL PROTECTED] Sent: 22 March 2008 22:52 To: 'PHP Internals' Subject: Re: [PHP-DEV] short_open_tag Johannes Schlüter schrieb: Now we have the big issue: Do we want to have short open tags forever? Well, without tooo much thinking my idea would be to drop ? but keep ?=, ?= shouldn't conflict with ?xml tags in the same file, but make it simple to do templating using PHP, on the other hand when not echo'ing stuff you already have to write more soo the four additional characters (php ) don't matter that much - especially every decent editor/ide should be able to give you a completion on that, if you want. ul ? foreach ($items as $item): ? li?=$item?/li ? endforeach ? /ul The problem I have with ?= is it doesnt really help simplify templating. You end up still having to explicitly encode the output with htmlspecialchars() or whatever. ul ? foreach ($items as $item): ? li?=htmlspecialchars($item)?/li ? endforeach ? /ul So ?= ends up not really that much of an improvement over ?php echo htmlspecialchars($item); ? imo. J -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [Patch] http_fopen_wrapper.c and allowing any response code w/o warning
Yes, had fun with trying to use http php streams ... Imo, 2xx status codes
should always be considered succesful.
http://bugs.php.net/bug.php?id=36947
http://marc.info/?l=php-internalsm=111384113712112w=2
J
-Original Message-
From: David Zülke [mailto:[EMAIL PROTECTED]
Sent: 01 November 2007 23:10
To: PHP Internals
Subject: Re: [PHP-DEV] [Patch] http_fopen_wrapper.c and
allowing any response code w/o warning
This is probably better:
if (options STREAM_ONLY_GET_HEADERS ||
(php_stream_context_get_option(context, http, ignore_errors,
tmpzval) == SUCCESS Z_BVAL_PP(tmpzval))) {
- David
Am 02.11.2007 um 00:06 schrieb David Zülke:
Hi folks,
I've recently played with CouchDB, which is a document
database with a
RESTful HTTP interface.
I noticed, however, that there is no way to prevent PHP
from throwing
a warning on response codes other than 200, 206, 301, 302 and 303.
Something like 201 Created throws a warning, for example.
But I'm not sure if simply adding that one to the list is
the proper
way forward, as I imagine there are many situations when
you just want
to get the response content and look at the headers afterwards (w/
stream_get_meta_data). So I looked at the code and came up
with this
change for http_fopen_wrapper.c line 547
(http://lxr.php.net/source/php-src/ext/standard/http_fopen_wrapper.c#5
47
):
if ((options STREAM_ONLY_GET_HEADERS) ||
(php_stream_context_get_option(context, http, ignore_errors,
tmpzval) == SUCCESS Z_TYPE_PP(tmpzval) == IS_BOOL
Z_BVAL(retval))) {
So when the option ignore_errors is set for HTTP on the
context, no
error will be thrown, and the response body is returned properly.
Is that a reasonable idea? I'm not entirely sure about the
ignore_errors name, maybe someone has a better suggestion.
I'd be happy to supply a full patch, but I wanted to hear if anyone
has thoughts on this first.
Cheers,
David
--
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Class Posing
Ideally think I'd prefer it finer grained...
interface A
{
}
class AImpl implements A
{
}
register('A', function() { return new AImpl(); });
register('Foo', function() { return new Bar(); });
$foo = new Foo();
$a = new A();
Would also require functions being values... Which would also be nice.
J
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Sebastian Bergmann
Sent: 02 October 2007 10:33
To: internals@lists.php.net
Subject: [PHP-DEV] Class Posing
From [1]:
Objective-C permits a class to wholly replace another
class within a
program. The replacing class is said to pose as the target class.
All messages sent to the target class are then instead received by
the posing class.
There are several restrictions on which classes can pose:
* A class may only pose as one of its direct or indirect
superclasses.
[The other restrictions do not apply to PHP]
Earlier this year, Johannes implemented class posing for PHP
as follows:
?php
class Foo {}
class Bar extends Foo {}
function new_overload($className)
{
if ($className == 'Foo') {
return new Bar;
}
// ...
}
$o = new Foo;
// $o is an object of Foo.
register_new_overload('new_overload');
$o = new Foo;
// $o is an object of Bar.
?
We (Johannes, Marcus, Sara, and myself) then discussed where
to put this functionality. Outside of core, there were two
places that both make
sense: pecl/operator and pecl/runkit.
However, to make this a viable mechanism that can be used in
tools such as PHPUnit (for which I could really use this
functionality), we agreed that it actually belongs into the core.
Opinions? Needless to say that I would love to see this in
PHP 5.3 ;-)
--
[1] http://en.wikipedia.org/wiki/Objective_C#Posing
--
Sebastian Bergmann
http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867
C514 B85B 5D69
--
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] RFC: mark functions as const for possible optimizations
Hi,
Just a thought, now dl() has been deprecated and disabled in SAPIs (except
CLI,CGI,embed), would that mean extension_loaded() would become a
optimizable function?
So something like
include extension_loaded('gmp') ? 'GMPFoo.php' : 'PHPFoo.php';
Would be optimized to be more APC friendly?
Jared
-Original Message-
From: Nuno Lopes [mailto:[EMAIL PROTECTED]
Sent: 14 September 2007 18:01
To: PHPdev
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [PHP-DEV] RFC: mark functions as const for possible
optimizations
Hi,
Following my last post on bytecode optimization
(http://news.php.net/php.internals/32113), I would like to
discuss a few more things.
The patch in that e-mail allowed the engine itself to do
transformations like, e.g.:
$a = 1*2*3*4*5+1-0; -- $a = 121;
However the patch is now a bit dead because Stas would like
to have more advanced things that I didn't have time yet to
look at (because the proposal introduces several difficult
ambiguities in the grammar).
So, let's move on for now :P
My proposal is the following:
some functions when fed with constant arguments always return
a constant value, too. e.g.:
strlen('abcd') === 4.
This means that an optimizer can and should do this
transformation. (and others like: $a='abcd'; strlen($a); -
4). I think Ilia created a list of such functions in his
optimizer. But I would like to have that list in the core, so
that everybody can benefit from it.
Basically the only thing needed to do is to change PHP_FE() to
PHP_CONST_FE() in the function entry tables.
The patch:
http://web.ist.utl.pt/nuno.lopes/zend_const_function_entry.txt
(includes a few function entries changed as an example)
Nuno
P.S.: the university semester has already started, so don't
worry with the
e-mail traffic I'm generating because it'll end pretty soon
(until the next
vacations :P)
--
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] bitwise operations and Unicode strings
-Original Message- From: Antony Dovgal [mailto:[EMAIL PROTECTED] Sent: 30 May 2007 09:21 To: [EMAIL PROTECTED] Cc: php-dev Subject: Re: [PHP-DEV] bitwise operations and Unicode strings On 30.05.2007 04:15, Richard Lynch wrote: This code outputs 3 in native mode and Fatal error: Unsupported operand types in Unicode mode. I believe this is an inconsistency and it should be possible to use Unicode strings there. Given that there are probably a bazillion PHP scripts written by newbies just like that, I'd have to say it's crucial for wide-spread Unicode adoption for it to just work No, I'd say there might be like ten scripts on the planet relying on bitwise operations with strings, since numeric strings behaviour is different here. I'd say more. Pear::Crypt_HMAC, for instance, does. /* Calculate the padded keys and save them */ $this-_ipad = (substr($key, 0, 64) ^ str_repeat(chr(0x36), 64)); $this-_opad = (substr($key, 0, 64) ^ str_repeat(chr(0x5C), 64)); Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] gd development as part of php.net
-Original Message- From: Thomas Boutell [mailto:[EMAIL PROTECTED] Sent: 31 August 2006 00:17 To: internals@lists.php.net Subject: [PHP-DEV] gd development as part of php.net Unfortunately there hasn't been any movement on this since I handed it over to Pierre in April. Obviously, since I sat on PHP myself for a really long time, I am not pointing the finger at Pierre here. I'm still the champion gd-neglect-ster by a LONG shot. However, I'm wondering if anyone else is eager to help him make a new release of gd happen as part of the PHP project. If necessary, I could go looking for a new maintainer again, though that surely wouldn't be fun and I'd prefer almost anything else. (: * * * On a related note, I'm wondering why PHP doesn't seem to have any official relationship with the ImageMagick project - Which offers an unofficial PHP extension of its own. Though gd has been good to me over the years, I'm not going to sit here and pretend gd has a modern graphics API. It doesn't. gd has a very 1989 API, full of integer-oriented assumptions and less-than-smooth implementations of graphics primitives, written by a guy with no formal background in graphics algorithms (me). And that's always going to be visible in the quality of its output, short of a total core rewrite and API redesign. The good thing about gd was always the simple API - but a simple API at the C level doesn't necessarily help anymore when the end user isn't coding in C anyway. And ImageMagick has a floating-point, vector-oriented API that can do a whole lot more. With a coder-friendly MagickWand API that gives it simplicity approaching gd, especially when used from languages like PHP. Also, the ImageMagick license appears to be GPL-compatible and making-money-compatible: http://www.imagemagick.org/script/license.php So, at the expense of my own site traffic perhaps, why the outdated gd API and not ImageMagick in the official PHP builds? There is a magickwand extension for PHP. http://www.magickwand.org/download/php/ I was involved in getting the windows builds of it made, until the lead familiarised himself with Win32/VC. The intention was to get it on pecl at some point. But the lead developer has, to my understanding, been too busy. Its quite a massive API. I think there are ~477 functions wrapped an available to be used in PHP. Which obviously is going to create huge load on documentation/bugs etc. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Problems with APC
-Original Message- From: Sara Golemon [mailto:[EMAIL PROTECTED] Sent: 27 August 2006 20:17 To: internals@lists.php.net; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [PHP-DEV] Problems with APC I get a segfault with PHP 5.2.0RC2 in CLI mode (Apache module seems to work) and APC 3.0.11 (without APC it works fine). Is this a known problem (maybe even fixed in CVS) or is it worth investigating? Yes, it's a known problem. http://blog.libssh2.org/index.php?/archives/20-Doctor!-Doctor! -It-hurts-when-I-do-this!.html But it's an EXTREMELY edge case one. (Only happens with ZTS enabled, in CLI mode, with enable_cli *not* turned on). I came across this some time ago when mixing Runkit_Sandbox with APC, just turn on enable_cli. It won't materially impact your command line experience. PHP 5.1.6 APC 3.0.11-dev crashes on shutdown irrespective of apc.enable_cli. Jared apc APC Support = enabled Version = 3.0.11-dev MMAP Support = Disabled Revision = $Revision: 3.90 $ Build Date = May 4 2006 00:20:07 Directive = Local Value = Master Value apc.cache_by_default = On = On apc.enable_cli = On = On apc.enabled = On = On apc.file_update_protection = 2 = 2 apc.filters = no value = no value apc.gc_ttl = 3600 = 3600 apc.max_file_size = 1M = 1M apc.num_files_hint = 1000 = 1000 apc.optimization = Off = Off apc.shm_segments = 1 = 1 apc.shm_size = 30 = 30 apc.slam_defense = Off = Off apc.stat = On = On apc.ttl = 0 = 0 apc.user_entries_hint = 100 = 100 apc.user_ttl = 0 = 0 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Problems with APC
I get a segfault with PHP 5.2.0RC2 in CLI mode (Apache module seems to work) and APC 3.0.11 (without APC it works fine). Is this a known problem (maybe even fixed in CVS) or is it worth investigating? Yes, it's a known problem. http://blog.libssh2.org/index.php?/archives/20-Doctor!-Doctor! -It-hurts-when-I-do-this!.html But it's an EXTREMELY edge case one. (Only happens with ZTS enabled, in CLI mode, with enable_cli *not* turned on). I came across this some time ago when mixing Runkit_Sandbox with APC, just turn on enable_cli. It won't materially impact your command line experience. PHP 5.1.6 APC 3.0.11-dev crashes on shutdown irrespective of apc.enable_cli. Forgot to add the bug report, http://pecl.php.net/bugs/bug.php?id=8574 Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RfC: rethink OO inheritance strictness
PS: An real-life example from those wo prefer the old behavior would be nice ;-) -soenke Yes, I having a hard time imaging one, other than some quick fix. I'd much rather have some decent refactoring tools. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] testing filter ext in RC1
Hi, Also it does seem NUL char safe? php -r $var='3'.chr(0).'foo'; var_dump(filter_data($var, FILTER_VALIDATE_INT)); int(3) Jared -Original Message- From: Pierre [mailto:[EMAIL PROTECTED] Sent: 28 July 2006 17:44 To: Kevin Waterson Cc: internals@lists.php.net Subject: Re: [PHP-DEV] testing filter ext in RC1 On 7/28/06, Kevin Waterson [EMAIL PROTECTED] wrote: This one time, at band camp, Pierre [EMAIL PROTECTED] wrote: if var was abc1234 then it would return NULL, is that correct? False if the value is not valid, null if the value does not exist (for example with input_get or input_get_args). In the case of filter_data, as you pass the variable, it will be either false or the correct value. here it returns '0' Please show me some code, here is not really helpful. For example: $ php -r '$var=1234; var_dump(filter_data($var, FILTER_VALIDATE_INT));' int(1234) $ php -r '$var=ab1234; var_dump(filter_data($var, FILTER_VALIDATE_INT));' bool(false) --Pierre -- 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] testing filter ext in RC1
Hi, An empty string returns 0. php -r $var=''; var_dump(filter_data($var, FILTER_VALIDATE_INT)); int(0) Which maybe is what was intended, but imho still should return false. Jared -Original Message- From: Pierre [mailto:[EMAIL PROTECTED] Sent: 28 July 2006 17:44 To: Kevin Waterson Cc: internals@lists.php.net Subject: Re: [PHP-DEV] testing filter ext in RC1 On 7/28/06, Kevin Waterson [EMAIL PROTECTED] wrote: This one time, at band camp, Pierre [EMAIL PROTECTED] wrote: if var was abc1234 then it would return NULL, is that correct? False if the value is not valid, null if the value does not exist (for example with input_get or input_get_args). In the case of filter_data, as you pass the variable, it will be either false or the correct value. here it returns '0' Please show me some code, here is not really helpful. For example: $ php -r '$var=1234; var_dump(filter_data($var, FILTER_VALIDATE_INT));' int(1234) $ php -r '$var=ab1234; var_dump(filter_data($var, FILTER_VALIDATE_INT));' bool(false) --Pierre -- 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] testing filter ext in RC1
-Original Message- From: Pierre [mailto:[EMAIL PROTECTED] Sent: 28 July 2006 18:34 To: [EMAIL PROTECTED] Cc: Kevin Waterson; internals@lists.php.net Subject: Re: [PHP-DEV] testing filter ext in RC1 On 7/28/06, Jared Williams [EMAIL PROTECTED] wrote: Hi, Also it does seem NUL char safe? php -r $var='3'.chr(0).'foo'; var_dump(filter_data($var, FILTER_VALIDATE_INT)); int(3) Please report bugs in pecl.php.net/filter. It is hard to keep a trace of each post around here :) Reported. http://pecl.php.net/bugs/bug.php?id=8315 - NUL http://pecl.php.net/bugs/bug.php?id=8316 - Empty string Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RfC: rethink OO inheritance strictness
Hi (Marcus),
unfortunately I'm not very happy with the direction OO
strictness takes
in PHP. I'm sure I'm not alone and many people second this feeling.
Precisely, let's have a look at the following:
[EMAIL PROTECTED]:~/build/php-5.2-debug$ cli
-derror_reporting=8191 -r 'class c{function f(){}} class d
extends c{function f($a){}}'
Strict Standards: Declaration of d::f() should be compatible
with that of c::f() in Command line code on line 1
[EMAIL PROTECTED]:~/build/php-unicode-debug$ cli
-derror_reporting=8191 -r 'class c{function f(){}} class d
extends c{function f($a){}}'
Fatal error: Declaration of d::f() must be compatible with
that of c::f() in Command line code on line 1
I *really* think that this enforcements are no good idea and
I _beg_ you that we leave this area to interfaces.
Not sure why this is necessary, why doesn't
Class C
{
function f() { }
}
Class D
{
private $c;
function __construct(C $c) { $this-c = $c; }
function f($a) { }
}
work, with PHP's duck typing?
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Adding pecl/zip to 5.2
Many people (incl. php devs) asked me if I can include zip in 5.2.0. Ilia thought it was too late in the game and planed to do it in 5.2.1. I like to have it in, as experimental. Please note that it intoduces a new class called Zip, but I never saw a php zip implementation named Zip. +1/-1/0? I would've preferred an unified package for handling multiple archives (zip/rar/tgz etc). Similar to what PDO does for databases, if it is going into core. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: PEAR::Date broken (Was: [PHP-CVS] cvs: php-src(PHP_5_2) /ext/date php_date.c php_date.h)
-Original Message-
From: Lester Caine [mailto:[EMAIL PROTECTED]
Sent: 19 July 2006 09:53
To: Derick Rethans
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: PEAR::Date broken (Was: [PHP-CVS]
cvs: php-src(PHP_5_2) /ext/date php_date.c php_date.h)
Derick Rethans wrote:
On Wed, 19 Jul 2006, Lester Caine wrote:
Andi Gutmans wrote:
I agree completely. Can't we just call the damn thing
DateTime stick it into
RC1 of PHP 5.2, and move on?
Gets my vote
( Now we just need browsers to return REAL timezone data ;) )
http://talks.php.net/show/time-phptek6/30 works pretty well... (but
talks.php.net doesn't have it so the example doesn't work there)
Not sure, but I think that still has the same problem with
not knowing
the real timezone/daylight saving of the client? I need to
know how to
convert UTC to local time for an arbitrary date/time for displaying a
calendar. Current solution is that the client sets their
timezone/daylight saving in their profile, but it does not track when
they move locations or have multiple timezone/daylight login sites :(
If just need to display dates in localtime, I do it all on the client, by
always sending a UTC datetime in a format that JS can parse.
function localizeDate(span)
{
var local = span.cloneNode(true);
var d = new Date(local.innerText);
local.innerText = d.toLocaleString();
local.className = 'date local';
if (local.innerText != span.innerText)
span.parentNode.replaceChild(local, span);
}
Unfortunately Mozilla/Firefox seems badly broken in that toLocaleString()
returns the same string as was passed in.
IE Opera works fine.
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PHP-I18N] RFC: Error handling in HTTP input decoding
P.S. - Has anyone considered offering up an RFC to IETF or W3C about adding a header to the spec? Or just asking the nice Firefox folks to blaze the trail with an X-header? PHP can't be the only web-language dealing with this issue. W3 standard is to have the charset parameter on the Content-Type header. Unfortunately this breaks too much server side software, so no UserAgents do it. Hence the _charset_ kludge Microsoft introduced awhile back, and Firefox and Opera (afaik) have now adopted. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PHP-I18N] RFC: Error handling in HTTP input decoding
P.S. - Has anyone considered offering up an RFC to IETF or W3C about adding a header to the spec? Or just asking the nice Firefox folks to blaze the trail with an X-header? PHP can't be the only web-language dealing with this issue. W3 standard is to have the charset parameter on the Content-Type header. Unfortunately this breaks too much server side software, so no UserAgents do it. Hence the _charset_ kludge Microsoft introduced awhile back, and Firefox and Opera (afaik) have now adopted. Forgot to add that _charset_ has found its way into the Web Forms 2.0 working draft too. http://whatwg.org/specs/web-forms/current-work/#the-charset Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PHP-I18N] RFC: Error handling in HTTP input decoding
-Original Message- From: Andrei Zmievski [mailto:[EMAIL PROTECTED] Sent: 10 July 2006 23:50 To: [EMAIL PROTECTED] Cc: 'Sara Golemon'; internals@lists.php.net Subject: Re: [PHP-DEV] Re: [PHP-I18N] RFC: Error handling in HTTP input decoding W3 standard is to have the charset parameter on the Content-Type header. Unfortunately this breaks too much server side software, so no UserAgents do it. Hence the _charset_ kludge Microsoft introduced awhile back, and Firefox and Opera (afaik) have now adopted. As far as I know, the form actually has to have a hidden _charset_ input field in order for this to work, no? Yes, it has to be present. But still I think it could be a useful clue. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC: Error handling in HTTP input decoding
-Original Message-
From: Andrei Zmievski [mailto:[EMAIL PROTECTED]
Sent: 22 June 2006 22:46
To: PHP Internals
Cc: PHP I18N
Subject: [PHP-DEV] RFC: Error handling in HTTP input decoding
I'd like to solicit opinions on how we should treat
conversion failures
during HTTP input decoding. There are two issues at hand: fallback
mechanism and application-driven decoding in case of failure. Let's
look at the proposal for the latter one first.
If the decoding of HTTP input fails (and the failure state would be
achieved as soon as even one variable fails), PHP should set an error
flag somewhere that is accessible to the user, via either a global
variable or a function. It should also keep the original request data
around (query string, POST body, and cookie data). The application
should be able to access this data, since the encoding can be
passed in
the query string [1]. The application can then check this error flag
and then call a function -- request_decode() perhaps -- to ask PHP to
re-decode the request data based on a this specific encoding. For
example:
if (request_decoding_failed()) {
request_decode(request_get_raw('ei'));
}
We might be able to tie this in with the input filter, but that means
that the input filter will have to be required by PHP. I am open to
other suggestions in this area.
As for the first issue, PHP attempts to decode the input using the
value of the unicode.output_encoding setting, because that is
the most
logical choice if we assume that the clients send the data
back in the
encoding that the page with the form was in. We could implement a
fallback mechanism where PHP looks at the Accept-Charset
header sent by
the client[2]. This header is supposed to indicate what
character sets
https://bugzilla.mozilla.org/show_bug.cgi?id=18643
Maybe of interest, it's the kludge for determining form charsets, after the
charset in the Content-Type header broke too much.
are acceptable for the response. While this is not the same as
specifying the character set of the request, it might be a
good enough
indicator of it. Or we could simply set the error state and let
application figure out what charset it wants to use for decoding.
Thanks for your attention.
-Andrei
[1] http://search.yahoo.com/search?ei=UTF-8p=php
[2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
--
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] Re: strlen() under unicode.semantics
Enjoyed Andrei's talk at the NYPHP Conference last week
about unicode in
PHP 6. He mentioned that when unicode.semantics is on,
strlen() will
return the number of characters rather than the number of
bytes, like
mb_string() does or strlen() if mbstring.func_overload is on.
The hitch here is there are situations where one needs to
know how many
bytes are in a string. Is there a function I've overlooked
that does
this or will do this, please?
My first question is: Why do you need to know the number of
bytes occupied
by a textual string? Is it because you want to work with
binary strings?
Because that's still very possible:
Even with unicode.semantics=on, the binary string type may be
explicitly
used in a few ways:
$a = bThis string contains an 0xF0 byte: \xF0;
$alen = strlen($a);
This being the simplest, the lowercase b (or u) characters
denote a string
as being a binary (or unicode) string explicitly. Leaving
these specifiers
off yield whatever type is appropriate to unicode.semantics.
In other cases, such as reading from a binary mode file:
$fp = fopen('foo.bin', 'rb');
$str = fread($fp, 100);
Hi,
What happens with
$fp = fopen('foo.bin', 'wb');
$written = fwrite($fp, $str);
if (strlen($str) != $written)
{
echo 'Not written', \n;
}
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC array functions
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
Sent: 27 May 2006 22:28
To: internals@lists.php.net
Subject: [PHP-DEV] RFC array functions
Hello internals,
i'd like to add two array functions:
- bool array_has_more(array $array)
checks whether $array has more elements after current position or
if array is at last position, preferable working inside foreach
Useful.
- bool array(array $array)
cehcks whether arra position is valid (e.g. like
key($array) !== NULL)
How do you disambiguate between this and
$array = array('foo', 'bar');
$anotherArray = array($array);
making array(0 = array(0 = 'foo', 1 = 'bar'))
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Flamewar Summary
There are 2 PHP 5.2 changes there has been a lot of back and
forth flaming going around and we need to finally come to a
decision about.
The two topics are:
Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
Addition of support for dynamic statics ala: class foo {}
foo::$bar = 1;
E_RECOVERABLE_ERROR +1
As for E_STRICT, am I right in thinking that some E_STRICT warnings are
generated by the parser, and before any PHP code is
executed? So using error_reporting(E_ALL ~E_STRICT) is never going to prevent
some E_STRICT warnings?
If so -1, as E_STRICT behaves differently compared to the other E_*s, otherwise
0.
foo::$bar = 1;
-1
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: private, protected, readonly, public
On May 13, 2006, at 7:18 PM, Marcus Boerger wrote:
hehe, maybe confused with delphi or borlands c++
additons? Speaking
of which before we add 'readonly' we should go for full property
support but on the other hand that might be a little bit too much
until php is used with code generators and gui designers where code
inspectors execute and manipulate source/code while developing.
Hi Marcus,
Full property support is high on my wishlist for 6.0. I was a
Delphi programmer for 5 years and miss properties. C#, Ruby,
and Java all have built in property support with accessor
methods, or at least a single standard implementation that
all the tools can get behind.
__get and __set leave you in complete limbo for both source
code and reflection based tools. I think the language
support has to come before the tools.
I think this can be implemented by adding a getter and setter
field to zend_property_info, then checking for it in
zend_std_read_property, etc. Although, I'm sure there's more
to it than that. Such an implementation would probably be 3
to 4 times faster than __get(). No switch, no $name
parameter, perhaps no guard logic. Checking for a getter or
setter in zend_property_info would be a fast boolean test on
a data structure thats already available, so I believe there
would be little overhead.
Here are a few use cases and syntax suggestions...
A. Declaring a property with accessor methods:
public $foo read getFoo write setFoo;
B. Read only property with accessor method could be declared:
public $foo read getFoo;
C. A shortcut notation could automatically generate the
accessor method based on another property:
public $foo read $_foo;
// internally generated method ala C# property implementation:
// public function __get_foo() { return $this-$_foo; }
D. Similar to read only, you could have split visibility, for
example, a public getter and a protected setter:
public $foo read getFoo write protected setFoo; // Handy use
case, not crazy about this syntax public function getFoo() {
return $this-_foo; } protected function setFoo($value) {
$this-_foo = $value }
E. To avoid warnings, declare the internal storage, too:
public $foo read $_foo write setFoo, protected $_foo;
public $foo read $_foo, protected $_foo; // readonly
F. Properties with accessor methods cannot be directly initialized.
Their internal storage can, however:
public $foo read $_foo write setFoo, protected $_foo = 'bar';
G. calling unset() on a property with accessor methods could
call the setter with NULL.
H. calling isset() on a property with accessor methods
returns FALSE if the property does not exist, otherwise calls
the getter and compares against NULL for compatibility purposes. (?)
I. calling property_exists() on a property with accessor
methods would always return TRUE.
J. The setter and getter could be inspected via ReflectionProperty.
K. Unlike __get, subclass property definitions could override
the parent declarations:
class Foo { public $prop; }
class Bar extends Foo { public $prop read getProp write
setProp; ... }
L. An abstract class need not declare the actual accessor
methods, they could be added as abstract by default:
abstract class Bar { public $foo read getFoo write setFoo; }
Yes, full property support would be nice. Though not to keen on that syntax,
but can't think of anything nicer as yet :)
Haxe ( http://www.haxe.org/ref#properties ) has something like
public $prop(getter, setter);
Where getter and setter can be a method name, null for not allowed, default for
basic accessor, which is less to type, but still not
that nice.
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] xmlwriter_write_raw() not in 5.1.4 yet?
I'm on the latest and greatest PHP 5.1.4. I can see the function I think I want in the manual: http://us3.php.net/manual/en/function.xmlwriter-write-raw.php But the manual says it's only in CVS. I confirmed that I don't have it: * Fatal error: Call to undefined function xmlwriter_write_raw() in ***.php on line ** I am hoping that this function would let me merge already-created XML into the XML I am writing and avoid the , , , etc escaping of content which is normally done when using xmlwriter_text(). Zend summary was talking about it back in December. We've had a couple version updates since then. Still not in the official release? * http://www.zend.com/zend/week/week268.php#Heading8 Anyone know the status of this function, if it does what I want, and what version I can start using it? I originally requested it. http://pecl.php.net/bugs/bug.php?id=6267 . I think it'll appear in 5.2, http://oss.backendmedia.com/PhP52 . Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Stop Breaking Our Apps For the Sake of OO
Pierre wrote: I forgot to mention how vicious such changes can be. Most of times the related tests are updated in the same commit (or right after) to follow the new behavior. Making nearly impossible to know about the breakages without duplicating core tests in our apps. Also commit messages or changelog entries are rarely explicit enough to mention them. Maybe we could set up a testing system that runs the tests from PHP_4_4, PHP_5_0, PHP_5_1, and HEAD and shows the differences? That way we would notice that a test that passed with a previous version fails with a newer one. Would have to diff the various tests too. Perhaps the tests cases should never be removed, but the expected results altered so a diff between differing test suite versions can show what behaviour has changed. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Stop Breaking Our Apps For the Sake of OO
-Original Message-
From: Derick Rethans [mailto:[EMAIL PROTECTED]
Sent: 11 May 2006 15:07
To: PHP Developers Mailing List
Subject: Re: [PHP-DEV] Stop Breaking Our Apps For the Sake of OO
On Thu, 11 May 2006, Derick Rethans wrote:
While I welcome new developments in either procedural or OO
interfaces
in PHP I do not agree with breaking BC (between 5.1 and 5.2 in this
case) just for the sake of OO purity. In this example there is the
following class:
snip
I've one more of those things. How to test if you're using
PHP 5.1 or PHP 5.2:
?php
class Bla
{
}
$b = new Bla;
if( $b != null )
{
echo PHP 5.1;
}
else
{
echo PHP 5.2;
}
?
Interesting logic break too...
$foo = new stdClass();
if ($foo == null || $foo != null) { echo 'Never gets echoed'; }
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] #line C macro equivalent in php ?
Hello William, as long as php has no goto no such generator is capable of generating php code. When that changes we want to have something alike of course. But actuall it is already in HEAD ... So thenWhy not cimply go with this: #line file line to simple becuase the tools in question would already do that? No such generator? ... I've have a port of Lemon that outputs PHP5, so a #line or equivalent would be nice. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Stop Breaking Our Apps For the Sake of OO
Jared Williams wrote:
Interesting logic break too...
$foo = new stdClass();
if ($foo == null || $foo != null) { echo 'Never gets echoed'; }
From a pure computer science point of view, the above makes
complete sense. Null means unknown value, so nothing is equal
to it, not even another null (because you don't know if the
other null's *unknown* value is equal to this null's
*unknown* value). is_null() would make more sense here.
Yes, in certain languages tristate logic makes sense. But I don't think PHP is
intended to be one of them.
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] array type hint and SPL array interfaces
Hi Marcus! I wondered, why PHP complains, if you have an array type hint in a method prototype and provide an object to this method, that implements the SPL interfaces to use objects as arrays. I would expect that, if an object can be handled exactly like an array, PHP should not complain, since the implementation of the method would not notice the difference. Or am I wrong? But the method may use an array_*() function, which would cause problems if they're handed an ArrayAccess implementation. So there is a difference. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.1.3, IIS FastCGI
Hi, It seems I can not get PHP 5.1.3 FastCGI to work. Had 5.1.3RC2 working with FastCGI. Was this a planned break, and requires some different means of getting it working? Or should I go file a bug report? Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 5.1.3, IIS FastCGI
-Original Message- From: Dmitry Stogov [mailto:[EMAIL PROTECTED] Sent: 03 May 2006 12:33 To: [EMAIL PROTECTED]; internals@lists.php.net Subject: RE: [PHP-DEV] PHP 5.1.3, IIS FastCGI It wasn't planned. What exactly doesn't work? Appears no requests get to the worker processes. They are created, but just do nothing it appears. C:\Inetpub\VTemplate\testspslist php PsList 1.21 - Process Information Lister Copyright (C) 1999-2002 Mark Russinovich Sysinternals - www.sysinternals.com Process information for WIN2KS: process php was not found on WIN2KS C:\Inetpub\VTemplate\testswget -s http://localhost/phpinfo.php --13:06:24-- http://localhost/phpinfo.php = `phpinfo.php' Resolving localhost... done. Connecting to localhost[127.0.0.1]:80... connected. HTTP request sent, awaiting response... Nothing happens here, but the worker processes have fired up... C:\Inetpub\VTemplate\testspslist php PsList 1.21 - Process Information Lister Copyright (C) 1999-2002 Mark Russinovich Sysinternals - www.sysinternals.com Process information for WIN2KS: Name Pid Pri Thd HndMem User Time Kernel Time Elapsed Time php-cgi 1784 8 2 38 6440 0:00:00.080 0:00:00.1000:01:56.417 php-cgi 740 8 2 41 6380 0:00:00.110 0:00:00.0500:01:56.397 php-cgi 2008 8 2 43 6380 0:00:00.110 0:00:00.0700:01:56.357 Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 5.1.3, IIS FastCGI
-Original Message- From: Dmitry Stogov [mailto:[EMAIL PROTECTED] Sent: 03 May 2006 12:33 To: [EMAIL PROTECTED]; internals@lists.php.net Subject: RE: [PHP-DEV] PHP 5.1.3, IIS FastCGI It wasn't planned. What exactly doesn't work? Appears no requests get to the worker processes. They are created, but just do nothing it appears. C:\Inetpub\VTemplate\testspslist php PsList 1.21 - Process Information Lister Copyright (C) 1999-2002 Mark Russinovich Sysinternals - www.sysinternals.com Process information for WIN2KS: process php was not found on WIN2KS C:\Inetpub\VTemplate\testswget -s http://localhost/phpinfo.php --13:06:24-- http://localhost/phpinfo.php = `phpinfo.php' Resolving localhost... done. Connecting to localhost[127.0.0.1]:80... connected. HTTP request sent, awaiting response... Nothing happens here, but the worker processes have fired up... C:\Inetpub\VTemplate\testspslist php PsList 1.21 - Process Information Lister Copyright (C) 1999-2002 Mark Russinovich Sysinternals - www.sysinternals.com Process information for WIN2KS: Name Pid Pri Thd HndMem User Time Kernel Time Elapsed Time php-cgi 1784 8 2 38 6440 0:00:00.080 0:00:00.1000:01:56.417 php-cgi 740 8 2 41 6380 0:00:00.110 0:00:00.0500:01:56.397 php-cgi 2008 8 2 43 6380 0:00:00.110 0:00:00.0700:01:56.357 Opened as bug, http://bugs.php.net/bug.php?id=37291 Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 5.1.3, IIS FastCGI
It should be already fixed in CVS. Please check. Ah. K :) Will check once the next snap is built. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 5.1.3, IIS FastCGI
It should be already fixed in CVS. Please check. Ah. K :) Will check once the next snap is built. Jared Just installed todays' 18:30 snap, and its working. Cheers. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] ext/filter, add input_get_args, support of scalar orarray result
-Original Message-
From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]
Sent: 02 May 2006 07:42
To: [EMAIL PROTECTED]
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] ext/filter, add input_get_args,
support of scalar orarray result
Pierre wrote:
I put a small example here:
http://pecl.php.net/~pierre/filter_input_get_args_example.phps
and the patch:
http://pecl.php.net/~pierre/patch_filter_input_get_args.txt
I think this looks ok. I have been trying to come up with a
shorter and cleaner syntax to specify these things, but so
far I haven't come up with anything I really like. The
closest I have come is something like
this:
$args = array(
'product_id' = 'Enc',
'component'= 'Int:Array:1-10',
'versions' = 'Enc',
'doesnotexist' = 'Int',
'testscalar' = 'Int:Scalar',
'testarray'= 'Int:Array'
);
Would a little helper function to create the array be a little neater (and less
typing :) for the more common complex options?
$args = array(
'component' = somefunc(FILTER_VALIDATE_INT, FILTER_FLAG_ARRAY, 1, 10);
);
But I am not completely happy with the magic shortcuts in the
strings there. The above would be equivalent to:
$args = array(
'product_id'= FILTER_SANITIZE_ENCODED,
'component' = array('filter'= FILTER_VALIDATE_INT,
'flags'= FILTER_FLAG_ARRAY,
'options'= array(min_range=1,
max_range=10)
),
'versions' = FILTER_SANITIZE_ENCODED,
'doesnotexist' = FILTER_VALIDATE_INT,
'testscalar'= array(
'filter' = FILTER_VALIDATE_INT,
'flags' = FILTER_FLAG_SCALAR,
),
'testarray'= array(
'filter' = FILTER_VALIDATE_INT,
'flags' = FILTER_FLAG_ARRAY,
)
);
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] open_basedir_for_include
Sara Golemon wrote: The PDM recommendation covering the removal of safe_mode included a note on expanding the role of open_basedir. To that end, I'd like to propose introducing a new ini option: open_basedir_for_include which would allow using include/require(_once) on an expanded set of directories than what open_basedir would otherwise allow. Since php_fopen_wrapper_for_zend() specifies STREAM_OPEN_FOR_INCLUDE, we can catch this option in the plain_files wrapper and expand the open_basedir check to allow specifying the alternate INI option (when set of course). Obviously if this new option were left unset and the regular open_basedir were set, we'd still use that for full BC. If noone objects I'll add this functionality in between unicode related patches in a week or so. Sounds like a good idea to me. A very handy use of open_basedir that is often overlooked is as a way to protect you from yourself. That is, you define up front where you know your application should be reading and writing from and if you happen to make a mistake in your code it will act as a safety net. Adding the ability to include files from common include directories without adding them to the list of real open_basedir directories makes this more useful. Any reason why can't set open_basedir programmatically? Obviously to only a subset of the current setting. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] phps line numbering
Jared Williams wrote: Replacing the list, with divs and using css generated content to display the line numbers, cleans up the paste output but won't get ... and doesn't work in IE. So no real win here. The semantic solution would be to use ol/li . Can't use ol/li thou, as that is what messes up the cut paste in FF. Even if you use conditional CSS, set the list-style to none, and use css generated content to inject the line numbers, when it cut pastes, FF forgets the list-style none, and still includes junk. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] phps line numbering
Patches have been written and languish simply awaiting inclusion in HEAD Johannes' method (olli.../li.../ol) doesn't copy paste well in FireFox 1.5 -- you might consider this a FF problem, but in any case, line numbers are pasted, so this is really a pain for sharing code. Until a good method is found (if there is one), I say leave the patch out -- although, FWIW, I _would_ like to see line numbers if there's a way to make it work well (avoid horizontal scrolling, paste without numbers). Pretty sure this isn't possible in Firefox, both avoiding horizontal scrolling and paste without numbers, are mutually exclusive. Replacing the list, with divs and using css generated content to display the line numbers, cleans up the paste output but won't get the word wrap. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Revisiting output control code
I'd like to suggest that we revisit the output control (output buffering) code base. The current implementation uses way too less commands to do too many different operations, which almost always causes problems with output handlers that need to maintain a state or context. Short example: ob_clean() causes havoc with ext/zlib ob handlers and any handlers found in pecl/http. ob_clean() passes currently buffered input through the handler and discards it, which means in the case of the gz handler that the gzip/zlib header bytes (and more) are missing from the sent data. Things I think that should come with the new code: Support for an opaque handler context, which will be passed to the handler. More distinct commands like FLUSH, RESTART and/or CLEAN. Thoughts/comments/flames? Sounds like should be built upon/replaced with streams. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] recover from a segfault
The problem is that setrlimit() need privilege to expand the process stack. I don't think it's a good idea to use this system call to fix the too-high-function-stack bug. There is no really way to fix correctly this bug. However I think we should re-examined the execution flow of PECL functions. How about core functions too.. Using array_walk_recursive to undo magic_quotes creates a stack smashing exploit. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PATCH] Custom Streams, fclose stream_close
Hi, stream_close can return any value it likes... however, it is ignored and php_userstreamop_close always returns success to the streams layer. This is a bug, but should be simple to fix. (volunteers welcome; I don't have a current cvs checkout). --Wez. This should fix it, I think. :) Hi, Is the PHP manual correct in that fclose() returns a bool, but a custom wrapper stream_close() is void? Would like to signal a problem if I have a problem closing a custom stream. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PATCH] Custom Streams, fclose stream_close
stream_close can return any value it likes... however, it is ignored and php_userstreamop_close always returns success to the streams layer. This is a bug, but should be simple to fix. (volunteers welcome; I don't have a current cvs checkout). This should fix it, I think. :) Please put it online and provide a link. We blcok all attachments which are not text/plain. http://ren.dotgeek.org/phppatches/userspace_stream_close_return.diff Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Custom Streams, fclose stream_close
Hi, Is the PHP manual correct in that fclose() returns a bool, but a custom wrapper stream_close() is void? Would like to signal a problem if I have a problem closing a custom stream. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: zend_hash.c fishy code
you are missing my point. My point is that when a hashtable
contains these two elements
example:
BUCKET_ENTRY for h=15
--- Bucket1 : key == numeric - h= numeric hash value == 15
\ Bucket2: key == some string key, with a hash
value equal to 15
Lets assume we want to delete the key
THI_HASH_A_HASH_FUNCTION_VALUE_OF_15
then the code in question will first hash it and gets h==15.
The next thing it will do is go through the linked list of
buckets for h==15.
Unfortunately the check there is broken. It will first check,
that p-h is == 15 and then check if p-nKeyLength==0 which
obviously is for our Bucket1. Unfortunately this is already
enough to evaluate to true. But it is not what we intended.
We wanted to delete bucket2.
But we end up with Bucket1 deleted.
/* original */
if ((p-h == h) ((p-nKeyLength == 0) || /* Numeric index */
((p-nKeyLength == nKeyLength) (!memcmp(p-arKey, arKey,
nKeyLength) {
Vs.
/* rearranged */
if ((p-h == h) (p-nKeyLength == nKeyLength)
((nKeyLength == 0) || (!memcmp(p-arKey, arKey,
nKeyLength
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] JSON inclusion in core
At 06:01 PM 1/20/2006, Rasmus Lerdorf wrote: Andi Gutmans wrote: Yeah, but the main problem with this kind of stuff is when you start mapping classes and even references. I think it requires some additional pluming to be really useful for writing robust JavaScript--PHP connectivity so that it's flexible enough for all those PHP packages to start using it. I'm +1 for including JSON but not on the way the API is defined right now. I guess I am confused. Javascript, and thus JSON, has no concept of an object. It has something it calls an object, but that is just an associative array. Are you trying to layer some other syntax on top of JSON to convey more meaning than what JSON/Javascript natively supports? Yes exactly. So for example, we should define some special string/value pair that conveys the class of the object (e.g. __classname:MyClass). I'd say that this is almost critical to allow a very nice mapping between the client side Javascript and the PHP layer. This way you can pretty much do a 1:1 mapping from Javascript objects (which might be nested) to PHP objects. The decode() would just find this __classname and make sure to instantiate MyClass and put the key/value pairs in that. What are the security implications of doing this? Creating objects based on a string from a untrusted source seems not good idea, unless can prevent tampering (with an HMAC or something). Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] JSON inclusion in core
AFAIK an object in JSON is just an associative array in PHP,
so I don't see the point here in implementing that in
anything else than an associative array on the PHP side.
The json extension currently creates stdClass objects.
$config = '{windowA:
{
left: 10,
right: 10,
height: 100,
width: 100
},
windowB:
{
left: 120,
right: 120,
height: 120,
width: 120
}
}';
$a = json_decode($config);
var_dump($a);
Outputs:
object(stdClass)#1 (2) {
[windowA]=
object(stdClass)#2 (4) {
[left]=
int(10)
[right]=
int(10)
[height]=
int(100)
[width]=
int(100)
}
[windowB]=
object(stdClass)#3 (4) {
[left]=
int(120)
[right]=
int(120)
[height]=
int(120)
[width]=
int(120)
}
}
Also it'd been nice if the requirement to have name/label in double quotes was
removed, (I havent read a JSON spec, so it maybe
correct) but javascript doesn't require it.
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] JSON inclusion in core
At 04:25 AM 1/21/2006, Jared Williams wrote: What are the security implications of doing this? Creating objects based on a string from a untrusted source seems not good idea, unless can prevent tampering (with an HMAC or something). Well I think the right thing to do is pass an array of allowed classes into json_decode() and raise an error/exception if it's not in the list. Perhaps just an interface? Like Traversable, means don't have to maintain an array. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Naming Arguments
From the perspective of providing reflection in general and giving something for editors with code completion to use in specific, would there be an interrest in backfilling the arg_info structs for internal functions (both core and otherwise) with argument naming and type hinting even where it's not technically needed? On the con side, this does add memory usage and processing time for no direct production benefit. Any utility which wanted this degree of introspection *could* parse the XML protos in phpdoc and get the same (or better) information, so it doesn't really gain that much for what it costs. Can you produce the arg_info structs from parsing the XML protos? Do please forget about the work required to fill in this information. There are more than enough volunteers to do the grunge work(and frankly it'd be tough for 'em to get it horribly wrong), this is just a question of: Would there be an interrest in folding this data into the core? and secondly: Should new extension writers be encouraged to fill this information in?. Perhaps some tool to generate boiler plate docbook from introspection would be enough encouragement? Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Named arguments revisited
I guess adding named arguments of internal functions would enable Reflection to properly reflect on function and method parameters of internal functions. Which would be nicer than the inconsistent state that exists now. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Named arguments revisited
Andrei Zmievski wrote: On Jan 9, 2006, at 4:09 AM, Aidan Lister wrote: As useful functions tend to increase in complexity over time, often so does the number of parameters. It soon gets to the point where function calls look like: foo(true, false, false, false, false, true) The rest of the parameters being required to be supplied, with their default value, when the user is only interested in changing the last option. If you get to the point where your function has a dozen parameters, I would suggest re-thinking the purpose and design of such a function, because you are likely trying to make it do too much. -Andrei In a simple highlighting function I wrote (which at 16k hits is probably considered useful) I needed most of the following parameters: $text $needle $strip_links $case_sensitive $whole_word_only $simple_text_only $highlight_pattern $return_or_print $use_xhtml $tooltips_or_divs I imagine any function dealing with html may use a significant portion of these. Obviously some of these are for effect, but I think my point is clear enough. I think that's a poor example. I see a highlighting problem split into multiple classes. One that generates a SAX stream from html, another class or two modifies SAX event stream, one removing links, and another injecting highlighting elements, and another pair of classes to reassemble the SAX event stream back into a string, one doing HTML, the other XHTML. If you have too many parameters that you want to start omitting parameters when calling a function, its probably time to refactor. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Labeled Breaks (not the G-word)
Guys, Laughter has nothing to do with it. However, as discussed between those who attended the meeting in Paris, goto earned its bad connotations for a reason. It was agreed that providing a general-purpose C-goto equivalent is not a good idea because it *will* very quickly lead to spaghetti coding styles. We also came to the conclusion that the main use case that is not covered by PHP today is that of 'centralized' error recovery, which requires forward jumping only (if it wasn't for that use case, I think we would have had consensus not to add any type of goto at all). So, the logical conclusion appeared to be: 1. A forward-jumping construct only, to avoid giving users too much ammo to shoot themselves in the foot with spaghetti coding. 2. A construct which is not named 'goto', not because of the bad connotations (that's actually a good reason to keep it named 'goto'), but in order to make it clear that it's not goto, so that nobody expects it to behave like goto in other languages. I'm not sold on reusing the break construct for that, since we're not really breaking, and I kind of like Ilia's jump idea. Another possibility would be reusing 'continue', which makes a bit more English sense, even though it's not very similar to continue's semantics. I got a horrid thought that people will end up trying to get around the limitation, abusing the forward only goto and other language constructs to get it todo backward jumps, and you'll have even worse code than with a backward jumping goto. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: namespace separator poll, update
On 11/27/05, Sara Golemon [EMAIL PROTECTED] wrote: Other possibilities: ** Double-Star+2 ;;Double-Semicolon +2 Reverse Heredoc Operator -1 ?? Double Question -1 -Sara I think we should use a non breaking space ( \xA0 ) as the separator, after all namespace class-method() looks great in an email, why not in code? ;) I say it should be an ini setting, and then everyone can have whatever they want.. ;) Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
