Re: [PHP-DEV] [RFC][DISCUSSION] Argon2 Password Hash

[Jared Williams]

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?

[Jared Williams]

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&m=143444845304138&w=2
> [2] https://marc.info/?t=14574424811&r=1&w=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

[Jared Williams]

On Wed, 2015-02-18 at 16:17 +0100, Nikita Popov wrote:
> On Wed, Feb 18, 2015 at 4:06 PM, Cesar Rodas  wrote:
> 
> >
> > On 18/02/15 15:59, Nikita Popov wrote:
> > > On Wed, Feb 18, 2015 at 7:22 AM, Dmitry Stogov  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()`, 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] Bug #64910: Line number of $e = new Exception vs. line number of throw $e

[Jared Williams]

 

> -Original Message-
> From: Sebastian Bergmann [mailto:sebast...@php.net] 
> Sent: 23 May 2013 21:18
> To: internals@lists.php.net
> Subject: [PHP-DEV] Bug #64910: Line number of $e = new 
> Exception vs. line number of throw $e
> 
>  Hi!
> 
>  The error message that is created for an uncaught exception 
> as well  as the stacktrace of an exception list the number of 
> the line on which  the exception object was created. I would 
> expect this to be number of  the line on which the exception 
> is raised using the throw statement.
> 
>  Derick agrees with me that this is a bug. We propose to 
> update the file  and line properties of the exception object in the
>  zend_throw_exception_internal() and zend_throw_exception()
functions.
> 
>  Would such a change be accepted? Does it require an RFC?
> 

I agree that it should have been where the throw occurs, to allow for
an ExceptionFactory type use.

There is a method of making it better, but it's bit (rather a lot)
gnarly.

function createException($errno, $message, Exception $exception =
null)
{
  // Please forgive us for what we are about to do.
  // Fix up exceptions so they appear closer to where they are thrown
  $f = Closure::bind(
  function() {
array_shift($this->trace);   // createException_
$t = array_shift($this->trace);   // createException
$this->line = $t['line'];
$this->file = $t['file'];
return $this;
  }, $this->createException_($errno, $message, $exception),
Exception::class);
  return $f();
}

private function createException_($errno, $message, Exception
$exception = null)
{
  switch ($errno)  {
case 2002:
  return new ConnectException($message, $errno, $exception);

case 2013:  // Connection dropped.
case 2006:  // Gone away
  return new ConnectionDroppedException($message, $errno,
$exception);

/*

*/

default:
  return new DatabaseException($message, $errno, $exception);
  }
}

So

throw $obj->createException(...);  reports a more useful/accurate
location.

Jared


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

RE: [PHP-DEV] __init magic method

[Jared Williams]

 

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

[Jared Williams]

 

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

[Jared Williams]

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

[Jared Williams]

 

> -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 
>  wrote:
> > On Wed, 29 Aug 2012, Nikita Popov wrote:
> >
> >> On Wed, Aug 29, 2012 at 10:10 PM, Derick Rethans 
>  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 ¤t().

Jared






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

RE: [PHP-DEV] [VOTE] Generators

[Jared Williams]

 

> -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] [RFC] Generators

[Jared Williams]

 

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

[Jared Williams]

 

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

[Jared Williams]

 

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

[Jared Williams]

 

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

[Jared Williams]

 

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

[Jared Williams]

 

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

[Jared Williams]

 

> -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] Traits and memory size

[Jared Williams]

 

> -Original Message-
> From: Ben Schmidt [mailto:mail_ben_schm...@yahoo.com.au] 
> Sent: 10 April 2012 02:35
> To: internals@lists.php.net
> Subject: [PHP-DEV] Traits and memory size
> 
> Hi!
> 
> Just a quick question about traits.
> 
> During the flattening process, is a copy made of the trait 
> code (or bytecode or whatever)?
> 
> So, if I have
> 
> trait A {
> // a bunch of methods
> }
> class B {
> use A;
> }
> class C {
> use A;
> }
> class D {
> use A;
> }
> 
> will I have four copies of A because it has been copied into 
> all of the classes, and thus this aspect of my code will take 
> up four times as much memory than if I did:
> 
> class A {
> // a bunch of methods
> }
> class B extends A {
> }
> class C extends A {
> }
> class D extends A {
> }
> 
> Or is the code shared so the memory use will be roughly the same?
> 
> I realise the use cases for traits and inheritance are 
> different, and often the situation will dictate the design, 
> but sometimes you have these two options so have to make a 
> design decision, and it would be nice to know the impact on 
> memory use/code size.
> 
> Hope this is a simple question and won't take too much time 
> for anyone to answer!
> 
> Thanks!
> 
> Ben.
> 

I don't know the answer to your question. 

But the decision to use traits or inheritance should be pretty
obvious, and the amount of memory either way uses should be
irrelevant. 
If either choice appears to be allocating too much, then it's the Zend
Engine itself that should be looked at, and not rewritting PHP code.

Jared


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

RE: [PHP-DEV] Object oriented page templates in PHP

[Jared Williams]

> -Original Message-
> From: Tom Boutell [mailto:t...@punkave.com] 
> Sent: 09 April 2012 16:10
> To: PHP Internals
> Subject: [PHP-DEV] Object oriented page templates in PHP
> 
> There has been talk of making PHP a better templating 
> language. After all, it did start out there.
> 
> Folks have mentioned ideas like making it easier to output 
> escaped content, etc., but these are all hardcoded solutions. 
> And one of the biggest problems with PHP as a template 
> language is that when best practices change, you're stuck 
> with the helper functions you already have unless you start 
> globally replacing things. You can't really subclass or 
> override a function.
> 
> So even frameworks that provide "helper functions" in the 
> vein of Symfony 1 (which borrowed the idea from Rails) get 
> stuck when you want to alter the behavior.
> 
> Last year I did a project in a one-off MVC framework of my 
> own in which I decided I didn't want to be stuck with that, 
> so I made a rule:
> anything I wanted to call from the template had to be a 
> method of $this, the view object in whose render() method the 
> template file was require()'d.
> 
> This turned out to be a good thing. By writing  $this->escape($foo) ?>, I was able to benefit from whatever 
> implementation of 'escape' the subclass of view in question 
> decided to supply to me.
> 
> But of course it is very verbose and a templating language 
> that is too tedious to use won't get used.
> 
> What if PHP supported a short tag for calling a method of $this?
> 
> Then one could write:
> 
> 
> 
> And 'escape' could be upgraded and modified as needed in an 
> object oriented way without the need to type  many
times.
> 
> A problem with this proposal is that it does not address 
> nesting. One still has to write:
> 
> escape($foo)) ?>
> 
> And it is fairly common to combine such operations.
> 
> So maybe I should just define a sublimetext shortcut for:
> 
> 
> 
> And be done with it. (: It detracts from readability relative 
> to a template language like Twig, but I can always choose to use
Twig.
> 
> This would be notably easier if PHP, like Java and C++, 
> called methods of the current object implicitly without the 
> need for $this->. But of course that would be too great a 
> change as there would be no way to make existing code work 
> correctly again if it reasonably expected
> implode() to call the usual PHP function and not a method. 
> Plus it's probably a real pain to implement in general.
> 
> Thoughts?
> 

$fn = [
'escape' => function($text) { return htmlspecialchars($text,
ENT_QUOTES|ENT_HTML5, 'UTF-8'); },
...
];
extract($fn);



Do I think it's a good idea?  Probably not in this case.

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

[Jared Williams]

Raised this 5 years ago.. 

http://marc.info/?l=php-internals&m=113998880315574&w=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

[Jared Williams]

 

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

[Jared Williams]

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?

[Jared Williams]

 

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

[Jared Williams]

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

[Jared Williams]

 

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

[Jared Williams]

 

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

[Jared Williams]

 

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

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] Re: [PHP-CVS] svn: /php/php-src/trunk/ NEWS ext/json/json.c ext/json/php_json.h ext/json/tests/serialize.phpt

[Jared Williams]

 

> -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 
>  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] What is the use of the $replacement property in the RegexIterator class.

[Jared Williams]

 

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

[Jared Williams]

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

[Jared Williams]

 

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


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

 
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,  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] 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/

[Jared Williams]

 

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

[Jared Williams]

 

> -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] php and multithreading (additional arguments)

[Jared Williams]

 

> -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 
>  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] array_seek function

[Jared Williams]

 

> -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] function call chaining

[Jared Williams]

 

> -Original Message-
> From: Stanislav Malyshev [mailto:s...@zend.com] 
> Sent: 19 January 2010 00:28
> To: 'PHP Internals'
> Subject: [PHP-DEV] function call chaining
> 
> Hi!
> 
> I wrote a small patch that enables this kind of syntax in PHP:
> 
> foo()();
> 
> What it means is that if foo() returns callable value (which 
> probably should be function name or closure) then it would be 
> called. Parameters and more than two sets of () work too.
> Of course, this is mostly useful for doing closures, and that 
> was primary drive for implementing it - to make working with 
> closures and especially function returning closures easier.
> What does not work currently is $foo->bar()() - since it is 
> surprisingly hard to tell parser it's not {$foo->bar}()() - 
> which of course is not what I want to do.
> 
> The patch is here: http://random-bits-of.info/funcfunc.diff
> 
> What do you think? If somebody has better idea btw - maybe 
> make something like {foo()}() - and make that work for any 
> expression inside {} - that might work too. So, what do you think?
> --
> Stanislav Malyshev, Zend Software Architect
> s...@zend.com   http://www.zend.com/
> (408)253-8829   MSN: s...@zend.com
> 
> --
> PHP Internals - PHP Runtime Development Mailing List To 
> unsubscribe, visit: http://www.php.net/unsub.php
> 

I've run into problems with 

$foo[1]();

If the closure attempts to change the value of $foo[1] then PHP
complains.
So was forced to assign to a temporary variable before hand.

$f = $foo[1];
$f();

I guessing foo()() could also suffer from the problem?

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

[Jared Williams]

 

> -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|1 // $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|1format(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)

[Jared Williams]

 

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

[Jared Williams]

 

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

[Jared Williams]

 

> -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[]=isset rfc/ifsetor?s%5B%5D=isset>)
> and it's rejection point was that it was currently not possible (
> http://marc.info/?l=php-internals&m=108931281901389&w=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.

[Jared Williams]

 

> -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 :
> > 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=ZEND002498&r=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()

[Jared Williams]

 

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

[Jared Williams]

 

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

[Jared Williams]

 

> -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] alpha3 or forever hold your peace

[Jared Williams]

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

[Jared Williams]

 

> -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] [RFC] Iteration tools

[Jared Williams]

"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()

[Jared Williams]

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

[Jared Williams]

 

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

[Jared Williams]

 

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

[Jared Williams]

 

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

[Jared Williams]

 

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

[Jared Williams]

 

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

[Jared Williams]

 

> -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 " > keep " 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.
> 
> 
> 
> 
> 
> 

The problem I have with 





So  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

[Jared Williams]

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-internals&m=111384113712112&w=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

[Jared Williams]

I think they end up using the dependency injection pattern. 

http://www.picocontainer.org/ java implementation with a PHP port.

http://sourceforge.net/projects/phemto/ is a more lightweight PHP
implementation. Its README
http://phemto.cvs.sourceforge.net/phemto/phemto/README?revision=1.1.1.1&view
=markup .


Problem is the cost of setting up these, by registering implementations,
performing reflection and so on is expensive especially considering the
stateless nature of PHP. 

J


> -Original Message-
> From: Stanislav Malyshev [mailto:[EMAIL PROTECTED] 
> Sent: 02 October 2007 21:21
> To: Sebastian Bergmann
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Class Posing
> 
> >  Stubs / Mock Objects !== Unit Tests. Class Posing allows 
> for better  
> > stubs / mock objects which in turn are tools to write better unit  
> > tests.
> 
> OK, I see that. The question is - does any of the known unit 
> test systems use mock objects? Does it do that in the 
> language that doesn't allow "new Foo" to create object of 
> entirely unrelated class? If so - how it is usually done?
> --
> Stanislav Malyshev, Zend Software Architect
> [EMAIL PROTECTED]   http://www.zend.com/
> (408)253-8829   MSN: [EMAIL PROTECTED]
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

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

RE: [PHP-DEV] Class Posing

[Jared Williams]

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

[Jared Williams]

 
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

[Jared Williams]

 

> -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] PHP Unicode extension in PHP6

[Jared Williams]

 

> -Original Message-
> From: Tomas Kuliavas [mailto:[EMAIL PROTECTED] 
> Sent: 21 May 2007 19:26
> To: Andrei Zmievski
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] PHP Unicode extension in PHP6
> 
> >> 0xC4 and 0x85 are hex codes for latin small letter a with 
> ogonek in 
> >> utf-8. ą
> >>
> >>  >> var_dump("ą" == "\xC4\x85");
> >> echo "ą\n";
> >> echo "\xC4\x85";
> >> ?>
> >>
> >> If script is written in utf-8, I expect bool(true) on 
> var_dump() line.
> >
> > var_dump("ą" == b"\xC4\x85");
> >
> > This will give you what you want, if the script is written in UTF-8 
> > and your runtime encoding is set to UTF-8.
> >
> >>  >> // example uses utf-8. similar code is used in iso-8859-2 - // 
> >> iso-8859-16 decoding. utf-8 decoding does not need mapping 
> tables // 
> >> and is written in pcre.
> >> $s1 = "ą";
> >> $s2 = "\xC4\x85";
> >> echo str_replace($s2,'ą',$s1);
> >> ?>
> >>
> >> Expected result: ą
> >> Got: ą
> >>
> >> test setup (php6.0-200705190630) uses trimmed php.ini with only 
> >> unicode.semantics=on setting
> >>
> >> unicode.fallback_encoding - no value
> >> unicode.filesystem_encoding - no value 
> unicode.http_input_encoding - 
> >> no value unicode.output_encoding - no value 
> unicode.runtime_encoding 
> >> - no value unicode.script_encoding - no value 
> unicode.semantics - On 
> >> unicode.stream_encoding - UTF-8
> >
> > Why didn't you set any encoding settings?
> 
> They are not documented and I am testing configurations that 
> might break scripts. If I test things and want to make code 
> portable, configuration is not supposed to be rational. I can 
> set option with ini_set(), if I understand what option does 
> and it fixes the issue.
> 
> http://www.php.net/unicode
> 
> Do you have updated documentation version which explains 
> encoding settings and lists available configuration values? 
> Or am I testing PHP6 too early and you are still months or 
> years away from 6.0.0 betas and rcs? Could you implement 
> pseudo encoding similar to 'pass' encoding used in mbstring?
> Current implementation does not give controls needed by 
> script writers.
> 
> SquirrelMail scripts are not written in unicode. They are in 
> ascii. If some 8bit value is used, it is always written in 
> octal or hex notation.
> These hex values are not written in one character set. In 
> some cases scripts use byte values. For example, locating 
> first utf-8 byte or looking for 0x80-0xFF bytes in string. In 
> other cases they are written in source or target character 
> set. For example, iso-8859-2 decoding function contains array 
> with iso-8859-2 hex values mapped to html codes. Code can't 
> use raw 8bit strings, because they might be corrupted in 
> misconfigured editor used by developer and it is very hard to 
> track such corruption.
> 8bit data can come only from user input (composed emails and 
> preferences, html forms, one common charset) and imap server 
> (received emails, lots of different charsets and encodings).
> 

Recent versions of PHP5, has a binary string introducer.

echo strlen(b"\xC4\x85");

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

[Jared Williams]

 

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

[Jared Williams]

 
> >  > 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] Problems with APC

[Jared Williams]

 

> -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] RfC: rethink OO inheritance strictness

[Jared Williams]

  
> 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

[Jared Williams]

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

[Jared Williams]

 

> -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] testing filter ext in RC1

[Jared Williams]

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] Adding pecl/zip to 5.2

[Jared Williams]

 
> 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] RfC: rethink OO inheritance strictness

[Jared Williams]

> 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 
> -d"error_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 
> -d"error_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] Re: PEAR::Date broken (Was: [PHP-CVS] cvs: php-src(PHP_5_2) /ext/date php_date.c php_date.h)

[Jared Williams]

 

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

[Jared Williams]

 

> -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] Re: [PHP-I18N] RFC: Error handling in HTTP input decoding

[Jared Williams]

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

[Jared Williams]

  
> 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] RFC: Error handling in HTTP input decoding

[Jared Williams]

 

> -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-8&p=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

[Jared Williams]

> 
> > 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 = b"This 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

[Jared Williams]

 

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

[Jared Williams]

> 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

[Jared Williams]

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

[Jared Williams]

 
> 
> 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] Stop Breaking Our Apps For the Sake of OO

[Jared Williams]

> 
> 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] #line C macro equivalent in php ?

[Jared Williams]

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

 

> -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:
> 
> 
> 
> I've one more of those things. How to test if you're using 
> PHP 5.1 or PHP 5.2:
> 
>  
> 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] Re: Stop Breaking Our Apps For the Sake of OO

[Jared Williams]

> 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] array type hint and SPL array interfaces

[Jared Williams]

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

RE: [PHP-DEV] PHP 5.1.3, IIS & FastCGI

[Jared Williams]

 
> > 
> > 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] PHP 5.1.3, IIS & FastCGI

[Jared Williams]

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

[Jared Williams]

 
>  
> 
> > -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\tests>pslist 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\tests>wget -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\tests>pslist 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

[Jared Williams]

 

> -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\tests>pslist 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\tests>wget -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\tests>pslist 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

[PHP-DEV] PHP 5.1.3, IIS & FastCGI

[Jared Williams]

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] ext/filter, add input_get_args, support of scalar orarray result

[Jared Williams]

 

> -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] RE: [PHP-DOC] Re: [PHP-DEV] Summer of Code

[Jared Williams]

 
> > How about moving away from using system entities to construct the 
> > manual and using Xinclude instead? (See the mysql ref 
> manual docbook 
> > sources) This would make the base pages independent from 
> each other, and loadable into a DOMDocument, which could be 
> transformed with xslt.
> 
> for what it's worth: my end-user experience of (and that of 
> pretty much everyone in php-land I work with/ speak to) is 
> that the mysql docs are a dog to work with and the the php 
> docs are in comparison a delight.

I'm not sure what you mean by end-user experience. Xinclude is just another 
mechanism for including a file in xml. 

Livedocs currently has todo a fair bit of work dealing with entities. Making 
each of the .xml files standalone would simplify it a
lot. 

I did attempt to write a custom user stream that injected entity definitions 
into an xml file, so you could load a raw page of the
manual directly into a DOMDocument and apply a xsl transform. Didn't have 
enough time/patience to get it working tho :)

Jared

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

[PHP-DEV] RE: [PHP-DOC] Re: [PHP-DEV] Summer of Code

[Jared Williams]

 

> -Original Message-
> From: Gabor Hojtsy [mailto:[EMAIL PROTECTED] 
> Sent: 15 April 2006 13:24
> To: Nuno Lopes
> Cc: Rasmus Lerdorf; internals; PHPdoc
> Subject: Re: [PHP-DOC] Re: [PHP-DEV] Summer of Code
> 
> Nuno Lopes wrote:
> >> Google is doing their Summer of Code thing again this 
> year.  You can 
> >> read more about it here: http://code.google.com/summerofcode.html
> > 
> > This year I might participate. I would like to do something in the 
> > core or even in the zend engine. I'll think in something.. 
> (I'm also 
> > open to suggestions, of course).
> > 
> > I would also like to propose a project related with the 
> documentation 
> > team, which is very useful to us:
> > * working on livedocs (rewriting the indexer, improving docbook 
> > compat, pear/gtk/smarty docs support, php 6 support, etc..)
> 
> +1 for someone cleaning up livedocs to a ready-to-deploy state :)

How about moving away from using system entities to construct the manual and 
using Xinclude instead? (See the mysql ref manual
docbook sources) This would make the base pages independent from each other, 
and loadable into a DOMDocument, which could be
transformed with xslt.

Jared

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

RE: [PHP-DEV] open_basedir_for_include

[Jared Williams]

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

  
> Sorry, I meant to send my first mail to the entire list about 
> this, but http://pastebin.com works fine here in firefox, 
> although Jared Williams reported back that it pastes the line 
> numbers for him.
> Version and OS differences perhaps? I don't have a machine to 
> test IE6, so I'm not sure about that, but Firefox is possible 
> at least.

Firefox 1.5.0.1 on Win2K is copying line numbers if select the whole of the 
source, or if just select a few lines, hashes (#) appear
instead.

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]

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

[Jared Williams]

 

> > Patches have been written and languish simply awaiting inclusion in 
> > HEAD
> 
> Johannes' method (..) 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

[Jared Williams]

> 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

[Jared Williams]

> 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

[Jared Williams]

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

RE: [PHP-DEV] [PATCH] Custom Streams, fclose & stream_close

[Jared Williams]

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

[PHP-DEV] Custom Streams, fclose & stream_close

[Jared Williams]

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