Re: [PHP-DEV] A new idea on PHP6.
I will also note that my phone cut off the part about this post not being serious. I, however, have no sense of humor. On Jul 18, 2012, at 11:17 PM, Ronald Chmara wrote: > With PHP 6, lets start with a: > Pure > Object > Oriented > PHP > > ...idea, and extend it out, so we can have a: > Structured > Heuristic > Idealistic > Taxonomy > > ..so we reduce user confusion, and eliminate the vast majority of our > userbase, (thus cutting down on bug reports, of course) so we can > have a: > Heuristic > Accessible > Readable > Available > Helpful > ...language advance. > > (This is not meant as a serious post, but as a post to increase levity > on this list. Your mileage may vary. Cape does not enable the wearer > to fly.) > > -Ronabop > > -- > 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] A new idea on PHP6.
I'll start off by saying that I am, personally, a great fan of OO. Pure OO languages have always tickled me just right. But I question the idea that making something pure OO makes it better. And in PHP, it wouldn't be a mere revamp of the OOP system like php5 did, it would fundamentally change the language. It wouldn't be PHP anymore. Also, it'd be slow. Very slow. There's no real way to keep PHP's model and go the route you're talking without turning the language into a vegetable. And that's okay. Because PHP isn't a one-size-fits-all tool. It's a web language, and it excels at being a web language. Why can't we just keep it that way, and use the tool appropriate for the job at hand? I wish we could stop trying to make PHP everything to everyone and just accept that sometimes java is the answer. Or python. Or ruby. Or any other language or technology that fits. Making PHP 100% OO won't make it better at web development. In fact, I'd argue it'd do the opposite, as a once simple language would now inherit not just the features that go with a pure OO language, but also the same considerations one has to make when dealing with such a language. Moreover, a change like this would result in one of two outcomes: PHP follows through with a solid, feature-complete OO language specification (unlikely) and thus loses the flexibility of being a dirty little dynamically typed language that cares little for enforcing type constraints, or, much more likely, we get a half assed solution because PHP wouldn't be PHP without that flexibility, and it's largely incompatible with a true OO architecture. Just my $0.02 On Jul 18, 2012, at 11:17 PM, Ronald Chmara wrote: > With PHP 6, lets start with a: > Pure > Object > Oriented > PHP > > ...idea, and extend it out, so we can have a: > Structured > Heuristic > Idealistic > Taxonomy > > ..so we reduce user confusion, and eliminate the vast majority of our > userbase, (thus cutting down on bug reports, of course) so we can > have a: > Heuristic > Accessible > Readable > Available > Helpful > ...language advance. > > (This is not meant as a serious post, but as a post to increase levity > on this list. Your mileage may vary. Cape does not enable the wearer > to fly.) > > -Ronabop > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] A new idea on PHP6.
With PHP 6, lets start with a: Pure Object Oriented PHP ...idea, and extend it out, so we can have a: Structured Heuristic Idealistic Taxonomy ..so we reduce user confusion, and eliminate the vast majority of our userbase, (thus cutting down on bug reports, of course) so we can have a: Heuristic Accessible Readable Available Helpful ...language advance. (This is not meant as a serious post, but as a post to increase levity on this list. Your mileage may vary. Cape does not enable the wearer to fly.) -Ronabop -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call for voting: [RFC] Allow use T_AS in closure use statement
On Wed, Jul 18, 2012 at 6:53 PM, Laruence wrote: > Hi: > I saw you two vote against for this RFC. > > could you explain why? then maybe I can improve it. > > thanks > > I can't speak for them, but it might have something to do with a lack of information. I don't recall seeing the discussion thread on this, either. Though I could've just missed it. More specifics I think would be helpful. --Kris
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
On Wed, Jul 18, 2012 at 6:16 PM, Rasmus Lerdorf wrote:
> On 07/18/2012 05:10 PM, David Muir wrote:
> > On 19/07/12 04:49, Rasmus Lerdorf wrote:
> >> On 07/18/2012 01:02 AM, Pierre Joye wrote:
> >>> hi,
> >>>
> >>> On Wed, Jul 18, 2012 at 9:35 AM, Stas Malyshev
> >>> wrote:
> Hi!
>
> > See the other answers, clear APIs, no more argument mess, cleanness.
> Cleanness has nothing to do with pseudo-objects.You don't have to use
> -> to have clean APIs, and using -> doesn't automatically make your
> APIs
> clean.
> >>> I really do not want to have a semantic discussion here.
> >>>
> >>> This syntax is sexy, allows us to clean our APIs, and is amazingly
> >>> handy.
> >> This makes no sense to me either. How does it let us clean the APIs? Can
> >> you give an example? I have one:
> >>
> >> $a = -5;
> >> $b = "-5";
> >>
> >> echo $a->abs(); // Outputs 5
> >> echo $b->abs(); // should still output 5
> >>
> >> What has been cleaned here over:
> >>
> >> echo abs($a);
> >> echo abs($b);
> >>
> >> other than being 2 characters longer to type? It's not like you can
> >> remove abs() from the string pseudo-object, so you are essentially just
> >> taking all the functions in the global namespace and attaching them as a
> >> method to every pseudo-object. Is that clean?
> >>
> >> I think there is something we can do around this, but an argument of "it
> >> is sexy and clean" needs to be backed up with some actual implementation
> >> details that make sense.
> >>
> >> -Rasmus
> >>
> >
> > Which is the needle, and which is the haystack?
> > $pos = strpos($string, 'a');
> > $pos = strpos('a', $string);
> >
> > vs
> > $pos = $string->pos('a');
> > $pos = 'a'->pos($string);
> >
> > I'm not proposing to use pos() as the method name, just showing an
> > example that this syntax can be cleaner.
>
> Or you could simply remember that it is always haystack,needle for
> strings and needle,haystack for arrays. Not that complicated.
>
> -Rasmus
>
> Really? Good to know . . .
Re: [PHP-DEV] Call for voting: [RFC] Allow use T_AS in closure use statement
Hi: I saw you two vote against for this RFC. could you explain why? then maybe I can improve it. thanks On Wed, Jul 18, 2012 at 11:21 PM, Laruence wrote: > On Wed, Jul 18, 2012 at 11:19 PM, Leigh wrote: >> I missed the discussion on this one, the RFC examples are very simple. Does >> it support aliasing array indices? >> >> For example: (use $matches[0] as $name) > sorry, no, it's only support literal variable for now. > > thanks >> >> On Jul 18, 2012 3:55 PM, "Laruence" wrote: >>> >>> Hi: >>> Call for voting for "Allow use T_AS in closure use statement", >>> https://wiki.php.net/rfc/useas#voting >>> >>> any comment will be appreciated. >>> >>> thanks >>> >>> -- >>> Laruence Xinchen Hui >>> http://www.laruence.com/ >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >> > > > > -- > Laruence Xinchen Hui > http://www.laruence.com/ -- 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] Pseudo-objects (methods on arrays, strings, etc.)
On 07/18/2012 05:10 PM, David Muir wrote:
> On 19/07/12 04:49, Rasmus Lerdorf wrote:
>> On 07/18/2012 01:02 AM, Pierre Joye wrote:
>>> hi,
>>>
>>> On Wed, Jul 18, 2012 at 9:35 AM, Stas Malyshev
>>> wrote:
Hi!
> See the other answers, clear APIs, no more argument mess, cleanness.
Cleanness has nothing to do with pseudo-objects.You don't have to use
-> to have clean APIs, and using -> doesn't automatically make your
APIs
clean.
>>> I really do not want to have a semantic discussion here.
>>>
>>> This syntax is sexy, allows us to clean our APIs, and is amazingly
>>> handy.
>> This makes no sense to me either. How does it let us clean the APIs? Can
>> you give an example? I have one:
>>
>> $a = -5;
>> $b = "-5";
>>
>> echo $a->abs(); // Outputs 5
>> echo $b->abs(); // should still output 5
>>
>> What has been cleaned here over:
>>
>> echo abs($a);
>> echo abs($b);
>>
>> other than being 2 characters longer to type? It's not like you can
>> remove abs() from the string pseudo-object, so you are essentially just
>> taking all the functions in the global namespace and attaching them as a
>> method to every pseudo-object. Is that clean?
>>
>> I think there is something we can do around this, but an argument of "it
>> is sexy and clean" needs to be backed up with some actual implementation
>> details that make sense.
>>
>> -Rasmus
>>
>
> Which is the needle, and which is the haystack?
> $pos = strpos($string, 'a');
> $pos = strpos('a', $string);
>
> vs
> $pos = $string->pos('a');
> $pos = 'a'->pos($string);
>
> I'm not proposing to use pos() as the method name, just showing an
> example that this syntax can be cleaner.
Or you could simply remember that it is always haystack,needle for
strings and needle,haystack for arrays. Not that complicated.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
On 19/07/12 04:49, Rasmus Lerdorf wrote:
On 07/18/2012 01:02 AM, Pierre Joye wrote:
hi,
On Wed, Jul 18, 2012 at 9:35 AM, Stas Malyshev wrote:
Hi!
See the other answers, clear APIs, no more argument mess, cleanness.
Cleanness has nothing to do with pseudo-objects.You don't have to use
-> to have clean APIs, and using -> doesn't automatically make your APIs
clean.
I really do not want to have a semantic discussion here.
This syntax is sexy, allows us to clean our APIs, and is amazingly handy.
This makes no sense to me either. How does it let us clean the APIs? Can
you give an example? I have one:
$a = -5;
$b = "-5";
echo $a->abs(); // Outputs 5
echo $b->abs(); // should still output 5
What has been cleaned here over:
echo abs($a);
echo abs($b);
other than being 2 characters longer to type? It's not like you can
remove abs() from the string pseudo-object, so you are essentially just
taking all the functions in the global namespace and attaching them as a
method to every pseudo-object. Is that clean?
I think there is something we can do around this, but an argument of "it
is sexy and clean" needs to be backed up with some actual implementation
details that make sense.
-Rasmus
Which is the needle, and which is the haystack?
$pos = strpos($string, 'a');
$pos = strpos('a', $string);
vs
$pos = $string->pos('a');
$pos = 'a'->pos($string);
I'm not proposing to use pos() as the method name, just showing an
example that this syntax can be cleaner.
David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_parse_parameters() improvements
Em Thu, 19 Jul 2012 01:11:38 +0200, Stas Malyshev
escreveu:
Example:
http://lxr.php.net/xref/PHP_TRUNK/ext/intl/timezone/timezone_methods.cpp#143
In this case, NULL, int and string are allowed. This would become much
simpler:
if (arg == NULL || Z_TYPE_PP(arg) == IS_NULL) {
se = TimeZone::createEnumeration();
} else {
long l;
char *s;
int s_len;
if (zend_parse_parameter(ZEND_PARSE_PARAMS_QUIET,
1 TSRMLS_DC, arg, "l", &l) == SUCCESS) {
TimeZone::createEnumeration((int32_t) l);
} else if (zend_parse_parameter(ZEND_PARSE_PARAMS_QUIET,
1 TSRMLS_DC, arg, "s", &s, &s_len) == SUCCESS) {
TimeZone::createEnumeration(s);
} else {
//raise errror
}
Wait, didn't you say applying zpp to arg as l, then as s would change
it? Or your function doesn't change it?
Yes, the zval is potentially changed in both calls (that's why the
argument is passed with double indirection). But this is not a problem
here (in fact, it simplifies resource management -- since the second
zend_parse_parameter() changes the zval in the stack, the engine can
reclaim the zval and string automatically when the function returns).
There's to argument if its processing fails. zend_parse_parameters()
(plural) changes the arguments only until it fails. Yes, whether an
argument is changed or not depends on its position relative to the failing
argument.
Since zend_parse_parameter() takes only one argument this is not a problem
-- supposedly, you call zend_parse_parameter() successfully only once. In
any case, you can always copy the zval yourself.
In any case, I think giving access to single-parameter parsing is a good
idea and allows functions to implement complex cases in more consistent
manner - right now I know there are some functions that return different
error messages than zpp does when they parse arguments, for example -
this can be fixes.
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Integer overflows on float to int casts
Cap it at INT_MAX, yeah, that seems reasonable. A notice seems reasonable but production servers displaying errors... devs will go mad :) On Jul 18, 2012 11:39 PM, "Nikita Popov" wrote: > Hi internals! > > When a large floating point number is cast to an integer we currently > have very low-level C behavior (integer overflow and wraparound): > > $ /c/php-5.4.1/php -r 'var_dump((int) 40);' > int(-294967296) > > $ /c/php-5.4.1/php -r 'var_dump((int) 60);' > int(1705032704) > > As a fun fact, if you do the same thing with a string float the number > if clipped instead of wrapped: > > $ /c/php-5.4.1/php -r 'var_dump((int) "40");' > int(2147483647) > > This also applies to zend_parse_parameters. l arguments are wrapped, L > arguments are clipped. > > In my eyes this kind of behavior has nothing to do in PHP. PHP is a > high-level language, it shouldn't exhibit low-level stuff like integer > overflows and wraparound. > > I think that at least for zend_parse_parameters this should be > changed. Overflowing float parameters should not be accepted. Instead > throw the usual E_WARNING and return FAILURE. > > I'm not sure though what one should do about the explicit (int) cast. > My preference would be to throw a notice and use the clipping > behavior. > > Thoughts? > > Nikita > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] zend_parse_parameters() improvements
Hi!
> Some deficiencies in zpp have been constrai
> ning the implementation of common scenarios such as 'allow integer or
> NULL'* or the more general 'allow different types for an argument'**.
>
> So I propose the changes in this branch:
>
> https://github.com/cataphract/php-src/compare/zpp_improv
This looks interesting. I have a bit different idea about how to make
"parameter not passed" scenario - see
https://wiki.php.net/rfc/skipparams - but having something like l! would
work in that case too.
It'd be nice to have a description of these as an RFC though - so we
could use it in the docs, when updating READMEs and for reference -
tracking down commit messages is not very convenient.
> Example:
> http://lxr.php.net/xref/PHP_TRUNK/ext/intl/timezone/timezone_methods.cpp#143
> In this case, NULL, int and string are allowed. This would become much
> simpler:
>
> if (arg == NULL || Z_TYPE_PP(arg) == IS_NULL) {
> se = TimeZone::createEnumeration();
> } else {
> long l;
> char *s;
> int s_len;
> if (zend_parse_parameter(ZEND_PARSE_PARAMS_QUIET,
> 1 TSRMLS_DC, arg, "l", &l) == SUCCESS) {
> TimeZone::createEnumeration((int32_t) l);
> } else if (zend_parse_parameter(ZEND_PARSE_PARAMS_QUIET,
> 1 TSRMLS_DC, arg, "s", &s, &s_len) == SUCCESS) {
> TimeZone::createEnumeration(s);
> } else {
> //raise errror
> }
Wait, didn't you say applying zpp to arg as l, then as s would change
it? Or your function doesn't change it?
In any case, I think giving access to single-parameter parsing is a good
idea and allows functions to implement complex cases in more consistent
manner - right now I know there are some functions that return different
error messages than zpp does when they parse arguments, for example -
this can be fixes.
--
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] 6.0 And Moving Forward
> People are forgetting why we have version numbers. > > Yes, it's very spectacular to have all the new stuff in a major release, but > that's not what major versions are for. > Major versions are for BC breaks. And point releases are for BC-compatible > new features. > Therefore in 5.x releases old and new features should co-exist, and in 6.x > the old ones should just go. > Otherwise there's no point of using versions *at all*, and PHP can just > publish build numbers or dates. > > Here's a refresher of the rules of versioning: http://semver.org/ > > Stan Stan, just to clarify, I'm for BC breaks and overall evolution in a language. It makes perfect sense to me, to go through the steps of marking deprecated and later removing those... As is clear on "Semantic Versioning" http://semver.org What I was stating is that: IF you want to keep the old way of doing things around instead of removing them, it should be "change settings/tag/whatever so it work as the old way" and not "change it so it works the new way", that was my only point. Cheers Daniel Macedo -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC karma request
I'd like to see some version of the null-coalescing ternary operator (recently brought up in a thread started by Rafael Dohms) make it into PHP. To help it along, may I have RFC karma so I can draft a proposal? My PHP wiki account name is "outis", e-mail is "ww.ga...@gmail.com". If there's a better/approved way of getting RFC karma than posting on the internals list, please let me know. So far, I haven't been able to find any official documentation on how.
[PHP-DEV] Integer overflows on float to int casts
Hi internals! When a large floating point number is cast to an integer we currently have very low-level C behavior (integer overflow and wraparound): $ /c/php-5.4.1/php -r 'var_dump((int) 40);' int(-294967296) $ /c/php-5.4.1/php -r 'var_dump((int) 60);' int(1705032704) As a fun fact, if you do the same thing with a string float the number if clipped instead of wrapped: $ /c/php-5.4.1/php -r 'var_dump((int) "40");' int(2147483647) This also applies to zend_parse_parameters. l arguments are wrapped, L arguments are clipped. In my eyes this kind of behavior has nothing to do in PHP. PHP is a high-level language, it shouldn't exhibit low-level stuff like integer overflows and wraparound. I think that at least for zend_parse_parameters this should be changed. Overflowing float parameters should not be accepted. Instead throw the usual E_WARNING and return FAILURE. I'm not sure though what one should do about the explicit (int) cast. My preference would be to throw a notice and use the clipping behavior. Thoughts? Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_parse_parameters() improvements
On Wed, Jul 18, 2012 at 11:05 PM, Gustavo Lopes wrote:
> Some deficiencies in zpp have been constrai
> ning the implementation of common scenarios such as 'allow integer or NULL'*
> or the more general 'allow different types for an argument'**.
>
> So I propose the changes in this branch:
>
> https://github.com/cataphract/php-src/compare/zpp_improv
>
> Please see the commit messages for the rationale.
>
> *Example:
> https://github.com/php/php-src/pull/13
> (again more recently on
> https://github.com/php/php-src/pull/133 )
> **
> Example:
> http://lxr.php.net/xref/PHP_TRUNK/ext/intl/timezone/timezone_methods.cpp#143
> In this case, NULL, int and string are allowed. This would become much
> simpler:
>
> if (arg == NULL || Z_TYPE_PP(arg) == IS_NULL) {
> se = TimeZone::createEnumeration();
> } else {
> long l;
> char *s;
> int s_len;
> if (zend_parse_parameter(ZEND_PARSE_PARAMS_QUIET,
> 1 TSRMLS_DC, arg, "l", &l) == SUCCESS) {
> TimeZone::createEnumeration((int32_t) l);
> } else if (zend_parse_parameter(ZEND_PARSE_PARAMS_QUIET,
> 1 TSRMLS_DC, arg, "s", &s, &s_len) == SUCCESS) {
> TimeZone::createEnumeration(s);
> } else {
> //raise errror
> }
> }
+1 The long/null issue comes up every once in a while. This is really useful.
Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implicit isset in ternary operator
On Wed, Jul 18, 2012 at 12:21 PM, Galen Wright-Watson wrote:
>
>
> On Wed, Jul 18, 2012 at 7:20 AM, Anthony Ferrara wrote:
>
>>
>> On Wed, Jul 18, 2012 at 10:15 AM, Rafael Dohms > >wrote:
>>
>> > [...]
>>
>> >
>> > This is basically because the ternary operator does not do a internal
>> > implicit isset, only an empty.
>> >
>>
>> It does not do an empty. Empty would avoid notices as well. All it does is
>> an implicit bool cast...
>>
>>
>> > Does this seem like a possible improvement we can work on? Anyone
>> > interested in championing the change?
>> >
>>
>> I like it in principle. My only concern is *why* wasn't it done this way
>> in
>> the first place... Is there a reason?
>>
>
> It changes the semantics. If the variable is set to a falsey value and ?:
> uses an implicit isset, the value of the expression will be the falsey
> value.
>
> $config['width'] = ''
> $width = $config['width'] ?: 300
> # $width == ''
>
> If !empty were used instead of isset, you could preserve semantics ($a ?:
> dflt = !empty($a) ? $a : dflt).
>
However, this would break if someone were to use an explicit isset, so ?:
could only use an implicit !empty if the expression isn't an isset
expression (which starts to get messy, grammar-wise).
Looking over the previous discussion, people objected to altering the
behavior of ?: precisely because it currently generates notices, which they
desire.
The following use-cases were put forward as commonly occurring and verbose
enough to desire syntactic sugar:
1. isset($arr['key']) ? $arr['key'] : dflt
2. ! empty($arr['key']) ? $arr['key'] : dflt
3. ! is_null($arr['key']) ? $arr['key'] : dflt (used instead of isset
version; both wouldn't appear in same code base)
4. $arr['key'] = isset($arr['key']) ? $arr['key'] : dflt
5. isset($arr['key']) ? strtoupper($arr['key']) : dflt
The following new operators were suggested:
1. new ternary based on isset (e.g. "$a ?? strtoupper($a) : 'DFLT'" with
implicit isset)
2. new shortcut ternary based on isset
3. new shortcut ternary based on !empty (objection: not as useful as
isset, since !empty is equivalent to !! but with notice suppression)
4. new shortcut ternary based on !== null or ! is_null
5. new shortcut ternary that only works on arrays and is based
on array_key_exists
6. indexing operator that suppress undefined index notices
7. variable access that suppresses undefined variable notices
8. assign-if-not-set operator (like ||= in Javascript)
Some objections to the above:
1. (new ternary) ?
2. (isset) Some developers always set variables and never want undefined
notice suppression (the "never-unset" style), which isset will do. However,
this isn't as common a style.
3. (!empty) Not as useful as isset, since !empty is equivalent to !! but
with notice suppression. Also, !empty($a)?$a:dflt isn't used as much as
isset($a)?$a:dflt.
4. (!== null / ! is_null) Not as useful as isset, since it doesn't
suppress notices, so isn't a replacement for the isset($a)?$a:dflt pattern.
However, it can be used in combination with 6 for the isset-based ternary
for arrays (e.g. "$arr?['key'] ?: 'dflt'").
5. (array_key_exists) Conceptually, anything unset has a null value, and
should thus be equivalent in value to something set to NULL.
array_key_exists distinguishes between unset and set to NULL, which
won't always match how some want to use the shortcut ternary. Thus, not as
useful as is_null.
6. (indexing w/o notices) ?
7. (variable access) Probably do more harm than good. It's easy to
ensure a variable is set.
8. (assign-if-not-set) For arrays, there's the alternative:
$arr += Array('key' => 'value');
This can also be used for a "never-unset" style to set defaults for an
array, which goes with the "! is_null($a) ? $a : dflt" pattern.
Various syntax proposals:
1. "$a ?? $b : dflt" as a ternary, with shortcutting behavior.
2. "$a ?? dflt" as a shortcut ternary
3. "$a ?! dflt" as a shortcut ternary based on !empty (could be added
along with "??"; objection is that it could ambiguate PHP's syntax,
conflicting with the not operator)
4. "$a $: dflt" as a shortcut ternary
5. "$arr?['key']" to suppress undefined index notices
6. "$arr@['key']" to suppress undefined index notices
7. "$?var" to suppress undefined variable notices
8. "$a ??= dflt" as an assign-if-not-set operator (goes along with "??")
9. "$a !?= dflt" as an assign-if-not-set operator ("!" suggests not-set)
10. "$a $:= dflt" as an assign-if-not-set operator (goes along with "$:")
?? / isset vs ?? / is_null
Of the various proposals, "??" (with semantics of "isset($a) ? $a : dflt")
already has a precedence: in C# as the null-coalescing operator. While PHP
doesn't have non-nullable types (hence "??" isn't a necessity), using ?? is
perhaps the least surprising option, and (including "??=") would cover
use-cases 1 and 4. On the
Re: [PHP-DEV] Implicit isset in ternary operator
It changes the semantics. If the variable is set to a falsey value and ?: uses an implicit isset, the value of the expression will be the falsey value. $config['width'] = '' $width = $config['width'] ?: 300 # $width == '' If !empty were used instead of isset, you could preserve semantics ($a ?: dflt = !empty($a) ? $a : dflt). Since this has been discussed before, here's a previous solution with zero of those problems: // A new operator. $width = $config['width'] ?? 300; // Actual behavior of the operator in pseudo code: $width = isset($config['width']) ? $config['width'] : 300; Why wasn't it implemented? No reason, it just wasn't. But people keep asking about it, so it's only a matter of time. Stan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
But OOP-like syntax on non-object data is still weird. The question about data manipulation behavior (is it a pointer like other objects or is it a scalar like existing array?) is a tough one. For the user's point of view there is no difference between the passing semantics of numbers/string primitives and objects. Only arrays differ. However we already have ArrayAccess and so on for objects, which creates array-like objects with object passing semantics. So the idea that something that looks like array will have passing semantics like an array is already wrong in PHP. The clarity of passing semantics is not a valid argument against pseudo methods for string/int/float/array primitives. Stan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] zend_parse_parameters() improvements
Some deficiencies in zpp have been constrai
ning the implementation of common scenarios such as 'allow integer or
NULL'* or the more general 'allow different types for an argument'**.
So I propose the changes in this branch:
https://github.com/cataphract/php-src/compare/zpp_improv
Please see the commit messages for the rationale.
*Example:
https://github.com/php/php-src/pull/13
(again more recently on
https://github.com/php/php-src/pull/133 )
**
Example:
http://lxr.php.net/xref/PHP_TRUNK/ext/intl/timezone/timezone_methods.cpp#143
In this case, NULL, int and string are allowed. This would become much
simpler:
if (arg == NULL || Z_TYPE_PP(arg) == IS_NULL) {
se = TimeZone::createEnumeration();
} else {
long l;
char *s;
int s_len;
if (zend_parse_parameter(ZEND_PARSE_PARAMS_QUIET,
1 TSRMLS_DC, arg, "l", &l) == SUCCESS) {
TimeZone::createEnumeration((int32_t) l);
} else if (zend_parse_parameter(ZEND_PARSE_PARAMS_QUIET,
1 TSRMLS_DC, arg, "s", &s, &s_len) == SUCCESS) {
TimeZone::createEnumeration(s);
} else {
//raise errror
}
}
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 6.0 And Moving Forward
Sure, BC breaks for 6.0, but it worries me. I don't want a Python 3 for PHP 6. Or heck, PHP5 for that matter. On Jul 18, 2012 9:50 PM, "Stan Vass" wrote: > Chaos will surely be, if we break PHP5 code. It should work without >> modification. > On Jul 18, 2012 9:34 PM, "Daniel Macedo" wrote: >> > > People are forgetting why we have version numbers. > > Yes, it's very spectacular to have all the new stuff in a major release, > but that's not what major versions are for. > Major versions are for BC breaks. And point releases are for BC-compatible > new features. > Therefore in 5.x releases old and new features should co-exist, and in 6.x > the old ones should just go. > Otherwise there's no point of using versions *at all*, and PHP can just > publish build numbers or dates. > > Here's a refresher of the rules of versioning: http://semver.org/ > > Stan >
Re: [PHP-DEV] 6.0 And Moving Forward
...er, wrote: > > use a slightly modified version of the open tag, for example > <*php, etc. This satisfies several desires: we don't want an extra > > line of boilerplate code like 'use PHP 6' to be required in every > > source file, we want a PHP 5 file to run without modification, and we > > want a PHP 6 file to be able to include a PHP 5 file without > > modification, but we don't want PHP 6 to have to be a superset of PHP > > I don't like this idea, and in fact if it's ever implemented I think > it should go the other way around. (i.e. use a compatibility mode) > > Mostly because people who want to properly maintain a project will go > through the source thoroughly to properly update legacy code, however > old legacy code that isn't going to be maintained usually warrants the > find and replace method where something like this could make sense... > > But my point is I'd rather have this option: > > 3. Build a high-quality tool to convert code automatically to the > > greatest extent possible > Telling the what's incompatible/broken and how to fix it, or do it > automagically if possible. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] 6.0 And Moving Forward
Chaos will surely be, if we break PHP5 code. It should work without modification. wrote: People are forgetting why we have version numbers. Yes, it's very spectacular to have all the new stuff in a major release, but that's not what major versions are for. Major versions are for BC breaks. And point releases are for BC-compatible new features. Therefore in 5.x releases old and new features should co-exist, and in 6.x the old ones should just go. Otherwise there's no point of using versions *at all*, and PHP can just publish build numbers or dates. Here's a refresher of the rules of versioning: http://semver.org/ Stan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 6.0 And Moving Forward
I do like the idea of pseudo-objects with methods as a way to create much cleaner APIs for strings and arrays, but the legacy APIs need to stick around. You don't need to break BC to remove legacy APIs in PHP6. #1. Introduce the new APIs in 5.x and gradually mark the old ones as deprecated, but keep them available. People will write forward-compatible code using the new APIs. #2. 2 years pass before 6.0 is out. #3. Remove the old, already deprecated APIs from 6.0. Simple. Stan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 6.0 And Moving Forward
Chaos will surely be, if we break PHP5 code. It should work without modification. wrote: > > use a slightly modified version of the open tag, for example > <*php, etc. This satisfies several desires: we don't want an extra > > line of boilerplate code like 'use PHP 6' to be required in every > > source file, we want a PHP 5 file to run without modification, and we > > want a PHP 6 file to be able to include a PHP 5 file without > > modification, but we don't want PHP 6 to have to be a superset of PHP > > I don't like this idea, and in fact if it's ever implemented I think > it should go the other way around. (i.e. use a compatibility mode) > > Mostly because people who want to properly maintain a project will go > through the source thoroughly to properly update legacy code, however > old legacy code that isn't going to be maintained usually warrants the > find and replace method where something like this could make sense... > > But my point is I'd rather have this option: > > 3. Build a high-quality tool to convert code automatically to the > > greatest extent possible > Telling the what's incompatible/broken and how to fix it, or do it > automagically if possible. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] 6.0 And Moving Forward
> use a slightly modified version of the open tag, for example <*php, etc. This satisfies several desires: we don't want an extra > line of boilerplate code like 'use PHP 6' to be required in every > source file, we want a PHP 5 file to run without modification, and we > want a PHP 6 file to be able to include a PHP 5 file without > modification, but we don't want PHP 6 to have to be a superset of PHP I don't like this idea, and in fact if it's ever implemented I think it should go the other way around. (i.e. use a 3. Build a high-quality tool to convert code automatically to the > greatest extent possible Telling the what's incompatible/broken and how to fix it, or do it automagically if possible. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 6.0 And Moving Forward
If there's this big conflict between BC breaks being bad because they discourage adoption and make old code unusable on the one hand, and good because they allow many things to be cleaned up and progress to be made, then why not pursue a three-pronged approach: 1. BC breaks are made wherever it makes sense to make the best PHP 6.0 possible 2. Near-full backwards compatibility is kept as an extension included with the core (a long way down the road, it can be deprecated, moved to PECL, dropped altogether, etc., once the migration is complete and old code has mostly been ported) 3. Build a high-quality tool to convert code automatically to the greatest extent possible One last suggestion is that in order to keep legacy 5.x code (using the compatibility extension) and 6.0 code interoperable, 6.0 should use a slightly modified version of the open tag, for example wrote: > On Wed, Jul 18, 2012 at 12:09 PM, Andrew Faulds wrote: > >> Kris, I'd love to break BC a lot and fix things, but it would seriously >> slow adoption. Fixing *bugs* has stopped people upgrading, imagine how they >> would react to non-bugs being changed. >> >> > I agree with your point. I guess my thinking is that this is an > unavoidable cost of progress, at least on a major version change. Given > that the alternative is an increasingly stagnated codebase, IMHO the cost > of slower adoption would be the "lesser of two evils." > > --Kris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
> I think there is something we can do around this... Reviewing the php array functions it seems to me that a new API would benefit from some sort of more intuitive organization, possibly around meta concepts specific to use. For example, I want to re-order an array (order is a meta-concept in this description) how I specifically want to re-order the array is a sub-concept or sub-property of this general thought process. If you're following me then an intuitive API would look something like array functions condensed into a small handful of more generalized functions that take an argument to specify their exact behavior. I.e. array_order($my_array, 'sort', 'alpha', 'asc'); as a rough idea or breaking away from the traditional API a bit further array_order->sort($my_array, 'alpha', 'asc'); I'm offering this as a general representation of the idea to organize and condense the API not as a fully flushed out representation of the end result so useful feedback would be around the concept and not the semantics hastily hatched code examples. - Bill
Re: [PHP-DEV] 6.0 And Moving Forward
On Wed, Jul 18, 2012 at 12:09 PM, Andrew Faulds wrote: > Kris, I'd love to break BC a lot and fix things, but it would seriously > slow adoption. Fixing *bugs* has stopped people upgrading, imagine how they > would react to non-bugs being changed. > > I agree with your point. I guess my thinking is that this is an unavoidable cost of progress, at least on a major version change. Given that the alternative is an increasingly stagnated codebase, IMHO the cost of slower adoption would be the "lesser of two evils." --Kris
Re: [PHP-DEV] Implicit isset in ternary operator
On Wed, Jul 18, 2012 at 7:20 AM, Anthony Ferrara wrote: > > On Wed, Jul 18, 2012 at 10:15 AM, Rafael Dohms >wrote: > > > [...] > > > > This is basically because the ternary operator does not do a internal > > implicit isset, only an empty. > > > > It does not do an empty. Empty would avoid notices as well. All it does is > an implicit bool cast... > > > > Does this seem like a possible improvement we can work on? Anyone > > interested in championing the change? > > > > I like it in principle. My only concern is *why* wasn't it done this way in > the first place... Is there a reason? > It changes the semantics. If the variable is set to a falsey value and ?: uses an implicit isset, the value of the expression will be the falsey value. $config['width'] = '' $width = $config['width'] ?: 300 # $width == '' If !empty were used instead of isset, you could preserve semantics ($a ?: dflt = !empty($a) ? $a : dflt).
Re: [PHP-DEV] Docs: php.ini vs. parse_ini_file()
On Wed, Jul 18, 2012 at 11:32 AM, Hannes Magnusson < hannes.magnus...@gmail.com> wrote: > On Wed, Jul 18, 2012 at 7:26 PM, Kris Craig wrote: > >> > >> I don't understand why on earth your are mailing the PHP *internal > >> developer mailinglist* with this matter? > >> > >> If you have any improvement suggestions for the documentations: > >> https://edit.php.net > >> > >> -Hannes > > > > > > I've seen the docs discussed on this list plenty of times. We do > maintain > > those as well as the code, after all. Unless you're proposing changing > the > > name of this list to *internal code developer mailinglist*, then I really > > don't think there's reason to get butthurt over it. > > I cannot say I have seen a single patch from you to the documentations. > And every subproject of PHP.net has its own list, in this case > php...@lists.php.net > > And yes. That is _exactly_ what this list is for; the internal code. > > This list gets crapload of weird spam, and there are very few people > from phpdoc@ that have the time to read all threads here to spot doc > discussions. > > Use the correct list. > > -Hannes > And how much spam was added by your whining about my spam, hmm? If you were so concerned about keeping traffic down, one would think you'd have sent a private email instead of complaining to the entire list. And yes, I have contributed to the man pages in the past. Not as frequently as I'd like, but this is part of my effort to improve on that record. Your hostility is hardly constructive in that regard. There are topics that can be appropriate for multiple lists. This is one of them. As I said, there is precedent for people discussing the website on this list and, unless I'm mistaken, there's no documented policy actually excluding internal development of the website from this list. But anyway, I've been criticized for letting myself get dragged into public pissing matches on this list before, so I'll bite my tongue and terminate the conversation here if there's nothing new to add. You've expressed your opinion and I've expressed mine; if you'd like to bicker with me some more, please send me a private email so everybody else doesn't have to read it. --Kris
Re: [PHP-DEV] 6.0 And Moving Forward
Kris, I'd love to break BC a lot and fix things, but it would seriously slow adoption. Fixing *bugs* has stopped people upgrading, imagine how they would react to non-bugs being changed. On Jul 18, 2012 7:21 PM, "Kris Craig" wrote: > > > On Wed, Jul 18, 2012 at 7:27 AM, Andrew Faulds wrote: > >> To avoid BC breaks we should try to avoid major syntax changes. > > > Again, why should we be worrying so much about BC breaks on a major > version increment? BC breakage is just a fact of life whenever a major > version of anything comes out. Because you can't have major improvements > without it, I would classify it as a necessary evil. > > Don't we have a deprecation policy already worked out for this sort of > thing? If we can throw an E_DEPRECATED, then do that; otherwise, I'd say > just make the change and document it very clearly. People are going to be > reluctant to switch to a new major version anyway; there are still a lo t > of people who use PHP 4. There's already an expectation that there will be > significant BC breaks. I think we're just shooting ourselves in the foot > if we keep trying to run away from that. It's either that or we let the > language stagnate indefinitely. > > If it's better, people will adopt. It'll just take time and convincing, > but that's also just something that comes with the territory I think. > > --Kris > >
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
On 07/18/2012 01:02 AM, Pierre Joye wrote: > hi, > > On Wed, Jul 18, 2012 at 9:35 AM, Stas Malyshev wrote: >> Hi! >> >>> See the other answers, clear APIs, no more argument mess, cleanness. >> >> Cleanness has nothing to do with pseudo-objects.You don't have to use >> -> to have clean APIs, and using -> doesn't automatically make your APIs >> clean. > > I really do not want to have a semantic discussion here. > > This syntax is sexy, allows us to clean our APIs, and is amazingly handy. This makes no sense to me either. How does it let us clean the APIs? Can you give an example? I have one: $a = -5; $b = "-5"; echo $a->abs(); // Outputs 5 echo $b->abs(); // should still output 5 What has been cleaned here over: echo abs($a); echo abs($b); other than being 2 characters longer to type? It's not like you can remove abs() from the string pseudo-object, so you are essentially just taking all the functions in the global namespace and attaching them as a method to every pseudo-object. Is that clean? I think there is something we can do around this, but an argument of "it is sexy and clean" needs to be backed up with some actual implementation details that make sense. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
hi, On Wed, Jul 18, 2012 at 7:50 PM, Ferenc Kovacs wrote: > Maybe we could introduce a new namespace for the new api instead of turning > the new api oop only (or using objects for groupping static stateless > functions into objects only to hint that they are working with the same > variable types). > > Combining this with the previously mentioned lets turn namespaces to first > class citizens and allowing exporting whole namespaces to the current scope > would make it possible to make the new api available in the global scope if > needed. > Ofc this still would be a huge task to rethink/reshape our current api. This falls almost exactly to what I would avoid to do, having same set of functions but with new names or signatures, under a separate namespace. 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] Docs: php.ini vs. parse_ini_file()
On Wed, Jul 18, 2012 at 7:26 PM, Kris Craig wrote: >> >> I don't understand why on earth your are mailing the PHP *internal >> developer mailinglist* with this matter? >> >> If you have any improvement suggestions for the documentations: >> https://edit.php.net >> >> -Hannes > > > I've seen the docs discussed on this list plenty of times. We do maintain > those as well as the code, after all. Unless you're proposing changing the > name of this list to *internal code developer mailinglist*, then I really > don't think there's reason to get butthurt over it. I cannot say I have seen a single patch from you to the documentations. And every subproject of PHP.net has its own list, in this case php...@lists.php.net And yes. That is _exactly_ what this list is for; the internal code. This list gets crapload of weird spam, and there are very few people from phpdoc@ that have the time to read all threads here to spot doc discussions. Use the correct list. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Docs: php.ini vs. parse_ini_file()
> > > I don't understand why on earth your are mailing the PHP *internal > developer mailinglist* with this matter? > > If you have any improvement suggestions for the documentations: > https://edit.php.net > > -Hannes > I've seen the docs discussed on this list plenty of times. We do maintain those as well as the code, after all. Unless you're proposing changing the name of this list to *internal *code* developer mailinglist*, then I really don't think there's reason to get butthurt over it. --Kris
Re: [PHP-DEV] 6.0 And Moving Forward
On Wed, Jul 18, 2012 at 7:27 AM, Andrew Faulds wrote: > To avoid BC breaks we should try to avoid major syntax changes. Again, why should we be worrying so much about BC breaks on a major version increment? BC breakage is just a fact of life whenever a major version of anything comes out. Because you can't have major improvements without it, I would classify it as a necessary evil. Don't we have a deprecation policy already worked out for this sort of thing? If we can throw an E_DEPRECATED, then do that; otherwise, I'd say just make the change and document it very clearly. People are going to be reluctant to switch to a new major version anyway; there are still a lo t of people who use PHP 4. There's already an expectation that there will be significant BC breaks. I think we're just shooting ourselves in the foot if we keep trying to run away from that. It's either that or we let the language stagnate indefinitely. If it's better, people will adopt. It'll just take time and convincing, but that's also just something that comes with the territory I think. --Kris
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
2012.07.18. 18:55, "Stas Malyshev" ezt írta: > > Hi! > > > Er, sorry, accidental capslock. This IS a new API. That was an example. > > I'm not saying just put -> everywhere, I'm saying we can keep array_* > > and add a new set of -> functions which are well-designed, consistent, etc. > > What "this"? So far I didn't see any single message discussing anything > about any API. All I see is discussing how we should have -> syntax > working on arrays and strings. IMO this is exactly the wrong place to > start, if your goal is to improve the API (if your goal is to have > "sexy" syntax, it's fine but then I do not see this goal as worthy). The > right place to start would be the API. > > -- > 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 > Maybe we could introduce a new namespace for the new api instead of turning the new api oop only (or using objects for groupping static stateless functions into objects only to hint that they are working with the same variable types). Combining this with the previously mentioned lets turn namespaces to first class citizens and allowing exporting whole namespaces to the current scope would make it possible to make the new api available in the global scope if needed. Ofc this still would be a huge task to rethink/reshape our current api.
Re: [PHP-DEV] [PATCH] pdo_odbc: fix pdo_odbc_error's use of SQLGetDiagRec()
On 07/18/2012 08:48 AM, Joe Orton wrote: The "state" parameter passed to SQLGetDiagRec() needs to be six bytes not 5; the attached patch fixes this, from Martin Osvald. Hi Joe, Is there any chance you can log this in https://bugs.php.net/ and/or submit a pull request at https://github.com/php/php-src ? 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] 6.0 And Moving Forward
It's possible, but we have to write too much code just to identify all possible overloads. If methods are overloaded by their signature, surely the PHP code will be more clean. Well, I'm just wondering if it is possible without start a war, I'm not sure how expensive it could be. On Wed, Jul 18, 2012 at 1:58 PM, Andrew Faulds wrote: > That would be cool, but couldn't you just detect argument types? > On Jul 18, 2012 5:55 PM, "Rafael Kassner" wrote: > >> I'm wondering if we could include method overloading. Will be pretty nice >> mixing it with scalar type hinting or scalar values as objects >> >> On Wed, Jul 18, 2012 at 11:27 AM, Andrew Faulds wrote: >> >>> To avoid BC breaks we should try to avoid major syntax changes. We could >>> make new applications "hide" legacy though, something like "use new;" >>> which >>> would remove deprecated and legacy functions from the global namespace. >>> On Jul 18, 2012 12:16 AM, "David Muir" wrote: >>> >>> > Took the words from my mouth. Removing legacy support is a terrible >>> idea >>> > for PHP6. It makes it impossible to write forwards compatible code that >>> > currently runs in PHP5. Even having it optional is a bad idea IMO >>> since it >>> > will fragment PHP hosting. Some will be able to run PHP6 only (no >>> legacy), >>> > some will be able to run PHP5+ but will still be marketed as PHP6. >>> Makes it >>> > that much harder to know if your code will run on a client's server. >>> > >>> > David >>> > >>> > On 18/07/12 00:04, Anthony Ferrara wrote: >>> > >>> >> I dislike this idea from the ground up. >>> >> >>> >> While I think having a legacy implementation is definitely worth >>> while, it >>> >> needs to be in core. So PHP6 would introduce the new syntax, and >>> include >>> >> the legacy functionality in as close to 100% backwards compatible way >>> as >>> >> possible. From there, we'd only remove the legacy functionality from >>> core >>> >> in 7 (which could be 4 or 5 years out). >>> >> >>> >> We don't want to be in the same situation with 6 that python was in >>> with >>> >> 3, >>> >> and perl was in 5. We want to encourage adoption. Having a PECL >>> extension >>> >> needed for adoption is not going to fly too well. But if we can add >>> the >>> >> new >>> >> functionality and give people an easy migration path, adoption will be >>> >> easier. It still may take years, but it will at least be fairly >>> smooth as >>> >> the majority of existing code will still work. Of course some BC >>> breaks >>> >> may >>> >> be necessary (a-la what happened with PHP5), but they should be fairly >>> >> localized and pretty easy to handle... And they should be justified >>> >> (breaking BC for the sake of it, as with these legacy functions, >>> would be >>> >> a >>> >> mistake)... >>> >> >>> >> My $0.02 at least. >>> >> >>> >> Anthony >>> >> >>> >> On Tue, Jul 17, 2012 at 9:41 AM, Andrew Faulds >> >> >wrote: >>> >> >>> >> This is an excellent idea. Full BC yet without legacy cruft. Old code >>> >>> runs >>> >>> on legacy support extensions, new code doesn't need it. >>> >>> On Jul 17, 2012 1:51 PM, "Leigh" wrote: >>> >>> >>> >>> Basically, the current function library is moved to the legacy >>> > namespace. The default setting is import the functions of the >>> legacy >>> > namespace into the root namespace for BC. But with that setting >>> > turned off all the existing functions go away to be replaced with a >>> > designed API, instead of a grown one, correcting the mistakes that >>> > have accumulated over the years. >>> > >>> Is there any reason why this cannot / should not be implemented as a >>> PHP 5 compatibility extension? >>> >>> I think those who never want to use it (PHP 6 purists) shouldn't >>> have >>> to have their binaries bloated by legacy code. It would also mean >>> that >>> the legacy implementation can be developed away from the new core, >>> and >>> not have any (negative) influence on it. >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >>> >>> >>> > >>> > >>> >> >> >> >> -- >> Atenciosamente, >> Rafael Kassner >> >> -- Atenciosamente, Rafael Kassner
Re: [PHP-DEV] 6.0 And Moving Forward
That would be cool, but couldn't you just detect argument types? On Jul 18, 2012 5:55 PM, "Rafael Kassner" wrote: > I'm wondering if we could include method overloading. Will be pretty nice > mixing it with scalar type hinting or scalar values as objects > > On Wed, Jul 18, 2012 at 11:27 AM, Andrew Faulds wrote: > >> To avoid BC breaks we should try to avoid major syntax changes. We could >> make new applications "hide" legacy though, something like "use new;" >> which >> would remove deprecated and legacy functions from the global namespace. >> On Jul 18, 2012 12:16 AM, "David Muir" wrote: >> >> > Took the words from my mouth. Removing legacy support is a terrible idea >> > for PHP6. It makes it impossible to write forwards compatible code that >> > currently runs in PHP5. Even having it optional is a bad idea IMO since >> it >> > will fragment PHP hosting. Some will be able to run PHP6 only (no >> legacy), >> > some will be able to run PHP5+ but will still be marketed as PHP6. >> Makes it >> > that much harder to know if your code will run on a client's server. >> > >> > David >> > >> > On 18/07/12 00:04, Anthony Ferrara wrote: >> > >> >> I dislike this idea from the ground up. >> >> >> >> While I think having a legacy implementation is definitely worth >> while, it >> >> needs to be in core. So PHP6 would introduce the new syntax, and >> include >> >> the legacy functionality in as close to 100% backwards compatible way >> as >> >> possible. From there, we'd only remove the legacy functionality from >> core >> >> in 7 (which could be 4 or 5 years out). >> >> >> >> We don't want to be in the same situation with 6 that python was in >> with >> >> 3, >> >> and perl was in 5. We want to encourage adoption. Having a PECL >> extension >> >> needed for adoption is not going to fly too well. But if we can add the >> >> new >> >> functionality and give people an easy migration path, adoption will be >> >> easier. It still may take years, but it will at least be fairly smooth >> as >> >> the majority of existing code will still work. Of course some BC breaks >> >> may >> >> be necessary (a-la what happened with PHP5), but they should be fairly >> >> localized and pretty easy to handle... And they should be justified >> >> (breaking BC for the sake of it, as with these legacy functions, would >> be >> >> a >> >> mistake)... >> >> >> >> My $0.02 at least. >> >> >> >> Anthony >> >> >> >> On Tue, Jul 17, 2012 at 9:41 AM, Andrew Faulds > >> >wrote: >> >> >> >> This is an excellent idea. Full BC yet without legacy cruft. Old code >> >>> runs >> >>> on legacy support extensions, new code doesn't need it. >> >>> On Jul 17, 2012 1:51 PM, "Leigh" wrote: >> >>> >> >>> Basically, the current function library is moved to the legacy >> > namespace. The default setting is import the functions of the >> legacy >> > namespace into the root namespace for BC. But with that setting >> > turned off all the existing functions go away to be replaced with a >> > designed API, instead of a grown one, correcting the mistakes that >> > have accumulated over the years. >> > >> Is there any reason why this cannot / should not be implemented as a >> PHP 5 compatibility extension? >> >> I think those who never want to use it (PHP 6 purists) shouldn't have >> to have their binaries bloated by legacy code. It would also mean >> that >> the legacy implementation can be developed away from the new core, >> and >> not have any (negative) influence on it. >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> >> >> > >> > >> > > > > -- > Atenciosamente, > Rafael Kassner > >
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
Obviously. This is simply the means to provide the new API without breaking BC. If people think this is acceptable then sure, let's plan an API. On Jul 18, 2012 5:54 PM, "Stas Malyshev" wrote: > Hi! > > > Er, sorry, accidental capslock. This IS a new API. That was an example. > > I'm not saying just put -> everywhere, I'm saying we can keep array_* > > and add a new set of -> functions which are well-designed, consistent, > etc. > > What "this"? So far I didn't see any single message discussing anything > about any API. All I see is discussing how we should have -> syntax > working on arrays and strings. IMO this is exactly the wrong place to > start, if your goal is to improve the API (if your goal is to have > "sexy" syntax, it's fine but then I do not see this goal as worthy). The > right place to start would be the API. > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 >
Re: [PHP-DEV] 6.0 And Moving Forward
I'm wondering if we could include method overloading. Will be pretty nice mixing it with scalar type hinting or scalar values as objects On Wed, Jul 18, 2012 at 11:27 AM, Andrew Faulds wrote: > To avoid BC breaks we should try to avoid major syntax changes. We could > make new applications "hide" legacy though, something like "use new;" which > would remove deprecated and legacy functions from the global namespace. > On Jul 18, 2012 12:16 AM, "David Muir" wrote: > > > Took the words from my mouth. Removing legacy support is a terrible idea > > for PHP6. It makes it impossible to write forwards compatible code that > > currently runs in PHP5. Even having it optional is a bad idea IMO since > it > > will fragment PHP hosting. Some will be able to run PHP6 only (no > legacy), > > some will be able to run PHP5+ but will still be marketed as PHP6. Makes > it > > that much harder to know if your code will run on a client's server. > > > > David > > > > On 18/07/12 00:04, Anthony Ferrara wrote: > > > >> I dislike this idea from the ground up. > >> > >> While I think having a legacy implementation is definitely worth while, > it > >> needs to be in core. So PHP6 would introduce the new syntax, and include > >> the legacy functionality in as close to 100% backwards compatible way as > >> possible. From there, we'd only remove the legacy functionality from > core > >> in 7 (which could be 4 or 5 years out). > >> > >> We don't want to be in the same situation with 6 that python was in with > >> 3, > >> and perl was in 5. We want to encourage adoption. Having a PECL > extension > >> needed for adoption is not going to fly too well. But if we can add the > >> new > >> functionality and give people an easy migration path, adoption will be > >> easier. It still may take years, but it will at least be fairly smooth > as > >> the majority of existing code will still work. Of course some BC breaks > >> may > >> be necessary (a-la what happened with PHP5), but they should be fairly > >> localized and pretty easy to handle... And they should be justified > >> (breaking BC for the sake of it, as with these legacy functions, would > be > >> a > >> mistake)... > >> > >> My $0.02 at least. > >> > >> Anthony > >> > >> On Tue, Jul 17, 2012 at 9:41 AM, Andrew Faulds >> >wrote: > >> > >> This is an excellent idea. Full BC yet without legacy cruft. Old code > >>> runs > >>> on legacy support extensions, new code doesn't need it. > >>> On Jul 17, 2012 1:51 PM, "Leigh" wrote: > >>> > >>> Basically, the current function library is moved to the legacy > > namespace. The default setting is import the functions of the legacy > > namespace into the root namespace for BC. But with that setting > > turned off all the existing functions go away to be replaced with a > > designed API, instead of a grown one, correcting the mistakes that > > have accumulated over the years. > > > Is there any reason why this cannot / should not be implemented as a > PHP 5 compatibility extension? > > I think those who never want to use it (PHP 6 purists) shouldn't have > to have their binaries bloated by legacy code. It would also mean that > the legacy implementation can be developed away from the new core, and > not have any (negative) influence on it. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > -- Atenciosamente, Rafael Kassner
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
Hi! > Er, sorry, accidental capslock. This IS a new API. That was an example. > I'm not saying just put -> everywhere, I'm saying we can keep array_* > and add a new set of -> functions which are well-designed, consistent, etc. What "this"? So far I didn't see any single message discussing anything about any API. All I see is discussing how we should have -> syntax working on arrays and strings. IMO this is exactly the wrong place to start, if your goal is to improve the API (if your goal is to have "sexy" syntax, it's fine but then I do not see this goal as worthy). The right place to start would be the API. -- 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] Pseudo-objects (methods on arrays, strings, etc.)
WHAT? Er, sorry, accidental capslock. This IS a new API. That was an example. I'm not saying just put -> everywhere, I'm saying we can keep array_* and add a new set of -> functions which are well-designed, consistent, etc. On Jul 18, 2012 5:35 PM, "Stas Malyshev" wrote: > Hi! > > > enough but I don't know the Zend engine well enough). This way we can > > have array->key, array->sort(TYPE), etc. for new code to use, instead of > > the legacy array and string method mess (the latter needs a cleanup more > > in particular). > > The mess does not exist because we have array_key() instead of > array->key(). There's nothing wrong with having array_key(). The mess > exists because functions do not form single API with single principle > behind it, but were added in ad-hoc manner, sometimes without > correlating them with others. So, if you want to clean it up, you'd want > to write a plan how new API would look like and how it will be better > than old one. If the solution is "let's use ->" then it's not worth it. > The solution that's worth it is "let's have this better API" and that's > where we should start, not with changing array_key() to array->key() and > saying "now we have clean sexy API". > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 >
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
hi Stas, On Wed, Jul 18, 2012 at 6:35 PM, Stas Malyshev wrote: > Hi! > >> enough but I don't know the Zend engine well enough). This way we can >> have array->key, array->sort(TYPE), etc. for new code to use, instead of >> the legacy array and string method mess (the latter needs a cleanup more >> in particular). > > The mess does not exist because we have array_key() instead of > array->key(). There's nothing wrong with having array_key(). The mess > exists because functions do not form single API with single principle > behind it, but were added in ad-hoc manner, sometimes without > correlating them with others. So, if you want to clean it up, you'd want > to write a plan how new API would look like and how it will be better > than old one. If the solution is "let's use ->" then it's not worth it. > The solution that's worth it is "let's have this better API" and that's > where we should start, not with changing array_key() to array->key() and > saying "now we have clean sexy API". > Please let me refresh the psat years history of PHP releases. Any attempt to change any kind of function signatures in the core has been rejected for obvious reasons (BC breaks, useless code changes, etc. etc.). So I won't spend a single second to try to propose to rewamp or duplicate functions for the sake of making the signature more consistent with each other, or cleaner. On the hand, this solution allows that, right away, without BC breaks and brings us to the (very) long term goal (actual object for standard types, like in other languages). Now you can totally disregard the benefit of this (purely vaporware right now) solution, but to keep saying that this argument is pointless is not going to bring us any step further, really not. 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] Docs: php.ini vs. parse_ini_file()
On Wed, Jul 18, 2012 at 1:19 AM, Kris Craig wrote: > I just noticed something that I hadn't really thought about before. I > couldn't remember the name of the function for parsing INI files so I did a > quick search. It took me straight to the page for php.ini directives. I > had to select "online documentation" from the dropdown and try again, this > time navigating down to the third result. > > Not overly cumbersome, of course, but I started thinking that maybe this > could be more difficult for someone who might be newer to PHP. I also > tried a Google search for 'php ini' (no quotes) to see what I'd get, and > the first 15 results (all of the first page and the top half of the second) > were for php.ini stuff. The 16th result was finally the parse_ini_file() > function. A lot of newbies in particular use Google as their first stop > when trying to find PHP functions for doing stuff, so this could give some > people the impression that PHP doesn't even have an INI parsing function. > > > Of course, most of this we really have no control over, but I would like to > propose adding a link to parse_ini_file() on the php.ini man pages (perhaps > something along the lines of, "Are you looking for?"). I can make the > edits myself but I'd like to see what y'all think first. > I don't understand why on earth your are mailing the PHP *internal developer mailinglist* with this matter? If you have any improvement suggestions for the documentations: https://edit.php.net -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Docs: php.ini vs. parse_ini_file()
On Wed, Jul 18, 2012 at 1:19 AM, Kris Craig wrote: > I just noticed something that I hadn't really thought about before. I > couldn't remember the name of the function for parsing INI files so I did a > quick search. It took me straight to the page for php.ini directives. I > had to select "online documentation" from the dropdown and try again, this > time navigating down to the third result. > > Not overly cumbersome, of course, but I started thinking that maybe this > could be more difficult for someone who might be newer to PHP. I also > tried a Google search for 'php ini' (no quotes) to see what I'd get, and > the first 15 results (all of the first page and the top half of the second) > were for php.ini stuff. The 16th result was finally the parse_ini_file() > function. A lot of newbies in particular use Google as their first stop > when trying to find PHP functions for doing stuff, so this could give some > people the impression that PHP doesn't even have an INI parsing function. > > > Of course, most of this we really have no control over, but I would like to > propose adding a link to parse_ini_file() on the php.ini man pages (perhaps > something along the lines of, "Are you looking for?"). I can make the > edits myself but I'd like to see what y'all think first. > I don't understand why on earth your are mailing the PHP *internal developer mailinglist* with this matter? If you have any improvement suggestions for the documentations: https://edit.php.net -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
Hi! > enough but I don't know the Zend engine well enough). This way we can > have array->key, array->sort(TYPE), etc. for new code to use, instead of > the legacy array and string method mess (the latter needs a cleanup more > in particular). The mess does not exist because we have array_key() instead of array->key(). There's nothing wrong with having array_key(). The mess exists because functions do not form single API with single principle behind it, but were added in ad-hoc manner, sometimes without correlating them with others. So, if you want to clean it up, you'd want to write a plan how new API would look like and how it will be better than old one. If the solution is "let's use ->" then it's not worth it. The solution that's worth it is "let's have this better API" and that's where we should start, not with changing array_key() to array->key() and saying "now we have clean sexy API". -- 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] [PATCH] pdo_odbc: fix pdo_odbc_error's use of SQLGetDiagRec()
The "state" parameter passed to SQLGetDiagRec() needs to be six bytes
not 5; the attached patch fixes this, from Martin Osvald.
diff --git a/ext/pdo_odbc/odbc_driver.c b/ext/pdo_odbc/odbc_driver.c
index 84a147b..ca2808c 100755
--- a/ext/pdo_odbc/odbc_driver.c
+++ b/ext/pdo_odbc/odbc_driver.c
@@ -114,7 +114,7 @@ void pdo_odbc_error(pdo_dbh_t *dbh, pdo_stmt_t *stmt,
PDO_ODBC_HSTMT statement,
* diagnostic records (which can be generated by PRINT statements
* in the query, for instance). */
while (rc == SQL_SUCCESS || rc == SQL_SUCCESS_WITH_INFO) {
- char discard_state[5];
+ char discard_state[6];
char discard_buf[1024];
SQLINTEGER code;
rc = SQLGetDiagRec(htype, eh, recno++, discard_state, &code,
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
It would probably be passed as first param to functions, or passed as $this, like other methods. On Jul 18, 2012 4:27 PM, "Amaury Bouchard" wrote: > Seems a lot like another syntactic sugar. > > Like in Lua, where you can write >obj:method(12) > instead of >obj.method(obj, 12) > > But OOP-like syntax on non-object data is still weird. The question about > data manipulation behavior (is it a pointer like other objects or is it a > scalar like existing array?) is a tough one. > > > 2012/7/18 Andrew Faulds > >> OK, ok. Let me clear some things up here. >> >> We don't want it to make things more object-oriented or whatever. The real >> motivation is to give us a chance to make a much cleaner, much nicer array >> API without breaking BC. We can keep the legacy array_* and unprefixed >> functions, but we can also create "pseudo-object methods" (not objects, >> but >> methods and possibly properties hooked into the method call processing, >> checking for non-object types - it's very easy to check (I've done it) for >> non-objects, and implementing this seems simple enough but I don't know >> the >> Zend engine well enough). This way we can have array->key, >> array->sort(TYPE), etc. for new code to use, instead of the legacy array >> and string method mess (the latter needs a cleanup more in particular). >> >> OK? >> On Jul 18, 2012 10:14 AM, "Pierre Joye" wrote: >> >> > hi, >> > >> > On Wed, Jul 18, 2012 at 10:13 AM, Stas Malyshev > > >> > wrote: >> > >> > > And no, it does not "allow us to clean our APIs" - I again point out >> > > using -> has nothing to do with cleaning APIs. Repeating "clean APIs" >> > > as if it is some magic spell will not make false statement true, and >> the >> > > statement that using -> somehow cleans up APIs is false. Cleaning APIs >> > > and pseudo-objects are two completely different things, and nobody yet >> > > shown any relationship between the two. >> > >> > You do not see it, your call. But it indeed does and anyone I was >> > talking to about this topic agrees with this view but two persons (you >> > incl.). >> > >> > Anyway, it is somehow pointless to argue to death about that as it is >> > technically not possible yet. I'm 200% sure it will happen. >> > >> > 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] Pseudo-objects (methods on arrays, strings, etc.)
Seems a lot like another syntactic sugar. Like in Lua, where you can write obj:method(12) instead of obj.method(obj, 12) But OOP-like syntax on non-object data is still weird. The question about data manipulation behavior (is it a pointer like other objects or is it a scalar like existing array?) is a tough one. 2012/7/18 Andrew Faulds > OK, ok. Let me clear some things up here. > > We don't want it to make things more object-oriented or whatever. The real > motivation is to give us a chance to make a much cleaner, much nicer array > API without breaking BC. We can keep the legacy array_* and unprefixed > functions, but we can also create "pseudo-object methods" (not objects, but > methods and possibly properties hooked into the method call processing, > checking for non-object types - it's very easy to check (I've done it) for > non-objects, and implementing this seems simple enough but I don't know the > Zend engine well enough). This way we can have array->key, > array->sort(TYPE), etc. for new code to use, instead of the legacy array > and string method mess (the latter needs a cleanup more in particular). > > OK? > On Jul 18, 2012 10:14 AM, "Pierre Joye" wrote: > > > hi, > > > > On Wed, Jul 18, 2012 at 10:13 AM, Stas Malyshev > > wrote: > > > > > And no, it does not "allow us to clean our APIs" - I again point out > > > using -> has nothing to do with cleaning APIs. Repeating "clean APIs" > > > as if it is some magic spell will not make false statement true, and > the > > > statement that using -> somehow cleans up APIs is false. Cleaning APIs > > > and pseudo-objects are two completely different things, and nobody yet > > > shown any relationship between the two. > > > > You do not see it, your call. But it indeed does and anyone I was > > talking to about this topic agrees with this view but two persons (you > > incl.). > > > > Anyway, it is somehow pointless to argue to death about that as it is > > technically not possible yet. I'm 200% sure it will happen. > > > > 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] Call for voting: [RFC] Allow use T_AS in closure use statement
On Wed, Jul 18, 2012 at 11:19 PM, Leigh wrote: > I missed the discussion on this one, the RFC examples are very simple. Does > it support aliasing array indices? > > For example: (use $matches[0] as $name) sorry, no, it's only support literal variable for now. thanks > > On Jul 18, 2012 3:55 PM, "Laruence" wrote: >> >> Hi: >> Call for voting for "Allow use T_AS in closure use statement", >> https://wiki.php.net/rfc/useas#voting >> >> any comment will be appreciated. >> >> thanks >> >> -- >> Laruence Xinchen Hui >> http://www.laruence.com/ >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> > -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call for voting: [RFC] Allow use T_AS in closure use statement
I missed the discussion on this one, the RFC examples are very simple. Does it support aliasing array indices? For example: (use $matches[0] as $name) On Jul 18, 2012 3:55 PM, "Laruence" wrote: > Hi: > Call for voting for "Allow use T_AS in closure use statement", > https://wiki.php.net/rfc/useas#voting > > any comment will be appreciated. > > thanks > > -- > Laruence Xinchen Hui > http://www.laruence.com/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
[PHP-DEV] Re: [RFC] foreach_variable supporting T_LIST
On Wed, Jul 18, 2012 at 10:49 PM, Laruence wrote:
> Hi:
> this is not a new RFC, I proposed it before, but due to my poor
> english and improper examples, it didn't get passed.
thanks phidev's good english, he re-wrote the descriptions.
thanks
>
> This feature introduces list() support in foreach constructs(more
> info can be found here: https://wiki.php.net/rfc/foreachlist):
>
> $users = array(
> array('Foo', 'Bar'),
> array('Baz', 'Qux');
> );
>
> // Before
> foreach ($users as $user) {
> list($firstName, $lastName) = $user;
> echo "First name: $firstName, last name: $lastName. ";
> }
>
> // After
> foreach ($users as list($firstName, $lastName)) {
> echo "First name: $firstName, last name: $lastName. ";
> }
> ?>
>
> what do you think? personally, I really think it's a good feature.
>
> what about commit this into trunk(php 5.5) ?
>
> thanks
>
> --
> Laruence Xinchen Hui
> http://www.laruence.com/
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Call for voting: [RFC] Allow use T_AS in closure use statement
Hi: Call for voting for "Allow use T_AS in closure use statement", https://wiki.php.net/rfc/useas#voting any comment will be appreciated. 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] [RFC] foreach_variable supporting T_LIST
Sounds great. Python has something similar for tuples, would be good if PHP
had this.
Are there any BC concerns? Don't see why this could break something.
On Jul 18, 2012 3:50 PM, "Laruence" wrote:
> Hi:
> this is not a new RFC, I proposed it before, but due to my poor
> english and improper examples, it didn't get passed.
>
> This feature introduces list() support in foreach constructs(more
> info can be found here: https://wiki.php.net/rfc/foreachlist):
>
> $users = array(
> array('Foo', 'Bar'),
> array('Baz', 'Qux');
> );
>
> // Before
> foreach ($users as $user) {
> list($firstName, $lastName) = $user;
> echo "First name: $firstName, last name: $lastName. ";
> }
>
> // After
> foreach ($users as list($firstName, $lastName)) {
> echo "First name: $firstName, last name: $lastName. ";
> }
> ?>
>
> what do you think? personally, I really think it's a good feature.
>
> what about commit this into trunk(php 5.5) ?
>
> thanks
>
> --
> Laruence Xinchen Hui
> http://www.laruence.com/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
[PHP-DEV] [RFC] foreach_variable supporting T_LIST
Hi: this is not a new RFC, I proposed it before, but due to my poor english and improper examples, it didn't get passed. This feature introduces list() support in foreach constructs(more info can be found here: https://wiki.php.net/rfc/foreachlist): what do you think? personally, I really think it's a good feature. what about commit this into trunk(php 5.5) ? 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] Implicit isset in ternary operator
Sounds good. CoffeeScript (a lightweight language with JS semantics that compiles to JS) has a existential operator, "?", and this looks similar and would be very nice. It's not the same thing, of course. It also reminds me of JavaScript's || behaviour. On Jul 18, 2012 3:24 PM, "Rafael Dohms" wrote: > On Wed, Jul 18, 2012 at 4:20 PM, Anthony Ferrara >wrote: > > > > > Does this seem like a possible improvement we can work on? Anyone > >> interested in championing the change? > >> > > > > I like it in principle. My only concern is *why* wasn't it done this way > > in the first place... Is there a reason? > > > > > I don't recall correctly, there was a thread on this by David Coalier some > time ago, but it went completely off course and i remember BC breaks were > part of the reason. I think we have a good plan for BC breaks now, so why > not rethink this. > > > > Anthony > > > > > > > -- > Rafael Dohms > PHP Evangelist and Community Leader > http://www.rafaeldohms.com.br > http://www.phpsp.org.br >
Re: [PHP-DEV] Implicit isset in ternary operator
On Wed, 18 Jul 2012 16:15:44 +0200, Rafael Dohms wrote: With the syntax improvements for 5.4 and some of the de-referencing work, code looks so much sleeker then before, but there is still one use case that really bugs me. Given this code: $width = (isset($config['width']))? $config['width'] : 300; Do we have to do this again?... We had this discussion an year ago. See http://grokbase.com/t/php/php-internals/113zbx5y77/implicit-isset-isempty-check-on-short-ternary-operator http://grokbase.com/t/php/php-internals/114br1w6gs/proposed-access-modifier-silent-was-re-php-dev-implicit-isset-isempty-check-on-short-ternary-operator -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
OK, ok. Let me clear some things up here. We don't want it to make things more object-oriented or whatever. The real motivation is to give us a chance to make a much cleaner, much nicer array API without breaking BC. We can keep the legacy array_* and unprefixed functions, but we can also create "pseudo-object methods" (not objects, but methods and possibly properties hooked into the method call processing, checking for non-object types - it's very easy to check (I've done it) for non-objects, and implementing this seems simple enough but I don't know the Zend engine well enough). This way we can have array->key, array->sort(TYPE), etc. for new code to use, instead of the legacy array and string method mess (the latter needs a cleanup more in particular). OK? On Jul 18, 2012 10:14 AM, "Pierre Joye" wrote: > hi, > > On Wed, Jul 18, 2012 at 10:13 AM, Stas Malyshev > wrote: > > > And no, it does not "allow us to clean our APIs" - I again point out > > using -> has nothing to do with cleaning APIs. Repeating "clean APIs" > > as if it is some magic spell will not make false statement true, and the > > statement that using -> somehow cleans up APIs is false. Cleaning APIs > > and pseudo-objects are two completely different things, and nobody yet > > shown any relationship between the two. > > You do not see it, your call. But it indeed does and anyone I was > talking to about this topic agrees with this view but two persons (you > incl.). > > Anyway, it is somehow pointless to argue to death about that as it is > technically not possible yet. I'm 200% sure it will happen. > > 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] Docs: php.ini vs. parse_ini_file()
Sounds good, search engines aren't always super smart. On Jul 18, 2012 1:20 AM, "Kris Craig" wrote: > I just noticed something that I hadn't really thought about before. I > couldn't remember the name of the function for parsing INI files so I did a > quick search. It took me straight to the page for php.ini directives. I > had to select "online documentation" from the dropdown and try again, this > time navigating down to the third result. > > Not overly cumbersome, of course, but I started thinking that maybe this > could be more difficult for someone who might be newer to PHP. I also > tried a Google search for 'php ini' (no quotes) to see what I'd get, and > the first 15 results (all of the first page and the top half of the second) > were for php.ini stuff. The 16th result was finally the parse_ini_file() > function. A lot of newbies in particular use Google as their first stop > when trying to find PHP functions for doing stuff, so this could give some > people the impression that PHP doesn't even have an INI parsing function. > > > Of course, most of this we really have no control over, but I would like to > propose adding a link to parse_ini_file() on the php.ini man pages (perhaps > something along the lines of, "Are you looking for?"). I can make the > edits myself but I'd like to see what y'all think first. > > --Kris >
Re: [PHP-DEV] 6.0 And Moving Forward
To avoid BC breaks we should try to avoid major syntax changes. We could make new applications "hide" legacy though, something like "use new;" which would remove deprecated and legacy functions from the global namespace. On Jul 18, 2012 12:16 AM, "David Muir" wrote: > Took the words from my mouth. Removing legacy support is a terrible idea > for PHP6. It makes it impossible to write forwards compatible code that > currently runs in PHP5. Even having it optional is a bad idea IMO since it > will fragment PHP hosting. Some will be able to run PHP6 only (no legacy), > some will be able to run PHP5+ but will still be marketed as PHP6. Makes it > that much harder to know if your code will run on a client's server. > > David > > On 18/07/12 00:04, Anthony Ferrara wrote: > >> I dislike this idea from the ground up. >> >> While I think having a legacy implementation is definitely worth while, it >> needs to be in core. So PHP6 would introduce the new syntax, and include >> the legacy functionality in as close to 100% backwards compatible way as >> possible. From there, we'd only remove the legacy functionality from core >> in 7 (which could be 4 or 5 years out). >> >> We don't want to be in the same situation with 6 that python was in with >> 3, >> and perl was in 5. We want to encourage adoption. Having a PECL extension >> needed for adoption is not going to fly too well. But if we can add the >> new >> functionality and give people an easy migration path, adoption will be >> easier. It still may take years, but it will at least be fairly smooth as >> the majority of existing code will still work. Of course some BC breaks >> may >> be necessary (a-la what happened with PHP5), but they should be fairly >> localized and pretty easy to handle... And they should be justified >> (breaking BC for the sake of it, as with these legacy functions, would be >> a >> mistake)... >> >> My $0.02 at least. >> >> Anthony >> >> On Tue, Jul 17, 2012 at 9:41 AM, Andrew Faulds > >wrote: >> >> This is an excellent idea. Full BC yet without legacy cruft. Old code >>> runs >>> on legacy support extensions, new code doesn't need it. >>> On Jul 17, 2012 1:51 PM, "Leigh" wrote: >>> >>> Basically, the current function library is moved to the legacy > namespace. The default setting is import the functions of the legacy > namespace into the root namespace for BC. But with that setting > turned off all the existing functions go away to be replaced with a > designed API, instead of a grown one, correcting the mistakes that > have accumulated over the years. > Is there any reason why this cannot / should not be implemented as a PHP 5 compatibility extension? I think those who never want to use it (PHP 6 purists) shouldn't have to have their binaries bloated by legacy code. It would also mean that the legacy implementation can be developed away from the new core, and not have any (negative) influence on it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] Implicit isset in ternary operator
On Wed, Jul 18, 2012 at 4:20 PM, Anthony Ferrara wrote: > > Does this seem like a possible improvement we can work on? Anyone >> interested in championing the change? >> > > I like it in principle. My only concern is *why* wasn't it done this way > in the first place... Is there a reason? > > I don't recall correctly, there was a thread on this by David Coalier some time ago, but it went completely off course and i remember BC breaks were part of the reason. I think we have a good plan for BC breaks now, so why not rethink this. > Anthony > > -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br
Re: [PHP-DEV] Implicit isset in ternary operator
Rafael, One point of clarity: On Wed, Jul 18, 2012 at 10:15 AM, Rafael Dohms wrote: > Hey Everyone, > > With the syntax improvements for 5.4 and some of the de-referencing work, > code looks so much sleeker then before, but there is still one use case > that really bugs me. > > Given this code: > > $width = (isset($config['width']))? $config['width'] : 300; > > The code is pretty straight forward, if width is set in the array, use it > otherwise use 300. > > This code would look much better if it could make use of the ternary > operator > > $width = $config['width'] ?: 300; > > The only reason for this to not work is: it throws a notice if the array > key is not there (which is the case we are covering anyway) > > This is basically because the ternary operator does not do a internal > implicit isset, only an empty. > It does not do an empty. Empty would avoid notices as well. All it does is an implicit bool cast... > Does this seem like a possible improvement we can work on? Anyone > interested in championing the change? > I like it in principle. My only concern is *why* wasn't it done this way in the first place... Is there a reason? Anthony
[PHP-DEV] Implicit isset in ternary operator
Hey Everyone, With the syntax improvements for 5.4 and some of the de-referencing work, code looks so much sleeker then before, but there is still one use case that really bugs me. Given this code: $width = (isset($config['width']))? $config['width'] : 300; The code is pretty straight forward, if width is set in the array, use it otherwise use 300. This code would look much better if it could make use of the ternary operator $width = $config['width'] ?: 300; The only reason for this to not work is: it throws a notice if the array key is not there (which is the case we are covering anyway) This is basically because the ternary operator does not do a internal implicit isset, only an empty. Does this seem like a possible improvement we can work on? Anyone interested in championing the change? -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br
Re: [PHP-DEV] 6.0 And Moving Forward
For a new version to be successful from a marketing perspective, there has to be such a thing as "good old code." Just as there are PHP 4 apps that are basically sound and maintainable code and require only a few reasonable changes to run well in PHP 5, that needs to be true for the transition to 5 to 6. Otherwise it just won't be accepted as "PHP" by most people. "If I have to start from scratch, I guess I'll just use Ruby" would be a very reasonable response (: I do like the idea of pseudo-objects with methods as a way to create much cleaner APIs for strings and arrays, but the legacy APIs need to stick around. On Tue, Jul 17, 2012 at 7:16 PM, David Muir wrote: > Took the words from my mouth. Removing legacy support is a terrible idea for > PHP6. It makes it impossible to write forwards compatible code that > currently runs in PHP5. Even having it optional is a bad idea IMO since it > will fragment PHP hosting. Some will be able to run PHP6 only (no legacy), > some will be able to run PHP5+ but will still be marketed as PHP6. Makes it > that much harder to know if your code will run on a client's server. > > David > > On 18/07/12 00:04, Anthony Ferrara wrote: >> >> I dislike this idea from the ground up. >> >> >> While I think having a legacy implementation is definitely worth while, it >> needs to be in core. So PHP6 would introduce the new syntax, and include >> the legacy functionality in as close to 100% backwards compatible way as >> possible. From there, we'd only remove the legacy functionality from core >> in 7 (which could be 4 or 5 years out). >> >> We don't want to be in the same situation with 6 that python was in with >> 3, >> and perl was in 5. We want to encourage adoption. Having a PECL extension >> needed for adoption is not going to fly too well. But if we can add the >> new >> functionality and give people an easy migration path, adoption will be >> easier. It still may take years, but it will at least be fairly smooth as >> the majority of existing code will still work. Of course some BC breaks >> may >> be necessary (a-la what happened with PHP5), but they should be fairly >> localized and pretty easy to handle... And they should be justified >> (breaking BC for the sake of it, as with these legacy functions, would be >> a >> mistake)... >> >> My $0.02 at least. >> >> Anthony >> >> On Tue, Jul 17, 2012 at 9:41 AM, Andrew Faulds >> wrote: >> >>> This is an excellent idea. Full BC yet without legacy cruft. Old code >>> runs >>> on legacy support extensions, new code doesn't need it. >>> On Jul 17, 2012 1:51 PM, "Leigh" wrote: >>> > Basically, the current function library is moved to the legacy > namespace. The default setting is import the functions of the legacy > namespace into the root namespace for BC. But with that setting > turned off all the existing functions go away to be replaced with a > designed API, instead of a grown one, correcting the mistakes that > have accumulated over the years. Is there any reason why this cannot / should not be implemented as a PHP 5 compatibility extension? I think those who never want to use it (PHP 6 purists) shouldn't have to have their binaries bloated by legacy code. It would also mean that the legacy implementation can be developed away from the new core, and not have any (negative) influence on it. -- 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 > -- 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] Pseudo-objects (methods on arrays, strings, etc.)
hi, On Wed, Jul 18, 2012 at 11:24 AM, Lester Caine wrote: > Please can we keep a 'legacy' version of PHP stable at some point in time > ... And let SonofPHP be forked off if that is what people want. Totally off topic, and as stated earlier, this solution does not break any existing functions or features. -- 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] Pseudo-objects (methods on arrays, strings, etc.)
Stas Malyshev wrote: I really do not want to have a semantic discussion here. > >This syntax is sexy, allows us to clean our APIs, and is amazingly handy. I'm sorry, but I can't understand how we can seriously consider making object call syntax mean two entirely different things, create pseudo-objects that look like objects in some situations, but not other situation and generally make a huge mess out of whole object model - because "-> is sexy". Is this really a level we want to have in the discussion? And no, it does not "allow us to clean our APIs" - I again point out using -> has nothing to do with cleaning APIs. Repeating "clean APIs" as if it is some magic spell will not make false statement true, and the statement that using -> somehow cleans up APIs is false. Cleaning APIs and pseudo-objects are two completely different things, and nobody yet shown any relationship between the two. >The reasons why it is not yet implemented have been listed here, only >a matter of time:) IMHO the reason it's not implemented is because it makes very little sense, and only reason I've seen so far to do it is "because it's sexy". Come on. Seconded ... ArrayObject class is available if you want the 'sexy' way of doing things but that adds nothing of use to the debate? My suggestion that the same is done for mbstring seems to have fallen on deaf ears, but both of these would answer some of the requests without affecting the core? The current debate seems to be one of 'php is crap lets rewrite all of it', but how much of the worlds online infrastructure is currently running using PHP and in a lot of cases PHP4? We have compiled forks with different syntaxes if people want to go that way, and yes we can stay with old versions, but we need reliable security maintenance on some legacy base. Please can we keep a 'legacy' version of PHP stable at some point in time ... And let SonofPHP be forked off if that is what people want. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
hi, On Wed, Jul 18, 2012 at 10:13 AM, Stas Malyshev wrote: > And no, it does not "allow us to clean our APIs" - I again point out > using -> has nothing to do with cleaning APIs. Repeating "clean APIs" > as if it is some magic spell will not make false statement true, and the > statement that using -> somehow cleans up APIs is false. Cleaning APIs > and pseudo-objects are two completely different things, and nobody yet > shown any relationship between the two. You do not see it, your call. But it indeed does and anyone I was talking to about this topic agrees with this view but two persons (you incl.). Anyway, it is somehow pointless to argue to death about that as it is technically not possible yet. I'm 200% sure it will happen. 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] Pseudo-objects (methods on arrays, strings, etc.)
Hi! > I really do not want to have a semantic discussion here. > > This syntax is sexy, allows us to clean our APIs, and is amazingly handy. I'm sorry, but I can't understand how we can seriously consider making object call syntax mean two entirely different things, create pseudo-objects that look like objects in some situations, but not other situation and generally make a huge mess out of whole object model - because "-> is sexy". Is this really a level we want to have in the discussion? And no, it does not "allow us to clean our APIs" - I again point out using -> has nothing to do with cleaning APIs. Repeating "clean APIs" as if it is some magic spell will not make false statement true, and the statement that using -> somehow cleans up APIs is false. Cleaning APIs and pseudo-objects are two completely different things, and nobody yet shown any relationship between the two. > The reasons why it is not yet implemented have been listed here, only > a matter of time :) IMHO the reason it's not implemented is because it makes very little sense, and only reason I've seen so far to do it is "because it's sexy". Come on. -- 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] Pseudo-objects (methods on arrays, strings, etc.)
hi, On Wed, Jul 18, 2012 at 9:35 AM, Stas Malyshev wrote: > Hi! > >> See the other answers, clear APIs, no more argument mess, cleanness. > > Cleanness has nothing to do with pseudo-objects.You don't have to use > -> to have clean APIs, and using -> doesn't automatically make your APIs > clean. I really do not want to have a semantic discussion here. This syntax is sexy, allows us to clean our APIs, and is amazingly handy. The reasons why it is not yet implemented have been listed here, only a matter of time :) 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] Pseudo-objects (methods on arrays, strings, etc.)
Hi! > See the other answers, clear APIs, no more argument mess, cleanness. Cleanness has nothing to do with pseudo-objects. You don't have to use -> to have clean APIs, and using -> doesn't automatically make your APIs clean. Using -> has absolutely nothing to do with API cleanness and arguments, so I don't understand how it's an argument for pseudo-objects. -- 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] Pseudo-objects (methods on arrays, strings, etc.)
hi! On Tue, Jul 17, 2012 at 10:30 PM, Stas Malyshev wrote: > Hi! > >> Having pure object would be not efficient enough and brings its lot of >> caveats. Also it is important to keep in mind that this idea does not >> apply only to array but to other types as well. > > Same for other types. Just adding -> doesn't make the code > object-oriented. Not the point. > And just bolting -> on top of regular function calls > because it looks prettier seems meaningless to me. OK, we could make > $foo->bar() mean bar($foo) - python already has pretty much the same > idea, after all - but what's the point in it? I don't see any that would > be worth the effort. See the other answers, clear APIs, no more argument mess, cleanness. Those are pretty good selling points and without any kind of BC. 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] Bug 55544
Hi, comments inline. Am 17.07.2012 18:57, schrieb Stas Malyshev: There's no version 5.4.4-1. The patch was 85a62e9086db7a8ddfcda4ab1279a2439935f8d5 merged but since then there were other changes to the code. Mike, could you please check if we have a regression there? OK, someone in the bug report refers to this version. Christian, if you are seeing the error again, please reopen the bug and add information about what you are seeing, with which code and on which OS, environment, etc. I'm not the original author of the bug report, so I can't reopen it. But there exists an open bug report for the same issue. So I will comment on this report. https://bugs.php.net/bug.php?id=62335 Thank you for your effort. Cheers, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
