[PHP-DEV] Some Stats
Number of posts to internals since Jan.1,2012 (top 15): [kris.cr...@gmail.com]= 249 [smalys...@sugarcrm.com] = 193 [pierre@gmail.com]= 146 [yohg...@ohgaki.net] = 105 [t...@punkave.com] = 98 [tyr...@gmail.com]= 96 [ircmax...@gmail.com] = 75 [keis...@gmail.com] = 75 [c...@l-i-e.com] = 63 [johncrens...@priacta.com]= 63 [ras...@lerdorf.com] = 61 [larue...@php.net]= 61 [simonsimc...@googlemail.com] = 58 [glo...@nebm.ist.utl.pt] = 51 [les...@lsces.co.uk] = 51 Number of posts to the commit list since Jan.1,2012 (top 25): [s...@php.net] = 412 [d...@php.net] = 146 [larue...@php.net] = 117 [a...@php.net] = 75 [cataphr...@php.net] = 59 [ir...@php.net]= 52 [ras...@php.net] = 51 [paj...@php.net] = 47 [johan...@php.net] = 42 [s...@php.net] = 36 [m...@php.net] = 31 [der...@php.net] = 25 [dmi...@php.net] = 23 [il...@php.net]= 22 [christopher.jo...@oracle.com] = 19 [smalys...@sugarcrm.com] = 17 [ni...@php.net]= 17 [pierre@gmail.com] = 15 [nlop...@php.net] = 12 [yohg...@php.net] = 11 [ahar...@php.net] = 11 [bj...@php.net]= 10 [phi...@php.net] = 8 [sebast...@php.net]= 8 [pierr...@php.net] = 7 -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] EXC_BAD_ACCESS, Could not access memory zval array type
Hi:
you can core dump the backtrace, then exam the related hash table to
find out what's going wrong there.
and some maybe un-relevant issues:
1. plz put all var declarations at the begining of a block (C89)
2. do not use this keyword as variable name (it's C++ keyword)
thanks
On Tue, Apr 17, 2012 at 2:12 PM, Yader Hernandez
yader.hernan...@gmail.com wrote:
Hello,
I'm trying to create an ArrayList as an extension. I'm currently
implementing ArrayList::contains(mixed $element) but I'm running into a
blocking issue.
It's currently causing a segfault when you call contains. I've tried to
track down what I'm doing wrong, but I've had no luck with it.
When running gdb this is what I get:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0x0001005812ca in
_zend_is_inconsistent
/* {{{ proto public boolean ArrayList::contain(mixed $element[, boolean
strict])
Returns true if this list contains the specified element. */
ZEND_METHOD(arraymap_class, contains) {
zval *element;
zend_bool strict = 0; /* strict comparison or not */
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, z|b, element,
strict) == FAILURE) {
RETURN_FALSE;
}
zval *this = getThis();
arraylist_object *intern;
intern = (arraylist_object *) zend_object_store_get_object(this
TSRMLS_CC);
/* Don't use ht as a variable, it's already being used. All ZEND_METHOD
have ht defined. */
HashTable *hash_table = Z_ARRVAL_P(intern-elements);
HashPosition pos;
zval **current;
zval res; /* comparison result */
int (*is_equal_func)(zval *, zval *, zval * TSRMLS_DC) =
is_equal_function;
if (strict) {
is_equal_func = is_identical_function;
}
zend_hash_internal_pointer_reset_ex(hash_table, pos);
while (zend_hash_get_current_data_ex(hash_table, (void **)current, pos)
== SUCCESS) {
is_equal_func(res, element, *current TSRMLS_CC);
if (Z_LVAL(res)) {
RETURN_TRUE;
}
zend_hash_move_forward_ex(hash_table, pos);
}
RETURN_FALSE;
}
I can't seem to spot any errors with this implementation. The next thing I
thought that could be wrong is how I'm creating elements pointer, but that
seems correct too:
static zend_object_value create_arraylist_object(zend_class_entry *ce
TSRMLS_DC) /* {{{ */
{
zend_object_value retval;
arraylist_object *intern;
intern = emalloc(sizeof(arraylist_object));
intern-size = 0;
zend_object_std_init(intern-std, ce TSRMLS_CC);
ALLOC_INIT_ZVAL(intern-elements);
array_init(intern-elements);
intern-std.ce = ce;
object_properties_init(intern-std, ce);
retval.handle = zend_objects_store_put(intern, NULL,
destroy_arraylist_object, NULL TSRMLS_CC);
retval.handlers = arraylist_object_handlers;
return retval;
}
/* }}} */
I'm not getting any compilation errors or any type of warnings. Everything
seems to be glueing itself correctly.
I'm hoping someone can see what I'm doing wrong so that I can move forward
with this.
thanks!
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] voting without vcs accounts
Why would that be a separate thread? Isn't that what we're talking about? I.e. determining who gets voting access and who doesn't? I just ask for clarification on how the community representatives (which is defined in the accepted voting RFC) can get their karma. You are talking about changing the requirements for somebody to be able to participate in the voting, thus changing/extending the original RFC. It's the same topic, and the question of who *should* or should not be allowed to vote was already raised previously on this thread. That's what I was responding to. So, deep breath =) I think Stas was a little bit offtopic/red herring with the discussion on why do we need non-vcs people to be allowed to vote. But to use that as an excuse to hijack the thread to resurrect the why can't everybody vote discussion isn't really nice, and I even asked it especially to not to do, as that was the reason which halted my previous attempt to address this issue. Could we all please focus on the original topic? Thanks! -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] release process with git
On Mon, Apr 9, 2012 at 08:54, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! 5.4.1 will be the first release we're releasing using our new git setup. I would like to refine a process that we used to have for releases and make small tweaks hopefully to allow us more predictable release schedule and faster releases. What I am proposing is the following: 1. At the start of the cycle, PHP-5.4.X is branched off PHP-5.4. This is done on Monday/Tuesday (days can be tweaked backforth a bit, but I assume we'll usually release on Thursday and count back from that). (tiny hijacking). The whole point of releasing on Thursdays is so sysadmins have the chance to update their servers in the event of known security problems before the weekend. This point however becomes void when we release late Thursdays evening American time, and we could just as well release on Saturday nights as noone in Europe will be able to update their servers, and the Americans will probably not be updating theirs either when they notice the release Fridays after lunch. Even keeping in mind most sysadmins probably use distro packages, these packages won't be built by their maintainers late Fridays and therefore never rolled out to the public until after the weekend. If we however switch to Tuesdays we atleast give the sysadmins (and package builders) a fighting chance of not needing to decide between running possibly very unsecure environment over the weekend or risk breaking the production environment due to unforeseen mishaps. Could we swap the release day to Tuesday? Or atleast very very very very early morning Thursdays? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] release process with git
Op 17-4-2012 9:47, Hannes Magnusson schreef: On Mon, Apr 9, 2012 at 08:54, Stas Malyshevsmalys...@sugarcrm.com wrote: Hi! 5.4.1 will be the first release we're releasing using our new git setup. I would like to refine a process that we used to have for releases and make small tweaks hopefully to allow us more predictable release schedule and faster releases. What I am proposing is the following: 1. At the start of the cycle, PHP-5.4.X is branched off PHP-5.4. This is done on Monday/Tuesday (days can be tweaked backforth a bit, but I assume we'll usually release on Thursday and count back from that). (tiny hijacking). The whole point of releasing on Thursdays is so sysadmins have the chance to update their servers in the event of known security problems before the weekend. This point however becomes void when we release late Thursdays evening American time, and we could just as well release on Saturday nights as noone in Europe will be able to update their servers, and the Americans will probably not be updating theirs either when they notice the release Fridays after lunch. Even keeping in mind most sysadmins probably use distro packages, these packages won't be built by their maintainers late Fridays and therefore never rolled out to the public until after the weekend. If we however switch to Tuesdays we atleast give the sysadmins (and package builders) a fighting chance of not needing to decide between running possibly very unsecure environment over the weekend or risk breaking the production environment due to unforeseen mishaps. Could we swap the release day to Tuesday? Or atleast very very very very early morning Thursdays? -Hannes Sounds like facilitating wrong security protocols to me. In this 365/24/7 environment, sysadmins should be willing and able to patch, fix and secure systems at any time. Weekend should be no excuse. Bas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] release process with git
On 17.04.12 10:24, Bas van Beek wrote: Sounds like facilitating wrong security protocols to me. In this 365/24/7 environment, sysadmins should be willing and able to patch, fix and secure systems at any time. Weekend should be no excuse. There are a lot of (very serious) shops out there without a 24/7 ops schedule. Let's not hurt them without a solid reason. - Martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Release day, was: release process with git
Hi! The whole point of releasing on Thursdays is so sysadmins have the chance to update their servers in the event of known security problems before the weekend. This point however becomes void when we release late Thursdays evening American time, and we could just as well release on Saturday nights as noone in Europe will be able to update their servers, and the Americans will probably not be updating theirs either when they notice the release Fridays after lunch. I tag and package Wednesday evening US Pacific time. I can change the Wednesday part, but not the evening US Pacific part, at least not until I move to a different timezone. If current schedule is not satisfactory, I have nothing against moving it to Tuesday. Pretty much any day is OK with me, so let's see what people think. -- 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] Re: New Feature: Fully qualified class name resolution as scalar with class keyword
May I suggest using foo::__CLASS__ instead of foo::class ? It's longer, but closer to what already exists for this semantic (class name as string), don't you think ? So, at current, is this small enough for just a pull request, or does this deserve its own RFC? Personnaly, I would say that an RFC would be good for historical reference and documentation. Nicolas
Re: [PHP-DEV] Some Stats
Hi! Number of posts to the commit list since Jan.1,2012 (top 25): [s...@php.net] = 412 This figure is unfortunately over-inflated by the unfortunate tags incident :) So subtract 300 or so from that :) -- 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] New Feature: Fully qualified class name resolution as scalar with class keyword
@Nicolas: wouldn't __CLASS__ introduce a bit of confusion with the existing
constant?
Marco Pivetta
http://twitter.com/Ocramius
http://marco-pivetta.com
On 17 April 2012 11:17, Nikita Popov nikita@googlemail.com wrote:
On Sat, Apr 14, 2012 at 9:50 PM, Ralph Schindler
ra...@ralphschindler.com wrote:
Hi all,
There are many different use cases were in code we expect classes names
as
arguments to functions as fully qualified names. We do this in ZF a lot
with our Service Location and DI components, but also with our code
reflection API, etc. A more interesting use case I would like to call
out
is with PHPUnit, for example in a test, you might find this:
$mock = $this-getMock('A\Namespaced\ClassName');
This becomes cumbersome when you are dealing with lots of strings about
lots
of class names. This is also an area where, currently, namespace
declaration and use statements offer no real support.
The patch located here:
https://github.com/ralphschindler/php-src/commit/02210d51851a96d723fbedcfc64cde9f9ae2b22a
... implements the ability for a developer to leverage the file's
namespace
declaration and use statements to be able to produce a scalar (string) of
the class name that can be then used, for example, as an argument to a
function elsewhere.
This overloads the class keyword, and by virtue of the existing usage
of
class this feature is completely backwards compatible. All existing
tests
pass. For example, the above PHPUnit snipped would become:
use A\Namespaced\ClassName;
$mock = $this-getMock(ClassName::class);
Another example with reflection:
use SomeOther\FullyNamespaced\ClassElsewhere as CE;
$r = new ReflectionClass(CE::class);
More examples from the test file:
namespace Foo\Bar {
class Baz {}
var_dump(Moo::CLASS); // Foo\Bar\Moo
}
namespace {
use Bee\Bop as Moo,
Foo\Bar\Baz;
var_dump(Baz::class); // Foo\Bar\Baz
var_dump(Boo::class); // Boo
var_dump(Moo::CLASS); // Bee\Bop
var_dump(\Moo::Class); // Moo
$class = Baz::class; // assign class as scalar to var
$x = new $class;
var_dump($x); object(Foo\Bar\Baz)#1 (0) {}
}
What do you guys think?
Hey Ralph!
I like the proposal :)
A quick note on the patch: As the class name is compile-time
resolvable it should in my eyes also be available as a
`static_scalar`, so that it can be used in initialization lists:
public function doFoo($withClass = ABC::class) {
new $withClass; // or whatever
}
To be available as both a `static_scalar` and a general `scalar` one
should put the rule in the `common_scalar` section.
What do you think?
Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Merge request to 5.4. pg_escape_*()
Hi Stats, Would you merge this to 5.4? http://git.php.net/?p=php-src.git;a=commit;h=77d11b4959066dcbd47fce2ca65c41f5361ad40b This makes other bug fixes easier and keep master and 5.4 in sync. I don't mean to 5.4.1, but it should not harm any existing features. If you would like, I'll cherry pick it to 5.4 branch to merge. Thank you. -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: New Feature: Fully qualified class name resolution as scalar with class keyword
May I suggest using foo::__CLASS__ instead of foo::class ? It's longer, but closer to what already exists for this semantic (class name as string), don't you think ? As Marco suggested, I think using __CLASS__ would be confusing to some. __CLASS__ generally means, where you see this, replace it with the class you are in right now. I generally don't like to draw comparisons too closely to Java and .NET, but Java has this, they call it a class literal, which works the same way as described in my new feature: http://stackoverflow.com/questions/2160788/what-is-a-class-literal-in-java In .net, if a type is a SystemType.Type object (which I think are all types), you can simply call a function on it to get the name: http://msdn.microsoft.com/en-us/library/9f49ew66.aspx In addition, I am unsure if there would be any BC issues with your proposed syntax. I do know with mine (::class) does not pose any BC issues since the class keyword was limited to declaring a class only. At least, the tests prove this, and I can't find any other usages of T_CLASS in the parser. Personnaly, I would say that an RFC would be good for historical reference and documentation. I think you're right, I'll do this today. -ralph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] is_numeric_string an hexadecimal numbers (123 == 0x7B)
Hi internals!
The internal is_numeric_string [1] function is used to check whether a
string contains a number (and to extract that number).
Currently is_numeric_string also accepts hexadecimal strings [2]
(apart from the normal decimal integers and doubles).
This can cause some quite odd behavior at times. E.g. string
comparisons also use is_numeric_string, resulting in the behavior:
var_dump('123' == '0x7b'); // true
In all other parts of the engine hexadecimal strings are not recognized [3]:
var_dump((int) '0x7b'); // int(0)
This also causes minor problems in other parts of the engine where
is_numeric_string is used. E.g.
$string = 'abc';
var_dump($string['0xabc']); // string(a)
// 0xabc is first accepted as a number by is_numeric_string, but then
cast to 0 by convert_to_long
But:
$string = 'abc';
var_dump($string['0abc']);
// outputs (as expected):
Notice: A non well formed numeric value encountered in /code/8KXrYZ on line 9
NULL
In my eyes accepting hex strings in is_numeric_string leads to a quite
big WTF effect and causes problems and as such should be dropped.
I don't think this has much BC impact, so it should be possible to change it.
Nikita
[1]: http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_operators.h#is_numeric_string
[2]: http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_operators.h#131
[3]:
http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is_numeric_string an hexadecimal numbers (123 == 0x7B)
hi! On Tue, Apr 17, 2012 at 1:20 PM, Nikita Popov nikita@googlemail.com wrote: [3]: http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion From the manual: If the string starts with valid numeric data, this will be the value used. Otherwise, the value will be 0 (zero). Valid numeric data is an optional sign, followed by one or more digits (optionally containing a decimal point), followed by an optional exponent. The exponent is an 'e' or 'E' followed by one or more digits. So no problem from to change this confusing behavior. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is_numeric_string an hexadecimal numbers (123 == 0x7B)
2012/4/17 Nikita Popov nikita@googlemail.com
var_dump('123' == '0x7b'); // true
In all other parts of the engine hexadecimal strings are not recognized
[3]:
var_dump((int) '0x7b'); // int(0)
Hi, Nikita
I personally would rather change the type-conversion for strings to integer ...
At least if you force it to do a type-cast (in other words: forcing to
get any valuable integer of that string) ...
Bye
Simon
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is_numeric_string an hexadecimal numbers (123 == 0x7B)
On Tue, 17 Apr 2012 13:20:33 +0200, Nikita Popov nikita@googlemail.com wrote: The internal is_numeric_string [1] function is used to check whether a string contains a number (and to extract that number). Currently is_numeric_string also accepts hexadecimal strings [2] (apart from the normal decimal integers and doubles). [...] In my eyes accepting hex strings in is_numeric_string leads to a quite big WTF effect and causes problems and as such should be dropped. I don't think this has much BC impact, so it should be possible to change it. I think definitely has a larger BC impact than you're portraying, I can see some people making comparisons against '0xA' instead of 0xA. Besides, this is part of the Zend API. It's already used in many extensions (though possibly some of these should be using a stricter function) and changing its behavior is a stable branch is not wise: http://lxr.php.net/opengrok/search?q=project=PHP_TRUNKdefs=refs=is_numeric_string But in case, if there are no graver BC impacts, +1 for master. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Some Stats
On 2012-04-17, Rasmus Lerdorf ras...@lerdorf.com wrote: Number of posts to the commit list since Jan.1,2012 (top 25): Number of commits to php-src (excluding merges) since Jan.1,2012 (top 15): 126 Xinchen Hui 83 Rasmus Lerdorf 79 Gustavo Andre dos Santos Lopes 73 Pierre Joye 62 Anatoliy Belsky 53 Stanislav Malyshev 46 Dmitry Stogov 45 Christopher Jones 36 Johannes Schlueter 32 Michael Wallner 29 Ilia Alshanetsky 28 Nikita Popov 17 Nuno Lopes 15 Derick Rethans 14 David Soria Parra -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is_numeric_string an hexadecimal numbers (123 == 0x7B)
On Tue, 17 Apr 2012 13:35:48 +0200, Simon Schick
simonsimc...@googlemail.com wrote:
2012/4/17 Nikita Popov nikita@googlemail.com
var_dump('123' == '0x7b'); // true
In all other parts of the engine hexadecimal strings are not recognized
[3]:
var_dump((int) '0x7b'); // int(0)
I personally would rather change the type-conversion for strings to
integer ...
At least if you force it to do a type-cast (in other words: forcing to
get any valuable integer of that string) ...
I think that would be an error. As was mentioned a few months ago when 0b
was introduced, no other number format has this behavior. You can't do
123 == 0b10 or 123 == 0876. Extending this hexadecimal oddity
instead of eliminating it is inconsistent with the treatment given to
those other formats.
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Release day, was: release process with git
On 2012-04-17, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! The whole point of releasing on Thursdays is so sysadmins have the chance to update their servers in the event of known security problems before the weekend. This point however becomes void when we release late Thursdays evening American time, and we could just as well release on Saturday nights as noone in Europe will be able to update their servers, and the Americans will probably not be updating theirs either when they notice the release Fridays after lunch. I tag and package Wednesday evening US Pacific time. I can change the Wednesday part, but not the evening US Pacific part, at least not until I move to a different timezone. If current schedule is not satisfactory, I have nothing against moving it to Tuesday. Pretty much any day is OK with me, so let's see what people think. Yes at the moment we have the problem that: Stas tags Wednesday evening US Pacific time Stefan builds Thursday during the day US Pacific time David announces after all this is done which is Thursday evening EU time sometimes it becomes so late that I can only do it friday morning. So if we want to release Thursday, then windows builds need to be done one Wednesday. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is_numeric_string an hexadecimal numbers (123 == 0x7B)
2012/4/17 Gustavo Lopes glo...@nebm.ist.utl.pt: I think that would be an error. As was mentioned a few months ago when 0b was introduced, no other number format has this behavior. You can't do 123 == 0b10 or 123 == 0876. Extending this hexadecimal oddity instead of eliminating it is inconsistent with the treatment given to those other formats. -- Gustavo Lopes Hi, Gustavo That's something I didn't know of ... if we're doing that, it should, of course, be also be done for the dual system. The only thing I wonder about is the code examples you're giving ... I would expect this to work if we start to change something here: var_dump((int) '0x7b'); // int(123) var_dump((int) '0b011'); // int(123) var_dump((int) '0123'); // int(123) The last example was not mentioned here before but as you set in an example, I did it here as well ... Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is_numeric_string an hexadecimal numbers (123 == 0x7B)
On 04/17/2012 01:20 PM, Nikita Popov wrote: I don't think this has much BC impact, so it should be possible to change it. Same here, i never even knew that this worked in a string context until recently. Autocast/comparison rules are already complicated enough as they are documented now, and i failed to find anything in the manual that would actually say that hex in a string context is support to work at all ... I can't really judge the BC implications though, so the best way would be to start throwing E_DEPRECATED warnings for now ... or maybe go the X11 way of deliberately break obscure feature and see how many complaints we get ;) -- hartmut -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is_numeric_string an hexadecimal numbers (123 == 0x7B)
On Apr 17, 2012, at 5:39, Hartmut Holzgraefe hartmut.holzgra...@gmail.commailto:hartmut.holzgra...@gmail.com wrote: Same here, i never even knew that this worked in a string context until recently. Autocast/comparison rules are already complicated enough as they are documented now, and i failed to find anything in the manual that would actually say that hex in a string context is support to work at all ... Would this end up changing the behavior of the user land is_numeric() function? The behavior actually is documented under that function: Finds whether the given variable is numeric. Numeric strings consist of [...]. Hexadecimal notation (0xFF) is allowed too but only without sign, decimal and exponential part. If so, although this does technically break BC in that case, I for one will not miss it. The only effect this will have on our code is to make validation of numeric input much easier and less error-prone. -- Bob Williams Sent from my iPad Notice: This communication, including attachments, may contain information that is confidential. It constitutes non-public information intended to be conveyed only to the designated recipient(s). If the reader or recipient of this communication is not the intended recipient, an employee or agent of the intended recipient who is responsible for delivering it to the intended recipient, or if you believe that you have received this communication in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any).
Re: [PHP-DEV] New Feature: Fully qualified class name resolution as scalar with class keyword
Hi Nikita,
A quick note on the patch: As the class name is compile-time
resolvable it should in my eyes also be available as a
`static_scalar`, so that it can be used in initialization lists:
public function doFoo($withClass = ABC::class) {
new $withClass; // or whatever
}
To be available as both a `static_scalar` and a general `scalar` one
should put the rule in the `common_scalar` section.
What do you think?
I've added this to the patch and Zend/tests:
*
https://github.com/ralphschindler/php-src/compare/master...feature/class-name-scalar
I've also added an RFC page, any thoughts on improving the RFC?
* https://wiki.php.net/rfc/class_name_scalars
-ralph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is_numeric_string an hexadecimal numbers (123 == 0x7B)
On Tue, Apr 17, 2012 at 1:44 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: On Tue, 17 Apr 2012 13:20:33 +0200, Nikita Popov nikita@googlemail.com wrote: The internal is_numeric_string [1] function is used to check whether a string contains a number (and to extract that number). Currently is_numeric_string also accepts hexadecimal strings [2] (apart from the normal decimal integers and doubles). [...] In my eyes accepting hex strings in is_numeric_string leads to a quite big WTF effect and causes problems and as such should be dropped. I don't think this has much BC impact, so it should be possible to change it. I think definitely has a larger BC impact than you're portraying, I can see some people making comparisons against '0xA' instead of 0xA. Yes, this definitely does have BC impact, but I don't think it is particularly large. The affected areas mainly would be: * String comparisons using == * Strings passed to internal functions which accept the value through an l zend_parse_parameters (functions doing manual type handling via the Z_TYPE and convert_to_long do not accept hex already now) * The userland function is_numeric The first two would mainly be a problem if somebody - as you already mention - has written '0xA' == $foo style comparisons or did stuff like round($number, '0xA'). Both cases - in my eyes - aren't particularly probably as anyone who knows what a hex number is probably also knows the difference between a string literal and a number literal. The last one is more problematic. It is explicitly documented as accepting hexadecimal numbers. In my eyes it too should not accept them, but I could imagine that people rely on this. Besides, this is part of the Zend API. It's already used in many extensions (though possibly some of these should be using a stricter function) and changing its behavior is a stable branch is not wise: http://lxr.php.net/opengrok/search?q=project=PHP_TRUNKdefs=refs=is_numeric_string I've already looked at some of these and in most (all?) cases the intended behavior seems to be to not allow hex (passing hex in those situations actually creates some kind of broken behavior). Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New Feature: Fully qualified class name resolution as scalar with class keyword
On 2012-04-17, Ralph Schindler ra...@ralphschindler.com wrote:
Hi Nikita,
A quick note on the patch: As the class name is compile-time
resolvable it should in my eyes also be available as a
`static_scalar`, so that it can be used in initialization lists:
public function doFoo($withClass = ABC::class) {
new $withClass; // or whatever
}
To be available as both a `static_scalar` and a general `scalar` one
should put the rule in the `common_scalar` section.
What do you think?
I've added this to the patch and Zend/tests:
*
https://github.com/ralphschindler/php-src/compare/master...feature/class-name-scalar
I've also added an RFC page, any thoughts on improving the RFC?
* https://wiki.php.net/rfc/class_name_scalars
In the examples, you mix case:
Boo::class
Moo::Class
\Moo::CLASS
Make sure you note that this is intentional, and that the keyword is
case insensitive -- i.e., changing the case does not alter the use cases
presented.
Also, I'd note why you're selecting class as the keyword (basically,
because it _is_ a keyword, and thus will never conflict with any class
constants or method names).
Otherwise, very straight-forward.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Some Stats
Great work everyone :) On 17 April 2012 12:44, David Soria Parra d...@php.net wrote: On 2012-04-17, Rasmus Lerdorf ras...@lerdorf.com wrote: Number of posts to the commit list since Jan.1,2012 (top 25): Number of commits to php-src (excluding merges) since Jan.1,2012 (top 15): 126 Xinchen Hui 83 Rasmus Lerdorf 79 Gustavo Andre dos Santos Lopes 73 Pierre Joye 62 Anatoliy Belsky 53 Stanislav Malyshev 46 Dmitry Stogov 45 Christopher Jones 36 Johannes Schlueter 32 Michael Wallner 29 Ilia Alshanetsky 28 Nikita Popov 17 Nuno Lopes 15 Derick Rethans 14 David Soria Parra -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- David Coallier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] EXC_BAD_ACCESS, Could not access memory zval array type
On Tue, Apr 17, 2012 at 12:06 AM, Laruence larue...@php.net wrote:
Hi:
you can core dump the backtrace, then exam the related hash table to
find out what's going wrong there.
So the problem doesn't seem to be with contains() at all. The problem is
actually coming from another method I implemented called
ArrayList::append(mixed $element). I figured it out by calling contains
first and I noticed it didn't cause a segfault. appends() seems rather
trivial but I guess I was wrong:
/* {{{ proto public boolean ArrayList::append(mixed $element)
Add an element to the end of the list */
ZEND_METHOD(arraymap_class, append) {
zval *object = getThis();
zval *element;
arraylist_object *intern;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, z, element) ==
FAILURE) {
RETURN_FALSE;
}
intern = (arraylist_object *) zend_object_store_get_object(object
TSRMLS_CC);
if (add_next_index_zval(intern-elements, element) == SUCCESS) {
Z_ADDREF_P(element); /* increases ref count */
intern-size++;
RETURN_TRUE;
}
RETURN_FALSE;
}
This method returns true, as expected.
and some maybe un-relevant issues:
1. plz put all var declarations at the begining of a block (C89)
2. do not use this keyword as variable name (it's C++ keyword)
fixed.
thanks
On Tue, Apr 17, 2012 at 2:12 PM, Yader Hernandez
yader.hernan...@gmail.com wrote:
Hello,
I'm trying to create an ArrayList as an extension. I'm currently
implementing ArrayList::contains(mixed $element) but I'm running into a
blocking issue.
It's currently causing a segfault when you call contains. I've tried to
track down what I'm doing wrong, but I've had no luck with it.
When running gdb this is what I get:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0x0001005812ca in
_zend_is_inconsistent
/* {{{ proto public boolean ArrayList::contain(mixed $element[, boolean
strict])
Returns true if this list contains the specified element. */
ZEND_METHOD(arraymap_class, contains) {
zval *element;
zend_bool strict = 0; /* strict comparison or not */
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, z|b, element,
strict) == FAILURE) {
RETURN_FALSE;
}
zval *this = getThis();
arraylist_object *intern;
intern = (arraylist_object *) zend_object_store_get_object(this
TSRMLS_CC);
/* Don't use ht as a variable, it's already being used. All
ZEND_METHOD
have ht defined. */
HashTable *hash_table = Z_ARRVAL_P(intern-elements);
HashPosition pos;
zval **current;
zval res; /* comparison result */
int (*is_equal_func)(zval *, zval *, zval * TSRMLS_DC) =
is_equal_function;
if (strict) {
is_equal_func = is_identical_function;
}
zend_hash_internal_pointer_reset_ex(hash_table, pos);
while (zend_hash_get_current_data_ex(hash_table, (void **)current,
pos)
== SUCCESS) {
is_equal_func(res, element, *current TSRMLS_CC);
if (Z_LVAL(res)) {
RETURN_TRUE;
}
zend_hash_move_forward_ex(hash_table, pos);
}
RETURN_FALSE;
}
I can't seem to spot any errors with this implementation. The next thing
I
thought that could be wrong is how I'm creating elements pointer, but
that
seems correct too:
static zend_object_value create_arraylist_object(zend_class_entry *ce
TSRMLS_DC) /* {{{ */
{
zend_object_value retval;
arraylist_object *intern;
intern = emalloc(sizeof(arraylist_object));
intern-size = 0;
zend_object_std_init(intern-std, ce TSRMLS_CC);
ALLOC_INIT_ZVAL(intern-elements);
array_init(intern-elements);
intern-std.ce = ce;
object_properties_init(intern-std, ce);
retval.handle = zend_objects_store_put(intern, NULL,
destroy_arraylist_object, NULL TSRMLS_CC);
retval.handlers = arraylist_object_handlers;
return retval;
}
/* }}} */
I'm not getting any compilation errors or any type of warnings.
Everything
seems to be glueing itself correctly.
I'm hoping someone can see what I'm doing wrong so that I can move
forward
with this.
thanks!
--
Laruence Xinchen Hui
http://www.laruence.com/
Re: [PHP-DEV] Re: New Feature: Fully qualified class name resolution as scalar with class keyword
Hi! May I suggest using foo::__CLASS__ instead of foo::class ? It's longer, but closer to what already exists for this semantic (class name as string), don't you think ? I like this. __CLASS__ is already being used as class name, and little chance of colliding with some code since you're not supposed to be using __ prefix in your names. -- 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] Re: New Feature: Fully qualified class name resolution as scalar with class keyword
On Tue, Apr 17, 2012 at 6:58 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! May I suggest using foo::__CLASS__ instead of foo::class ? It's longer, but closer to what already exists for this semantic (class name as string), don't you think ? I like this. __CLASS__ is already being used as class name, and little chance of colliding with some code since you're not supposed to be using __ prefix in your names. From the collisions point of view `class` and `__CLASS__` are equally safe. They both are lexer keywords, so it's not possible to declare constants with them as name. Imho ClassName::class reads nicer and also looks similar to the similar ClassName.class syntax in Java. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: New Feature: Fully qualified class name resolution as scalar with class keyword
On 2012-04-17, Stas Malyshev smalys...@sugarcrm.com wrote: May I suggest using foo::__CLASS__ instead of foo::class ? It's longer, but closer to what already exists for this semantic (class name as string), don't you think ? I like this. __CLASS__ is already being used as class name, and little chance of colliding with some code since you're not supposed to be using __ prefix in your names. class won't collide anyways, as it's already a keyword, and you can't use it in your constant or function names. __CLASS__ has bad connotations for me, as it resolves to the declaring class normally, not the class invoked. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] '9223372036854775807' == '9223372036854775808'
On 04/13/2012 04:01 AM, Gustavo Lopes wrote: Currently, when two strings are compared, PHP tries to do a numerical comparison first. Therefore: var_dump(010 == 10); //true I'm replying to this old mail now, because of the current discussion about hex numbers. The phrase numerical comparison caught my eye because it seems in-precise, for example: var_dump(010 == 10); // false Don't forget octal. Chris -- christopher.jo...@oracle.com http://twitter.com/#!/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New Feature: Fully qualified class name resolution as scalar with class keyword
Hi Ralph, On 17/04/12 10:54, Ralph Schindler wrote: I've also added an RFC page, any thoughts on improving the RFC? * https://wiki.php.net/rfc/class_name_scalars Are you sure that the example section is correct? Because your first var_dump is Moo::CLASS but the symbol Moo does not exist yet, only the class Foo\Bar\Baz was declared at this point. Btw, interesting patch and nice implementation. I approved. Best regards. -- Ivan Enderlin Developer of Hoa http://hoa.42/ or http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://lifc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Some Stats
On Mon, Apr 16, 2012 at 11:57 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: Number of posts to internals since Jan.1,2012 (top 15): [kris.cr...@gmail.com]= 249 Wooot! What's my prize? ;P Now I just need to start getting some commits in there --Kris
Re: [PHP-DEV] is_numeric_string an hexadecimal numbers (123 == 0x7B)
On 4/17/12 08:17, Nikita Popov nikita@googlemail.com wrote: The last one is more problematic. It is explicitly documented as accepting hexadecimal numbers. In my eyes it too should not accept them, but I could imagine that people rely on this. This always struck me as mistaken design. Why accept hex or decimal, but not the other bases that PHP knows about? I can see a small number of scenarios where having it accept hex input is definitely useful, but I suspect that the vast majority of cases out there where it's used is in validation routines expecting straightforward, base-10 numbers. And I know that, of all such cases I've seen (and I've seen quite a few, since one of our interview test questions implicitly covers it), most programmers are blissfully ignorant of the hex support and unwittingly allow bad user data to slip into their applications to become trusted data. Not good. As I mentioned in my last message, I wouldn't be bothered if this behavior were simply removed. I think it would affect a small number of people knowingly relying on the feature, while it would fix probably many thousands of bugs out there lurking in less-aware programmers' code. Even better, though, might be to add a flag parameter that would give the programmer explicit control over its behavior, including which bases to allow (and including the bases currently MIA). -Bob -- Robert E. Williams, Jr. Associate Vice President of Software Development Newtek Businesss Services, Inc. -- The Small Business Authority https://www.newtekreferrals.com/rewjr http://www.thesba.com/ Notice: This communication, including attachments, may contain information that is confidential. It constitutes non-public information intended to be conveyed only to the designated recipient(s). If the reader or recipient of this communication is not the intended recipient, an employee or agent of the intended recipient who is responsible for delivering it to the intended recipient, or if you believe that you have received this communication in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: New Feature: Fully qualified class name resolution as scalar with class keyword
From the collisions point of view `class` and `__CLASS__` are equally safe. Imho ClassName::class reads nicer and also looks similar to the similar ClassName.class syntax in Java. The current __CLASS__ could then be written self::class. Looks more namespace/object oriented, where __CLASS__ feels procedural? How would static::class behave ? is it handled by the current patch? Maybe the test case could be extended to reflect this, and also for self::class? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re voting
Sharon, On Mon, Apr 16, 2012 at 8:42 PM, sle...@pipeline.com wrote: Stas: Just b/c there are rarely any women at all that participate on this list, could we at list maintain a facade of gender neutrality? I seriously can't believe that you used the word him. What about her? Yeah, her as in myself and every other woman who codes with PHP whether to earn her living or to have a pleasant past-time? I am sure that there are plenty of PHP women just like me who might really appreciate having the opportunity to vote on changes that might effect the way we work. Currently, it's as clear as mud to me as to what I need to do to be able to have some kind of voting impact. The protocol or process needs to be clearly articulated in very clear language so that all concerned PHP men and women can be informed. Sharon Lee Levy, ZCE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php You raise a valid concern, but I think you were unfairly harsh toward Stas. The gender-neutral he is an accepted standard in English. Maybe it shouldn't be, and I would applaud efforts to change that, but berating someone who uses it isn't the best way to get your message across. Personally, I'm a fan of the singular they. Some people prefer to use ze instead, but I think it just sounds stupid. Why? Well, just say the following sentence in a funny accent of your choosing and you'll understand: What is ze doing?! ;) --Kris
Re: [PHP-DEV] Some Stats
Wooot! What's my prize? ;P Shame.
[PHP-DEV] Make require*/include* behave like a function for returning values, and more
Hi everyone,
I have noticed that it is not possible to do something like that:
// foo.php
?php
return ['foo' = 'bar'];
// bar.php
?php
var_dump((require 'foo.php')['foo']);
Array access on a require does not work: we have a parse error. Is it
just a parser issue? Because a file can return an array without any problem.
For now, one possible solution is to write a function that requires a
file and returns the result, such as:
// bar.php
?php
function my_require ( $file ) { return require $file; }
var_dump(my_require('foo'.php')['foo']);
It would be nice if require (and require_once, include and include_once)
instructions would behave like functions when returning values.
Thoughts?
In the same way, it is not possible for now to do something like that:
function f ( ) {
return function ( $msg ) {
return $msg . '!';
}
}
f()('foo');
We have a parse error again. Is it a parser issue?
It could be interesting to have this feature in PHP because file can
return closure! It would be great to extend this syntax on require and
others instructions, such as:
?php
(require 'baz.php')('a message'); // chaining methods calls
Finally, what about exporting only some symbols? It could be a middle
step between declaring classes as private, protected and public and all
public. We can imagine somethings like:
// foo.php
?php
class IAmPrivate { }
class IAmPublic { }
export [IAmPublic]; // or export [IAmPublic::class], please see current
discussion about Classname::class proposition.
Here, the “export” keyword will act like “return” but it will specify
that all declaring symbols inside the file will not be exposed outside
the file except specified ones. It could add a “module aspect” to PHP,
and it does not break the compatibility.
Thoughts?
Best regards.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/
PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://lifc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Some Stats
On Tue, Apr 17, 2012 at 12:05 PM, Sean Coates s...@seancoates.com wrote: Wooot! What's my prize? ;P Shame. Hmm can I just opt for the cash payout instead? --Kris
Re: [PHP-DEV] New Feature: Fully qualified class name resolution as scalar with class keyword
var_dump is Moo::CLASS but the symbol Moo does not exist yet, only the class Foo\Bar\Baz was declared at this point. It could exist. It could be a class name handled by an autoloader somewhere else. This method of class name resolving operates in the spirit of how our namespace implementation works. Namespaces don't actually import things into the files symbol table, it makes aliases for them, as such the namespace implementation alone never triggers an autoload simply b/c you were talking about a class somewhere. The ::class resolver essentially does the same thing, for any given name you are talking about, it will resolve that name against the current namespace resolution rules. Btw, interesting patch and nice implementation. I approved. Best regards. Thanks! -ralph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Make require*/include* behave like a function for returning values, and more
Hi everyone,
I have noticed that it is not possible to do something like that:
// foo.php
?php
return ['foo' = 'bar'];
// bar.php
?php
var_dump((require 'foo.php')['foo']);
Array access on a require does not work: we have a parse error. Is it
just a parser issue? Because a file can return an array without any problem.
For now, one possible solution is to write a function that requires a
file and returns the result, such as:
// bar.php
?php
function my_require ( $file ) { return require $file; }
var_dump(my_require('foo'.php')['foo']);
It would be nice if require (and require_once, include and include_once)
instructions would behave like functions when returning values.
Thoughts?
In the same way, it is not possible for now to do something like that:
function f ( ) {
return function ( $msg ) {
return $msg . '!';
}
}
f()('foo');
We have a parse error again. Is it a parser issue?
It could be interesting to have this feature in PHP because file can
return closure! It would be great to extend this syntax on require and
others instructions, such as:
?php
(require 'baz.php')('a message'); // chaining methods calls
Finally, what about exporting only some symbols? It could be a middle
step between declaring classes as private, protected and public and all
public. We can imagine somethings like:
// foo.php
?php
class IAmPrivate { }
class IAmPublic { }
export [IAmPublic]; // or export [IAmPublic::class], please see current
discussion about Classname::class proposition.
Here, the “export” keyword will act like “return” but it will specify
that all declaring symbols inside the file will not be exposed outside
the file except specified ones. It could add a “module aspect” to PHP,
and it does not break the compatibility.
Thoughts?
Best regards.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/
PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://lifc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make require*/include* behave like a function for returning values, and more
I don't see any fundamental benefit to having this in PHP.
It doesn't work around any current restrictions in the language.
It just looks like extra fluffy magic that we could do without.
- Paul.
On Tue, Apr 17, 2012 at 8:18 PM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:
Hi everyone,
I have noticed that it is not possible to do something like that:
// foo.php
?php
return ['foo' = 'bar'];
// bar.php
?php
var_dump((require 'foo.php')['foo']);
Array access on a require does not work: we have a parse error. Is it just
a parser issue? Because a file can return an array without any problem.
For now, one possible solution is to write a function that requires a file
and returns the result, such as:
// bar.php
?php
function my_require ( $file ) { return require $file; }
var_dump(my_require('foo'.php'**)['foo']);
It would be nice if require (and require_once, include and include_once)
instructions would behave like functions when returning values.
Thoughts?
In the same way, it is not possible for now to do something like that:
function f ( ) {
return function ( $msg ) {
return $msg . '!';
}
}
f()('foo');
We have a parse error again. Is it a parser issue?
It could be interesting to have this feature in PHP because file can
return closure! It would be great to extend this syntax on require and
others instructions, such as:
?php
(require 'baz.php')('a message'); // chaining methods calls
Finally, what about exporting only some symbols? It could be a middle step
between declaring classes as private, protected and public and all public.
We can imagine somethings like:
// foo.php
?php
class IAmPrivate { }
class IAmPublic { }
export [IAmPublic]; // or export [IAmPublic::class], please see current
discussion about Classname::class proposition.
Here, the “export” keyword will act like “return” but it will specify that
all declaring symbols inside the file will not be exposed outside the file
except specified ones. It could add a “module aspect” to PHP, and it does
not break the compatibility.
Thoughts?
Best regards.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/
PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://lifc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: New Feature: Fully qualified class name resolution as scalar with class keyword
How would static::class behave ? is it handled by the current patch?
Maybe the test case could be extended to reflect this, and also for
self::class?
Fantastic question. I am unsure how to handle this. Currently, it will
simply resolve those names against the rules (I am sure this is the
wrong behavior.) So,
namespace Foo\Bar { var_dump(self::class); }
Would now produce:
string(12) Foo\Bar\self
This is the same with 'self', 'static', and 'parent'. I guess the
question is, should that produce a compile error, or conditionally work
depending on if you are inside of a class declaration or not?
I will add this consideration to the RFC.
-ralph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make require*/include* behave like a function for returning values, and more
Hi Paul,
On 17/04/12 15:31, Paul Dragoonis wrote:
I don't see any fundamental benefit to having this in PHP.
Unexposed symbols can be interesting when instrumended code (for my
concerns) or simply for security and safety reasons. So, benefits exist.
It doesn't work around any current restrictions in the language.
What do you mean?
It just looks like extra fluffy magic that we could do without.
No extra magic stuffs, just new interesting features. Allowing (require
'file.php')['foo'] or (require 'file.php')('foo') is consistent with the
fact that a file can return an array or a function. And yes, it's kind
of syntax sugar from a certain point of view but it could improve PHP
experience without adding any magic stuff. It's just more consistent.
No?
Cheers.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/
PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://lifc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New Feature: Fully qualified class name resolution as scalar with class keyword
On Sat, Apr 14, 2012 at 12:50 PM, Ralph Schindler
ra...@ralphschindler.comwrote:
Hi all,
There are many different use cases were in code we expect classes names as
arguments to functions as fully qualified names. We do this in ZF a lot
with our Service Location and DI components, but also with our code
reflection API, etc. A more interesting use case I would like to call out
is with PHPUnit, for example in a test, you might find this:
$mock = $this-getMock('A\Namespaced\**ClassName');
[...]
This overloads the class keyword, and by virtue of the existing usage of
class this feature is completely backwards compatible. All existing
tests pass. For example, the above PHPUnit snipped would become:
Would it be easy to have a patch that simply allows use of the class name,
or is the ::class suffix necessary to resolve some ambiguity? Example
usage:
$mock = $this-getMock(A\Namespaced\**ClassName);
# or
use A\Namespaced\ClassName;
$mock = $this-getMock(ClassName);
Would changing the definition for class_name_scalar be sufficient?
class_name_scalar:
class_name { zend_resolve_class_name($1, ZEND_FETCH_CLASS_GLOBAL,
1 TSRMLS_CC); $$ = $1; }
;
To my eye, this is the least surprising syntax.
Re: [PHP-DEV] New Feature: Fully qualified class name resolution as scalar with class keyword
On Tue, Apr 17, 2012 at 9:36 PM, Galen Wright-Watson ww.ga...@gmail.com wrote:
Would it be easy to have a patch that simply allows use of the class name,
or is the ::class suffix necessary to resolve some ambiguity? Example
usage:
$mock = $this-getMock(A\Namespaced\**ClassName);
# or
use A\Namespaced\ClassName;
$mock = $this-getMock(ClassName);
Would changing the definition for class_name_scalar be sufficient?
class_name_scalar:
class_name { zend_resolve_class_name($1, ZEND_FETCH_CLASS_GLOBAL,
1 TSRMLS_CC); $$ = $1; }
;
To my eye, this is the least surprising syntax.
In your above example ClassName could just as well be a constant :)
Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Some Stats
On 04/17/2012 11:41 AM, Kris Craig wrote: On Mon, Apr 16, 2012 at 11:57 PM, Rasmus Lerdorf ras...@lerdorf.com mailto:ras...@lerdorf.com wrote: Number of posts to internals since Jan.1,2012 (top 15): [kris.cr...@gmail.com mailto:kris.cr...@gmail.com]= 249 Wooot! What's my prize? ;P Now I just need to start getting some commits in there Kris, this was actually the point of that email. You are extremely busy on this list and while I appreciate the enthusiasm, it would be good if you could try to refrain from commenting on every single thread multiple times every day. Let it sit for a while, see what everyone has to say and write a single message with your thoughts. This list is mainly for the people working on the code. Many of us are simply deleting entire threads unread at this point which isn't a healthy habit to get into. One idea for everyone on the list is a kind of self-imposed list posting quota. For every commit, bug comment, doc contribution, infrastructure contribution you make you get a post to the list. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New Feature: Fully qualified class name resolution as scalar with class keyword
Would changing the definition for class_name_scalar be sufficient?
class_name_scalar:
class_name { zend_resolve_class_name($1, ZEND_FETCH_CLASS_GLOBAL,
1 TSRMLS_CC); $$ = $1; }
;
To my eye, this is the least surprising syntax.
As far as I can tell, this rule will not compile as it conflicts with
other rules, namely around the namespace implementation rules.
Besides that though, an original design goal was to implement it closer
to how other languages solve the same-ish problem. This solution is
somewhat in line with Java (.class) and Ruby (.class.name), Python
actually uses the same but instead of .class, they use .__class__.__name__
-ralph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: New Feature: Fully qualified class name resolution as scalar with class keyword
class won't collide anyways, as it's already a keyword, and you can't use it in your constant or function names. __CLASS__ has bad connotations for me, as it resolves to the declaring class normally, not the class invoked. I tend to agree. __CLASS__ to me belongs to the family of constants like __DIR__ and __FILE__ where they are meant to be evaluated in-place and are simply a substitution for something completely static. In my mind, while Foo::class returns a scalar, it is subject to resolution by use statements generally at the top of a file or namespace declaration and is computed based on what namespace it is in and what use statements affect it. -ralph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re voting
On Mon, Apr 16, 2012 at 8:42 PM, sle...@pipeline.com wrote: Stas: Just b/c there are rarely any women at all that participate on this list, could we at list maintain a facade of gender neutrality? One of my favorite PHP dev folks is Sara Golemon. A fucking rock star. Female, I believe. I think she might be into women, but I don't really know, or care, because we honor *code*, not biological plumbing. Point being that PHP is not a sex or gender hostile community. -Bop -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Release day, was: release process with git
Hi! Stas tags Wednesday evening US Pacific time Stefan builds Thursday during the day US Pacific time David announces after all this is done which is Thursday evening EU time sometimes it becomes so late that I can only do it friday morning. So if we want to release Thursday, then windows builds need to be done one Wednesday. OK, I can tag on Tuesday instead, will it make things better? Let's try it with 5.4.1. -- 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] Some Stats
The author of an RFC does need to respond to concerns raised (although possibly not the same concerns over and over). On Tue, Apr 17, 2012 at 3:46 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 04/17/2012 11:41 AM, Kris Craig wrote: On Mon, Apr 16, 2012 at 11:57 PM, Rasmus Lerdorf ras...@lerdorf.com mailto:ras...@lerdorf.com wrote: Number of posts to internals since Jan.1,2012 (top 15): [kris.cr...@gmail.com mailto:kris.cr...@gmail.com] = 249 Wooot! What's my prize? ;P Now I just need to start getting some commits in there Kris, this was actually the point of that email. You are extremely busy on this list and while I appreciate the enthusiasm, it would be good if you could try to refrain from commenting on every single thread multiple times every day. Let it sit for a while, see what everyone has to say and write a single message with your thoughts. This list is mainly for the people working on the code. Many of us are simply deleting entire threads unread at this point which isn't a healthy habit to get into. One idea for everyone on the list is a kind of self-imposed list posting quota. For every commit, bug comment, doc contribution, infrastructure contribution you make you get a post to the list. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Some Stats
Maybe this has been suggested before, but it would be nice if comments in, ahem, request for comments could be consolidated into one spot, the RFC page itself. Facebook comments come to mind, though I'm sure there are other solutions based on OpenID, etc. Sent from my iPhone On 18 Apr, 2012, at 5:07 AM, Tom Boutell t...@punkave.com wrote: The author of an RFC does need to respond to concerns raised (although possibly not the same concerns over and over). On Tue, Apr 17, 2012 at 3:46 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 04/17/2012 11:41 AM, Kris Craig wrote: On Mon, Apr 16, 2012 at 11:57 PM, Rasmus Lerdorf ras...@lerdorf.com mailto:ras...@lerdorf.com wrote: Number of posts to internals since Jan.1,2012 (top 15): [kris.cr...@gmail.com mailto:kris.cr...@gmail.com]= 249 Wooot! What's my prize? ;P Now I just need to start getting some commits in there Kris, this was actually the point of that email. You are extremely busy on this list and while I appreciate the enthusiasm, it would be good if you could try to refrain from commenting on every single thread multiple times every day. Let it sit for a while, see what everyone has to say and write a single message with your thoughts. This list is mainly for the people working on the code. Many of us are simply deleting entire threads unread at this point which isn't a healthy habit to get into. One idea for everyone on the list is a kind of self-imposed list posting quota. For every commit, bug comment, doc contribution, infrastructure contribution you make you get a post to the list. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is_numeric_string an hexadecimal numbers (123 == 0x7B)
2012/4/17 Simon Schick simonsimc...@googlemail.com Hi, Gustavo That's something I didn't know of ... if we're doing that, it should, of course, be also be done for the dual system. The only thing I wonder about is the code examples you're giving ... I would expect this to work if we start to change something here: var_dump((int) '0x7b'); // int(123) var_dump((int) '0b011'); // int(123) var_dump((int) '0123'); // int(123) The last example was not mentioned here before but as you set in an example, I did it here as well ... Bye Simon Hi, all As I saw now in another thread - I forgot the octal number-system which takes 0 as prefix ... and this would change the result of my last example: var_dump((int) '0173'); // int(123) This makes me quite unsure if this should be done the way I proposed ... Here I would not expect it to happen like this. Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Some Stats
On Tue, 17 Apr 2012 23:23:35 +0200, Tjerk Meesters tjerk.meest...@gmail.com wrote: Maybe this has been suggested before, but it would be nice if comments in, ahem, request for comments could be consolidated into one spot, the RFC page itself. Facebook comments come to mind, though I'm sure there are other solutions based on OpenID, etc. This list should remain the main place for discussing PHP development. The volume of e-mails can be mitigated by sending more consolidated answers (that cover several points discussed recently) and avoiding recycling arguments. It's of little use to bring the same issues over and over again, be it with different or the same people. It doesn't matter if someone didn't get it, you don't have to convince him individually that you're right as that will have a near null effect on the outcome of the RFC. In my opinion, one of the problems with these RFC threads is that the proposers are busy retorting over and over again instead of just collecting the objections and address them either by changing the proposal or responding *once* in a well thought-out manner. That objection and a short response should also be included in the RFC to avoid it being brought up again. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] voting without vcs accounts
Hi! http://www.mail-archive.com/internals@lists.php.net/msg51948.html Pierre said that it was a bug(better to say lack of restriction), that everybody with wiki account was able to vote, so I changed the voting plugin to only allow the specific groups(vcs + voting) to be able to vote. This is the authenticated vote. It has also option of having non-authenticated vote. My point is that we are talking about some formal processes but I don't see what would be the desired purpose of such processes. For release process, it's releasing a stable code in time. For RFC, it is informing people about proposed feature and getting it discussed and hopefully accepted. Here, I'm not sure what is the goal. To be able to get voting karma if you meet the requirements. without the need to bribe Hannes, Philip or any other wiki admin. I don't see how getting you voting carma, whatever it might be, can be a goal of PHP project. I'm talking about the goal of the whole thing. -- 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] voting without vcs accounts
On Tue, Apr 17, 2012 at 11:48 PM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! http://www.mail-archive.com/internals@lists.php.net/msg51948.html Pierre said that it was a bug(better to say lack of restriction), that everybody with wiki account was able to vote, so I changed the voting plugin to only allow the specific groups(vcs + voting) to be able to vote. This is the authenticated vote. It has also option of having non-authenticated vote. ok, I didn't knew/remembered that. To be able to get voting karma if you meet the requirements. without the need to bribe Hannes, Philip or any other wiki admin. I don't see how getting you voting carma, whatever it might be, can be a goal of PHP project. I'm talking about the goal of the whole thing. sorry, I can't really follow you with that. do you have a problem allowing the non-vcs users (defined by the voting rfc) to vote, or do you have a problem providing a clear way for them to get their voting karma? -- Ferenc Kovács @Tyr43l - http://tyrael.hu
[PHP-DEV] Variable-length args by reference
Hi,
the topic of variable argument-lists for functions in connection with
getting the parameters by reference came up. This is currently not
possible with func_get_args(), though a hack with debug_backtrace() is
possible.
How would you think about extending func_get_args() and func_get_arg()
to allow for:
$args = func_get_args(FUNC_GET_ARGS_BY_REFERENCE);
$arg0 = func_get_arg (0, FUNC_GET_ARGS_BY_REFERENCE);
(default would be FUNC_GET_ARGS_BY_COPY)
Currently only the following hack works:
function calc()
{
$d = debug_backtrace();
$args = $d[0]['args'];
$args[0] *= 2;
$args[1] *= 2;
}
$a = 5;
$b = 7;
var_dump ($a, $b);
calc($a, $b);
var_dump ($a, $b);
Kind regards,
Stefan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Variable-length args by reference
On 04/18/2012 12:02 AM, Stefan Neufeind wrote:
Hi,
the topic of variable argument-lists for functions in connection with
getting the parameters by reference came up. This is currently not
possible with func_get_args(), though a hack with debug_backtrace() is
possible.
How would you think about extending func_get_args() and func_get_arg()
to allow for:
$args = func_get_args(FUNC_GET_ARGS_BY_REFERENCE);
$arg0 = func_get_arg (0, FUNC_GET_ARGS_BY_REFERENCE);
(default would be FUNC_GET_ARGS_BY_COPY)
Currently only the following hack works:
function calc()
{
$d = debug_backtrace();
$args = $d[0]['args'];
$args[0] *= 2;
$args[1] *= 2;
}
$a = 5;
$b = 7;
var_dump ($a, $b);
calc($a, $b);
var_dump ($a, $b);
Hmm, that example also only works because of the call-time
pass-by-reference? *sigh*
Sorry, I forgot those ampersands in the call to calc(). Doesn't work
without.
I hope the idea is clear though. Any chance we might make this possible
through func_get_args()?
Regards,
Stefan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Some Stats
On Tue, Apr 17, 2012 at 2:42 PM, Gustavo Lopes glo...@nebm.ist.utl.ptwrote: On Tue, 17 Apr 2012 23:23:35 +0200, Tjerk Meesters tjerk.meest...@gmail.com wrote: Maybe this has been suggested before, but it would be nice if comments in, ahem, request for comments could be consolidated into one spot, the RFC page itself. Facebook comments come to mind, though I'm sure there are other solutions based on OpenID, etc. This list should remain the main place for discussing PHP development. The volume of e-mails can be mitigated by sending more consolidated answers (that cover several points discussed recently) and avoiding recycling arguments. It's of little use to bring the same issues over and over again, be it with different or the same people. It doesn't matter if someone didn't get it, you don't have to convince him individually that you're right as that will have a near null effect on the outcome of the RFC. In my opinion, one of the problems with these RFC threads is that the proposers are busy retorting over and over again instead of just collecting the objections and address them either by changing the proposal or responding *once* in a well thought-out manner. That objection and a short response should also be included in the RFC to avoid it being brought up again. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Yeah one of the problems that really frustrates the hell out of me is that, after I've answered a question or responded to an objection, somebody new jumps in and raises the exact same issue. When I tell them to read earlier in the thread for my answer, they tend to get hostile and will often just keep re-repeating the criticism until I finally get fed-up and just repeat the response I'd posted earlier. Rinse and repeat. I'm naturally verbose and so I'll always tend to have more volume than the average, but a huge portion of it could be eliminated if we could find a way to break this pattern of the proposer being beaten over the head with the same criticism(s) over and over and over again regardless of whether or not it was responded to. In my current RFC, once we eventually were able to break out of that circular pattern, we started to actually make some real progress. So I definitely agree that this is a problem and no doubt there are things that I and other proposers can do to help, but I think a large bulk of the problem is actually happening on the other end. The proposer then has the option to either shut up and not argue for their proposal or add to the incessant volume of noise. I'm not one to simply lie back and give-up when things get tough, but I'll try to see if I can find a way to consolidate my responses better. However, we have to do something on the other end of this as well or the problem will persist. --Kris
Re: [PHP-DEV] Variable-length args by reference
Hi,
2012/4/18 Stefan Neufeind neufe...@php.net:
On 04/18/2012 12:02 AM, Stefan Neufeind wrote:
Hi,
the topic of variable argument-lists for functions in connection with
getting the parameters by reference came up. This is currently not
possible with func_get_args(), though a hack with debug_backtrace() is
possible.
How would you think about extending func_get_args() and func_get_arg()
to allow for:
$args = func_get_args(FUNC_GET_ARGS_BY_REFERENCE);
$arg0 = func_get_arg (0, FUNC_GET_ARGS_BY_REFERENCE);
(default would be FUNC_GET_ARGS_BY_COPY)
Currently only the following hack works:
function calc()
{
$d = debug_backtrace();
$args = $d[0]['args'];
$args[0] *= 2;
$args[1] *= 2;
}
$a = 5;
$b = 7;
var_dump ($a, $b);
calc($a, $b);
var_dump ($a, $b);
Hmm, that example also only works because of the call-time
pass-by-reference? *sigh*
Sorry, I forgot those ampersands in the call to calc(). Doesn't work
without.
I hope the idea is clear though. Any chance we might make this possible
through func_get_args()?
I don't know what you would like to do, but
function calc($args = NULL) {
var_dump(count($args)); // num of args
$args[1] *= 2;
}
calc(array(1,2,3,4));
would work.
Regards,
--
Yasuo Ohgaki
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP Dependencies
Hey guys, Forgive me if this has been addressed before, but I was wondering: Have we ever considered maintaining an RPM for PHP dependencies for each version branch? The are legitimate reasons why people prefer to build PHP manually instead of building from a repo, but those reasons often don't extend to the various extensions. So ideally, it would be awesome to be able to build those from a repo and have them match the builds used by that particular PHP version. For example, on CentOS I might do something like, sudo yum install php-common --enablerepo=PHP5_3. I was actually thinking of creating and maintaining some RPM packages for that purpose, but I figured it might be good to find out if there's already a better method first. Thanks! --Kris
Re: [PHP-DEV] Variable-length args by reference
On Wed, 2012-04-18 at 00:02 +0200, Stefan Neufeind wrote: How would you think about extending func_get_args() and func_get_arg() to allow for: $args = func_get_args(FUNC_GET_ARGS_BY_REFERENCE); $arg0 = func_get_arg (0, FUNC_GET_ARGS_BY_REFERENCE); (default would be FUNC_GET_ARGS_BY_COPY) Well we have to know the type before actually calling the function as for references we need something we can write to. So unless somebody comes up with a clever trick this would require a new language construct. And well, as a sidenote which I mention often: Don't use references :-) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Some Stats
My response earlier was meant to be funny, mostly, but I did also intend to convey some of the same things Rasmus said. The only person who wants to participate in a conversation where someone is hogging the floor is the person doing the talking. Yeah one of the problems that really frustrates the hell out of me is that, after I've answered a question or responded to an objection, somebody new jumps in and raises the exact same issue. When I tell them to read earlier in the thread for my answer, they tend to get hostile and will often just keep re-repeating the criticism until I finally get fed-up and just repeat the response I'd posted earlier. Rinse and repeat. In my opinion, the main reason this happens is because of your natural verbosity (as you put it). People are busy—especially smart people. You want the smart people to be able to read the important bits of your proposals/ideas, but most of them are unwilling and unable to sift through hundreds of messages. This is why they ask questions that have already been answered. Ignoring entire threads is a horrible thing for PHP's most valuable contributors to be doing, but I bet very few of the main committers in the list Rasmus posted have actually read all of the messages in all of the threads, lately. There's just too much posting, and as you can see from the stats, the distribution of posts is way out of balance (the #1 poster should never have more than twice as many posts as the #3 poster in a functional community). PHP has functioned as some sort of meritocracy since I've been a part of the community (and I'm sure that it was this way before then, too). If you want your opinions and comments to have weight, here, it's important to do more than talk. [1] Please, for the sake of people reading this list, adjust your posting habits accordingly. S [1] Before I get more whiny emails from more whiny people calling me some sort of hypocrite: while I have been mostly dormant (including posts to this list), lately, I've also put in hundreds of hours contributing to many parts of PHP over the years—I say this not to seek a pat on the back; I'm just looking for some understanding from new(ish) people. I have stepped back for many reasons, but one of those is definitely the unreasonably low signal to noise ratio on this list.
Re: [PHP-DEV] Re: New Feature: Fully qualified class name resolution as scalar with class keyword
Hi!
Fantastic question. I am unsure how to handle this. Currently, it will
simply resolve those names against the rules (I am sure this is the
wrong behavior.) So,
namespace Foo\Bar { var_dump(self::class); }
This should produce an error outside of class context, I think. Inside
of class context, self parent should work, I think, but static can't
work as it's caller-dependent.
--
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] Re: New Feature: Fully qualified class name resolution as scalar with class keyword
Hi! I tend to agree. __CLASS__ to me belongs to the family of constants like __DIR__ and __FILE__ where they are meant to be evaluated in-place and are simply a substitution for something completely static. But that's exactly what Foo::class is - completely static constant. In my mind, while Foo::class returns a scalar, it is subject to resolution by use statements generally at the top of a file or namespace declaration and is computed based on what namespace it is in and what use statements affect it. In the same vein you could say class statements affect __CLASS__ :). They are both compile-time constants. -- 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] voting without vcs accounts
Hi! sorry, I can't really follow you with that. do you have a problem allowing the non-vcs users (defined by the voting rfc) to vote, or do you have a problem providing a clear way for them to get their voting karma? I have a problem that we don't have understanding of what is the goal of this whole vote setup. What is it for? What we will be doing with it? And please don't say it says so in RFC - it is not a goal. -- 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
[PHP-DEV] [RFC] skipping optional parameters
Hi! One of the annoying things I've encountered in working with PHP was dealing with functions having long optional parameter lists, especially if you need to change only the last one - you have to copy all the defaults. Full named params implementation would solve it, probably, but before we have that here's an easier solution for part of the problem: https://wiki.php.net/rfc/skipparams Basically, it allows you to do this: create_query(deleted=0, name,,, /*report_errors*/ true); Implementation of it is here: https://github.com/smalyshev/php-src/tree/skip_params All things described in RFC seem to be working, please tell me if I forgot anything. If it's accepted I'll also add tests, etc. of course. -- 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] Some Stats
On Tue, Apr 17, 2012 at 3:42 PM, Sean Coates s...@seancoates.com wrote: My response earlier was meant to be funny, mostly, but I did also intend to convey some of the same things Rasmus said. The only person who wants to participate in a conversation where someone is hogging the floor is the person doing the talking. Yeah one of the problems that really frustrates the hell out of me is that, after I've answered a question or responded to an objection, somebody new jumps in and raises the exact same issue. When I tell them to read earlier in the thread for my answer, they tend to get hostile and will often just keep re-repeating the criticism until I finally get fed-up and just repeat the response I'd posted earlier. Rinse and repeat. In my opinion, the main reason this happens is because of your natural verbosity (as you put it). People are busy—especially smart people. You want the smart people to be able to read the important bits of your proposals/ideas, but most of them are unwilling and unable to sift through hundreds of messages. This is why they ask questions that have already been answered. But isn't that just a circular argument? I.e. They're not reading the list because its too cluttered, and, They're cluttering the list because they're not reading it. If people would read the first few messages in a thread, there wouldn't be all this clutter because they wouldn't be asking questions that have already been answered. And if they can't be troubled to do that, then they should hold-off on posting. Busy or not, rule #1 on any forum is that you should *read* the thread you're responding to. Yes, I can do my part by making my posts more succinct and I'll work on that, but what I'm saying is it's a two-way street. Me doing that alone won't be enough to solve this problem. Here's my rule: If a thread is important enough to object to its content, it's important enough to read. If it's not important enough to read, then it's not important enough to respond to. Simple as that. If you're too busy to read everything, I respect that. But if you then start cluttering that same thread with stuff that's already been said, you're just making the problem worse by turning a lively thread into a deluge. If I post an RFC and somebody raises a concern, I'll respond to it. It's totally unnecessary for someone to then post the same concern as if I never did respond, and then turn around and complain that the thread is too cluttery. We can't have it both ways. --Kris
Re: [PHP-DEV] voting without vcs accounts
On 04/17/2012 03:50 PM, Stas Malyshev wrote: Hi! sorry, I can't really follow you with that. do you have a problem allowing the non-vcs users (defined by the voting rfc) to vote, or do you have a problem providing a clear way for them to get their voting karma? I have a problem that we don't have understanding of what is the goal of this whole vote setup. What is it for? What we will be doing with it? And please don't say it says so in RFC - it is not a goal. Stas, I'm with Ferenc on this. We just need one or two sentences somewhere in the wiki saying how non-contributors can get vote karma. The sentences should give the physical process and what kind of people we will give karma to. Chris -- christopher.jo...@oracle.com http://twitter.com/#!/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] skipping optional parameters
Stas Malyshev wrote: Basically, it allows you to do this: create_query(deleted=0, name,,, /*report_errors*/ true); I'm a huge fan of this idea, for all the reasons listed on the RFC and one additional one: it brings normal functions in line with the syntax for list() - We can skip parameters in list() using the same syntax, so to my eye, this brings consistency. (Of course, list() is a construct, not a function, but considering how similar the syntax is, I think this makes sense.) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] skipping optional parameters
On 18.04.2012 00:54, Stas Malyshev wrote: One of the annoying things I've encountered in working with PHP was dealing with functions having long optional parameter lists, especially if you need to change only the last one - you have to copy all the defaults. Full named params implementation would solve it, probably, but before we have that here's an easier solution for part of the problem: https://wiki.php.net/rfc/skipparams Basically, it allows you to do this: create_query(deleted=0, name,,, /*report_errors*/ true); Pretty cool especially since it avoids the problem when refactoring code of knowing whether the use of the default param was intentional or just as a filler to reach a later parameter. I do have two remarks though: - I hope it doesn't mean giving up on named args, because that would look way cleaner. - Would it be possible to allow trailing commas in combination to this? i.e. foo(arg,) would just call foo with arg and then the default value for the second arg if there is one, or just nothing. That would make multi-line function calls a bit cleaner, and more similar to arrays. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] skipping optional parameters
Hi,
2012/4/18 Stas Malyshev smalys...@sugarcrm.com:
Hi!
One of the annoying things I've encountered in working with PHP was
dealing with functions having long optional parameter lists, especially
if you need to change only the last one - you have to copy all the
defaults. Full named params implementation would solve it, probably, but
before we have that here's an easier solution for part of the problem:
https://wiki.php.net/rfc/skipparams
Basically, it allows you to do this:
create_query(deleted=0, name,,, /*report_errors*/ true);
Implementation of it is here:
https://github.com/smalyshev/php-src/tree/skip_params
All things described in RFC seem to be working, please tell me if I
forgot anything. If it's accepted I'll also add tests, etc. of course.
Introducing undefined might be good.
Intention becomes clearer and we may do
if ($var === undefined) {
echo '$var is undefined';
}
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] skipping optional parameters
Hi!
Introducing undefined might be good.
Intention becomes clearer and we may do
if ($var === undefined) {
echo '$var is undefined';
}
What is undefined and how $var gets assigned it?
--
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] voting without vcs accounts
On Apr 17, 2012, at 4:08 PM, Christopher Jones wrote: On 04/17/2012 03:50 PM, Stas Malyshev wrote: Hi! sorry, I can't really follow you with that. do you have a problem allowing the non-vcs users (defined by the voting rfc) to vote, or do you have a problem providing a clear way for them to get their voting karma? I have a problem that we don't have understanding of what is the goal of this whole vote setup. What is it for? What we will be doing with it? And please don't say it says so in RFC - it is not a goal. Stas, I'm with Ferenc on this. We just need one or two sentences somewhere in the wiki saying how non-contributors can get vote karma. The sentences should give the physical process and what kind of people we will give karma to. The problem is that the voting RFC does not define who can vote. It contains two parts: 1. Those with SVN [sic] access (but how does karma come into play?) 2. Those without (how do we provide such rights? to whom?) If these are to be answered (they should) then I don't think an RFC can be edited like that (people already voted on it), so suspect we'd need a new RFC to replace it. Fun! I suspect most people voted Yes for that RFC thinking it'd mean less noise on this list while not caring about the details. That's only a guess. But trouble is, defining the Who is the most difficult part and a big reason why general consensus is preferred. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] skipping optional parameters
Hi,
2012/4/18 Stas Malyshev smalys...@sugarcrm.com:
Hi!
Introducing undefined might be good.
Intention becomes clearer and we may do
if ($var === undefined) {
echo '$var is undefined';
}
What is undefined and how $var gets assigned it?
I'm thinking undefined like JavaScript.
AFAIK, engine does not have undefined state.
It may be too many changes required.
Just skipping would work and I'm not against it.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] skipping optional parameters
Hi,
It's undefined, so it does not have to keep track state ;)
But it may require a lot of changes, so I don't matter much.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
2012/4/18 Yasuo Ohgaki yohg...@ohgaki.net:
Hi,
2012/4/18 Stas Malyshev smalys...@sugarcrm.com:
Hi!
Introducing undefined might be good.
Intention becomes clearer and we may do
if ($var === undefined) {
echo '$var is undefined';
}
What is undefined and how $var gets assigned it?
I'm thinking undefined like JavaScript.
AFAIK, engine does not have undefined state.
It may be too many changes required.
Just skipping would work and I'm not against it.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] skipping optional parameters
On 18/04/2012, at 10:54 AM, Stas Malyshev wrote: Hi! One of the annoying things I've encountered in working with PHP was dealing with functions having long optional parameter lists, especially if you need to change only the last one - you have to copy all the defaults. Full named params implementation would solve it, probably, but before we have that here's an easier solution for part of the problem: https://wiki.php.net/rfc/skipparams Basically, it allows you to do this: create_query(deleted=0, name,,, /*report_errors*/ true); Implementation of it is here: https://github.com/smalyshev/php-src/tree/skip_params All things described in RFC seem to be working, please tell me if I forgot anything. If it's accepted I'll also add tests, etc. of course. Hi I like this proposal. One thing pops out at me though. Since func_num_args() won't be able to be used to see if an argument is set, could a func_isset_arg() be added? So something like: if(func_num_args() 2) $value = func_get_arg(2); would become: if(func_isset_arg(2)) $value = func_get_arg(2); --- Simon Welsh -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] skipping optional parameters
Hi! I'm thinking undefined like JavaScript. Well, in PHP null is closest, but a bit different. I.e. in JS undefined a is an error, but a[0] where a is empty is undefined. In PHP in both cases you get null and notice, and in both cases you can use isset/empty to check for it. -- 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] [RFC] skipping optional parameters
Hi, 2012/4/18 Simon J Welsh si...@welsh.co.nz: On 18/04/2012, at 10:54 AM, Stas Malyshev wrote: Hi! One of the annoying things I've encountered in working with PHP was dealing with functions having long optional parameter lists, especially if you need to change only the last one - you have to copy all the defaults. Full named params implementation would solve it, probably, but before we have that here's an easier solution for part of the problem: https://wiki.php.net/rfc/skipparams Basically, it allows you to do this: create_query(deleted=0, name,,, /*report_errors*/ true); Implementation of it is here: https://github.com/smalyshev/php-src/tree/skip_params All things described in RFC seem to be working, please tell me if I forgot anything. If it's accepted I'll also add tests, etc. of course. Hi I like this proposal. One thing pops out at me though. Since func_num_args() won't be able to be used to see if an argument is set, could a func_isset_arg() be added? So something like: if(func_num_args() 2) $value = func_get_arg(2); would become: if(func_isset_arg(2)) $value = func_get_arg(2); Good point. For func_get_arg(), having undefined is mandatory, otherwise we cannot tell if it is defined or not. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] skipping optional parameters
Hi! Since func_num_args() won't be able to be used to see if an argument is set, could a func_isset_arg() be added? So something like: if(func_num_args() 2) $value = func_get_arg(2); would become: if(func_isset_arg(2)) $value = func_get_arg(2); I think it's easier to just do func_get_args() and check for isset there :) You usually don't have too many args so getting all of them is not a big problem. -- 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] [RFC] skipping optional parameters
Hi, On Wed, Apr 18, 2012 at 01:56, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Since func_num_args() won't be able to be used to see if an argument is set, could a func_isset_arg() be added? So something like: if(func_num_args() 2) $value = func_get_arg(2); would become: if(func_isset_arg(2)) $value = func_get_arg(2); I think it's easier to just do func_get_args() and check for isset there :) You usually don't have too many args so getting all of them is not a big problem. +1 BTW: the diffs show a lot of WS changes that you should probably fix. Best, -- 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 -- Etienne Kneuss http://www.colder.ch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] skipping optional parameters
On Wed, Apr 18, 2012 at 2:03 AM, Etienne Kneuss col...@php.net wrote: Hi, On Wed, Apr 18, 2012 at 01:56, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Since func_num_args() won't be able to be used to see if an argument is set, could a func_isset_arg() be added? So something like: if(func_num_args() 2) $value = func_get_arg(2); would become: if(func_isset_arg(2)) $value = func_get_arg(2); I think it's easier to just do func_get_args() and check for isset there :) You usually don't have too many args so getting all of them is not a big problem. +1 BTW: the diffs show a lot of WS changes that you should probably fix. On a side note, one can pass ?w=1 to the github diff, so it will show up without WS changes: https://github.com/smalyshev/php-src/commit/0f78493d3e96a627caa8258ee9e618301b6b3511?w=1 Makes is a bit easier to spot the relevant parts. I'm also +1 on the proposal :) Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] skipping optional parameters
Hi! BTW: the diffs show a lot of WS changes that you should probably fix. That's Eclipse, it loves to strip trailing whitespace... Which btw shows for some reason we have lots of it in our code. -- 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] [RFC] skipping optional parameters
Hi, 2012/4/18 Stas Malyshev smalys...@sugarcrm.com: Hi! Since func_num_args() won't be able to be used to see if an argument is set, could a func_isset_arg() be added? So something like: if(func_num_args() 2) $value = func_get_arg(2); would become: if(func_isset_arg(2)) $value = func_get_arg(2); I think it's easier to just do func_get_args() and check for isset there :) You usually don't have too many args so getting all of them is not a big problem. This works. I think it's fine with this. There may be a few codes that have BC issues, but it's new PHP anyway. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Dependencies
On 18 April 2012 06:40, Kris Craig kris.cr...@gmail.com wrote: Forgive me if this has been addressed before, but I was wondering: Have we ever considered maintaining an RPM for PHP dependencies for each version branch? The are legitimate reasons why people prefer to build PHP manually instead of building from a repo, but those reasons often don't extend to the various extensions. So ideally, it would be awesome to be able to build those from a repo and have them match the builds used by that particular PHP version. For example, on CentOS I might do something like, sudo yum install php-common --enablerepo=PHP5_3. I'm not really sure there's much benefit to the PHP project itself doing this — I know we still ship a spec file, but other than the special case of Windows, I think it's better if we just ship a tarball and let downstream maintainers work their magic from there, including build dependency aids like this. It's hard to cover all the RPM-using distributions with a single RPM, and it might be more hassle than it's worth to try. I was actually thinking of creating and maintaining some RPM packages for that purpose, but I figured it might be good to find out if there's already a better method first. You might want to talk to Remi Collet before putting much effort in; he builds excellent RPMs for each version for Fedora, Red Hat and CentOS and may well have some ideas on the best way to go about this. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] skipping optional parameters
On Wednesday, April 18, 2012 06:54 AM, Stas Malyshev wrote: Hi! https://wiki.php.net/rfc/skipparams Basically, it allows you to do this: create_query(deleted=0, name,,, /*report_errors*/ true); Implementation of it is here: https://github.com/smalyshev/php-src/tree/skip_params All things described in RFC seem to be working, please tell me if I forgot anything. If it's accepted I'll also add tests, etc. of course. Hate to be contrary, it does raise a few questions. a) it kind of encourages using long lists of arguments (which is not normally regarded as good practice) b) the usual recommendation for solving that issue is to accept an array (fake named arguments) c) the current situation would syntax error out on ,, as a function call argument, which is handy if you accidentally typed ,, twice by accident. if this changes, not only would you loose this syntax error, but it would do unpredictable things. For my 2c, does not look like a very good idea.. Regards Alan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] skipping optional parameters
Hi! a) it kind of encourages using long lists of arguments (which is not normally regarded as good practice) This ship has sailed long ago, these lists are the reality. And rewriting all the code to change all function calls is in most cases completely infeasible. c) the current situation would syntax error out on ,, as a function call argument, which is handy if you accidentally typed ,, twice by accident. if this changes, not only would you loose this syntax error, but it would do unpredictable things. There are many situations where you could type something by accident and have it change the meaning of the call. For example, if to type: if($foo); bar(); then bar() would execute always. This does not prevent us from using ; as statement separator or from using if's. -- 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] Some Stats
On 04/17/2012 11:41 AM, Kris Craig wrote: On Mon, Apr 16, 2012 at 11:57 PM, Rasmus Lerdorf ras...@lerdorf.com mailto:ras...@lerdorf.com wrote: Number of posts to internals since Jan.1,2012 (top 15): [kris.cr...@gmail.com mailto:kris.cr...@gmail.com] = 249 Wooot! What's my prize? ;P Now I just need to start getting some commits in there Kris, this was actually the point of that email. You are extremely busy on this list and while I appreciate the enthusiasm, it would be good if you could try to refrain from commenting on every single thread multiple times every day. Let it sit for a while, see what everyone has to say and write a single message with your thoughts. Rasmus makes an excellent point here, and I think Saun also makes this very telling statement... Ignoring entire threads is a horrible thing for PHP's most valuable contributors to be doing, but I bet very few of the main committers in the list Rasmus posted have actually read all of the messages in all of the threads, lately. I've tread conveying this same point in my brief response to Kris' thread by stating that I thought the RFC should then be revised in order to alleviate much of the confusion that seemed to resonate around this thread. I agree with Kris that this is a two-way street, but I have no illusions that one side was more at fault than the other. This is simply a matter of either be the first to take action and show initiative and ownership of the situation in order to take control, or cease to become a part of the solution and ultimately amalgamate with the problem. Kriss, you no doubt have passion. I believe I'm not alone in saying that I would like to see you focus this passion into efforts that will produce more fruitful and constructive results. Some times letting nonconstructive criticism go isn't the same thing as simply lie back and give-up when things get tough, as you put it. Remember the proverb less is more... It takes a stronger person to be able to tolerate harsh criticism (even if there is any merit to it) and simply redirect their frustration into productivity and delivering better results, rather than those who simply deliver on yet even more harsh criticism. Kriss, I respect you, I appreciate your dedication and I only wish you the best. Mind you I would never wish something upon someone that I do not already wish upon myself. I want to see us all succeed and there should be no reason why I'd be pleased with seeing anyone fail. Remember that your success only contributes to my success and the success of PHP's community collectively. I hope these words help you in refining your efforts and lead you to better results. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Some Stats
On Tue, Apr 17, 2012 at 7:30 PM, Sherif Ramadan theanomaly...@gmail.comwrote: On 04/17/2012 11:41 AM, Kris Craig wrote: On Mon, Apr 16, 2012 at 11:57 PM, Rasmus Lerdorf ras...@lerdorf.com mailto:ras...@lerdorf.com wrote: Number of posts to internals since Jan.1,2012 (top 15): [kris.cr...@gmail.com mailto:kris.cr...@gmail.com]= 249 Wooot! What's my prize? ;P Now I just need to start getting some commits in there Kris, this was actually the point of that email. You are extremely busy on this list and while I appreciate the enthusiasm, it would be good if you could try to refrain from commenting on every single thread multiple times every day. Let it sit for a while, see what everyone has to say and write a single message with your thoughts. Rasmus makes an excellent point here, and I think Saun also makes this very telling statement... Ignoring entire threads is a horrible thing for PHP's most valuable contributors to be doing, but I bet very few of the main committers in the list Rasmus posted have actually read all of the messages in all of the threads, lately. I've tread conveying this same point in my brief response to Kris' thread by stating that I thought the RFC should then be revised in order to alleviate much of the confusion that seemed to resonate around this thread. I agree with Kris that this is a two-way street, but I have no illusions that one side was more at fault than the other. This is simply a matter of either be the first to take action and show initiative and ownership of the situation in order to take control, or cease to become a part of the solution and ultimately amalgamate with the problem. Kriss, you no doubt have passion. I believe I'm not alone in saying that I would like to see you focus this passion into efforts that will produce more fruitful and constructive results. Some times letting nonconstructive criticism go isn't the same thing as simply lie back and give-up when things get tough, as you put it. Remember the proverb less is more... It takes a stronger person to be able to tolerate harsh criticism (even if there is any merit to it) and simply redirect their frustration into productivity and delivering better results, rather than those who simply deliver on yet even more harsh criticism. Kriss, I respect you, I appreciate your dedication and I only wish you the best. Mind you I would never wish something upon someone that I do not already wish upon myself. I want to see us all succeed and there should be no reason why I'd be pleased with seeing anyone fail. Remember that your success only contributes to my success and the success of PHP's community collectively. I hope these words help you in refining your efforts and lead you to better results. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I appreciate the kind words. However, the fact that the RFC is in an initial draft does not excuse repeating things that have been covered already on the topic. I wanted to wait on updating the RFC until there was a chance to discuss some of the methodologies available. I think we've pretty well covered that, and now it's just a matter of me finding the time to update it during a work week. =) But yes producing more than just words is one of my goals. I recently moved to Seattle and my old system was fried, so just this past weekend I finally got my new system built and am still in the process of setting everything up for a suitable dev/hosting environment. For example, I'd planned to have my approved apxs RFC implemented over a month ago, but I've been hit with one delay after another over here. I'll try to reduce the noise by cutting down on less necessary responses to other threads. But as far as the RFC thread goes, it might be prudent for us to find a way to fork lively RFC discussions onto another medium, whether it be a separate list, some sort of chat environment, etc. I really don't want to discourage people from going all-out in RFC debates (provided that they at least read before posting), so I think it would be good to brainstorm some ideas on that, because even if you eliminate redundancy and verbosity, controversial RFCs will always carry with them a flood of emails. So having a way to move the conversation aside while still keeping it publicly accessible and reviewable I think would be a worthwhile topic to discuss. --Kriss [sic; it's actually Kris lol ;p]
Re: [PHP-DEV] [RFC] skipping optional parameters
On Tue, Apr 17, 2012 at 6:54 PM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! One of the annoying things I've encountered in working with PHP was dealing with functions having long optional parameter lists, especially if you need to change only the last one - you have to copy all the defaults. Full named params implementation would solve it, probably, but before we have that here's an easier solution for part of the problem: https://wiki.php.net/rfc/skipparams Basically, it allows you to do this: create_query(deleted=0, name,,, /*report_errors*/ true); Implementation of it is here: https://github.com/smalyshev/php-src/tree/skip_params All things described in RFC seem to be working, please tell me if I forgot anything. If it's accepted I'll also add tests, etc. of course. Stas, this is fantastic! Not a voter, but I would be very thankful for this addition to PHP. Adam
Re: [PHP-DEV] voting without vcs accounts
hi Stas, On Wed, Apr 18, 2012 at 12:50 AM, Stas Malyshev smalys...@sugarcrm.com wrote: I have a problem that we don't have understanding of what is the goal of this whole vote setup. What is it for? What we will be doing with it? And please don't say it says so in RFC - it is not a goal. Let me clarify that and try to do not go backwards while we have finally moved forward. The goal is to have community leader participating in our design discussions and decisions. It has happened already for a couple of RFCs (accepted and rejected) and went very well. The FUDs about core devs, legacy developers and the like loosing control about the direction PHP takes has been killed, it did not happen and it is very unlikely that it will happen. How do the community leaders come in? They are usually very well known and already participate to php in one way or another (bugs report, testing, etc.) and are part of a known OSS project (we have drupal, zf, symfony already for example). Having a couple of devs to second their addition is also requested. This has been said many times already in the past and it is said in the RFC as well. We do not need over killed process as an attempt to make php more closed to our communities. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] voting without vcs accounts
hi, On Wed, Apr 18, 2012 at 1:29 AM, Philip Olson phi...@roshambo.org wrote: 1. Those with SVN [sic] access (but how does karma come into play?) It does, or we begin to have 2nd, 3rd and totally irrelevant classes of developers or doc writers. 2. Those without (how do we provide such rights? to whom?) See my other reply, easy, simple, harmless. I suspect most people voted Yes for that RFC thinking it'd mean less noise on this list while not caring about the details. That's only a guess. But trouble is, defining the Who is the most difficult part and a big reason why general consensus is preferred. I prefer not to comment on that part. It is like saying that people are not able to take a qualified decision, for whatever reasons. I have been myself tempted to think or say the same about some of the php.net members, and have been proven wrong many times. So let ignore this comment. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] voting without vcs accounts
On Wed, Apr 18, 2012 at 7:37 AM, Pierre Joye pierre@gmail.com wrote: hi, On Wed, Apr 18, 2012 at 1:29 AM, Philip Olson phi...@roshambo.org wrote: 1. Those with SVN [sic] access (but how does karma come into play?) It does, or we begin to have 2nd, 3rd and totally irrelevant classes of developers or doc writers. A not was missing. It should have been: It does not, or we begin to have 2nd, 3rd and totally irrelevant classes of developers or doc writers. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] skipping optional parameters
Hi!
My opinion is that solution tries to overcome bad consequences of
legacy code, when it's not feasible to change something without
breakage a lot of code, although the real solution is to refactor
functions with long variable lists (as Uncle Bob says), maybe this
should be noted in documentation of this feature.
Alan nicely highlighted all cons of this feature, but instead of
voting against it I suggest to put that into the docs, so people can
use it wisely and understand consequences.
One question about implementation:
Given we have this function
function create_query($where, $order_by, $join_type='', $execute = false,
$report_errors = true) {}
and this statement
On the engine level, it will be implemented by putting NULL in the place
where the parameter is passed.
what value $join_type will get on this call?
create_query(deleted=0, name,,, /*report_errors*/ true);
NULL or empty string? I.e. will optional parameters always get NULLs
or their default values?
Thanks.
--
Regards,
Shein Alexey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
