Re: [PHP-DEV] PHP User Survey

[Pierre Joye]

Hi Chris,
On Feb 20, 2013 9:36 PM, "Christopher Jones" 
wrote:

>
> My thesis is the other way round.  More people in the community need
> to become PHP core developers.  This is historically how PHP
> development has occurred, since nobody has idle time to adopt projects
> they are not 100% behind.

We have more new active contributors than ever before. Actually the top 5
contributors are here for less than a couple of years or even less than one.

> Increasing user involvement is easier (and more often) said than done.
> I'd prefer to see effort spent mentoring, rather than running surveys.

Having our user at large express their needs or opinion is about
contributing. It is actually the very first step to contribution.

> I do have a lot of reservations about a survey.  But if you do run
> one, I'm sure I'll look at the results.

I do not have a single doubt. Why? Surveys are one of many ways to get
feedback. They have no contracting values but give us some numbers about
one rfc or another. That may help us to focus on one feature instead of
another if we see a large number of users looking forward to it.

Cheers,

[PHP-DEV] Pull request for array_filter() improvement

[Tjerk Anne Meesters]

Hi,

I found myself wanting a feature of array_filter() with which I can perform
filtering based on the array key instead of the value.

To scratch this itch, I decided to dive into C again and just add the
feature. My proposal is to add a third argument to array_filter() that will
send the array keys to the callback.

function myfilter($value, $key)
{
return $key > 4;
}

array_filter([1, 2, 3, 4, 5, 6, 7], 'myfilter', true);
// returns: [6, 7]


The pull request can be found here: https://github.com/php/php-src/pull/287

If this is useful for the language as a whole, do let me know what else I
should do to champion it.

Thanks!

-- 
--
Tjerk

[PHP-DEV] ArrayObject Odd Behavior

[Mike Willbanks]

Hello Again,

I wanted to bring back the topic I started on ArrayObject; I've been doing
a ton of work with ArrayObject lately and finding some odd behavior.
 Firstly it would be great to know if these are by design or bugs.
 Secondly there are some areas where it likely needs to be improved.

1: ArrayObject return by reference:
Yes, you can tell offsetGet and __get to return by a reference; however, in
the case of multi-dimensional arrays it will not work due to the internal
implementation of ArrayObject.  Internally it stores everything in a
private variable "storage" which is an instance of an ArrayObject.
 Unfortunately since it is a regular instance of an ArrayObject and not one
of the current declarations it will pose issues when attempting to unset
variables.

Example:
class myArrayObject extends ArrayObject
{
public function &offsetGet($key) {
$var =& $this->storage[$key];
return $var;
}
}
$ao = new myArrayObject(array('foo' => array('bar' => 'baz')));
unset($ao['foo']['bar']);
PHP Notice:  Indirect modification of overloaded element of myArrayObject
has no effect

2: ArrayObject and Iterators:
For some reason when you do an exchangeArray with an iterator, it basically
does a type cast leaving you with an array key of the iterator class name
appended with "var".  Unfortunately this key is "special" or something
because it cannot be accessed, isset returns false but you can get to your
records by either foreach or shifting or popping the array.  Not really
certain if this is intended at all and if so might need to be reworked?

Example:
var = $array;
}
}

public function rewind() {
reset($this->var);
}

public function current() {
return current($this->var);
}

public function key() {
return key($this->var);
}

public function next() {
return next($this->var);
}

public function valid() {
$key = key($this->var);
$var = ($key !== NULL && $key !== FALSE);
return $var;
}
}

$ao = new ArrayObject();
$mi = new MyIterator(array('foo' => 'bar'));
$ao->exchangeArray($mi);

$array = $ao->getArrayCopy();
var_dump($array);
var_dump(isset($array['MyIteratorvar']));
$params = array_shift($array);
var_dump($params);
var_dump(isset($params['foo']));

This will output:
array(1) {
  ["MyIteratorvar"]=>
  array(1) {
["foo"]=>
string(3) "bar"
  }
}
bool(false)
array(1) {
  ["foo"]=>
  string(3) "bar"
}
bool(true)


That one had me dumb founded for a while; you can see this behavior just as
easy by doing it directly on the iterator itself and type casting it to an
array.

Example:
$ir = new MyIterator(array('foo' => 'bar'));
var_dump((array) $ir);

Anyhow it would be good to know your thoughts; on these two things.  I
believe there is a bug ticket already for the first item; the second item
 I didn't see anything within the first few pages but maybe I'm searching
for it without the right keywords.

Thanks for listening!

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Ryan McCue]

Levi Morrison wrote:
>>  - 5.3: goto. A good thing we can do it. I'm not sure for what exactly but I 
>> am sure there is somebody out there :)
> 
> An associate of mine used it in his HTTP message parser. He's sure
> glad it's there :)
> 

Conversely, I have two HTTP message parsers that I maintain, and neither
of them use goto. Certainly possible to avoid it there.

That said, I do think goto has legitimate uses, even if I don't need it.

-- 
Ryan McCue


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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Levi Morrison]

>  - 5.3: goto. A good thing we can do it. I'm not sure for what exactly but I 
> am sure there is somebody out there :)

An associate of mine used it in his HTTP message parser. He's sure
glad it's there :)

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

Re: [PHP-DEV] [RFC] send/recvmsg() wrappers in ext/socket

[Ferenc Kovacs]

On Tue, Jan 22, 2013 at 6:23 PM, Gustavo Lopes wrote:

> https://wiki.php.net/rfc/**sendrecvmsg
>
> The module ext/sockets, a wrapper around the sockets API, does not include
> support to recvmsg() and sendmsg(). This RFC addresses this shortcoming by
> support introducing limited (only a few types of messages are supported)
> support for these functions.
>
> --
> Gustavo Lopes
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Hi Gustavo,

Could you update the status of the RFC and list it on
https://wiki.php.net/rfc/ ?

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] PHP causing high number of NFS getattr operations?

[Terry Ellison]

On 20/02/13 23:52, Brendon Colby wrote:

Terry,

Thanks for your detailed input. This is essentially what I did in my test setup.

APC is definitely critical to the performance of our site. I'm just
very curious to see how much impact the high number of getattr
operations coming from the Apache/PHP servers is having on the filer.
It looks like we might be able to move our PHP files to local storage
to at least measure the impact this is having.

Brendon


Brendon,

I think that PHP is a great platform; it's just that PHP's sweet spot is 
just a little off the optimum for typical scalable enterprise 
infrastructures.  IMO, the main issue that you should consider and 
discuss with your infrastructure support team is how to mitigate the 
impacts for such high-throughput business critical applications. As you 
(and Rasmus previously, IIRC) mention one key issue is what is on local 
and what is on network attached storage.


On one system that I got hauled in to troubleshoot, it turned out that 
the main problem was that the PHP session data was being written to a 
directory in shared storage, causing write-though overload that ended up 
hitting half a dozen key apps.  It was a trivial configuration change to 
move it to local storage transforming performance.  (I apologise if I am 
telling how "to suck eggs" but this is really for others tracking this 
thread) the main issue here is that the file hierarchies that must have 
some integrity over the application tier need to be on the NAS, 
everything else is a matter of convenience vs performance, so for 
example having a cron job to rsync the apps PHP hierarchy onto local 
storage might well transform your app performance and give an indirect 
boost to cohosted apps.  Happy hunting :)

Re: [PHP-DEV] PHP 6 : a new API ?

[Michael Shadle]

On Wed, Feb 20, 2013 at 3:23 PM, Wim Godden  wrote:

> I agree that in most cases, that's a good thing. But it's also how we ended
> up with a thing called the Y2k problem : stuff running forever.
>
> Disclaimer : I've been developing with PHP since 1997, so I'm very fond of
> the language. "If it ain't broke, don't fix it" is true, but I think we can
> all admit that on consistency level PHP has been at least badly damaged from
> the start. So maybe we need to think about fixing at least some parts of it.

I wouldn't compare the two... I'm not using deprecated stuff (although
it might be someday :() mainly just saying while everyone has been
extending PHP into Java-land, JSON-esque short arrays, lots more OO
fun, namespaces, etc... I could still code anything out of the box
with procedural PHP 5.2.x for the most part (with only a couple
function and parameter additions added in 5.3/5.4)

I've never had any APC issues - whereas OO code has had odd
incompatibilities, and IMHO the obsession with OO has introduced more
complexity into the language and everything related to it. Not the
popular opinion I know, but that's what open source is all about,
right?

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

Re: [PHP-DEV] PHP causing high number of NFS getattr operations?

[Brendon Colby]

On Tue, Feb 19, 2013 at 11:06 AM, Terry Ellison  wrote:
> Brendon,
>
> Just to follow up with a bit more detail, apart from the obvious NFS tuning
> with things like the actimeo mount parameters, you can get a better idea of
> what is going on if you use a local copy of one of your apps running under a
> local linux apache server.  This is an example from my Ubuntu laptop, but it
> works just as well on a test VM if you still use WinXX on your PC.
>
> trace_wget () {
>   sleep 1
>   coproc sudo strace -p $(ps -C apache2 --no-headers -o pid) -tt -o
> /tmp/strace$1.log
>   sleep 1; ST_PID=$(ps -C strace --no-headers -o pid)
>   wget "http://localhost/$2"; -O /dev/null -o /dev/null
>   sleep 2; sudo kill $ST_PID
> }
> # start Apache in debug mode
> sudo service apache2 stop
> sudo bash -c ". /etc/apache2/envvars; coproc apache2 -X"
>
> # trace three gets
> trace_wget 0 phpinfo.php
> trace_wget 1 mwiki/index.php?title=Main_Page
> trace_wget 2 mwiki/index.php?title=Main_Page
>
> #restart normally
> sudo service apache2 stop
> sudo service apache2 start
> sudo chmod 777 /tmp/strace?.log
>
> grep -c "open(" /tmp/strace?.log
> grep -c "stat(" /tmp/strace?.log
>
> The first get is just to load and prime the mod_php5 thread (Ubuntu has a
> crazy localtime implementation), the second loads and compiles the PHP
> MediaWiki modules needed to render a page, the third repeats this now fully
> cached in ACP.  In this case,
> we have:
>
>   open()fstat()/lstat()
> /tmp/strace1.log   108   650  (Priming the APC cache)
> /tmp/strace2.log27   209  (Using the APC cache)
>
> So APC *does* materially reduce the I/O calls, and (if you look at the
> traces) it removes most of the mmaps and compilation.  The MWiki autoloader
> uses require() to load classes but in the code as a whole the most common
> method of loading modules is require_once() (414 uses as opposed to 44 in
> total of the other include or require functions) and as I said in my
> previous post, this I/O is avoidable by recoding the ZEND_INCLUDE_OR_EVAL
> hander to work cooperatively with the opcode cache when present.
>
> Note that even when the cache does this, it still can't optimize coding
> patterns like:
>
> if ( file_exists( "$IP/AdminSettings.php" ) ) {
> require( "$IP/AdminSettings.php" );
> }
>
> and IIRC mwiki does 4 of these on a page render.  Here a pattern based on
> (@include($file) == 1) is more cache-friendly.
>
> Now this isn't a material performance issue when the code tree is mounted on
> local storage (as is invariably the case for a developer test configuration)
> as the stat / open overhead of a pre-(file) cached file is microseconds, but
> it is material on scalable production infrastructure which uses network
> attached NFS or NTFS file systems.
>
> So in summary, this is largely avoidable but unfortunately I don't think
> that we can persuade the dev team to address this issue, even if I gave them
> the solution as a patch :-(
>
> Regards
> Terry Ellison

Terry,

Thanks for your detailed input. This is essentially what I did in my test setup.

APC is definitely critical to the performance of our site. I'm just
very curious to see how much impact the high number of getattr
operations coming from the Apache/PHP servers is having on the filer.
It looks like we might be able to move our PHP files to local storage
to at least measure the impact this is having.

Brendon

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

Re: [PHP-DEV] PHP 6 : a new API ?

[Wim Godden]

Michael Shadle wrote:

I'm aware people complain about PHP flaws, but having misc global core 
functions for strings, arrays and other data types is a new one.

I am still a purest at heart and don't see the need for namespacing in general. 
I am thinking it provides some lower level memory space improvements and less 
conflicts, but I feel like if you can't code in global space perhaps you should 
be rethinking how you code. I don't think most people care about the lower 
level advantages, they're just looking at it from a code laziness perspective.

Why make \bar\baz\foo() or $bar->baz->foo() instead of bar_baz_foo()? Prefixing 
functions seems perfectly effective. I see a lot of code that looks like they're 
using namespaces or OO just to group things together and organize code in some 
fashion. Not because there's any inherent benefit.

I'd much rather see effort taken on renaming functions to be more consistent, 
and making needle/haystack consistent, and maybe throw in named parameters. PHP 
is getting too complex as it is.
  
I've been talking to people about this concept for 2-3 years and get 
mixed responses about it.
Although my approach is slightly different : instead of just namespacing 
existing functions, I'd go the extra mile to resolve the inconsistencies 
that PHP has had to live with for so long. So for example :
- str_replace would have an identical function called String_replace (or 
\String\replace if you really want to have the namespacing, which 
actually wouldn't be required and might even cause conflicts for certain 
code already using namespaces with certain names)
- strpos --> String_position with a needle/haystack that's consistent 
with String_replace

- etc.
The old functions would remain, so old code still works as before. 
Deprecating those old functions could be something for 6.2 or so, with 
actual removal for 7.0, meaning it provides people a full major release 
to adapt, which is much more gentle than what Python did. Given that PHP 
5 is now almost 9 years old, if future major PHP releases follow the 
same pace, that should be enough time to declare 10-year old PHP code 
EOL ;-)
Additionally, a lot of code could be 'fixed' automatically, since the 
functions would be identical, perhaps only differing in the parameter 
order, which is not an issue for automatic changes either.


In fact, the concept is not really new. DateTime is probably the best 
existing example of such an implementation. We had to live with 
date_add, date_create, date_diff and so on, but DateTime provides a 
clearer, more consistent approach, one that could be replicated for most 
of the other language features.


Pros :
- Clearer naming, obviously.
- Consistency across the board, in names and parameters
- Easier for non-PHP developers to switch to the language. Now many of 
them see the mess that function names in PHP is (underscored, not 
underscored, with prefix, without prefix, 'to' written as 'to', 'to' 
written as 2, etc.) and they instantly turn back


Cons :
- There will be a very small performance hit, since 1 of the 2 will 
always be an alias for the other, be it with possible changed parameter 
order
- More typing - yes, the names will (usually) be longer. But that's what 
auto-complete is for...
- We'll be stuck with 2 names for every function for an entire major 
release and the parameter order would be different for some of them.

- Purists will say that we're breaking their language.


PHP purest at heart, (who has code that has lasted for a decade and multiple 
major php code changes still did not break it)
  
I agree that in most cases, that's a good thing. But it's also how we 
ended up with a thing called the Y2k problem : stuff running forever.


Disclaimer : I've been developing with PHP since 1997, so I'm very fond 
of the language. "If it ain't broke, don't fix it" is true, but I think 
we can all admit that on consistency level PHP has been at least badly 
damaged from the start. So maybe we need to think about fixing at least 
some parts of it.
Don't get me wrong, I know it's not as easy as switching a incandescent 
light bulb to a led light bulb, but the hardest job will be deciding on 
the names themselves. But if we can find a common ground there (yes, 
yes, I'm dreaming), we might finally get a trully consistent set of core 
functions in PHP. And although it might not be the most critical 
improvement PHP needs, it most certainly would be one we could publicly 
brag about.


Just my 2 cents...


Kind regards,

Wim

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Lars Strojny]

As a general reply: I’d like to disagree, and here is why. Yes, we should not 
let half baked features in but we need to add more and more features, also 
syntax wise. For three reasons:


 - Parity/expectations/me too: so you can do that in PHP as well
 - Expressiveness: allow better ways to express the same idea in more concise 
ways
 - Innovation: bring unexpected features to the language people didn’t even 
expect


Let’s recall a few of the latest additions:


 - 5.3: namespaces. Provided the foundation for awesome stuff like PSR-1, which 
in turn provides the foundation for the even more awesome stuff composer is.
 - 5.3: goto. A good thing we can do it. I'm not sure for what exactly but I am 
sure there is somebody out there :)
 - 5.3: Closures, huge thing for us, a matter of parity to other languages. 
Really changes the face of a lot of APIs (see e.g. Doctrine transactional(), 
the whole micro framework movement, React)
 - 5.4: Closures 2.0 with $this binding. Honestly, without it, Closures are a 
little meh. But it was good we waited and got it right.
 - 5.4: Short array syntax. A parity/culture issue.
 - 5.4: Traits, I am happy we got horizontal reuse right
 - 5.4: array dereferencing. Very small but useful. To me it feels more like a 
bugfix
 - 5.4: callable type hint. Small change with a huge impact
 - 5.5: Generators, also a matter of parity and a matter of awesomeness
 - 5.5: ClassName::class syntax. A really good improvement to the overall 
usability of namespaces. Just imagine how much shorter unit test setUp() 
methods will become


What we have on our list that, from my perspective, will sooner or later hit us:


 - Property accessors in some form or another: a lot of people seem to like it.
 - Annotation support: we would have a lot of customers for it.
 - Autoboxing for primitives. Allows us to fix a lot of problems in 
ext/standard.
 - Unicode. Obviously.
 - Named parameters. A recurring topic might be a topic worth digging deeper.
 - I'm positive the Generics discussion will arise at some point again.


… and these are just the changes on a syntax/semantics level, I'm not talking 
about all the awesome technologies (one of which you are working on) we need to 
integrate tighter and eventually bundle with core. I don’t believe we should 
let our users outgrow the language, quite the opposite, we should grow with our 
users and the broader web community, otherwise we will fail. PHP is nowadays 
used for tasks it never was intended to be used but that’s a good thing. We 
need to continuously adapt. What’s true for software projects is true for 
languages: stop improving actually reduces its value over time.

cu,
Lars

Am 20.02.2013 um 19:18 schrieb Derick Rethans :

> Looks like it is time to forward this email from 2006 again:
> 
> -- Forwarded message --
> Date: Thu, 09 Mar 2006 12:57:32 +0200
> From: Zeev Suraski 
> To: internals@lists.php.net
> Subject: [PHP-DEV] Give the Language a Rest motion
> 
> I'd like to raise a motion to 'Give the Language a Rest'.
> 
> Almost a decade since we started with the 2nd iteration on the syntax (PHP 3),
> and 2 more major versions since then, and we're still heatedly debating on
> adding new syntactical, core level features.
> 
> Is it really necessary?  I'd say in almost all cases the answer's no, and a
> bunch of cases where a new feature could be useful does not constitute a good
> enough reason to add a syntax level feature.  We might have to account for new
> technologies, or maybe new ways of thinking that might arise, but needless to
> say, most of the stuff we've been dealing with in recent times doesn't exactly
> fall in the category of cutting edge technology.
> 
> My motion is to make it much, much more difficult to add new syntax-level
> features into PHP.  Consider only features which have significant traction to 
> a
> large chunk of our userbase, and not something that could be useful in some
> extremely specialized edge cases, usually of PHP being used for non web stuff.
> 
> How do we do it?  Unfortunately, I can't come up with a real mechanism to
> 'enforce' a due process and reasoning for new features.
> 
> Instead, please take at least an hour to bounce this idea in the back of your
> mind, preferably more.  Make sure you think about the full context, the huge
> audience out there, the consequences of  making the learning curve steeper 
> with
> every new feature, and the scope of the goodness that those new features 
> bring.
> Consider how far we all come and how successful the PHP language is today, in
> implementing all sorts of applications most of us would have never even 
> thought
> of when we created the language.
> 
> Once you're done thinking, decide for yourself.  Does it make sense to be
> discussing new language level features every other week?  Or should we, 
> perhaps,
> invest more in other fronts, which would be beneficial for a far bigger
> audience.  The levels above - extensions to keep with

Re: [PHP-DEV] Getting separate outputs with Date Functions

[Kris Craig]

On Wed, Feb 20, 2013 at 11:54 AM, David Soria Parra  wrote:

> On 2013-02-19, Stas Malyshev  wrote:
> > Hi!
> >
> >> echo date_create('@1361240634')->format('Y-m-d');
> >> // output: 2013-02-19
> >>
> >> echo date('Y-m-d',1361240634);
> >> // output: 2013-02-18
> >
> > timestamp dates are created with UTC TZ, date() assumes your configured
> TZ.
>
> I ran into this myself and I personally consider date() assuming your
> configured TZ A bug. Timestamps are defined as UTC and the behaviour of
> DateTime is correct there, that it always assume UTC. date() should do
> the same. But then date() behaviour has been that way since ages
> and probably a lot of code out there is assuming the current TZ when
> using date().
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I'm not sure if I would go so far as to call it a bug, since that is the
intended behavior and developers tend to rely on that.  However, the
inconsistent behavior between how date() and DateTime factor timezones
should at least be documented if it isn't already.

What if we added an optional argument to date() that would allow the
developer to specify a timezone, including UTC?  The default behavior would
be the same as it is now, so there wouldn't be any BC breakage.  Thoughts?

--Kris

Re: [PHP-DEV] PHP User Survey

[Kris Craig]

On Wed, Feb 20, 2013 at 12:35 PM, Christopher Jones <
christopher.jo...@oracle.com> wrote:

>
>
> On 02/20/2013 12:00 PM, Paul Reinheimer wrote:
>
>> Hi All,
>>
>> My apologies for the intrusion, I'll keep this brief.
>>
>> In many discussions over the past few months there has been talk about
>> what
>> the community at large needs. Pierre said just earlier today:
>>
>> "I would also say it us time for us to get back in sync with the
>> communities needs. I am not talking about the last days RFCs but in
>> general."
>>
>
> Hi Paul,
>
> My thesis is the other way round.  More people in the community need
> to become PHP core developers.  This is historically how PHP
> development has occurred, since nobody has idle time to adopt projects
> they are not 100% behind.
>
> Increasing user involvement is easier (and more often) said than done.
> I'd prefer to see effort spent mentoring, rather than running surveys.
>
> I do have a lot of reservations about a survey.  But if you do run
> one, I'm sure I'll look at the results.
>
> Chris
>
> --
> christopher.jo...@oracle.com  http://twitter.com/ghrd
> Newly updated, free PHP & Oracle book:
> http://www.oracle.com/**technetwork/topics/php/**
> underground-php-oracle-manual-**098250.html
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I agree that we need more core devs (myself included), but I think it's
worth remembering that most PHP developers are not programmers who would be
comfortable working in ANSI C.  The point of a survey would be to guage
what PHP users want.  Whether or not we choose to act on that would be up
to the actual core devs, but at least we would have some helpful data on
what the average PHP developer would like to see.

We could probably mitigate your concern (and please correct me if I'm wrong
on this assumption) by making it clear in the RFC that these survey results
are completely non-binding and intended for informational purposes only.

[PHP-DEV] PHP User Survey

[Paul Reinheimer]

Hi All,

My apologies for the intrusion, I'll keep this brief.

In many discussions over the past few months there has been talk about what
the community at large needs. Pierre said just earlier today:

"I would also say it us time for us to get back in sync with the
communities needs. I am not talking about the last days RFCs but in
general."

The other point that comes up is the difficulty in reaching a large portion
of the community. They don't come to conferences, they don't sit on this
list, they don't go to user groups. They work with PHP for months or years,
but the rest of the "community" doesn't even know who they are. I believe
Rasmus has mentioned this on a few occasions.

So my suggestion is simple, let's ask them: What they want, What they need,
how they installed PHP (source, rpm, deb, provided by hosting provider,
Zend Server), etc. Let's create a survey, and link to it prominently on
php.net. I considered just writing a survey myself, but even if everyone I
knew tweeted it I'd still lack the reach to hit those outside the
traditional community.


While this is clearly not a suggestion to change PHP, i'll write this up in
RFC format if there's interest. Should give people an opportunity to
discuss questions and such.


thanks for your time
paul


-- 
Paul Reinheimer

Re: [PHP-DEV] Getting separate outputs with Date Functions

[David Soria Parra]

On 2013-02-19, Stas Malyshev  wrote:
> Hi!
>
>> echo date_create('@1361240634')->format('Y-m-d');
>> // output: 2013-02-19
>> 
>> echo date('Y-m-d',1361240634);
>> // output: 2013-02-18
>
> timestamp dates are created with UTC TZ, date() assumes your configured TZ.

I ran into this myself and I personally consider date() assuming your
configured TZ A bug. Timestamps are defined as UTC and the behaviour of
DateTime is correct there, that it always assume UTC. date() should do
the same. But then date() behaviour has been that way since ages
and probably a lot of code out there is assuming the current TZ when
using date().

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

Re: [PHP-DEV] PHP User Survey

[Christopher Jones]

On 02/20/2013 12:00 PM, Paul Reinheimer wrote:

Hi All,

My apologies for the intrusion, I'll keep this brief.

In many discussions over the past few months there has been talk about what
the community at large needs. Pierre said just earlier today:

"I would also say it us time for us to get back in sync with the
communities needs. I am not talking about the last days RFCs but in
general."


Hi Paul,

My thesis is the other way round.  More people in the community need
to become PHP core developers.  This is historically how PHP
development has occurred, since nobody has idle time to adopt projects
they are not 100% behind.

Increasing user involvement is easier (and more often) said than done.
I'd prefer to see effort spent mentoring, rather than running surveys.

I do have a lot of reservations about a survey.  But if you do run
one, I'm sure I'll look at the results.

Chris

--
christopher.jo...@oracle.com  http://twitter.com/ghrd
Newly updated, free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html

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

Re: [PHP-DEV] PHP User Survey

[Kris Craig]

On Wed, Feb 20, 2013 at 12:27 PM, Florin Razvan Patan  wrote:

> Hi Paul,
>
> On Wed, Feb 20, 2013 at 10:00 PM, Paul Reinheimer 
> wrote:
> > Hi All,
> >
> > My apologies for the intrusion, I'll keep this brief.
> >
> > In many discussions over the past few months there has been talk about
> what
> > the community at large needs. Pierre said just earlier today:
> >
> > "I would also say it us time for us to get back in sync with the
> > communities needs. I am not talking about the last days RFCs but in
> > general."
> >
> > The other point that comes up is the difficulty in reaching a large
> portion
> > of the community. They don't come to conferences, they don't sit on this
> > list, they don't go to user groups. They work with PHP for months or
> years,
> > but the rest of the "community" doesn't even know who they are. I believe
> > Rasmus has mentioned this on a few occasions.
> >
> > So my suggestion is simple, let's ask them: What they want, What they
> need,
> > how they installed PHP (source, rpm, deb, provided by hosting provider,
> > Zend Server), etc. Let's create a survey, and link to it prominently on
> > php.net. I considered just writing a survey myself, but even if
> everyone I
> > knew tweeted it I'd still lack the reach to hit those outside the
> > traditional community.
> >
> >
> > While this is clearly not a suggestion to change PHP, i'll write this up
> in
> > RFC format if there's interest. Should give people an opportunity to
> > discuss questions and such.
> >
> >
> > thanks for your time
> > paul
> >
> >
> > --
> > Paul Reinheimer
>
> Thank you for championing this. I've been promoting this kind of
> feedback for a while now.
>
> Just like the discussion I've had earlier on the IRC channel, I do
> believe that when proposals are made/are at a point where the
> internals don't agree with which solution is better and it should
> affect the community at large, it would be better to just ask the
> community and see what they want/agree on. The issue would
> be that in some cases one side would lose but the same thing
> happens when the debate is done here, on the mailing list, and
> a solution doesn't satisfy some people and ends up being the
> standard for the whole community.
>
> These votes shouldn't be seen as a must but should serve more
> as a guideline.
>
> As for the problems raised by Kris, I think that a simple system
> based on the e-mail address of the voter with some prior
> confirmation / pending approval, like for the mailing lists, should
> be enough to grant the right to vote or not. Even if some people
> were to have multiple accounts, I don't think they'd go to the
> trouble of spawning a very large number of e-mail addresses just
> to see their favorite option accepted.
>
> I'd be more that happy to provide any help possible for the RFC
> as well as the survey / surveys themselves.
>
>
>
> Best regards.
> 
> Florin Patan
> https://github.com/dlsniper
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Agreed on all of your points, Florin.  Perhaps the three of us can make
this a collaborative effort if everyone's willing.

--Kris

Re: [PHP-DEV] PHP User Survey

[Florin Razvan Patan]

Hi Paul,

On Wed, Feb 20, 2013 at 10:00 PM, Paul Reinheimer  wrote:
> Hi All,
>
> My apologies for the intrusion, I'll keep this brief.
>
> In many discussions over the past few months there has been talk about what
> the community at large needs. Pierre said just earlier today:
>
> "I would also say it us time for us to get back in sync with the
> communities needs. I am not talking about the last days RFCs but in
> general."
>
> The other point that comes up is the difficulty in reaching a large portion
> of the community. They don't come to conferences, they don't sit on this
> list, they don't go to user groups. They work with PHP for months or years,
> but the rest of the "community" doesn't even know who they are. I believe
> Rasmus has mentioned this on a few occasions.
>
> So my suggestion is simple, let's ask them: What they want, What they need,
> how they installed PHP (source, rpm, deb, provided by hosting provider,
> Zend Server), etc. Let's create a survey, and link to it prominently on
> php.net. I considered just writing a survey myself, but even if everyone I
> knew tweeted it I'd still lack the reach to hit those outside the
> traditional community.
>
>
> While this is clearly not a suggestion to change PHP, i'll write this up in
> RFC format if there's interest. Should give people an opportunity to
> discuss questions and such.
>
>
> thanks for your time
> paul
>
>
> --
> Paul Reinheimer

Thank you for championing this. I've been promoting this kind of
feedback for a while now.

Just like the discussion I've had earlier on the IRC channel, I do
believe that when proposals are made/are at a point where the
internals don't agree with which solution is better and it should
affect the community at large, it would be better to just ask the
community and see what they want/agree on. The issue would
be that in some cases one side would lose but the same thing
happens when the debate is done here, on the mailing list, and
a solution doesn't satisfy some people and ends up being the
standard for the whole community.

These votes shouldn't be seen as a must but should serve more
as a guideline.

As for the problems raised by Kris, I think that a simple system
based on the e-mail address of the voter with some prior
confirmation / pending approval, like for the mailing lists, should
be enough to grant the right to vote or not. Even if some people
were to have multiple accounts, I don't think they'd go to the
trouble of spawning a very large number of e-mail addresses just
to see their favorite option accepted.

I'd be more that happy to provide any help possible for the RFC
as well as the survey / surveys themselves.



Best regards.

Florin Patan
https://github.com/dlsniper

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

Re: [PHP-DEV] PHP User Survey

[Kris Craig]

On Wed, Feb 20, 2013 at 12:00 PM, Paul Reinheimer wrote:

> Hi All,
>
> My apologies for the intrusion, I'll keep this brief.
>
> In many discussions over the past few months there has been talk about what
> the community at large needs. Pierre said just earlier today:
>
> "I would also say it us time for us to get back in sync with the
> communities needs. I am not talking about the last days RFCs but in
> general."
>
> The other point that comes up is the difficulty in reaching a large portion
> of the community. They don't come to conferences, they don't sit on this
> list, they don't go to user groups. They work with PHP for months or years,
> but the rest of the "community" doesn't even know who they are. I believe
> Rasmus has mentioned this on a few occasions.
>
> So my suggestion is simple, let's ask them: What they want, What they need,
> how they installed PHP (source, rpm, deb, provided by hosting provider,
> Zend Server), etc. Let's create a survey, and link to it prominently on
> php.net. I considered just writing a survey myself, but even if everyone I
> knew tweeted it I'd still lack the reach to hit those outside the
> traditional community.
>
>
> While this is clearly not a suggestion to change PHP, i'll write this up in
> RFC format if there's interest. Should give people an opportunity to
> discuss questions and such.
>
>
> thanks for your time
> paul
>
>
> --
> Paul Reinheimer
>

I like the idea, though I would be extremely concerned about making this
survey as scientific as possible so that we don't wind up with biased or
inaccurate results.  Common examples would be duplicate voting, leading or
subjective questions, and limited sampling.  If those hurdles could be
overcome, I'm all for it.  I'd be happy to assist with the RFC and the
voting app/questions if there's sufficient interest here.

--Kris

Re: [PHP-DEV] PHP causing high number of NFS getattr operations?

[Brendon Colby]

On Mon, Feb 18, 2013 at 7:10 PM, Terry Ellison  wrote:
>
> Brendon, are your scripts doing a log of include_once / require_once calls?

Yep, but we also changed our autoload script (auto_prepend_file) to
use require instead of require_once, and we still saw the same
behavior (open calls for the PHP files required by the
auto_prepend_file same as before).

> In you look at ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER() in
> Zend/zend_vm_execute.h then you will see that this Zend handler does
> zend_resolve_path() for any xxx_ONCE instructions and zend_stream_open() on
> the first request of the same.  Yes APC rehooks this handler with a wrapper
> but this is only for lazy loading.  When it honors the xxx_once
> instructions, it will still open the streams even if the code itself is
> fully cached in APC and the I/O is entirely nugatory.  I suspect that this
> could generate the NFS traffic that you are discussing.

Yes if the streams are opened whether cached or not, then this will
result in an automatic getattr request to the NFS server which is
exactly what we're seeing.

Brendon

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

[PHP-DEV] Does ZendOptimizerPlus work on FreeBSD?

[Dmitry Stogov]

Hi,

If anyone tested ZendOptimizerPlus on FreeBSD, please let me know about
failures.
I have a report that may take me a long time to verify.

https://github.com/zend-dev/ZendOptimizerPlus/issues/32

Thanks. Dmitry.

Re: [PHP-DEV] [RFC] Short syntax for anonymous functions

[Lazare Inepologlou]

2013/2/20 Sanford Whiteman 

> > It still looks like some random characters bashed together by a monkey
> > with a keyboard.
>
> +1, I am a fiend for ternary expressions and crazy one-liners, but
> this makes me want to go back and unroll everything I've ever done
> into readable code. :)
>
> -- S.
>


Long code is not always equivalent to readable code. A shorter syntax could
improve readability in *some* cases.

Long:
$users->OrderBy( function( $x ){ return $x->Surname; } );

Short:
$users->OrderBy( $x ==> $x->Surname );



Lazare INEPOLOGLOU
Ingénieur Logiciel

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Pierre Joye]

I would also say it us time for us to get back in sync with the communities
needs. I am not talking about the last days RFCs but in general.
On Feb 20, 2013 7:19 PM, "Derick Rethans"  wrote:

> Looks like it is time to forward this email from 2006 again:
>
> -- Forwarded message --
> Date: Thu, 09 Mar 2006 12:57:32 +0200
> From: Zeev Suraski 
> To: internals@lists.php.net
> Subject: [PHP-DEV] Give the Language a Rest motion
>
> I'd like to raise a motion to 'Give the Language a Rest'.
>
> Almost a decade since we started with the 2nd iteration on the syntax (PHP
> 3),
> and 2 more major versions since then, and we're still heatedly debating on
> adding new syntactical, core level features.
>
> Is it really necessary?  I'd say in almost all cases the answer's no, and a
> bunch of cases where a new feature could be useful does not constitute a
> good
> enough reason to add a syntax level feature.  We might have to account for
> new
> technologies, or maybe new ways of thinking that might arise, but needless
> to
> say, most of the stuff we've been dealing with in recent times doesn't
> exactly
> fall in the category of cutting edge technology.
>
> My motion is to make it much, much more difficult to add new syntax-level
> features into PHP.  Consider only features which have significant traction
> to a
> large chunk of our userbase, and not something that could be useful in some
> extremely specialized edge cases, usually of PHP being used for non web
> stuff.
>
> How do we do it?  Unfortunately, I can't come up with a real mechanism to
> 'enforce' a due process and reasoning for new features.
>
> Instead, please take at least an hour to bounce this idea in the back of
> your
> mind, preferably more.  Make sure you think about the full context, the
> huge
> audience out there, the consequences of  making the learning curve steeper
> with
> every new feature, and the scope of the goodness that those new features
> bring.
> Consider how far we all come and how successful the PHP language is today,
> in
> implementing all sorts of applications most of us would have never even
> thought
> of when we created the language.
>
> Once you're done thinking, decide for yourself.  Does it make sense to be
> discussing new language level features every other week?  Or should we,
> perhaps,
> invest more in other fronts, which would be beneficial for a far bigger
> audience.  The levels above - extensions to keep with the latest
> technologies,
> foundation classes, etc.  Pretty much, the same direction other mature
> languages
> went to.
>
> To be clear, and to give this motion higher chances of success, I'm not
> talking
> about jump.  PHP can live with jump, almost as well as it could live
> without it
> :)  I'm talking about the general sentiment.
>
> Zeev
>
> --
> 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] date/strtotime poor performance - further digging (v 5.4.9)

[Ferenc Kovacs]

On Tue, Dec 4, 2012 at 5:58 PM, Paul Taulborg  wrote:

> So, I've been going through the internals of date() and related,
> trying to isolate where some poor performance is, to try and find ways
> to optimize it. In doing so, I came across this:
>
> On line 863 of ext/date/php_date.c is this code:
> } else if (*DATEG(default_timezone) &&
> timelib_timezone_id_is_valid(DATEG(default_timezone), tzdb)) {
>
> I noticed it's checking every time that the timezone is "still" valid.
> Commenting this out results in a tremendous speed increase. From my
> tests before, I saw 3.3 seconds for strtotime, and 1.75s for date.
> After commenting out the timelib_timezone_id_is_valid check above,
> speed increased to 2.3s and 1.2s respectively! (Tests are run 1
> million times each)
>
> It immediately jumped out at me, because on a few lines prior is
> initializes DATEG(default_timezone) and checks to make sure it's valid
> there. Additionally, in PHP_FUNCTION(date_default_timezone_set) it
> also checks to ensure it is a valid timezone.
>
> Having only glanced at what ini_set() does internally, I can presume
> this check is there to prevent a bad value being set via that command?
> However, I'm not certain it directly writes the value to
> DATEG(default_timezone), so it may not be relevant at all. If it does,
> some better cursory bounds checking in ini_set() might save a lot of
> redundant bounds checking during runtime calls. It would also make
> more sense to error them out on the ini_set() line rather than on a
> date() call that was the result of an improperly configured value.
>
> Rather than spending time digging into that when it may not be
> applicable I figured I'd ask here if anyone is more familiar with the
> inner-workings of ini_set and other globals that can give me some
> insight into this? Seems like an easy optimization to make, if I'm not
> missing something else.
>
> Thanks!
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Hi,

Derick, could you please spare some to look into this (and maybe to look
into the couple of patches sent to the list from Paul)?

Thanks!

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Re: [PATCH] (v 5.4.11-dev) ext/date/php_date.c cleanup

[Ferenc Kovacs]

On Fri, Dec 7, 2012 at 8:54 PM, Paul Taulborg  wrote:

> Sorry for the double message, still getting used to doing patches
> instead of applying changes directly. I accidentally attached an old
> patch file, not the latest. The previous had a bug in
> php_date_initialize() which I caught in my testing (I left the local
> variable tzi, by mistake, instead of using now->tz_info), but didn't
> regenerate the patch file. Caught up upon reviewing the patch itself
> and realizing it was the old one. :-/
>
> Attached is the proper patch, thanks.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Hi,

Could you open a bug on http://bugs.php.net/ and attach the patch (or
create a pull request and link that)?
I think it would be also useful if you could split the changes into
separate two patches: one for the whitespace changes and one for the actual
code adjustments.
Thanks!

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[PHP-DEV] Give the Language a Rest motion (fwd)

[Derick Rethans]

Looks like it is time to forward this email from 2006 again:

-- Forwarded message --
Date: Thu, 09 Mar 2006 12:57:32 +0200
From: Zeev Suraski 
To: internals@lists.php.net
Subject: [PHP-DEV] Give the Language a Rest motion

I'd like to raise a motion to 'Give the Language a Rest'.

Almost a decade since we started with the 2nd iteration on the syntax (PHP 3),
and 2 more major versions since then, and we're still heatedly debating on
adding new syntactical, core level features.

Is it really necessary?  I'd say in almost all cases the answer's no, and a
bunch of cases where a new feature could be useful does not constitute a good
enough reason to add a syntax level feature.  We might have to account for new
technologies, or maybe new ways of thinking that might arise, but needless to
say, most of the stuff we've been dealing with in recent times doesn't exactly
fall in the category of cutting edge technology.

My motion is to make it much, much more difficult to add new syntax-level
features into PHP.  Consider only features which have significant traction to a
large chunk of our userbase, and not something that could be useful in some
extremely specialized edge cases, usually of PHP being used for non web stuff.

How do we do it?  Unfortunately, I can't come up with a real mechanism to
'enforce' a due process and reasoning for new features.

Instead, please take at least an hour to bounce this idea in the back of your
mind, preferably more.  Make sure you think about the full context, the huge
audience out there, the consequences of  making the learning curve steeper with
every new feature, and the scope of the goodness that those new features bring.
Consider how far we all come and how successful the PHP language is today, in
implementing all sorts of applications most of us would have never even thought
of when we created the language.

Once you're done thinking, decide for yourself.  Does it make sense to be
discussing new language level features every other week?  Or should we, perhaps,
invest more in other fronts, which would be beneficial for a far bigger
audience.  The levels above - extensions to keep with the latest technologies,
foundation classes, etc.  Pretty much, the same direction other mature languages
went to.

To be clear, and to give this motion higher chances of success, I'm not talking
about jump.  PHP can live with jump, almost as well as it could live without it
:)  I'm talking about the general sentiment.

Zeev

-- 
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] Passing process handles to proc_open and co

[Ferenc Kovacs]

>
> Ah right, I was thinking about other handles.
>
> It seems that I may have found one possible cause, which may also
> cause the hang because we do not see the EOF. We should close the
> inherited handle after CreateProcess. And we should not always set
> inherit to true (as you stated earlier) when all 0-1 are given.
>
> I have to test all that in the coming days :)
>
>
Hi Pierre,

did you find the time to do that?
could we at least open a bug or reopen 44942 until we come up with a more
robust solution?



-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] zend_execute_internal

[Ferenc Kovacs]

On Mon, Oct 22, 2012 at 12:21 PM, Adi Mutu  wrote:

> Hello,
>
> Can somebody explain me the purpose of zend_execute_internal?
>
> Thanks,
> A.


Hi,

>From my really rough understanding that hook allows extensions to hook into
indirect (call_user_func(), array_map(), etc.) php function calls.
this is used by extensions like suhosin or xdebug where you either want to
prevent the execution of those calls or log/debug them.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Should "apc.slam_defence" and "apc.write_lock" be turned on at the same time?

[Ferenc Kovacs]

On Sun, Oct 21, 2012 at 10:26 AM, Jason Gu  wrote:

> Hi Internals
>
> I wondering if "apc.slam_defence" and "apc.write_lock" should be turned on
> at the same time?
>
> The default for APC v3.1.13 have both settings turned on.
>
> But the documentation says "apc.slam_defence is Deprecated by
> apc.write_lock."
>
> http://www.php.net/manual/en/**apc.configuration.php#ini.apc.**
> slam-defense
>
> So I'd like to know how should the settings be configured?
>
> Thanks
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
from a quick look and based on the documentation I think that the default
values should be changed as there is no reason to have the slam_defense
enabled, and on a related note the docs refer to this section as
slam_defense being an integer which controls a percentage (so valid values
are between 0 and 100) while the code seems to parse and store this as a
boolean value.
could somebody look into this and clarify the docs maybe?


-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] PHP causing high number of NFS getattr operations?

[Terry Ellison]

On 20/02/13 08:26, Stas Malyshev wrote:
That depends of what your error handlers do. Some may write to log 
files, etc. if not configured properly (since error_reporting setting 
doesn't have to be considered in it). IIRC, for most of the cases O+ 
should be able to resolve all includes/requires on cached files 
without syscalls - but file_exists is a different matter since caching 
it in generic case can be very dangerous. 
I am not suggesting caching file_exists but rather encouraging coding 
patterns which avoid its use /if/ the application is intended to give 
good cached performance -- e.g. apps like mwiki, wordpress and drupal.



I guess that I should bite the bullet and switch to 5.5.  I've been
working on an evaluatorfork of APC optimized for CLI/GCI which tackles a
lot of these issues head on and performs reasonable well, but I realise
that this is a dead-end and will never get deployed, but I am currently
considering regressing some of this technology into 5.5 and O+.  Are you
interested in a version of O+ which supports all SAPIs?

I think right now O+ can support CLI (provided enable_cli is set) but
for most cases it's kind of useless since scripts are rarely re-included
in common CLI scenarios. So if you know how to improve common CLI
scenarios it may be interesting, though I imagine it's not the most
common use case. But if it adds there without problems for anything
else, why not.
Let me get a dev stack for 5.5 and O+ up and then I can comment on 
this.  As far as APC's support for CLI goes -- the cache doesn't connect 
to the apache2 SMA even if you run the cli process in the same UID, and 
since the SMA gets released when the process count goes to zero, caching 
doesn't really do anything as the cache discarded between cli 
executions, so if practice you always run uncached.


As to the frequency of the use case, maybe not in the case of cli, but 
cgi is still tremendously common, as shared hosting providers still need 
to implement UID-based separation of scripting environments for 
different user accounts.  There are still significant scaling issues 
with php-fpm in this usecase, so only a few SHPs offer FastCGI support 
and then only as a premium option. BTW, I saw that you recommended in 
one of your blog posts that you to use a bytecode cache if you care 
about performance should do. However, a lot of app maintainers who use a 
shared hosting service do care about performance but don't have this as 
an option :-(


For example with my cli-based LPC opcode cache, I can do a series of  
"make test" runs (1) with the opcache disabled; (2) with it enabled but 
the cache empty and (3) with it enabled and the cache(s) primed.  
Ideally all three (*) should give the same test results, and this gives 
you confidence that the cache is working properly.  I would like to do 
this with APC or O+, but in practice AFAIK, I can't do (3) so how do I 
or the developers know what PHP and extension features aren't being 
supported / working properly when the code is cached?


(*) With the tests as currently written, some fail with case (3) because 
the runs are missing compiler warnings which are only generated if the 
code isn't cached (and in case of my cache at its current build quite a 
few fail because it still doesn't play nicely with other extensions like 
phar.)

Re: [PHP-DEV] [RFC] Allow trailing comma in function call argument lists

[Nikita Popov]

On Tue, Feb 19, 2013 at 1:06 PM, Sara Golemon  wrote:

> Opening RFC to allow trailing comma in function call argument lists
>
> https://wiki.php.net/rfc/trailing-comma-function-args
>

Imho this change isn't necessary (though I'm also not strongly against). I
don't really buy the VCS argument, as the usage of function argument lists
and arrays are quite different. Functions have a fixed parameter
specification, so you don't really "just add another argument" (exception:
variadics). Arrays are quite different in that regard.

Also in my personal experience people quite rarely use the
one-argument-per-line notation for functions. If the line gets to long
people split the arguments to an extra line, but usually it's not necessary
to wrap things across so many lines that these concerns become relevant. (I
mean, this is PHP and not the Win32API with 12-required-arguments
functions...)

I could see a minor benefit for code generation, though there too the
difference isn't really large (especially if you can use implode).

Nikita

Re: [PHP-DEV] Dropping requirement for `function` keyword for methods in classes/interfaces/etc

[Ferenc Kovacs]

On Wed, Feb 20, 2013 at 12:12 AM, Nikita Nefedov  wrote:

> On Tue, 19 Feb 2013 19:10:22 -, Rasmus Lerdorf 
> wrote:
>
>  On 02/19/2013 03:07 PM, Nikita Nefedov wrote:
>>
>>  Are you grepping for all the functions or you are grepping just for some
>>> specific function? If so, you are likely already know what visibility
>>> this function has, so couldn't you grep for `public %functionName%`
>>> instead of `function %functionName%`?
>>> At the end, you can always use `grep
>>> '(function|public|private|**protected) functionName' file`, and if it's
>>> long to type, you can make sh script, or even alias.
>>>
>>
>> public is the default visibility so it is often left off, so no, I can't
>> grep for that.
>>
>> -Rasmus
>>
>
> As Sara noted, we shouldn't let users define methods without modifiers at
> all, so at least public/private/protected will have to be there.
>
>
So omitting function is good because it saves keystrokes and you can still
(ab)use the visibility modifiers for grepping, and that shouldn't be
omitted anyway because having explicit visibility over saving a couple of
keystrokes is a good thing as Sara noted™.

Changing the language so the visibility modifiers are mandatory would cause
a little bit more visible/explicit declarations(only a little bit, because
it is really easy to remember what is the default visibility), and it would
require to change/fix a large amount of code but automating that would be
fairly trivial (one could even do it using grep :P).
Making the function keyword optional would cause no BC issues, and it would
make possible to write more javaish looking code, which would perceived as
a good thing by some peple, and ofc it would save us typing out the
function keyword (btw. my IDE autocompletes that so that would only spare
me 3 keystrokes).
On the other hand it would make parsing/grepping php code a little bit more
difficult and can cause some issues later on (eg. if the function keyword
is optional and we add features like accessors/etc. later on, they need to
have more explicit declaration or will be more confusing to read).

Personally I agree with Zeev and co that changing the language should be
always done when the pros clearly outweights the cons and I think that this
isn't the case here.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Re: [RFC] Allow trailing comma in function call argument lists

[David Muir]

On 20/02/2013, at 10:47 PM, Alain Williams  wrote:

> On Wed, Feb 20, 2013 at 03:26:26AM -0800, Sara Golemon wrote:
>> On Tue, Feb 19, 2013 at 4:06 AM, Sara Golemon  wrote:
>>> Opening RFC to allow trailing comma in function call argument lists
>>> 
>>> https://wiki.php.net/rfc/trailing-comma-function-args
>> For the record, I've updated the RFC just now to include
>> function/method/closure declarations as well:
>> 
>> function foo(
>>  $bar,
>>  $baz,
>> ) {
>> 
>> }
>> 
>> Not a pattern I see as much, but for the sake of consistency, it
>> doesn't hurt to put it on the table for discussion.
> 
> I would argue against the RFC.
> 
> The trailing comma is useful with arrays since it is not uncommon that members
> need to be added to an array over time. This is often as a result of changes
> outside of the program (eg: another user added to an ACL). Such a change does
> not alter the purpose or functionality that is represented by the array, it 
> just
> does it for more somethings (users in my example).
> 
> Much source/version control is line based and so trailing commas helps keep
> differences short.
> 
> With functions: I do not see arguments being added in the same way, ie you are
> getting the function to do more of the same by adding an extra argument. If an
> extra argument is added it is because what the function does has changed in 
> some way.
> This is very different from the just-a-bit-more scenario that you have with 
> arrays.
> 
> If a function has a list of arguments that is expected to change, many
> programmers would do that by passing an array to the function and arrays can
> already have trailing commands 
> 
> Also: many other languages (eg C, Perl) allow a trailing comma in arrays, but
> not to function arguments. This change would make PHP different from what many
> programmers might expect.
> 
> -- 
> Alain Williams
> Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
> Lecturer.
> +44 (0) 787 668 0256  http://www.phcomp.co.uk/
> Parliament Hill Computers Ltd. Registration Information: 
> http://www.phcomp.co.uk/contact.php
> #include 
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


The one place I would find this to be super handy would be when specifying 
arguments to sprintf(), and other variable argument functions.

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

Re: [PHP-DEV] Re: [RFC] Allow trailing comma in function call argument lists

[Alain Williams]

On Wed, Feb 20, 2013 at 03:26:26AM -0800, Sara Golemon wrote:
> On Tue, Feb 19, 2013 at 4:06 AM, Sara Golemon  wrote:
> > Opening RFC to allow trailing comma in function call argument lists
> >
> > https://wiki.php.net/rfc/trailing-comma-function-args
> >
> For the record, I've updated the RFC just now to include
> function/method/closure declarations as well:
> 
> function foo(
>   $bar,
>   $baz,
> ) {
> 
> }
> 
> Not a pattern I see as much, but for the sake of consistency, it
> doesn't hurt to put it on the table for discussion.

I would argue against the RFC.

The trailing comma is useful with arrays since it is not uncommon that members
need to be added to an array over time. This is often as a result of changes
outside of the program (eg: another user added to an ACL). Such a change does
not alter the purpose or functionality that is represented by the array, it just
does it for more somethings (users in my example).

Much source/version control is line based and so trailing commas helps keep
differences short.

With functions: I do not see arguments being added in the same way, ie you are
getting the function to do more of the same by adding an extra argument. If an
extra argument is added it is because what the function does has changed in 
some way.
This is very different from the just-a-bit-more scenario that you have with 
arrays.

If a function has a list of arguments that is expected to change, many
programmers would do that by passing an array to the function and arrays can
already have trailing commands 

Also: many other languages (eg C, Perl) allow a trailing comma in arrays, but
not to function arguments. This change would make PHP different from what many
programmers might expect.

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: 
http://www.phcomp.co.uk/contact.php
#include 

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

Re: [PHP-DEV] [RFC] Allow trailing comma in function call argument lists

[Sara Golemon]

On Wed, Feb 20, 2013 at 3:32 AM, Martin Keckeis
 wrote:
> -1
>
> For array it's okay, but for functions? I think the code is harder to read
> that way...
>
> If I would see a call written this way:
> phpinfo(,)
>
> There are three possible values: Defaultvalue, null or something differnt?
>
You wouldn't see that call, it would be a syntax error.  You might see
something like this however, which may illustrate the same point you
were trying to make:

phpinfo(INFO_ALL,);

To me the meaning seems obvious, it's the same semantics as: $a =
array('foo',); which nobody seems to have trouble with.  I do
appreciate that you disagree, however.


> @Sara cool base idea ;-)  (https://github.com/sgolemon/objectifier)
>
Turns out niki did it first, and his approach was a lot better,
actually: https://github.com/nikic/scalar_objects

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

Re: [PHP-DEV] [RFC] Allow trailing comma in function call argument lists

[Martin Keckeis]

2013/2/19 Sara Golemon 

> Opening RFC to allow trailing comma in function call argument lists
>
> https://wiki.php.net/rfc/trailing-comma-function-args
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
-1

For array it's okay, but for functions? I think the code is harder to read
that way...

If I would see a call written this way:
phpinfo(,)

There are three possible values: Defaultvalue, null or something differnt?

@Sara cool base idea ;-)  (https://github.com/sgolemon/objectifier)

[PHP-DEV] Re: [RFC] Allow trailing comma in function call argument lists

[Sara Golemon]

On Tue, Feb 19, 2013 at 4:06 AM, Sara Golemon  wrote:
> Opening RFC to allow trailing comma in function call argument lists
>
> https://wiki.php.net/rfc/trailing-comma-function-args
>
For the record, I've updated the RFC just now to include
function/method/closure declarations as well:

function foo(
  $bar,
  $baz,
) {

}

Not a pattern I see as much, but for the sake of consistency, it
doesn't hurt to put it on the table for discussion.

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

Re: [PHP-DEV] [RFC] Allow trailing comma in function call argument lists

[Sara Golemon]

On Wed, Feb 20, 2013 at 12:47 AM, Florin Razvan Patan
 wrote:
> For example, I would expect that if I have:
>
> function A($b, $c = 'd') {}
>
> when I see A($b, ) to have no syntax errors but rather $c defaulted to
> the value in the function signature, which is not implied nor assumed
> by the RFC but it would be by the one reading a function.
>
Your assumption would be correct.  Since the trailing comma is
ignored, the function call happens with only one argument and the
second is left as the default.

> Then when I have
>
> function A($b, $c = 'd', $e) {}
>
> to be able to have A($b, , $e) which again this RFC doesn't specify
> that it allows but leads to confusion.
>
That function signature is invalid, so you'd never have code like that
running anyway.
The call is also invalid and again you wouldn't have code like that
because it would never run.

Thee RFC doesn't explicitly specify either of these points, but they
are implied by the patch provided which only allows for a tailing
comma at the end, not "bonus commas" in the middle or at the
beginning.

> As for the argument about the VCS, I really don't see an issue with
> the current way of thing. Some people don't use the comma at the
> end of the arrays and it doesn't mean that they all should.
>
Of course not, but as you stated it would help consistency if they could.

-Sara

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

Re: [PHP-DEV] [RFC] Allow trailing comma in function call argument lists

[Sara Golemon]

On Tue, Feb 19, 2013 at 6:51 PM, Sherif Ramadan  wrote:
> While I think it's a good idea I just have one question about the
> implication of the change. Does this mean that null will be passed to the
> function argument when a trailing comma remains?
>
No.  The trailing comma is simply ignored, there's another RFC up
about default args, but this doesn't intersect with that.

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

RE: [PHP-DEV] Dropping requirement for `function` keyword for methods in classes/interfaces/etc

[Zeev Suraski]

> The key question for me is: does removing it hurt PHP in any way? And
for me,
> the answer is a clear and resounding no.

This is completely the wrong question to ask (IMHO).  I think the answer
is wrong too, but that's a different story.

The correct question is:
"Does it bring substantial value to be considered for inclusion in one of
the world's most popular programming languages?"  For me, the answer is a
clear and resounding no.
>From my POV that's where the story ends.  The whole discussion about greps
and IDEs misses the point - we shouldn't even be discussing a 'feature'
that brings no value to the table.

The only reason I wrote my reply is that we seem to be having an influx of
those RFCs that fail this very basic requirement.

Zeev

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

Re: [PHP-DEV] Dropping requirement for `function` keyword for methods in classes/interfaces/etc

[Sanford Whiteman]

> As for classes/interfaces/traits and so on, if they are ever added in PHP
> to be declared inside classes and so on then I see no issues with this.
> A class/interface or a trait keyword would still be needed to make the
> difference between a them imho.

No, if you *only* allow inner classes at any point, you don't have
ambiguity. So by your standard, that version of PHP should drop the
keyword because there's only one unambiguous "something{}"
construction in that context.

I'm not saying you _should_ drop the keyword, I'm just explaining what
I think is the slippery slope of this kind of non-improvement. 

> Grepping for sources is like a daily operation and by using IDEs like
> Netbeans/Eclipse/PHPStorm one has the ability to just search for a
> symbol directly, regardless if you can click of function name or not.

I don't think you followed the matter of complex search/replace and
the new regex you'd have to "just" use all the time. I use a
sophisticated IDE as I mentioned, but its s/r function is separate
from its "find declaration" function. Not to mention searching for
duplicate declarations or in files you don't have in your workspace.
This is a real problem and I'm very happy we don't have it now.

> No voting karma here as well but I do tons of code reviews and this is
> just my opinion, you know, from the userland.

I am debating from userland as well. But I'm all done w/this one.

-- S.


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

Re: [PHP-DEV] Dropping requirement for `function` keyword for methods in classes/interfaces/etc

[Sanford Whiteman]

> So no you are not saying "PHP is not Java or C#". I don't want to touch
> any religious views but it's really funny to read :)

Not sure I get your remark... of those languages, I've said, in
essence [1] "Don't *force* PHP to look less like Java, ECMAScript, C#,
or C++ without a good reason and a new feature" and [2] "Don't
preclude other languages' advanced features from being added to PHP
later -- even much later -- with their most obvious syntax by clipping
syntax in PHP.now so that later additions are more difficult."

And PHP is looking more like ES in some ways (array literals). I like
that. I don't insist on it, but it's a leg up. CF did that too a while
back, and that brought me back to it for a project.

As I said, if inner classes are ever added to PHP, it stands to reason
they would follow the syntax of other C-style languages. And you might
then apply your (I believe flawed) argument that "any token that could
be considered superfluous in a given parser context *and* PHP version
should become optional" with the default meaning being permanently
fixed as of that PHP version.

It doesn't stand up to scrutiny because you just end up with more
magic to remember and no real advantages, especially over time.

But really, really truly, I am not going to comment again on this
thread but just wish you luck in swaying the people that count!

Cheers,

-- S.


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

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Gustavo Lopes]

Em 2013-02-20 10:32, Stas Malyshev escreveu:

This isn't really a good data since most of this code creates its own
DateTime and thus there's very little relevancy to what we're talking
about. If you look up the functions that actually accept DateTime:


http://code.google.com/codesearch#search/&type=cs&q=DateTime%5Cs%5C$%20lang:%5Ephp$

the picture would be quite different. I scanned through first 5 pages
and couldn't find a function that actually calls modify() on DateTime
object it receives.


Well, the majority of the code here just calls ->format() (which may 
very well be considered a point in your favor). But again most of the 
time an operation with side effects is called, there's no assignment. I 
also went through the first pages and saw one instance of an operation 
with side effects with assignment and three others without (setTime, 
setTimestamp and setTimeZone).


It's very tedious to go through this because most that don't just call 
format just set a field with it. This is potentially dangerous, of 
course, depending on what's further done with the field.


In any case, this seems like a pointless exercise. The solution is 
simple: separate the classes and provide a toDateTime() on 
DateTimeImmutable for interoperability purposes. One wouldn't need to go 
through Atom libraries code to know this is a solution that can't cause 
problems.


--
Gustavo Lopes

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

Re: [PHP-DEV] Dropping requirement for `function` keyword for methods in classes/interfaces/etc

[Florin Razvan Patan]

Sandy,

On Wed, Feb 20, 2013 at 11:59 AM, Sanford Whiteman
 wrote:
>> Classes always should be declared with class keyword, because there could
>> be ambiguity whether it's class, interface or trait.
>
> If only inner classes are allowed in a given PHP version, there's no
> ambiguity about whether "something{}" just inside a a class is an
> inner class.
>
> That's the justification for removing "function" just inside classes,
> isn't it? That it's not ambiguous because the only thing as of PHP.now
> that can take the form "sometype somevisibility something(){}" is a
> function?
>
> Well, if in PHP.later, the only thing that takes the form "sometype
> something{}" is an inner class, then leaving off the "sometype" there
> is also unambiguous (but also similarly gratuitous).
>
> And if in PHP.later.still you have inner interfaces, then the
> unmodified one still defaults to inner class and only a literal
> "interface something{}" is an inner intf.
>
> (I'm attempting a RAA argument but maybe failing)
>
> -- Sandy | FigureOne Support Team
>


I think you've abstracted this one way too much.

For me right now all I see is a useless keyword in a class. We don't
have 'visbilitytype var/property $varName' right now but you are
comfortable with them knowing that they are just properties of the
class.

If I were to be on this road I could in fact argue that currently we have
a lack of consistency between class methods and properties. You can
have a look on this image if you want an example:
http://i.imgur.com/Q0ZOZns.png

For the part where public is optional, I think that most frameworks
and practices they promote and users actually do type the keyword
and have it there for the sake of consistency. It might not be the case
for now, but I think that it would rather be useful to enforce the visibility
types rather that the 'function' keyword.

As for classes/interfaces/traits and so on, if they are ever added in PHP
to be declared inside classes and so on then I see no issues with this.
A class/interface or a trait keyword would still be needed to make the
difference between a them imho.

Grepping for sources is like a daily operation and by using IDEs like
Netbeans/Eclipse/PHPStorm one has the ability to just search for a
symbol directly, regardless if you can click of function name or not.

No voting karma here as well but I do tons of code reviews and this is
just my opinion, you know, from the userland.


Regards.

Florin Patan
https://github.com/dlsniper

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

Re: [PHP-DEV] [RFC] Short syntax for anonymous functions

[Sanford Whiteman]

> It still looks like some random characters bashed together by a monkey
> with a keyboard.

+1, I am a fiend for ternary expressions and crazy one-liners, but
this makes me want to go back and unroll everything I've ever done
into readable code. :) 

-- S.



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

Re: [PHP-DEV] PHP 6 : a new API ?

[Sebastian Krebs]

2013/2/20 Klaus Ufo 

> Hi there !
>
> We all know that the current PHP API has flaws. Maybe we could use
> namespaces to build a new coherent PHP API ? Like :
>
> - \arr
> - \num
> - \str
>
> and so on. Advantages :
>
> - no more global functions
>

Just to throw that in: Even if you pack them into namespaces they will
still remain global functions. They simply don't live in the root-namespace
anymore.


> - separation of concerns
> - backward compatibility

- work can be done progressively
> - easy to add user-defined functions (using php namespaces)
> - we could provide a \str\utf8 namespace
>
> This is just an idea. I don't know what is your vision for a next PHP 6.
>
> KH
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
github.com/KingCrunch

Re: [PHP-DEV] [RFC] Short syntax for anonymous functions

[Derick Rethans]

On Tue, 19 Feb 2013, Levi Morrison wrote:

> > Have you considered how this will work/look in an array?
> >
> > $a = [$b => ($n) $m => $m * $n]; // wat.
> 
> First off, it should be:
> 
> $a = [$b => ($n) |$m| => $m * $n];
> 
> The || make a big difference in this situation.

It still looks like some random characters bashed together by a monkey 
with a keyboard.

cheers,
Derick

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

Re: [PHP-DEV] Dropping requirement for `function` keyword for methods in classes/interfaces/etc

[Nikita Nefedov]

On Wed, 20 Feb 2013 09:59:51 -, Sanford Whiteman  
 wrote:


Classes always should be declared with class keyword, because there  
could

be ambiguity whether it's class, interface or trait.


If only inner classes are allowed in a given PHP version, there's no
ambiguity about whether "something{}" just inside a a class is an
inner class.

That's the justification for removing "function" just inside classes,
isn't it? That it's not ambiguous because the only thing as of PHP.now
that can take the form "sometype somevisibility something(){}" is a
function?

Well, if in PHP.later, the only thing that takes the form "sometype
something{}" is an inner class, then leaving off the "sometype" there
is also unambiguous (but also similarly gratuitous).

And if in PHP.later.still you have inner interfaces, then the
unmodified one still defaults to inner class and only a literal
"interface something{}" is an inner intf.

(I'm attempting a RAA argument but maybe failing)

-- Sandy | FigureOne Support Team




So no you are not saying "PHP is not Java or C#". I don't want to touch  
any religious views but it's really funny to read :)


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

Re: [PHP-DEV] Dropping requirement for `function` keyword for methods in classes/interfaces/etc

[Sanford Whiteman]

> Classes always should be declared with class keyword, because there could
> be ambiguity whether it's class, interface or trait.

If only inner classes are allowed in a given PHP version, there's no
ambiguity about whether "something{}" just inside a a class is an
inner class.

That's the justification for removing "function" just inside classes,
isn't it? That it's not ambiguous because the only thing as of PHP.now
that can take the form "sometype somevisibility something(){}" is a
function?

Well, if in PHP.later, the only thing that takes the form "sometype
something{}" is an inner class, then leaving off the "sometype" there
is also unambiguous (but also similarly gratuitous).

And if in PHP.later.still you have inner interfaces, then the
unmodified one still defaults to inner class and only a literal
"interface something{}" is an inner intf.

(I'm attempting a RAA argument but maybe failing)

-- Sandy | FigureOne Support Team


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

Re: [PHP-DEV] PHP 6 : a new API ?

[Florin Razvan Patan]

Hello,

On Wed, Feb 20, 2013 at 9:22 AM, Klaus Ufo  wrote:
> Hi there !
>
> We all know that the current PHP API has flaws. Maybe we could use namespaces 
> to build a new coherent PHP API ? Like :
>
> - \arr
> - \num
> - \str
>
> and so on. Advantages :
>
> - no more global functions

I actually like global functions even if most of the time I spend is in
OO code. I don't want / need to have simple scripts / crons that
are suddenly more complex to manage just because I can't have
them.

> - separation of concerns

While I understand the needs to be pure about things, I do think that
there's such a thing as too pure. Does the current way of things
break something?

> - backward compatibility

This would rather be a backward incompatibility if I understand this
correctly.

> - work can be done progressively
> - easy to add user-defined functions (using php namespaces)

I have no troubles in having my defined functions up and running as
they are now. The fact that they are always in the global scope makes
things much simpler for me when I want to do simple things.

> - we could provide a \str\utf8 namespace

Wasn't UTF8 a major pita and abandoned in favor of better things for
the moment?
>
> This is just an idea. I don't know what is your vision for a next PHP 6.
>
> KH
>

My vision for the PHP 6 is rather different that yours and if you want,
you can read about it here:
http://florinpatan.ro/2013/02/11/next-big-thing-in-php/
(sorry if I'm not allowed to share such links here).

And as Michael Shadle said, I'd rather have things like consistent
parameters order or named parameters or both rather that namespacing
functions like this.


Regards.

Florin Patan
https://github.com/dlsniper

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

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Benjamin Eberlei]

People are not using modify() in this way, because they have been bitten
before I would suppose.

What i find important about the DateTime vs DateTimeImmutable is the
expectations I have with regard to how they work with internal state.

If i have a typehint for DateTime, i clone the object before working on it.
If I have a typehint for DateTimeImmutable, i just start using it.

This means the usage patterns for both objects will look very different.
Also for example, the following code is not possible without instanceof
checks:

function thirtyDaysLater(DateTime $dt)
{
$later = clone $dt;
$later->modify("+30 day");

return $later;
}

If i pass a DateTimeImmutable in there, the code will not work.

Imho its not about people are not using it this way in open source code,
its about creating a very likely source of bugs of the ugly to debug kind.


On Wed, Feb 20, 2013 at 10:32 AM, Stas Malyshev wrote:

> Hi!
>
> > To "accept a DateTimeImmutable" is not the same as "no recoverable
> > fatal error when a DateTimeImmutable is passed". You can't possibly know
> > whether passing a DateTimeImmutable is safe without reviewing the code
> > on all the call hierarchy starting from where your DateTimeImmutable is
> > passed.
>
> If I know what the code does with dates, I don't need to review it.
>
> > misleading statement -- it assumes codebases exist in isolation. But
> > current libraries that take DateTime will still be used in 5.5; in fact,
> > that's the basis of your whole argument for this choice.
>
> This is true. That's why I want to see what is more probable - that
> library accepts DateTime and would be fine with DateTimeImmutable or
> that library accepts DateTime and would have to be rewritten to work
> with DateTimeImmutable.
>
> > Here is some data:
> >
> >
> http://code.google.com/codesearch#search/&q=%5C$date-%3Emodify%20lang:php&type=cs&sq=
> >
> > As you can see, your assumption is false. In the majority of cases,
> > there is no assignment.
>
> This isn't really a good data since most of this code creates its own
> DateTime and thus there's very little relevancy to what we're talking
> about. If you look up the functions that actually accept DateTime:
>
>
> http://code.google.com/codesearch#search/&type=cs&q=DateTime%5Cs%5C$%20lang:%5Ephp$
>
> the picture would be quite different. I scanned through first 5 pages
> and couldn't find a function that actually calls modify() on DateTime
> object it receives.
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] double val to long val conversion issue

[Gustavo Lopes]

Em 2013-02-20 9:15, Stas Malyshev escreveu:

Hi!

Also, I'm not sure I understand what 64-bit test is supposed to 
return
and why - why negative number is converted to positive one? What 
exactly

this change is supposed to improve?


The least significant bytes are preserved. Take int(-2056257536) and
int(2943463994971652096):

In[6]:= BitAnd[2^32 - 1, {-2056257536, 2943463994971652096}]

Out[6]= {2238709760, 2238709760}


I'm not sure I understand, what this syntax means and how it explains
why we're doing these conversions?


It doesn't, of course. I was just showing why there are changes in 
sign.



I.e. what requires this change and
how it is beneficial? I understand that it preserves least 
significant

bits, but why we should preserve them and discard sign, for example?


First of all, there are no change for the ]LONG_MAX, ULONG_MAX] range. 
Doubles in that range (notice they're positive numbers) already got 
converted to negative numbers.


The problem was that for numbers outside the [LONG_MIN, ULONG_MAX] 
range, the code relied on undefined behavior that did vary between 
platforms. This change does away with the undefined behavior and 
provides a uniform treatment of the finite double domain. (int)$dval is 
now round*($dval) mod 2^(PHP_INT_SIZE*8) converted to a signed integer 
of size PHP_INT_SIZE*8 bits assuming a two's complement representation, 
for all finite $dval double values.


You could argue that another behavior like clipping at 
LONG_MAX/LONG_MIN is preferable. But we can't do it for BC reasons. And 
especially for 32-bit long systems, the current behavior is very useful. 
For instance let's say you had some network protocol that used an 
unsigned 32-bit int on which you needed to do some bitwise operations. 
You can use a double to represent the range 2^31..2^32-1 that you got 
from, from instance, adding two large PHP integers, cast it to int and 
do your bitwise operation.


* Actually, I just realized the code probably needs a small adjustment 
to make the double always round towards zero. This is only important in 
32-bit systems though; for the others, the doubles outside the long 
range have no fractional part.


--
Gustavo Lopes

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

Re: [PHP-DEV] Dropping requirement for `function` keyword for methods in classes/interfaces/etc

[Sanford Whiteman]

> Global functions remain its requirement for keyword, just methods
> lose 

I understand that. You didn't read my post carefully because I was
noting this exact inconsistency.

> it. And it doesn't mean that you can't write
> class Foo {
> function bar() {}
> }

No, it means you _have to_ write it that way if you want the same
function definition to work in and out of a class. Like I said, I
expect the simplest function def to Just Work (as it does now) in
either scope.

This is not a technical BC break but a conceptual break that
disregards existing realities of refactoring (as well as realities of
who writes the code we end up maintaining). 

> What about readability - removal of this keyword will make a better
> readability of methods. Instead of
> abstract class Foo {
> public function make()
> {
> // some code
> }

> public abstract function do();
> }

> You will need to read just
> class Foo {
> public make()
> {
> // some code
> }

> public abstract do();
> }

That's no more readable to me. And even if I pretended to find it so,
I want to to read other contemporary languages with relative ease as
well, rather than being coddled by sugar that doesn't exist in other
C-style languages. PHP is not Java or C#, yes; yet the more
"streamlined" we get while those languages are adding actual features,
the worse off we'll be when we have to get the gist of something in a
verbose foreign language. And I don't want to drop "function" on the
server and then forget it in JavaScript. That's a net loss for me and
the millions of other users jacking both trades.

> It's not function a keyword who lets you recognize function
> definition/declaration, but it's usually a pair of brackets. 

The function(){} construction is critical to recognizing a function
definition. Simply looking for curly braces is not sufficient, since
obviously a {} block does not mean you're in a function. {} is perhaps
more predictive at the second level of a class file, but in a codebase
in general it would be reckless to treat {}, or even (){}, as denoting
a function definition, since the former squarely does not and the
latter is more likely to mean an forgotten semicolon in real-world
code.

> This function keyword is just noise for now, it doesn't serve any
> purpose aside from typing grep 'function funcname' instead of grep
> '(private|protected|public|abstract|static)funcname' , but, you
> know, if you love shell so much (or are forced to use it) you are
> probably familiar with creating 'shortcuts' for it, scripts or
> aliases.

I could scarcely disagree more with your minimizing view of how people
seek and scan code.

I think I'd better stop discussing it as well -- I don't have voting
karma so good luck either way

-- S.


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

Re: [PHP-DEV] PHP 6 : a new API ?

[Michael Shadle]

On 02/19/2013 11:22 PM, Klaus Ufo wrote:
> Hi there !
> 
> We all know that the current PHP API has flaws. Maybe we could use namespaces 
> to build a new coherent PHP API ? Like :
> 
> - \arr
> - \num
> - \str
> 
> and so on. Advantages :
> 
> - no more global functions
> - separation of concerns
> - backward compatibility
> - work can be done progressively
> - easy to add user-defined functions (using php namespaces)
> - we could provide a \str\utf8 namespace
> 
> This is just an idea. I don't know what is your vision for a next PHP 6.
> 
> KH
> 


I'm aware people complain about PHP flaws, but having misc global core 
functions for strings, arrays and other data types is a new one.

I am still a purest at heart and don't see the need for namespacing in general. 
I am thinking it provides some lower level memory space improvements and less 
conflicts, but I feel like if you can't code in global space perhaps you should 
be rethinking how you code. I don't think most people care about the lower 
level advantages, they're just looking at it from a code laziness perspective.

Why make \bar\baz\foo() or $bar->baz->foo() instead of bar_baz_foo()? Prefixing 
functions seems perfectly effective. I see a lot of code that looks like 
they're using namespaces or OO just to group things together and organize code 
in some fashion. Not because there's any inherent benefit.

I'd much rather see effort taken on renaming functions to be more consistent, 
and making needle/haystack consistent, and maybe throw in named parameters. PHP 
is getting too complex as it is.

Signed,
PHP purest at heart, (who has code that has lasted for a decade and multiple 
major php code changes still did not break it)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Stas Malyshev]

Hi!

> To "accept a DateTimeImmutable" is not the same as "no recoverable 
> fatal error when a DateTimeImmutable is passed". You can't possibly know 
> whether passing a DateTimeImmutable is safe without reviewing the code 
> on all the call hierarchy starting from where your DateTimeImmutable is 
> passed.

If I know what the code does with dates, I don't need to review it.

> misleading statement -- it assumes codebases exist in isolation. But 
> current libraries that take DateTime will still be used in 5.5; in fact, 
> that's the basis of your whole argument for this choice.

This is true. That's why I want to see what is more probable - that
library accepts DateTime and would be fine with DateTimeImmutable or
that library accepts DateTime and would have to be rewritten to work
with DateTimeImmutable.

> Here is some data:
> 
> http://code.google.com/codesearch#search/&q=%5C$date-%3Emodify%20lang:php&type=cs&sq=
> 
> As you can see, your assumption is false. In the majority of cases, 
> there is no assignment.

This isn't really a good data since most of this code creates its own
DateTime and thus there's very little relevancy to what we're talking
about. If you look up the functions that actually accept DateTime:

http://code.google.com/codesearch#search/&type=cs&q=DateTime%5Cs%5C$%20lang:%5Ephp$

the picture would be quite different. I scanned through first 5 pages
and couldn't find a function that actually calls modify() on DateTime
object it receives.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Benjamin Eberlei]

The problem with DateTimeImmutable extends DateTime is, that the client
code not just magically works with immutable date times, it also works
differently with regard to state, so this will be a source of subtle and
annoying bugs. See the following example:

https://gist.github.com/beberlei/4994193

The client code actually has to know if the instance is DateTime or
DateTimeImmutable and behave differently. Or just use "clone" as before,
and then there is no difference to pre 5.5 code anyways.


On Wed, Feb 20, 2013 at 10:07 AM, Gustavo Lopes wrote:

> Em 2013-02-20 9:41, Stas Malyshev escreveu:
>
>  There's nothing that "everybody" is
>> doing - there are tons of different usage patterns, some of them common,
>> some incompatible. We need to look on what is more probable - that
>> people use DateTime as hint for operations that do not modify the
>> incoming object or that they do modify it and also would put
>> DateTimeImmutable in this code.
>>
>
> No, we do not need to look on what is more probable. It's only when we
> select this very ill-advised option, that we need to start guessing if
> people used all the guarantees of DateTime (namely its side-effects) or not.
>
>
>  So on one side we have existing code that would not accept
>> DateTimeImmutable without extensive modification,
>>
>
> To "accept a DateTimeImmutable" is not the same as "no recoverable fatal
> error when a DateTimeImmutable is passed". You can't possibly know whether
> passing a DateTimeImmutable is safe without reviewing the code on all the
> call hierarchy starting from where your DateTimeImmutable is passed.
>
>
>  unless we create the
>> inheritance, on the other side we have some code that modifies DateTime
>> and should be protected from passing DateTimeImmutable - but there's no
>> such code yet since nobody passes DateTimeImmutable anywhere yet, so we
>> don't make any problem for existing code.
>>
>
> "[C]ode that modifies DateTime and should be protected from passing
> DateTimeImmutable" DOES exist already. Saying that it's not a problem for
> existing code because no one passes DateTimeImmutable is a misleading
> statement -- it assumes codebases exist in isolation. But current libraries
> that take DateTime will still be used in 5.5; in fact, that's the basis of
> your whole argument for this choice.
>
>
>  I find it highly likely that majoirty of DateTime users don't care if
>> it's mutable or not since they either don't change it (most frequent use
>> case) or use something like $foo = $bar->modify("+1 day"); and never
>> rely on the fact that $bar was modified. Of course, I have no data about
>> how many but I find it highly likely that many users simply don't care
>> about the difference.
>>
>
> Here is some data:
>
> http://code.google.com/**codesearch#search/&q=%5C$date-**
> %3Emodify%20lang:php&type=cs&**sq=
>
> As you can see, your assumption is false. In the majority of cases, there
> is no assignment.
>
> --
> Gustavo Lopes
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Gustavo Lopes]

Em 2013-02-20 9:41, Stas Malyshev escreveu:

There's nothing that "everybody" is
doing - there are tons of different usage patterns, some of them 
common,

some incompatible. We need to look on what is more probable - that
people use DateTime as hint for operations that do not modify the
incoming object or that they do modify it and also would put
DateTimeImmutable in this code.


No, we do not need to look on what is more probable. It's only when we 
select this very ill-advised option, that we need to start guessing if 
people used all the guarantees of DateTime (namely its side-effects) or 
not.



So on one side we have existing code that would not accept
DateTimeImmutable without extensive modification,


To "accept a DateTimeImmutable" is not the same as "no recoverable 
fatal error when a DateTimeImmutable is passed". You can't possibly know 
whether passing a DateTimeImmutable is safe without reviewing the code 
on all the call hierarchy starting from where your DateTimeImmutable is 
passed.



unless we create the
inheritance, on the other side we have some code that modifies 
DateTime
and should be protected from passing DateTimeImmutable - but there's 
no
such code yet since nobody passes DateTimeImmutable anywhere yet, so 
we

don't make any problem for existing code.


"[C]ode that modifies DateTime and should be protected from passing 
DateTimeImmutable" DOES exist already. Saying that it's not a problem 
for existing code because no one passes DateTimeImmutable is a 
misleading statement -- it assumes codebases exist in isolation. But 
current libraries that take DateTime will still be used in 5.5; in fact, 
that's the basis of your whole argument for this choice.



I find it highly likely that majoirty of DateTime users don't care if
it's mutable or not since they either don't change it (most frequent 
use

case) or use something like $foo = $bar->modify("+1 day"); and never
rely on the fact that $bar was modified. Of course, I have no data 
about
how many but I find it highly likely that many users simply don't 
care

about the difference.


Here is some data:

http://code.google.com/codesearch#search/&q=%5C$date-%3Emodify%20lang:php&type=cs&sq=

As you can see, your assumption is false. In the majority of cases, 
there is no assignment.


--
Gustavo Lopes

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

Re: [PHP-DEV] [RFC] Allow trailing comma in function call argument lists

[Lars Strojny]

Hi,

Am 20.02.2013 um 06:24 schrieb Laruence :

> On Tue, Feb 19, 2013 at 8:06 PM, Sara Golemon  wrote:
>> Opening RFC to allow trailing comma in function call argument lists
>> 
>> https://wiki.php.net/rfc/trailing-comma-function-args

-1 on this as well. If you don’t like the diffs, fix the diff implementation to 
ignore trailing comma changes. But I guess I'm in a minority here and it is 
easy to prevent stuff like that with a code sniffer rule.

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

Re: [PHP-DEV] [RFC] Allow trailing comma in function call argument lists

[Florin Razvan Patan]

Hello,

On Tue, Feb 19, 2013 at 2:06 PM, Sara Golemon  wrote:
> Opening RFC to allow trailing comma in function call argument lists
>
> https://wiki.php.net/rfc/trailing-comma-function-args
>

As a person who deals with code reviews from many programmers
each day, I'd have to say this would be confusing. I do agree that
it helps consistency but by far it implies many things that are really
not what they seem.

For example, I would expect that if I have:

function A($b, $c = 'd') {}

when I see A($b, ) to have no syntax errors but rather $c defaulted to
the value in the function signature, which is not implied nor assumed
by the RFC but it would be by the one reading a function.

Then when I have

function A($b, $c = 'd', $e) {}

to be able to have A($b, , $e) which again this RFC doesn't specify
that it allows but leads to confusion.

As for the argument about the VCS, I really don't see an issue with
the current way of thing. Some people don't use the comma at the
end of the arrays and it doesn't mean that they all should.

So from my point of view, this adds more ambiguity to the language
and the problem it solves is very small.


Best regards,
Florin

Florin Patan
https://github.com/dlsniper

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

Re: [PHP-DEV] bug 49348 - notice on $this->undefined++

[Stas Malyshev]

Hi!

> The idea of the fix is fine (I didn't check all the related changes in
> PHP extensions).
> I think it must be included into 5.5.

Thanks for reviewing it! If I don't head any objections in next couple
of days, I'll merge it to 5.5.

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

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

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Stas Malyshev]

Hi!

> The problem with the argument that "everybody 'typehints' DateTime; we  
> should inherit from it so that the code will run when the pass it a  
> DateTimeImmutable" is that it assumes that everybody who typehints  
> DateTime uses DateTime in a manner compatible with DateTimeImmutable. I  
> don't believe that no one relies on DateTime method's side effects -- I  
> certainly do.

We can not make sense of the problem if we keep talking in terms of
"everybody is doing this or that". There's nothing that "everybody" is
doing - there are tons of different usage patterns, some of them common,
some incompatible. We need to look on what is more probable - that
people use DateTime as hint for operations that do not modify the
incoming object or that they do modify it and also would put
DateTimeImmutable in this code.

So on one side we have existing code that would not accept
DateTimeImmutable without extensive modification, unless we create the
inheritance, on the other side we have some code that modifies DateTime
and should be protected from passing DateTimeImmutable - but there's no
such code yet since nobody passes DateTimeImmutable anywhere yet, so we
don't make any problem for existing code.

My personal opinion is that having the first covered covers more cases
than the second, since it saves more boilerplate code.

> The argument is that people are using DateTime as if it were immutable and  
> you can now fix this wrong code by passing a DateTimeImmutable instead? I  
> find it highly unlikely.

I find it highly likely that majoirty of DateTime users don't care if
it's mutable or not since they either don't change it (most frequent use
case) or use something like $foo = $bar->modify("+1 day"); and never
rely on the fact that $bar was modified. Of course, I have no data about
how many but I find it highly likely that many users simply don't care
about the difference.

> IMO, the classes should not be part of the same hierarchy. If it doesn't  

This means hinting for DateTime would be useless for common
(non-modifying) use cases and there's no recourse to do anything else
since there's no common ground. The name DateTimeImmutable kind of
implies it is the same as DateTime only not mutable, but in fact writing
code that could accept them both

> Even if most people DO use DateTime in a compatible way, this is a very  
> myopic way to advance the language or handle a transition. If the  
> DateTimeImmutable interface is superior, people will move to it. If it's  
> important for functions to accept both (I don't think it is), a common  
> superclass with weaker guarantees can be extracted.

That would create javaesque constructs of classes and interfaces that do
nothing useful but exist merely so that there would be nice hierarchies,
and people would have to learn all that to use them, which makes it
significantly harder to use the language.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

Re: [PHP-DEV] Dropping requirement for `function` keyword for methods in classes/interfaces/etc

[Pierrick Charron]

> Protip: use an IDE.
>

The IDE that i'm using may search for something like function \w to find
all the functions of my code. So I may have to wait for a new update of the
IDE to be able to use the index, and I also may have to pay to get the
update of my IDE. So why would I want all this if I can just keep the
function keyword.

Pierrick

Re: [PHP-DEV] bug 49348 - notice on $this->undefined++

[Dmitry Stogov]

Hi Stas,

The idea of the fix is fine (I didn't check all the related changes in PHP
extensions).
I think it must be included into 5.5.

Thanks. Dmitry.

On Tue, Feb 19, 2013 at 1:23 PM, Stas Malyshev wrote:

> Hi!
>
> I've created a pull to fix bug 49348 - when undefined properties do not
> produce a notice when doing something like $this->undefined++, unlike
> regular variables that do.
>
> Unfortunately, this fix seems to require changing signature of
> get_property_ptr_ptr(), adding fetch type, which makes it impossible for
> 5.4, and which would require any module that is compiled for 5.5 add
> ifdefs if they override this handler (of course, I've fixed the ones in
> the core). The pull is at: https://github.com/php/php-src/pull/281
>
> However, I think that even though missing notice is not that big a deal,
> having properties behaving inconsistently is, so this needs to be fixed.
> Anybody has any objection or sees something wrong with the patch?
>
> Also, if somebody has an idea of a better fix that won't require
> changing the API, it's be nice, I couldn't think of any.
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] PHP causing high number of NFS getattr operations?

[Stas Malyshev]

Hi!

> Yes, this is an overhead, but it is small beer compared to doing a
> getattr() RPC across the server room fabric to a NAS server backend.

That depends of what your error handlers do. Some may write to log
files, etc. if not configured properly (since error_reporting setting
doesn't have to be considered in it).
IIRC, for most of the cases O+ should be able to resolve all
includes/requires on cached files without syscalls - but file_exists is
a different matter since caching it in generic case can be very dangerous.

> I guess that I should bite the bullet and switch to 5.5.  I've been
> working on an evaluatorfork of APC optimized for CLI/GCI which tackles a
> lot of these issues head on and performs reasonable well, but I realise
> that this is a dead-end and will never get deployed, but I am currently
> considering regressing some of this technology into 5.5 and O+.  Are you
> interested in a version of O+ which supports all SAPIs? 

I think right now O+ can support CLI (provided enable_cli is set) but
for most cases it's kind of useless since scripts are rarely re-included
in common CLI scenarios. So if you know how to improve common CLI
scenarios it may be interesting, though I imagine it's not the most
common use case. But if it adds there without problems for anything
else, why not.

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

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

Re: [PHP-DEV] Question on hash api

[Gustavo Lopes]

Em 2013-02-20 8:09, Tjerk Anne Meesters escreveu:

Hi,

I've forked out an interesting project on Github that implements 
XXHash and
extended it to work with the hash() function family. Project links 
below.


The integration is pretty straightforward, but the following code had 
me

concerned:

PHP_HASH_API void PHP_XXH32Update(PHP_XXH32_CTX *context, const 
unsigned

char *input, unsigned int inputLen)
{
XXH32_feed(context->state, (void *)input, (int)inputLen);
}

The XXH32_feed() takes an int argument, whereas the update ops 
function

takes an unsigned int for the input length.

Would that ever give a problem? If so, what kind of workaround am I 
looking

at?



Not unless and unsigned int with a value larger than INT_MAX is passed. 
I took a quick look at the calls to ->hash_update and the largest value 
potentially passed seems to be from a PHP string (via 
php_hash_hmac_round), which has an int for the length and therefore is 
not a problem.


--
Gustavo Lopes

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

Re: [PHP-DEV] Dropping requirement for `function` keyword for methods in classes/interfaces/etc

[Nikita Nefedov]

On Wed, 20 Feb 2013 08:02:36 -, Sanford Whiteman  
 wrote:



While I'm thinking about this (though I should leave it alone): who's
to say that PHP won't some day get inner classes? By deciding the
"default" inner member of a class will be a function, you're choosing
the one that has a global/procedural equivalent where the short syntax
won't work, instead of leaving the concept unused for the possible
future when:

class myClass {
mySomething { // is equivalent to class mySomething {
(Yes, you could say mySomething(...) { } is a public function and
mySomething { } is an innner class, but you get the idea.)

-- S.




Classes always should be declared with class keyword, because there could  
be ambiguity whether it's class, interface or trait.
Also, I will say it again: as Sara noted, we *really* shouldn't let users  
define methods without any modifiers, like this: class Foo { asd() { echo  
"this is parse error"; } }


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

Re: [PHP-DEV] Dropping requirement for `function` keyword for methods in classes/interfaces/etc

[Nikita Nefedov]

On 20.02.2013, at 1:42, Sanford Whiteman 
 wrote:

> Seems this would complicate the transplanting of (global) functions
> into (default public) class methods and vice versa. This is a common
> refactoring task -- at least IME -- and before I adjust visibility I
> would expect the function to Just Work.
> 
> So this works in a class to define the function:
> 
> function my_function() { }
> 
> And I expect to be able to pull that out into the global scope as-is.
> 
> But if people start using this super-shorthand in the class:
> 
> my_function() { }
> 
> Then when I pull it out into my function library, I'll get errors.
> 
> The reverse is also true: I expect to get a fatal from leaving off a
> semicolon between function_call() and {} but at the top level of a
> class it gets smoothly compiled as a function definition.
> 
> Look, I know there are similar cases throughout PHP (and other
> languages) already, but why add more for no (IMO) payoff? Perhaps not
> the most compelling case against this new sugar, but it would suffice
> to stop me from ever using it.

Hi Sandy, it won't complicate you anything.
Global functions remain its requirement for keyword, just methods lose it. And 
it doesn't mean that you can't write
class Foo {
function bar() {}
}

As I said, there are no bc breaks at all. My initial patch doesn't forces you 
to write any keyword, so you are actually can declare a method just with 
foo(){}, but it is absolutely doable, i'm just from my cell phone now.


What about readability - removal of this keyword will make a better readability 
of methods. Instead of
abstract class Foo {
public function make()
{
// some code
}

public abstract function do();
}

You will need to read just
class Foo {
public make()
{
// some code
}

public abstract do();
}

It's not function a keyword who lets you recognize function 
definition/declaration, but it's usually a pair of brackets. This function 
keyword is just noise for now, it doesn't serve any purpose aside from typing 
grep 'function funcname' instead of grep 
'(private|protected|public|abstract|static)funcname' , but, you know, if you 
love shell so much (or are forced to use it) you are probably familiar with 
creating 'shortcuts' for it, scripts or aliases.


Now what I think about all this "give the arguments" - the thing is - function 
keyword is just redundant. It's like appendix, we just don't need it, there's 
no point in it (yeah, except grepping), and we can drop it without any bc 
breaks, so why don't just do it?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] double val to long val conversion issue

[Stas Malyshev]

Hi!

>> Also, I'm not sure I understand what 64-bit test is supposed to return
>> and why - why negative number is converted to positive one? What exactly
>> this change is supposed to improve?
> 
> The least significant bytes are preserved. Take int(-2056257536) and  
> int(2943463994971652096):
> 
> In[6]:= BitAnd[2^32 - 1, {-2056257536, 2943463994971652096}]
> 
> Out[6]= {2238709760, 2238709760}

I'm not sure I understand, what this syntax means and how it explains
why we're doing these conversions? I.e. what requires this change and
how it is beneficial? I understand that it preserves least significant
bits, but why we should preserve them and discard sign, for example?

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

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

Re: [PHP-DEV] Dropping requirement for `function` keyword for methods in classes/interfaces/etc

[Sanford Whiteman]

While I'm thinking about this (though I should leave it alone): who's
to say that PHP won't some day get inner classes? By deciding the
"default" inner member of a class will be a function, you're choosing
the one that has a global/procedural equivalent where the short syntax
won't work, instead of leaving the concept unused for the possible
future when:

class myClass {
mySomething { // is equivalent to class mySomething {

(Yes, you could say mySomething(...) { } is a public function and
mySomething { } is an innner class, but you get the idea.)

-- S.



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