[PHP-DEV] bug 49348 - notice on $this-undefined++
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] bug 49348 - notice on $this-undefined++
On Tue, Feb 19, 2013 at 4:23 AM, Stas Malyshev smalys...@sugarcrm.comwrote: 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? Looks like a reasonable fix to me. It's unfortunate it has to wait for 5.5, but I couldn't think of a more clever fix that wouldn't break the API. 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?
The point that this thread highlights is that apps developers / administrators at both ends of the scale -- the enterprise and the shared service user -- normally have little say over the infrastructure architecture on which their application runs. In both these cases the infrastructure will be hosting 100s if not 1000s of apps, and the environment cannot be tailored to any one app. So issues like storage architecture and security architecture (e.g. UID-based enforcement of app separation) are a given as NFRs (non-functional requirements). Use of NFS with server / storage separation is still a standard implementation design pattern, when enterprises require simple-to-manage scalability on these tiers. We aren't going to change this, and neither will the O/P. Surely PHP will achieve better penetration and the greater acceptance if it can offer more robust performance in this sort of environment? Sure, but then you can go with something like Redis. But, again, if you go back to the original question, this has nothing to do with often-changing data in a couple of PHP include files: We have several Apache 2.2 / PHP 5.4 / APC 3.1.13 servers all serving mostly PHP over NFS (we have separate servers for static content). So they are serving up all their PHP over NFS for some reason.
[PHP-DEV] Trait vs magic constants (bug #61033)
Hi Internals after quite a long time,
There is an issue in the tracker (#61033 and somewhat related #64239)
about magic constants behaviour in aliased trait methods. Stefan
classified #61033 as a feature not a bug however he suggested to start
a discussion about it.
So here's the case: how to get current running method name when in an
aliased trait method:
trait T {
public function method() {
// __FUNCTION__ is method
}
}
class C {
use T { method as m; }
public function method() {}
}
This is all nice and dandy but imagine (among other things) that you
want to return a callback to itself from such a method. How would you go
about it?
Returning [$this, __FUNCTION__] would be most obvious but it's obviously
not what we want. Apart from using debug_backtrace (which has it's own
issues; #64239 being one) I don't see any way of doing it.
So: is this a feature or a bug?
And if it really is a feature then either we need another magic const
(like suggested in #64239) or (preferably IMO) a method to resolve
method name at runtime (a counterpart to get_called_class() - say
get_called_method()).
Cheers
Marcin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Questions regarding DateTimeImmutable
On Fri, 15 Feb 2013, Nikita Popov wrote: for PHP 5.5 a new DateTimeImmutable class was introduced, which is a variant of DateTime, which has methods working on a clone of the original object. There was no RFC on this and some of the design decisions are a bit uncleared to me, so I figured I'd write a mail: a) The DateTimeImmutable class extends the DateTime class. Why was this done this way? Both classes are incompatible (as in the inheritance violates LSP). E.g. if you hint against DateTime, then passing in DateTimeImmutable will not work (as the behavior is different). The same also applies the other way around (DateTime extending DateTimeImmutable). Imho a mutable and an immutable variant of a class can't reasonably extend from one another, so I'm not sure why this was done. It was mostly done so that methods and code accepting do not need signature changes. In many cases library code would accept a DateTime, call modify and return the changed object - not realizing that the original object was changed as well causes issues with calling code. By having DateTimeImmutable extend DateTime they can continue to pass them in, without having to change library code at all. b) The DateTimeImmutable class is (method-wise) an exact copy of DateTime. This makes for some rather weird method names for an immutable object. E.g. there is DateTimeImmutable::modify, which to me seems quite contradictory. There are also a lot of methods of the DateTimeImmutable::setTime form, which also seems rather odd and confusing (how can I set something on an immutable object?) It just returns the changed object instead of changing the object itself *and* returning the changed object (as DateTime does). cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Questions regarding DateTimeImmutable
On Fri, 15 Feb 2013, Sanford Whiteman wrote: I think it was done to ease adoption even though it was known to violate LSP. To quote Stas, As for established practice, everybody expects DateTime, so IMHO we should leave DateTime as base class even though it's not strictly OO-pure. This way does let users sub in DateTimeImmutable more easily and patch over a ton of unintended -- maybe not even fully noted or understood -- defects in their apps? I dunno. Yes, that's exactly the idea. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Allow trailing comma in function call argument lists
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
Re: [PHP-DEV] [RFC] Allow trailing comma in function call argument lists
On Tue, 19 Feb 2013, Sara Golemon wrote: Opening RFC to allow trailing comma in function call argument lists https://wiki.php.net/rfc/trailing-comma-function-args +1 cheers, Derick -- 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
On Tue, Feb 19, 2013 at 1:06 PM, Sara Golemon poll...@php.net wrote: Opening RFC to allow trailing comma in function call argument lists https://wiki.php.net/rfc/trailing-comma-function-args looks good and consistent enough, you have my vote :) -- Pierre @pierrejoye -- 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
2013/2/19 Sara Golemon poll...@php.net: 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 I'm all for it! Waiting for the official voting... -- 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
Just a question from one of the lingering listeners: would this change also ease the `skipping` of default values for parameters? (as discussed for RFC https://wiki.php.net/rfc/skipparams) That way it would be consistent with this RFC and the list() construct ? With regards, Robin Speekenbrink 2013/2/19 Sara Golemon poll...@php.net 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
Re: [PHP-DEV] [RFC] Allow trailing comma in function call argument lists
On Tue, Feb 19, 2013 at 4:41 AM, Kingsquare.nl - Robin Speekenbrink ro...@kingsquare.nl wrote: Just a question from one of the lingering listeners: would this change also ease the `skipping` of default values for parameters? (as discussed for RFC https://wiki.php.net/rfc/skipparams) That way it would be consistent with this RFC and the list() construct ? It's orthogonal to skipparams. It'd neither help nor hurt based on the recommendations of that RFC. With regard to list(), it already supports expressions like this: list($x,) = array(123); so nothing more needs to be done for it and it's not at odds with either of these RFCs. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Short syntax for anonymous functions
Inspired by Sara, here is another RFC, I finally got around to draft: https://wiki.php.net/rfc/short-syntax-for-anonymous-function Please feedback, -- Marcello Duarte
[PHP-DEV] [RFC] Allow non-scalar keys in foreach
Hi internals! This RFC proposes to remove the type-restrictions on Iterator keys used in foreach: https://wiki.php.net/rfc/foreach-non-scalar-keys I took over Levi's RFC and added a patch for it. Thoughts? Nikita
Re: [PHP-DEV] [RFC] Short syntax for anonymous functions
On Tue, 19 Feb 2013, Marcello Duarte wrote: Inspired by Sara, here is another RFC, I finally got around to draft: https://wiki.php.net/rfc/short-syntax-for-anonymous-function I'd be really reluctant to add this -- it's yet another (superfluous) syntactical sugar, there is no patch, and how does this work with bound variables (use keyword)? cheers, Derick -- 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
Marcello, On Tue, Feb 19, 2013 at 7:57 AM, Marcello Duarte mdua...@inviqa.com wrote: Inspired by Sara, here is another RFC, I finally got around to draft: https://wiki.php.net/rfc/short-syntax-for-anonymous-function Please feedback, -- Marcello Duarte I like the concept. I dislike the syntax. It looks too much like a JSON object declaration, and it feels like it should be returning an object instead of a closure/anonymous function. Additionally, I don't like that it's also a closure. Short functions like this should be for simple functions... Perhaps: lambda $x: trim($x); $x: trim($x); Or something similar... Anthony
Re: [PHP-DEV] [RFC] Short syntax for anonymous functions
On 19 February 2013 13:57, Marcello Duarte mdua...@inviqa.com wrote:
Inspired by Sara, here is another RFC, I finally got around to draft:
https://wiki.php.net/rfc/short-syntax-for-anonymous-function
Please feedback,
Duh, I don't think function(){} is long.
--
Regards,
Mike
Re: [PHP-DEV] [RFC] Short syntax for anonymous functions
I also am not in favour of the syntax, it's too short and quirky. I'm honestly fine with 'function()' it's very explicit On Tue, Feb 19, 2013 at 1:20 PM, Anthony Ferrara ircmax...@gmail.comwrote: Marcello, On Tue, Feb 19, 2013 at 7:57 AM, Marcello Duarte mdua...@inviqa.com wrote: Inspired by Sara, here is another RFC, I finally got around to draft: https://wiki.php.net/rfc/short-syntax-for-anonymous-function Please feedback, -- Marcello Duarte I like the concept. I dislike the syntax. It looks too much like a JSON object declaration, and it feels like it should be returning an object instead of a closure/anonymous function. Additionally, I don't like that it's also a closure. Short functions like this should be for simple functions... Perhaps: lambda $x: trim($x); $x: trim($x); Or something similar... Anthony
Re: [PHP-DEV] [RFC] Allow non-scalar keys in foreach
On Tue, 19 Feb 2013, Nikita Popov wrote: This RFC proposes to remove the type-restrictions on Iterator keys used in foreach: https://wiki.php.net/rfc/foreach-non-scalar-keys I took over Levi's RFC and added a patch for it. Under Open Questions you write: What should be done with the keys that are valid in the iterator, but not in the array? I think the best approach would be to just set the array keys with the exact same semantics as PHP would do (i.e. with all casts and warnings). Would __toString be called in case the key was an object? cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine -- 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
2013/2/19 Marcello Duarte mdua...@inviqa.com:
Inspired by Sara, here is another RFC, I finally got around to draft:
https://wiki.php.net/rfc/short-syntax-for-anonymous-function
Please feedback,
--
Marcello Duarte
BC break detected:
?php
{
echo foo\n;
return bar;
};
echo baz\n;
return 42;
?
The {} would probably be a closure that is not assigned to anything
while the current behaviour is to print foo and exit while returning
bar.
-1 since it only saves 10 chars (function()) without real added value.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Allow non-scalar keys in foreach
On Tue, Feb 19, 2013 at 2:25 PM, Derick Rethans der...@php.net wrote: On Tue, 19 Feb 2013, Nikita Popov wrote: This RFC proposes to remove the type-restrictions on Iterator keys used in foreach: https://wiki.php.net/rfc/foreach-non-scalar-keys I took over Levi's RFC and added a patch for it. Under Open Questions you write: What should be done with the keys that are valid in the iterator, but not in the array? I think the best approach would be to just set the array keys with the exact same semantics as PHP would do (i.e. with all casts and warnings). Would __toString be called in case the key was an object? Current behavior of PHP can be found here: http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_execute.c#996 So if one goes with that approach, then no, __toString won't be called, it'll throw a * Warning*: Illegal offset type and not set the key. Don't know whether that's good or bad ^^ Nikita
Re: [PHP-DEV] [RFC] Short syntax for anonymous functions
Hi,
I don't really like to write every time a long 'function()', only for passing
a little callback like 'function ($v) { var_dump($v); }'...:
Nice proposal, but writing the last argument outside of the function call could
be confusing... An user-function is not a language construct (like while etc.)
regards,
Bob
Am 19.2.2013 um 13:57 schrieb Marcello Duarte mdua...@inviqa.com:
Inspired by Sara, here is another RFC, I finally got around to draft:
https://wiki.php.net/rfc/short-syntax-for-anonymous-function
Please feedback,
--
Marcello Duarte
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Allow non-scalar keys in foreach
I think the warning can stay as-is, __toString is not necessarily available so casting to string in all occasions is probably not what we want. I'm glad somebody could take this over and provide a complete patch, thanks Nikita! On Tue, Feb 19, 2013 at 2:25 PM, Derick Rethans der...@php.net wrote: On Tue, 19 Feb 2013, Nikita Popov wrote: This RFC proposes to remove the type-restrictions on Iterator keys used in foreach: https://wiki.php.net/rfc/foreach-non-scalar-keys I took over Levi's RFC and added a patch for it. Under Open Questions you write: What should be done with the keys that are valid in the iterator, but not in the array? I think the best approach would be to just set the array keys with the exact same semantics as PHP would do (i.e. with all casts and warnings). Would __toString be called in case the key was an object? cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Etienne Kneuss http://www.colder.ch
Re: [PHP-DEV] [RFC] Allow trailing comma in function call argument lists
Sara, I wasnt commenting that this RFC was different, just in agreement that this syntax is _more_ in line with the list() construct (which then might reflect the skipparams rfc)) If i wasnt clear: from a user point of view: i am all for this RFC ;) Met vriendelijke groet, Robin Speekenbrink Kingsquare BV 2013/2/19 Sara Golemon poll...@php.net On Tue, Feb 19, 2013 at 4:41 AM, Kingsquare.nl - Robin Speekenbrink ro...@kingsquare.nl wrote: Just a question from one of the lingering listeners: would this change also ease the `skipping` of default values for parameters? (as discussed for RFC https://wiki.php.net/rfc/skipparams) That way it would be consistent with this RFC and the list() construct ? It's orthogonal to skipparams. It'd neither help nor hurt based on the recommendations of that RFC. With regard to list(), it already supports expressions like this: list($x,) = array(123); so nothing more needs to be done for it and it's not at odds with either of these RFCs. -Sara
Re: [PHP-DEV] [RFC] Short syntax for anonymous functions
Hello, On Tue, Feb 19, 2013 at 2:57 PM, Marcello Duarte mdua...@inviqa.com wrote: Inspired by Sara, here is another RFC, I finally got around to draft: https://wiki.php.net/rfc/short-syntax-for-anonymous-function Please feedback, -- Marcello Duarte I really don't like syntax for this. It makes it hard to follow. Removing a couple of characters while making the syntax harder to follow isn't a good thing imho. Also it's a BC break, like Patrick mentioned. Have a nice day, 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] [RFC] Short syntax for anonymous functions
Thanks for the feedback. I get most people here don't appreciate the value of
the feature.
I can understand that If you haven't tried to write a tool like capistrano,
rspec, chef, puppet, etc, etc in PHP you probably won't see much value in
implementing such things.
On 19 Feb 2013, at 13:19, Derick Rethans wrote:
On Tue, 19 Feb 2013, Marcello Duarte wrote:
Inspired by Sara, here is another RFC, I finally got around to draft:
https://wiki.php.net/rfc/short-syntax-for-anonymous-function
I'd be really reluctant to add this -- it's yet another (superfluous)
syntactical sugar, there is no patch, and how does this work with bound
variables (use keyword)?
I added an example with the use keyword.
What is superfluous for is useful for other users. It would be useful building
DSL. At my company we use loads of ruby tools for deploying, provisioning, etc.
just because of the DSL they provide. The array short syntax was great news.
Adding a short syntax for closures would make it possible to write such scripts
in PHP – where the syntax would not stand on its way.
On 19 Feb 2013, at 13:28, Patrick ALLAERT wrote:
BC break detected:
?php
{
echo foo\n;
return bar;
};
echo baz\n;
return 42;
?
I am actually more concerned with Patrick's feedback regarding BC. I can't
think of a solution for this right now.
cheers,
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Marcello Duarte
Re: [PHP-DEV] [RFC] Allow non-scalar keys in foreach
Gah, no top posting! On Tue, 19 Feb 2013, Etienne Kneuss wrote: On Tue, Feb 19, 2013 at 2:25 PM, Derick Rethans der...@php.net wrote: On Tue, 19 Feb 2013, Nikita Popov wrote: This RFC proposes to remove the type-restrictions on Iterator keys used in foreach: https://wiki.php.net/rfc/foreach-non-scalar-keys I took over Levi's RFC and added a patch for it. Under Open Questions you write: What should be done with the keys that are valid in the iterator, but not in the array? I think the best approach would be to just set the array keys with the exact same semantics as PHP would do (i.e. with all casts and warnings). Would __toString be called in case the key was an object? I think the warning can stay as-is, __toString is not necessarily available so casting to string in all occasions is probably not what we want. I think it should cast to a string if possible. You are now making iterator_to_array not work with the new feature, and I find that a bit silly. Whether it should be __toString (or __toKey) I don't really care, but this new support for objects should be supported everywhere (and that includes iterator_to_array). cheers, Derick -- 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
Hi Marcello,
Am 19.02.2013 um 14:51 schrieb Marcello Duarte mdua...@inviqa.com:
Thanks for the feedback. I get most people here don't appreciate the value of
the feature.
I can understand that If you haven't tried to write a tool like capistrano,
rspec, chef, puppet, etc, etc in PHP you probably won't see much value in
implementing such things.
On 19 Feb 2013, at 13:19, Derick Rethans wrote:
On Tue, 19 Feb 2013, Marcello Duarte wrote:
Inspired by Sara, here is another RFC, I finally got around to draft:
https://wiki.php.net/rfc/short-syntax-for-anonymous-function
I don’t like the syntax, but the proposal in general. If you compare PHPs
syntax to various others, it is indeed clumsy.
Python:
map(lambda v: v * 2, [1, 2, 3])
Ruby:
[1, 2, 3].map{|x| x * 2}
Scala:
List(1, 2, 3).map((x: Int) = x * 2)
PHP:
array_map(function ($x) {return $x * 2;}, [1, 2, 3]);
So even a statically typed language like Scala is shorter and better to read. A
good improvement would be implicit return and getting rid of the function
keyword.
array_map(($x): $x * 2;, [1, 2, 3]);
But this RFC should come with a patch, otherwise we are discussing things that
aren’t necessarily easy to implement.
cu,
Lars
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Allow non-scalar keys in foreach
On Tue, Feb 19, 2013 at 2:55 PM, Derick Rethans der...@php.net wrote: Gah, no top posting! On Tue, 19 Feb 2013, Etienne Kneuss wrote: On Tue, Feb 19, 2013 at 2:25 PM, Derick Rethans der...@php.net wrote: On Tue, 19 Feb 2013, Nikita Popov wrote: This RFC proposes to remove the type-restrictions on Iterator keys used in foreach: https://wiki.php.net/rfc/foreach-non-scalar-keys I took over Levi's RFC and added a patch for it. Under Open Questions you write: What should be done with the keys that are valid in the iterator, but not in the array? I think the best approach would be to just set the array keys with the exact same semantics as PHP would do (i.e. with all casts and warnings). Would __toString be called in case the key was an object? I think the warning can stay as-is, __toString is not necessarily available so casting to string in all occasions is probably not what we want. I think it should cast to a string if possible. You are now making iterator_to_array not work with the new feature, and I find that a bit silly. Whether it should be __toString (or __toKey) I don't really care, but this new support for objects should be supported everywhere (and that includes iterator_to_array). I think this RFC is orthogonal to iterator_to_array supporting conversions from objects to keys. $array[$obj] = 42; does not call __toString (or __toKey), it throws a catchable fatal. IMO it would be inconsistent if iterator_to_array gracefully accepted objects as keys.
Re: [PHP-DEV] [RFC] Short syntax for anonymous functions
I can understand that If you haven't tried to write a tool like capistrano, rspec, chef, puppet, etc, etc in PHP you probably won't see much value in implementing such things. Your RFC doesn't go to great lengths to explain the value either. Pretend the reader has no experience with any of those tools you mention, pretend the only language they know is PHP, please explain where the value for this syntax is in PHP? I find the existing syntax easy to understand. I find the proposed syntax disproportionally difficult and unintuitive in relation to any benefit it is supposed to give. What is superfluous for is useful for other users. It would be useful building DSL. At my company we use loads of ruby tools for deploying, provisioning, etc. just because of the DSL they provide. The array short syntax was great news. Adding a short syntax for closures would make it possible to write such scripts in PHP – where the syntax would not stand on its way. insert PHP is not Ruby rhetoric If Ruby is the right tool for the job, and PHP is not the right tool for the job, the answer to which language to use seems obvious right? I disagree wholeheartedly that this proposed syntax would make code in any way more readable, or maintainable.
Re: [PHP-DEV] [RFC] Short syntax for anonymous functions
I also don't like the RFC proposed syntax. I have to say that I don't
really like those short magic-like syntax things in in other languages too.
If you work with them on the day-to-day basis and tools are built around
those concepts - it's one thing. In PHP syntax is mostly self-explanatory
and for the most part there is only one way to do it (or the differences in
syntax have their own uses - like for () {} is used in code and for ():
endfor; is good for templates).
I like the current $x = function () {}. It's the same in JavaScript (and
because most of us use jQuery - we use it a lot) and realistically I don't
type it - IDE does auto-complete for me.
P.S. I want to tell all those syntax enhancement guys - don't push
syntax-sugar stuff into PHP for the sake of shorter syntax. First, for the
most part it looks alien in PHP. Second - it really depends on the
preception - I for example hate Ruby syntax, it's crap and unreadable -
this just illustrated that's one mans beauty is other mans ugly. PHP syntax
maybe not the most pretty out there, but it is sure as hell easy to read
even if coder makes a mess of it. I saw the opinion on the internet that
PHP is a scripted version of C in the sense of their positioning and usage.
And I totally agree with it, and I want it to stay that way. PHP should not
be the pretty one, or be on the feature edge. PHP needs to just walk with
time and adopt the good stuff fully integrating into itself, not just
patching the core and adding some half-weird syntax that just doesn't
really fit PHP.
You also have to remember that PHP is a WEB development script language,
not general purpose script language like Ruby or Python. Not all features,
that are good in general purpose languages, are good for WEB language. Some
of those features may bring performance hits that are not worth it.
My 0.02$,
Arvids.
Re: [PHP-DEV] [RFC] Allow trailing comma in function call argument lists
On 19 Feb 2013, at 12:06, Sara Golemon poll...@php.net wrote: Opening RFC to allow trailing comma in function call argument lists https://wiki.php.net/rfc/trailing-comma-function-args +1 Melanie -- 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
+1 On Feb 19, 2013 10:13 AM, Cyberspice thyberthpi...@gmail.com wrote: On 19 Feb 2013, at 12:06, Sara Golemon poll...@php.net wrote: Opening RFC to allow trailing comma in function call argument lists https://wiki.php.net/rfc/trailing-comma-function-args +1 Melanie -- 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
+1 On 19 February 2013 07:06, Sara Golemon poll...@php.net wrote: 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
Re: [PHP-DEV] [RFC] Allow trailing comma in function call argument lists
On Feb 19, 2013, at 8:00 AM, Sara Golemon poll...@php.net wrote: On Tue, Feb 19, 2013 at 4:41 AM, Kingsquare.nl - Robin Speekenbrink ro...@kingsquare.nl wrote: Just a question from one of the lingering listeners: would this change also ease the `skipping` of default values for parameters? (as discussed for RFC https://wiki.php.net/rfc/skipparams) That way it would be consistent with this RFC and the list() construct ? It's orthogonal to skipparams. It'd neither help nor hurt based on the recommendations of that RFC. With regard to list(), it already supports expressions like this: list($x,) = array(123); so nothing more needs to be done for it and it's not at odds with either of these RFCs. I would vote +1 on this solely for the sake of consistency. I've never liked the idea behind the parser's actions on constructs (list, array). -Sara -- 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] PHP causing high number of NFS getattr operations?
On 19/02/13 09:36, Terry Ellison wrote:
The point that this thread highlights is that apps developers /
administrators at both ends of the scale -- the enterprise and the
shared service user -- normally have little say over the
infrastructure architecture on which their application runs. In both
these cases the infrastructure will be hosting 100s if not 1000s of
apps, and the environment cannot be tailored to any one app. So
issues like storage architecture and security architecture (e.g.
UID-based enforcement of app separation) are a given as NFRs
(non-functional requirements). Use of NFS with server / storage
separation is still a standard implementation design pattern, when
enterprises require simple-to-manage scalability on these tiers. We
aren't going to change this, and neither will the O/P.
Surely PHP will achieve better penetration and the greater acceptance
if it can offer more robust performance in this sort of environment?
Sure, but then you can go with something like Redis.
But, again, if you go back to the original question, this has nothing to
do with often-changing data in a couple of PHP include files:
We have several Apache 2.2 / PHP 5.4 / APC 3.1.13 servers all serving
mostly PHP over NFS (we have separate servers for static content).
So they are serving up all their PHP over NFS for some reason.
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
Re: [PHP-DEV] [RFC] Short syntax for anonymous functions
There's already been an overwhelming negative reaction to this
particular proposed syntax so I won't belabor the point much. In
short, this is too similar to block statements and does have BC
issues.
--
IF (and I stress if) we add a a shorter anonymous function syntax I'd
like it to be geared towards one-liners because that's where the
current syntax feels really verbose, especially when you close over
other variables:
function ($n) use ($m) { return $m * $n; }
Versus one potential option:
($value) |$m| = $m * $n;
This syntax is short and expressive at the expense of clarity.
Basically all short-syntax has that trade-off, so I am personally fine
with it. The only other potential problem I see is parsing it; someone
more familiar with PHP's parser would have to verify whether that
would be a problem.
--
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
IF (and I stress if) we add a a shorter anonymous function syntax I'd
like it to be geared towards one-liners because that's where the
current syntax feels really verbose, especially when you close over
other variables:
function ($n) use ($m) { return $m * $n; }
Versus one potential option:
($value) |$m| = $m * $n;
My apologies, this was meant to read:
($n) |$m| = $m * $n;
--
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
Hello,
On Tue, Feb 19, 2013 at 6:09 PM, Levi Morrison morrison.l...@gmail.com wrote:
There's already been an overwhelming negative reaction to this
particular proposed syntax so I won't belabor the point much. In
short, this is too similar to block statements and does have BC
issues.
--
IF (and I stress if) we add a a shorter anonymous function syntax I'd
like it to be geared towards one-liners because that's where the
current syntax feels really verbose, especially when you close over
other variables:
function ($n) use ($m) { return $m * $n; }
Versus one potential option:
($value) |$m| = $m * $n;
This syntax is short and expressive at the expense of clarity.
Basically all short-syntax has that trade-off, so I am personally fine
with it. The only other potential problem I see is parsing it; someone
more familiar with PHP's parser would have to verify whether that
would be a problem.
I think that before we establish a syntax for this we should see if there's
a real need for this feature, and after that, get a syntax to implement the
feature.
Say we agree on the syntax above
($n) |$m| = $m * $n;
What happens when my one liner function needs to do one more operation
like checking the value of $n before multiplication?
I'd rather see a proposal to drop the 'function' keyword from the classes
methods and only leave the visibility scope and method name, but for
anonymous functions like this one I'd rather keep the 'function' keyword in
order to have better visibility when I'm doing a code review/scan new code
in a library.
What do you think?
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
($n) = { echo $n; }
($n) use ($m) = { echo $n; }
On Tue, Feb 19, 2013 at 8:11 PM, Levi Morrison morrison.l...@gmail.comwrote:
IF (and I stress if) we add a a shorter anonymous function syntax I'd
like it to be geared towards one-liners because that's where the
current syntax feels really verbose, especially when you close over
other variables:
function ($n) use ($m) { return $m * $n; }
Versus one potential option:
($value) |$m| = $m * $n;
My apologies, this was meant to read:
($n) |$m| = $m * $n;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Best regards, Andrey
Re: [PHP-DEV] [RFC] Short syntax for anonymous functions
On 19 Feb 2013, at 16:29, Morfi wrote:
($n) = { echo $n; }
($n) use ($m) = { echo $n; }
Morfi, the problem pointed out already is when you have no arguments it would
be the same as the statement block, which would cause BC issues.
On Tue, Feb 19, 2013 at 8:11 PM, Levi Morrison morrison.l...@gmail.comwrote:
IF (and I stress if) we add a a shorter anonymous function syntax I'd
like it to be geared towards one-liners because that's where the
current syntax feels really verbose, especially when you close over
other variables:
function ($n) use ($m) { return $m * $n; }
Versus one potential option:
($value) |$m| = $m * $n;
My apologies, this was meant to read:
($n) |$m| = $m * $n;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Best regards, Andrey
--
Marcello Duarte
marcello.dua...@gmail.com
http://marcelloduarte.net
--
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
On Tue, 19 Feb 2013 16:31:39 -, Marcello Duarte mdua...@inviqa.com
wrote:
On 19 Feb 2013, at 16:29, Morfi wrote:
($n) = { echo $n; }
($n) use ($m) = { echo $n; }
Morfi, the problem pointed out already is when you have no arguments it
would be the same as the statement block, which would cause BC issues.
Why not () = { echo $n; } then?
--
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
Say we agree on the syntax above ($n) |$m| = $m * $n; What happens when my one liner function needs to do one more operation like checking the value of $n before multiplication? As I stated before suggesting the syntax: It's only meant for a single expression. It's purposefully NOT intended to cover multiple expressions. In that case the current (verbose) syntax is better for all criteria I care about. Additionally, neither Python nor Dart allows multiple expressions in their short-syntax functions. -- 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
Say we agree on the syntax above ($n) |$m| = $m * $n; What happens when my one liner function needs to do one more operation like checking the value of $n before multiplication? As I stated before suggesting the syntax: It's only meant for a single expression. It's purposefully NOT intended to cover multiple expressions. In that case the current (verbose) syntax is better for all criteria I care about. Additionally, neither Python nor Dart allows multiple expressions in their short-syntax functions. Have you considered how this will work/look in an array? $a = [$b = ($n) $m = $m * $n]; // wat. S -- 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
On 19 Feb 2013, at 14:16, Leigh wrote: I can understand that If you haven't tried to write a tool like capistrano, rspec, chef, puppet, etc, etc in PHP you probably won't see much value in implementing such things. Your RFC doesn't go to great lengths to explain the value either. Pretend the reader has no experience with any of those tools you mention, pretend the only language they know is PHP, please explain where the value for this syntax is in PHP? Very good feedback. Very much appreciated. I will see if I can expand on what I have that. Thank you. I find the existing syntax easy to understand. I find the proposed syntax disproportionally difficult and unintuitive in relation to any benefit it is supposed to give. What is superfluous for is useful for other users. It would be useful building DSL. At my company we use loads of ruby tools for deploying, provisioning, etc. just because of the DSL they provide. The array short syntax was great news. Adding a short syntax for closures would make it possible to write such scripts in PHP – where the syntax would not stand on its way. insert PHP is not Ruby rhetoric If Ruby is the right tool for the job, and PHP is not the right tool for the job, the answer to which language to use seems obvious right? I find that more and more my developers have to learn ruby just to be able to work in our projects. We are one of the largest PHP shops in Europe and even the proprietary tools we are writing for DevOps stuff we are writing in Ruby. This small syntax arrangement would make it possible to write DSLs in PHP. The result is that I can have my PHP developers focusing on one language only and get the job done. The problem of the web is a bit more complex now, if you look on all you need to develop and deploy a large PHP application. I disagree wholeheartedly that this proposed syntax would make code in any way more readable, or maintainable. Please understand that there is a difference between code you write and other people maintain, and code you write for other people to use. The purpose of this feature is focused on the later, to allow the construction of DSLs, so users of your code can focus on the task at hand. -- Marcello Duarte -- 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
On Tue, Feb 19, 2013 at 6:40 PM, Levi Morrison morrison.l...@gmail.comwrote:
Say we agree on the syntax above
($n) |$m| = $m * $n;
What happens when my one liner function needs to do one more operation
like checking the value of $n before multiplication?
As I stated before suggesting the syntax: It's only meant for a single
expression. It's purposefully NOT intended to cover multiple
expressions. In that case the current (verbose) syntax is better for
all criteria I care about. Additionally, neither Python nor Dart
allows multiple expressions in their short-syntax functions.
+1
A similar syntax was applied in C# lambads. For example :
m = m * n. Though C# allows to use code block in lambdas, I do think that
we should focus on one-expression only, since the current callbacks syntax
(function() { }) is great, I believe, for multiline code.
--
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
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. Secondly, if you hit a situation where the syntax is confusing, use a less confusing syntax if possible. This goes for any type of syntactic confusion, not just short-array syntax. -- 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
On 19 February 2013 16:46, Marcello Duarte mdua...@inviqa.com wrote: I find that more and more my developers have to learn ruby just to be able to work in our projects. We are one of the largest PHP shops in Europe and even the proprietary tools we are writing for DevOps stuff we are writing in Ruby. This small syntax arrangement would make it possible to write DSLs in PHP. The result is that I can have my PHP developers focusing on one language only and get the job done. The problem of the web is a bit more complex now, if you look on all you need to develop and deploy a large PHP application. That is one of the choices you made for your projects. You looked at what was available, and decided that Ruby was the best choice for the task at hand. While I agree it's unfortunate that your developers to have to waste their time learning Ruby, when they could be doing more productive things, that doesn't mean it's a good idea to try and retrofit some evil syntax into PHP just for you, no matter how large an organisation you are. By the way, PHP is open source, feel free to make the parser do whatever you want. On 19 February 2013 16:40, Levi Morrison morrison.l...@gmail.com wrote: Say we agree on the syntax above ($n) |$m| = $m * $n; What happens when my one liner function needs to do one more operation like checking the value of $n before multiplication? As I stated before suggesting the syntax: It's only meant for a single expression. It's purposefully NOT intended to cover multiple expressions. In that case the current (verbose) syntax is better for all criteria I care about. Additionally, neither Python nor Dart allows multiple expressions in their short-syntax functions. I prefer this. In this case (imho), a simplified syntax *should* go hand in hand with simplified functionality. If PHP is to adopt such a syntax I'd much prefer it takes the single expression approach. This does achieve the goals of easy readability and maintenance because you know the expression is bound by certain limitations.
Re: [PHP-DEV] [RFC] Allow non-scalar keys in foreach
I think the warning can stay as-is, __toString is not necessarily available so casting to string in all occasions is probably not what we want. I think it should cast to a string if possible. You are now making iterator_to_array not work with the new feature, and I find that a bit silly. Whether it should be __toString (or __toKey) I don't really care, but this new support for objects should be supported everywhere (and that includes iterator_to_array). I think this RFC is orthogonal to iterator_to_array supporting conversions from objects to keys. $array[$obj] = 42; does not call __toString (or __toKey), it throws a catchable fatal. IMO it would be inconsistent if iterator_to_array gracefully accepted objects as keys. Personally I think the real problem here is that `iterator_to_array` should *not* copy keys by default. However, what's done is done and we need to thoughtfully consider this situation. You already CAN return objects from an iterator; you just can't use it in a foreach. If you try to use that iterator in `iteator_to_array` you get a lovely warning: Warning: Illegal type returned from %s::key() in %s on line %d I'm all for *not* changing that behavior; if they want it ignore keys then they can pass `false` as a second parameter to `iterator_to_array`. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Questions regarding DateTimeImmutable
a) The DateTimeImmutable class extends the DateTime class. Why was
this done this way? Both classes are incompatible (as in the
inheritance violates LSP). E.g. if you hint against DateTime, then
passing in DateTimeImmutable will not work (as the behavior is
different). The same also applies the other way around (DateTime
extending DateTimeImmutable). Imho a mutable and an immutable variant
of a class can't reasonably extend from one another, so I'm not sure
why this was done.
It was mostly done so that methods and code accepting do not need
signature changes. In many cases library code would accept a DateTime,
call modify and return the changed object - not realizing that the
original object was changed as well causes issues with calling code. By
having DateTimeImmutable extend DateTime they can continue to pass them
in, without having to change library code at all.
What if they return the same object knowing that `modify` actually
modifies the object? I personally would have done that except in the
lucky situation that I used it in the return statement:
return $timestamp-modify('+30 days');
Then I'd luckily work with DateTimeImmutable.
---
While I personally think DateTime should have been immutable from the
beginning, I don't think it's in PHP's best interest to try to fix
this particular problem by introducing DateTimeImmutable.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Dropping requirement for `function` keyword for methods in classes/interfaces/etc
Hi! As someone mentioned in the thread about short syntax for closures, we could also drop requirement for `function` keyword when defining/declaring methods in classes, interfaces or traits. I have long noticed how redundant it is. The patch is pretty easy as it was with commas :) It is absolutely backwards compatible (you can use `function` or you can not use it). Here's the patch: https://gist.github.com/nikita2206/4988075 If people will welcome this proposal, I would need some karma for making RFC. -- 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
On 19 Feb 2013, at 17:32, Leigh wrote: On 19 February 2013 16:46, Marcello Duarte mdua...@inviqa.com wrote: I find that more and more my developers have to learn ruby just to be able to work in our projects. We are one of the largest PHP shops in Europe and even the proprietary tools we are writing for DevOps stuff we are writing in Ruby. This small syntax arrangement would make it possible to write DSLs in PHP. The result is that I can have my PHP developers focusing on one language only and get the job done. The problem of the web is a bit more complex now, if you look on all you need to develop and deploy a large PHP application. That is one of the choices you made for your projects. You looked at what was available, and decided that Ruby was the best choice for the task at hand. While I agree it's unfortunate that your developers to have to waste their time learning Ruby, when they could be doing more productive things, that doesn't mean it's a good idea to try and retrofit some evil syntax into PHP just for you, no matter how large an organisation you are. I am curious: evil syntax? I am not attached to the syntax I have described. I am open to discuss the syntax. It would be good with using the callable as last argument converted into a block for DSLs. I don't think this is evil, but I don't want to fall into a personal taste debate. I want something I can use. And just for you is also inaccurate. You will find that the technologies I've been referring to are becoming the tools you will use for DevOps, etc... tasks. Do you guys listen to people outside of internals? It would be good to have a feedback mechanism that actually involve PHP developers in real world projects. I take that if you are coding with other languages like C, all the time, that you may loose contact with the way things are done. By the way, PHP is open source, feel free to make the parser do whatever you want. On 19 February 2013 16:40, Levi Morrison morrison.l...@gmail.com wrote: Say we agree on the syntax above ($n) |$m| = $m * $n; What happens when my one liner function needs to do one more operation like checking the value of $n before multiplication? As I stated before suggesting the syntax: It's only meant for a single expression. It's purposefully NOT intended to cover multiple expressions. In that case the current (verbose) syntax is better for all criteria I care about. Additionally, neither Python nor Dart allows multiple expressions in their short-syntax functions. I prefer this. In this case (imho), a simplified syntax *should* go hand in hand with simplified functionality. If PHP is to adopt such a syntax I'd much prefer it takes the single expression approach. This does achieve the goals of easy readability and maintenance because you know the expression is bound by certain limitations. -- Marcello Duarte Head of Training Inviqa enterprise open source e-mail: marce...@inviqa.com mobile: +44 78 3316 8193 phone: +44 20 3179 9555 twitter: @_md @Inviqa inviqa.com Disclaimer This email and any attachments may be confidential and are intended solely for the use of the addressee. Any views or opinions expressed are those of the author and may not represent those of Inviqa. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error.
Re: [PHP-DEV] bug 49348 - notice on $this-undefined++
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. I've been bitten by this from time to time. A notice would have been nice. -- 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
Hi, On Tue, 2013-02-19 at 21:44 +, Nikita Nefedov wrote: Hi! As someone mentioned in the thread about short syntax for closures, we could also drop requirement for `function` keyword when defining/declaring methods in classes, interfaces or traits. I proposed this in November '10: http://news.php.net/php.internals/50628 I agreed to the conclusion that the function keyword provided a nice way to grep for functions when handling foreign code and leaving it out only provides little improvement in less typing. Please provide new arguments for a new discussion. (That thread was rather long) And as a general note I'd like to remind you all about Rasmus' recent mail: http://news.php.net/php.internals/65894 - In my words: Why not fix bugs instead of creating new ones? johannes -- 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
@Marcello: actually, I am also of the idea that there's no real additional
value in such a syntax...
Since I'm using ZF2 (yeah, that framework that converts array to
applications) I am kinda used to have dozens of `function () {}` closures
for service factories: so far no problems with it.
As stated before, it spares 9 chars while the end developer (devops or
whoever coding instead of of the devops) loses a lot of readability that is
not really such a big problem.
Also, as it is for DSLs, you could always use a parser to handle this kind
of thing in your own domain.
What exactly is the limit that you see when applying the more verbose
`function () {}` syntax? I am just wondering since moving to `{}` will
still not make this portable to any platform except PHP itself.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
Re: [PHP-DEV] [RFC] Allow trailing comma in function call argument lists
On 19.02.2013 13:06, Sara Golemon wrote: Opening RFC to allow trailing comma in function call argument lists https://wiki.php.net/rfc/trailing-comma-function-args For completeness' sake: The VCS argument is kind of moot if you format your source code like it's sometimes/often seen in Haskell code: $fp = fopen( sample.txt , r+ ); (but mostly not with function calls, more with data structures afaik) I know, hardly anyone uses this in PHP, but it's a workaround for the main reasoning in the RFC. Personally, I'm +1 :) Greetings, Florian -- 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
On 02/19/2013 09:45 AM, Marcello Duarte wrote: And just for you is also inaccurate. You will find that the technologies I've been referring to are becoming the tools you will use for DevOps, etc... tasks. Do you guys listen to people outside of internals? It would be good to have a feedback mechanism that actually involve PHP developers in real world projects. I take that if you are coding with other languages like C, all the time, that you may loose contact with the way things are done. I should add don't flame existing developers to https://blogs.oracle.com/opal/entry/the_mysterious_php_rfc_process (Note that In summary paragraph at the end). Without getting into the merits of the syntax change, I will say that the RFC is missing a lot: who will write the patch, where are examples of syntax in other languages, where is the clear comparison with existing PHP syntax, what are the quantifiable benefits. Don't forget to update the RFC with the mail list comments, e.g. the BC issue. Even if your RFC is rejected, it will help future PHP development if the RFC contains a summary of mail list discussions. 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] Dropping requirement for `function` keyword for methods in classes/interfaces/etc
On Tue, 19 Feb 2013 17:53:40 -, Johannes Schlüter johan...@schlueters.de wrote: I agreed to the conclusion that the function keyword provided a nice way to grep for functions when handling foreign code and leaving it out only provides little improvement in less typing. Please provide new arguments for a new discussion. (That thread was rather long) And as a general note I'd like to remind you all about Rasmus' recent mail: http://news.php.net/php.internals/65894 - In my words: Why not fix bugs instead of creating new ones? johannes Hmm, I agree about grepping, but how often do you do it? Actually, last time I grepped php files was half a year ago I think, when I had just ssh connection and didn't want to mount sshfs. But usually there's IDEs that can statically analyze your code and let you search against huge codebases in seconds, I don't want to sound mean, but hey, does anybody greps php code? What about reasoning - of course there's no reasons besides less typing. At the moment, usually when I want to define method, I usually already know will be in its body so I'm trying to type as fast as I can, and I often make some mistake in `public` keyword or `function`, actually it happens all the time :) So for me it would be pretty good feature if I could write one less word. I agree with Sara about requirement for explicit declaration of visibility attr. -- 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
On 02/19/2013 02:39 PM, Nikita Nefedov wrote: Hmm, I agree about grepping, but how often do you do it? Actually, last time I grepped php files was half a year ago I think, when I had just ssh connection and didn't want to mount sshfs. But usually there's IDEs that can statically analyze your code and let you search against huge codebases in seconds, I don't want to sound mean, but hey, does anybody greps php code? About 20-30 times every single day. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Quick question about bug 64154
Hey guys, Somebody filed a bug report (https://bugs.php.net/bug.php?id=64154) about non-bundled extensions like php_zip being included in php.ini. Is there a reason why we're keeping those in there, or is it just that nobody ever got around to removing them? Thanks! --Kris
Re: [PHP-DEV] Dropping requirement for `function` keyword for methods in classes/interfaces/etc
Rasmus Lerdorf wrote: On 02/19/2013 02:39 PM, Nikita Nefedov wrote: Hmm, I agree about grepping, but how often do you do it? Actually, last time I grepped php files was half a year ago I think, when I had just ssh connection and didn't want to mount sshfs. But usually there's IDEs that can statically analyze your code and let you search against huge codebases in seconds, I don't want to sound mean, but hey, does anybody greps php code? About 20-30 times every single day. Ditto via the Eclipse equivalent ... Has anything changed since we last discussed this? And threw it out ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- 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
On Tue, Feb 19, 2013 at 11:53 AM, Lester Caine les...@lsces.co.uk wrote: Rasmus Lerdorf wrote: On 02/19/2013 02:39 PM, Nikita Nefedov wrote: Hmm, I agree about grepping, but how often do you do it? Actually, last time I grepped php files was half a year ago I think, when I had just ssh connection and didn't want to mount sshfs. But usually there's IDEs that can statically analyze your code and let you search against huge codebases in seconds, I don't want to sound mean, but hey, does anybody greps php code? About 20-30 times every single day. Ditto via the Eclipse equivalent ... Has anything changed since we last discussed this? And threw it out ... Yes: the dynamics of the people who vote. -- 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
On Tue, 19 Feb 2013 18:02:57 -, Christopher Jones christopher.jo...@oracle.com wrote: What about including a few basic examples aka test cases in your patch? If the feature is accepted, you'll need to include a LOT of testcases. Chris Hi Chris, this code could be a basic case (just for the sake of understanding) https://gist.github.com/nikita2206/4988665 But I will add an actual tests if it's going to receive some support. On Tue, 19 Feb 2013 18:41:41 -, Rasmus Lerdorf ras...@lerdorf.com wrote: On 02/19/2013 02:39 PM, Nikita Nefedov wrote: About 20-30 times every single day. -Rasmus Hi Rasmus, 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. -- 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
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 -- 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
On Tue, 19 Feb 2013 19:10:22 -, Rasmus Lerdorf ras...@lerdorf.com 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. -- 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++
Hi Stas, I'll take a look tomorrow or after tomorrow. Sorry, quite busy. Thanks. Dmitry. On Tue, Feb 19, 2013 at 1:23 PM, Stas Malyshev smalys...@sugarcrm.comwrote: 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?
Hi! and IIRC mwiki does 4 of these on a page render. Here a pattern based on (@include($file) == 1) is more cache-friendly. This goes back to the fact that @ does not really disable errors - it only disables reporting of the errors, but the whole message is generated and goes all the cycle up to the actual error reporting before being suppressed. I've tried to address this problem a number of times but looks like there's really no way to do it without sacrificing some parts of current error reporting such as track_errors. 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 :-( Could you explain what you're talking about here? -- 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
On Tue, 2013-02-19 at 23:07 +, Nikita Nefedov wrote: At the end, you can always use `grep '(function|public|private| protected) You've forgotten abstract and static (mind that we don't force the order of those) It saves 9 key strokes (while many IDEs can assist) and helps when looking for issues in foreign code bases (what many of us do) so unless there's anything new we should try to keep this list productive. 5.5 is waiting to get out. johannes -- 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
On 20 February 2013 00:12, Nikita Nefedov inefe...@gmail.com wrote: On Tue, 19 Feb 2013 19:10:22 -, Rasmus Lerdorf ras...@lerdorf.com 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Just a quick check: you're absolutely certain this issue isn't much better/easier handled with IDE macros/plugins? Something along the lines of zen coding? If you're really that obsessed with typing 9 characters less, you must have considered keyboard shortcuts that let you type the docblock, visibility, etc. in just 3-5 keystrokes. Just a thought from userland Peter -- hype WWW: plphp.dk / plind.dk CV: careers.stackoverflow.com/peterlind LinkedIn: plind Twitter: kafe15 /hype -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Quick question about bug 64154
Den 19/02/2013 kl. 19.48 skrev Kris Craig kris.cr...@gmail.com: Hey guys, Somebody filed a bug report (https://bugs.php.net/bug.php?id=64154) about non-bundled extensions like php_zip being included in php.ini. Is there a reason why we're keeping those in there, or is it just that nobody ever got around to removing them? Don't we build zip as a static extension on Windows? Thanks! --Kris -- 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
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.
-- Sandy
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Quick question about bug 64154
Kalle Sommer Nielsen in php.internals (Tue, 19 Feb 2013 22:27:42 +0100): Den 19/02/2013 kl. 19.48 skrev Kris Craig kris.cr...@gmail.com: Somebody filed a bug report (https://bugs.php.net/bug.php?id=64154) about non-bundled extensions like php_zip being included in php.ini. Is there a reason why we're keeping those in there, or is it just that nobody ever got around to removing them? Don't we build zip as a static extension on Windows? Yes, but the php.ini_development and php.ini_production still contain this line, even in PHP 5.5.0alpha4: ;extension=php_zip.dll So I can imagine a user is looking for php_zip.dll. Jan -- 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
Are we really trying to look under ground now for ways to change the language syntax? Unless there's a strong case to adding/removing/changing syntax, that goes well beyond 'because we can' or 'it shortens the code' it shouldn't even be brought up for discussion. Zeev On 19 בפבר 2013, at 19:44, Nikita Nefedov inefe...@gmail.com wrote: Hi! As someone mentioned in the thread about short syntax for closures, we could also drop requirement for `function` keyword when defining/declaring methods in classes, interfaces or traits. I have long noticed how redundant it is. The patch is pretty easy as it was with commas :) It is absolutely backwards compatible (you can use `function` or you can not use it). Here's the patch: https://gist.github.com/nikita2206/4988075 If people will welcome this proposal, I would need some karma for making RFC. -- 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] PHP causing high number of NFS getattr operations?
On 19/02/13 20:32, Stas Malyshev wrote: Hi! and IIRC mwiki does 4 of these on a page render. Here a pattern based on (@include($file) == 1) is more cache-friendly. This goes back to the fact that @ does not really disable errors - it only disables reporting of the errors, but the whole message is generated and goes all the cycle up to the actual error reporting before being suppressed. I've tried to address this problem a number of times but looks like there's really no way to do it without sacrificing some parts of current error reporting such as track_errors. Yup, in this scenario we're trading off two things. What the pattern is saying is if the source file exists then compile it. However, if the file exists, in say 90+% of the cases, and the code is often cached then the file_exists check generates I/O that isn't needed if the file is already APC (or O+ / xcache) cached. Yup if the file is missing then the error is generated and trapped in the reporting cycle, but the final result is that the result is false and the false==1 fails. Other than the wasted cycles in running up this stack, there aren't any other side-effects that I am aware of. Are there any? 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. 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 :-( Could you explain what you're talking about here? The fact that you are engaging in this dialogue is great and I really appreciate it. What I am still trying to work out is how to interact with you guys in a way that is mutually productive. I did make the mistake of choosing the mainstay stable version iN live prod systems use -- 5.3 -- to take this whole issue apart and I guess that the dev team regards this as history. 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? In architectural terms I feel that having a universal cache option is important. It changes the mindset from something which is only used in niche performance use cases to a standard option. It also means that the cache can be stress tested by the entire php test suite. However, to do some of this you don't start with a patch, but with an RFC informed by evidence, and that's my real reason for doing this demonstrator. //Terry
Re: [PHP-DEV] PHP 5.3.22RC1 and 5.4.12RC1 Released for Testing!
Johannes Schlüter in php.internals (Thu, 31 Jan 2013 16:00:17 +0100): If no critical issues is found in this RC, the final version will be released in two weeks. Just curious: what is keeping 5.3.22 and 5.4.12 from being released? Are there any issues? Jan -- 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
2013/2/19 Nikita Nefedov inefe...@gmail.com: Hmm, I agree about grepping, but how often do you do it? Actually, last time I grepped php files was half a year ago I think, when I had just ssh connection and didn't want to mount sshfs. But usually there's IDEs that can statically analyze your code and let you search against huge codebases in seconds, I don't want to sound mean, but hey, does anybody greps php code? Yes, daily. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Questions regarding DateTimeImmutable
On Tue, 19 Feb 2013 13:01:18 +0100, Derick Rethans der...@php.net wrote: On Fri, 15 Feb 2013, Sanford Whiteman wrote: I think it was done to ease adoption even though it was known to violate LSP. To quote Stas, As for established practice, everybody expects DateTime, so IMHO we should leave DateTime as base class even though it's not strictly OO-pure. This is not a matter of some abstract OO-pureness. 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. This way does let users sub in DateTimeImmutable more easily and patch over a ton of unintended -- maybe not even fully noted or understood -- defects in their apps? I dunno. 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. Yes, that's exactly the idea. IMO, the classes should not be part of the same hierarchy. If it doesn't matter whether a DateTime or a DateTimeImmutable is passed, then don't typehint. An advantage of PHP is that you can use duck typing. If you do typehint, but then the subclasses break the post-conditions... what's the point? 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. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.22RC1 and 5.4.12RC1 Released for Testing!
On Wed, 2013-02-20 at 00:13 +0100, Jan Ehrhardt wrote: Johannes Schlüter in php.internals (Thu, 31 Jan 2013 16:00:17 +0100): If no critical issues is found in this RC, the final version will be released in two weeks. Just curious: what is keeping 5.3.22 and 5.4.12 from being released? Are there any issues? As a look on qa.php.net or the box on the top right of php.net tells we have RC2 for both out, you can also see in the repo that the release is being prepared: http://git.php.net/?p=php-src.git;a=blobdiff;f=NEWS;h=d3a3e9fa0f344d9b736ea17ce408df6b02e8b561;hp=c4262020de69b7a93b8fcf4923e85194756435a7;hb=0183c29cb3921926855ed6f5e7cea7851fb8a5a1;hpb=904d2202eaecb7c300c36f37ebc5503513220c09 Please test the RCs and provide test feedback. Thanks. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.22RC1 and 5.4.12RC1 Released for Testing!
Hi! Johannes Schlüter in php.internals (Thu, 31 Jan 2013 16:00:17 +0100): If no critical issues is found in this RC, the final version will be released in two weeks. Just curious: what is keeping 5.3.22 and 5.4.12 from being released? Are there any issues? We had 5.4.12 RC2 last week, due to recent SOAP fixes we had to pull in, and will have 5.4.12 GA this week. -- 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] Debug build with shared pdo_mysql module
Hi, On Sat, 2013-02-16 at 19:46 +0100, Pierre Schmitz wrote: Hi, our default PHP package includes pdo_mysql as a shared module. Creating a debug build with the same configuration seems to be impossible due to bug #60840. This bug was closed as Not a bug but it is not clear how this should be solved. Why does it only break if --enable-debug is passed and works fine without? Am I missing something obvious here? This was indeed an oversight. I've reopened the bug and attached a primitive (not really tested) patch to it. For the final solution I have to discuss with Andrey, who is on vacation. Should be done well in time for PHP 5.3.23 and 5.4.13 as well as 5.5.0. johannes -- Johannes Schlüter, ORACLE, MySQL Engineering -- 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
On Tue, Feb 19, 2013 at 4:01 PM, Zeev Suraski z...@zend.com wrote: Are we really trying to look under ground now for ways to change the language syntax? Unless there's a strong case to adding/removing/changing syntax, that goes well beyond 'because we can' or 'it shortens the code' it shouldn't even be brought up for discussion. I am something of a language guru and to me syntax is *extremely* important. Am I of the opinion that removing the function keyword from the class definition will help? Yes, I am. Do I think it's some incredible advancement? No, I don't. 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. I do not grep code for method definitions: I know exactly where they are and so will my IDE if I happen to not be using vim. And for those who like to grep for method definitions they can keep the keyword present. -- 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
On 02/19/2013 03:45 PM, Levi Morrison wrote: 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. I do not grep code for method definitions: I know exactly where they are and so will my IDE if I happen to not be using vim. And for those who like to grep for method definitions they can keep the keyword present. Except when I come along and try to grok your code. I rarely search my own code. From the very beginning of PHP we have always favoured readability over fewer keystrokes. -Rasmus -- 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
On Tue, 19 Feb 2013 03:07:37 +0100, Stas Malyshev smalys...@sugarcrm.com
wrote:
If no one objects, I'll merge this into 5.5 and master:
https://github.com/cataphract/php-src/compare/dval_to_lval
Maybe add UNEXPECTED around the if condition? Since it's marked as
zend_always_inline I imagine it's supposed to be performance-sensitive...
I can add that.
Also, skip comments in tests seem to be wrong:
+if (PHP_INT_SIZE != 4)
6
+ die(skip for machines with 32-bit longs);
But actually it skips for longs NOT being 32-bit. Same with other test.
run-tests.php strips off the skip and shows only for machines with
32-bit. The skip is necessary for the test to be skipped.
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}
--
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
I am something of a language guru and to me syntax is *extremely* important. Am I of the opinion that removing the function keyword from the class definition will help? Yes, I am. I'm missing the help. It saves 9 characters and creates a disjunction between global function syntax and function-as-method syntax? Sorry, I can't see this as anything better than neutral. And for those who like to grep for method definitions they can keep the keyword present. ... in their own code, not in all the code they are forced to maintain (whether that be newbie sloppy code or super-cool library code). -- 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
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. I do not grep code for method definitions: I know exactly where they are and so will my IDE if I happen to not be using vim. And for those who like to grep for method definitions they can keep the keyword present. Except when I come along and try to grok your code. I rarely search my own code. Protip: use an IDE. No, I'm serious. I work from the command-line a lot. I grep, awk and sed a lot of things on a weekly (sometimes daily) basis. However, it does not replace a good IDE. Ever done a replace from the command line only to find out you messed up some binary files and/or git/svn information? Happens all the time when I don't use an IDE; good IDE's don't make that mistake. Let's stop pretending that the vast majority of PHP users actually grep source code looking for `function foo`. They don't. *They don't even know how to use grep.* However, every PHP developer has to write `function` and more importantly they have to read `function` over and over again. --- Does that mean that I think `function` ABSOLUTELY SHOULD BE made optional? No. I don't. Am I tired of everyone complaining about this particular issue and pointing to the fact that some external tool won't work if you remove the otherwise unnecessary keyword? Yes, I am. Take a step back and look at your argument guys: you may have strong personal feelings about it, but it's a pretty thin argument. -- 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
Protip: use an IDE. Linux is my IDE. -- Herman Radtke @hermanradtke | http://hermanradtke.com -- 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
Let's stop pretending that the vast majority of PHP users actually grep source code looking for `function foo`. They don't. *They don't even know how to use grep.* I don't grep as in `grep`, but as in regex search that is part of my IDE but is not also tokenizing/whateverizing/PHP-aware. My IDE lets me search for the declaration of a method by right-clicking class-method(), but it's only able to do that because it knows how to find the class definition and look there (and it doesn't use an autoloader). If I want to do a bulk search, it switches to regex, which doesn't share that intelligence. But I haven't upgraded to the v8 of this thing, only v7, so who knows... I find it indispensable and I'm not going to switch to another one because it isn't smart enough to do a PHP-aware bulk search. -- 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
On Tue, 2013-02-19 at 17:08 -0700, Levi Morrison wrote: Let's stop pretending that the vast majority of PHP users actually grep source code looking for `function foo`. That was never said, but there's a big number of people who has to deal with code produced by others and doing tasks where it is not always appropriate to startup and IDE and create a project and index it and grep is not always a simple grep but some more complex operation involving a search. And as you are happy with your idea you can certainly create shortcuts so you can type puf or such instead of public function and maybe even to hide the function word. They don't. *They don't even know how to use grep.* However, every PHP developer has to write `function` and more importantly they have to read `function` over and over again. The ones who don't know about 'grep' are happy about the extra clue. Am I tired of everyone complaining about this particular issue and pointing to the fact that some external tool won't work if you remove the otherwise unnecessary keyword? Yes, I am. Take a step back and look at your argument guys: you may have strong personal feelings about it, but it's a pretty thin argument. The argument for removing (or rather: the argument for adding yet another alternate syntax) is even weaker. Code is more often read than written. Now let's focus on work. johannes (who will now ignore this thread - we're turning in circles) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.22RC1 and 5.4.12RC1 Released for Testing!
Stas Malyshev in php.internals (Tue, 19 Feb 2013 15:35:54 -0800): Johannes Schlüter in php.internals (Thu, 31 Jan 2013 16:00:17 +0100): If no critical issues is found in this RC, the final version will be released in two weeks. Just curious: what is keeping 5.3.22 and 5.4.12 from being released? Are there any issues? We had 5.4.12 RC2 last week, due to recent SOAP fixes we had to pull in, and will have 5.4.12 GA this week. OK. Johannes' reply made me think I mistook the final RC for the release, but you seem to indicate there was indeed a little delay. For Johannes: building 5.3.22 and 5.4.12 (both NTS, Windows) right now. I will report back if I run into something. Jan -- 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
On Feb 19, 2013, at 6:01 PM, Zeev Suraski z...@zend.com wrote: Are we really trying to look under ground now for ways to change the language syntax? Agree 100%. Not to mention, I plan on eventually convincing enough people to replace that keyword with a type hint ;) Unless there's a strong case to adding/removing/changing syntax, that goes well beyond 'because we can' or 'it shortens the code' it shouldn't even be brought up for discussion. Zeev On 19 בפבר 2013, at 19:44, Nikita Nefedov inefe...@gmail.com wrote: Hi! As someone mentioned in the thread about short syntax for closures, we could also drop requirement for `function` keyword when defining/declaring methods in classes, interfaces or traits. I have long noticed how redundant it is. The patch is pretty easy as it was with commas :) It is absolutely backwards compatible (you can use `function` or you can not use it). Here's the patch: https://gist.github.com/nikita2206/4988075 If people will welcome this proposal, I would need some karma for making RFC. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP causing high number of NFS getattr operations?
On 02/19/2013 03:08 PM, Terry Ellison wrote: I guess that I should bite the bullet and switch to 5.5. Yes. 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? Yes, but there are some SAPIs that are more common, so these should be prioritized if trade-offs are required. My particular desire is for embed SAPI support. We use this in our Tuxedo application server, but it is a relatively niche use case. In architectural terms I feel that having a universal cache option is important. It changes the mindset from something which is only used in niche performance use cases to a standard option. It also means that the cache can be stress tested by the entire php test suite. However, to do some of this you don't start with a patch, but with an RFC informed by evidence, and that's my real reason for doing this demonstrator. I'm looking forward to seeing your suggestions and patches. 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] [RFC] Allow trailing comma in function call argument lists
On Tue, Feb 19, 2013 at 7:06 AM, Sara Golemon poll...@php.net wrote: 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 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?
Re: [PHP-DEV] [RFC] Allow trailing comma in function call argument lists
On Tue, Feb 19, 2013 at 8:06 PM, Sara Golemon poll...@php.net wrote: Opening RFC to allow trailing comma in function call argument lists https://wiki.php.net/rfc/trailing-comma-function-args -1 on this. I really don't like this, it look very weird, and the gain is minor. thanks -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Question on hash api
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?
Thanks!
Project links:
php-xxhash: https://github.com/datibbaw/php-xxhash
XXHash: http://code.google.com/p/xxhash/
[PHP-DEV] PHP 6 : a new API ?
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 : a new API ?
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 While it's good to see people float ideas, what is needed is real commitment to write the code to implement them. Can you comment on what participation you envisage for yourself? At the moment your email sounds like a someone should do list (see point 4 of https://blogs.oracle.com/opal/entry/the_mysterious_php_rfc_process). If this isn't the case, I look forward to seeing some prototypes from you or from anyone else willing to contribute to your ideas. 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
