Re: [PHP-DEV] 6.0 And Moving Forward
That would be nice and all, but I'd rather we add methods to arrays.
On Jul 17, 2012 1:26 AM, David Muir davidkm...@gmail.com wrote:
On 14/07/12 01:33, Anthony Ferrara wrote:
Hey all,
I know that 6.0 was originally supposed to be the unicode conversion of
the
engine. However it appears that all progress on that has stopped for quite
some time.
So, I was curious if we could start a conversation around what 6.0 would
look like if we didn't go the unicode route. What would be the major
changes that we'd base it on.
Here are a few of the ideas that have been floating around in my head.
1. Change the error handling system from the current E_* system to typed
exceptions for everything but advisory errors (E_STRICT, E_NOTICE,
E_DEPRECATED). Why? Because the current error system encourages ignoring
or
not checking what the error was, and it makes defensive programming quite
difficult. This is arguable and preference for sure, but it's a major
change that could have large benefits.
2. Make namespaces first-class meta-objects. That way, you could have
namespace private and protected classes, functions, variables, etc. This
would allow for better scoping of modules...
3. Make all zval types pseudo-objects. Basically enabling something akin
to
auto-boxing allowing a significant amount of the standard library to be
eventually deprecated in favor of acting on methods (not initially, but
opens the door).
4. Rewrite the entire parser completely. I keep hearing about how bad
PHP's
parser is, and how it's growing out of control. Perhaps this is a good
time
to rewrite it (perhaps changing semantics slightly) to be better adapted
towards future changes...
I'm not saying all of them are solid. I'm not saying any of them are
solid.
But hopefully this can spark a discussion around it...
Thoughts?
Anthony
I'd *really* like to see the following being possible:
$array = array('foo' = 'bar');
$object = (object) $array;
echo $array['foo']; //bar
echo $array-foo; //bar
echo $object['foo']; //bar
echo $object-foo; //bar
Is there a technical reason for the difference that currently exists?
Cheers,
David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Random string generation (á la password_make_salt)
hi, On Mon, Jul 16, 2012 at 10:19 PM, Ángel González keis...@gmail.com wrote: About supporting POSIX classes, that could be cool. But you then need a way to enumerate them. Note that isalpha() will be provided by the C library, so you can't count on having its data. It's possible that PCRE, which we bundle, contains the needed unicode tables. If anything, then ICU data. POSIX is the worst thing ever when it comes to locale support. 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] [proposal + pull request] Replace logo GUIDs with data URIs
hi, On Sat, Jul 14, 2012 at 11:29 PM, Brandon Wamboldt brandon.wambo...@gmail.com wrote: FYI, data URIs are only supported in IE8 or higher, IE7 and below do not support them. That's fine, not like it is a mission critical feature anyway. 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] 6.0 And Moving Forward
Hi, On 07/17/2012 05:40 AM, Nicholas Curtis wrote: Great Idea, would love to see current standard library in a legacy namespace and a new standard library implemented as methods of primitive types. The idea to separate old and new behaviour has some charm. $string = Hello, World; echo $strong-toUpper(); // HELLO, WORLD $int = 3; echo $int-round(2); // 3.0 While still preserving $legacy.strTopUpper($string) and $legacy.round($int) I wouldn't do that because it implies two things: - you have to change existing code (if I understand your syntax correctly) - you could mix old and new style in one file Somebody proposed (in some other thread some weeks ago) to introduce some code versioning. IIRC he proposed the ?php6 opening tag instead of ?php. (I'd prefer something like ?php+ - but that's just a naming thing. And of course: You could still mix different styles in one file - but not in one php block. And that's easier to handle by coding conventions in the team.) Versioning could be a chance to evolve the language and not to mess with existing code. BUT: I don't know if that's doable internally. And it's probably a lot of work... Regards Thomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 6.0 And Moving Forward
you have to change existing code (if I understand your syntax correctly) I think the idea here is to put functions likes floor and round in a legacy namespace of sorts, so they are not accessible in the global namespace. Then you have an .ini directive that imports the legacy namespace into the global namespace. Disable the .ini directive for 100% PHP6 mode, leave it in for legacy support. If it's enabled, you could mix round( $int ) and $int-round() in the same file. That's my understanding at least. On Tue, Jul 17, 2012 at 6:07 AM, Thomas Nunninger tho...@nunninger.infowrote: Hi, On 07/17/2012 05:40 AM, Nicholas Curtis wrote: Great Idea, would love to see current standard library in a legacy namespace and a new standard library implemented as methods of primitive types. The idea to separate old and new behaviour has some charm. $string = Hello, World; echo $strong-toUpper(); // HELLO, WORLD $int = 3; echo $int-round(2); // 3.0 While still preserving $legacy.strTopUpper($string) and $legacy.round($int) I wouldn't do that because it implies two things: - you have to change existing code (if I understand your syntax correctly) - you could mix old and new style in one file Somebody proposed (in some other thread some weeks ago) to introduce some code versioning. IIRC he proposed the ?php6 opening tag instead of ?php. (I'd prefer something like ?php+ - but that's just a naming thing. And of course: You could still mix different styles in one file - but not in one php block. And that's easier to handle by coding conventions in the team.) Versioning could be a chance to evolve the language and not to mess with existing code. BUT: I don't know if that's doable internally. And it's probably a lot of work... Regards Thomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- *Brandon Wamboldt* Programmer / Web Developer StackOverflow Careers Profilehttp://careers.stackoverflow.com/brandonwamboldt- GitHub Profile https://github.com/brandonwamboldt - LinkedInhttps://github.com/brandonwamboldt - My Blog http://brandonwamboldt.ca/
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
hi, On Tue, Jul 17, 2012 at 2:12 AM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: Let's ignore empty arguments like make[s] PHP feel modern. That aside, the main argument advanced in this message makes no sense. This idea has been proposed many times in the past and it is actually a very good proposal, for array, string or other types. The only reason why it is not yet implemented is the technical complexity to do it. We need pseudo objects and the likes, and it is really not something easy to do, in an efficient enough way. Adding method call syntax to arrays hardly makes PHP more object oriented. Syntax is unimportant. There's no substantial difference between array_slice($arr, ...) and $arr-slice(...). There is a huge difference. One of the main difference would be to finally have an uniform API and not this painful inconsistent APIs we have to maintain. There is, in my opinion, *one* merit here -- redesigning -- and perhaps reimplementing -- the arrays functions API. This will require a lot of work, thought, and time tough. Yes, but long due, same for strings. 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.)
I think strings are even more important, they have an even messier API than arrays. On Jul 17, 2012 11:07 AM, Pierre Joye pierre@gmail.com wrote: hi, On Tue, Jul 17, 2012 at 2:12 AM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: Let's ignore empty arguments like make[s] PHP feel modern. That aside, the main argument advanced in this message makes no sense. This idea has been proposed many times in the past and it is actually a very good proposal, for array, string or other types. The only reason why it is not yet implemented is the technical complexity to do it. We need pseudo objects and the likes, and it is really not something easy to do, in an efficient enough way. Adding method call syntax to arrays hardly makes PHP more object oriented. Syntax is unimportant. There's no substantial difference between array_slice($arr, ...) and $arr-slice(...). There is a huge difference. One of the main difference would be to finally have an uniform API and not this painful inconsistent APIs we have to maintain. There is, in my opinion, *one* merit here -- redesigning -- and perhaps reimplementing -- the arrays functions API. This will require a lot of work, thought, and time tough. Yes, but long due, same for strings. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
On Tue, 17 Jul 2012 12:07:09 +0200, Pierre Joye wrote: On Tue, Jul 17, 2012 at 2:12 AM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: Adding method call syntax to arrays hardly makes PHP more object oriented. Syntax is unimportant. There's no substantial difference between array_slice($arr, ...) and $arr-slice(...). There is a huge difference. One of the main difference would be to finally have an uniform API and not this painful inconsistent APIs we have to maintain. There isn't a difference in terms of making PHP more object oriented, which was the main advantage advanced by the OP. I'm all for redesigning strings/arrays APIs (presented as an afterthought by the OP), but for that the discussion should be centered on what those APIs will look like, not the syntax one uses to call them. In fact, quite frequently, syntax discussions make more important design decisions be ignored (see namespaces). There is, in my opinion, *one* merit here -- redesigning -- and perhaps reimplementing -- the arrays functions API. This will require a lot of work, thought, and time tough. Yes, but long due, same for strings. -- 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.)
hi Gustavo, On Tue, Jul 17, 2012 at 12:21 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: There isn't a difference in terms of making PHP more object oriented, which was the main advantage advanced by the OP. I'm all for redesigning strings/arrays APIs (presented as an afterthought by the OP), but for that the discussion should be centered on what those APIs will look like, not the syntax one uses to call them. To provide pseudo objects is a damned good point and long due. Please don't focus on a badly formulated initial post (more object oriented), we are not in a CS course but in the PHP internals discussions list :). In fact, quite frequently, syntax discussions make more important design decisions be ignored (see namespaces). Syntax easiness and APIs cleanness are what make a language attractive. 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.)
I might not have made it clear, but the main reasons I want it are: - Chance to clean up array/string/etc APIs - Looks nicer IMO, slightly clearer what functions do and affect On Jul 17, 2012 11:21 AM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: On Tue, 17 Jul 2012 12:07:09 +0200, Pierre Joye wrote: On Tue, Jul 17, 2012 at 2:12 AM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: Adding method call syntax to arrays hardly makes PHP more object oriented. Syntax is unimportant. There's no substantial difference between array_slice($arr, ...) and $arr-slice(...). There is a huge difference. One of the main difference would be to finally have an uniform API and not this painful inconsistent APIs we have to maintain. There isn't a difference in terms of making PHP more object oriented, which was the main advantage advanced by the OP. I'm all for redesigning strings/arrays APIs (presented as an afterthought by the OP), but for that the discussion should be centered on what those APIs will look like, not the syntax one uses to call them. In fact, quite frequently, syntax discussions make more important design decisions be ignored (see namespaces). There is, in my opinion, *one* merit here -- redesigning -- and perhaps reimplementing -- the arrays functions API. This will require a lot of work, thought, and time tough. Yes, but long due, same for strings. -- Gustavo Lopes
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
Pierre Joye wrote: This idea has been proposed many times in the past and it is actually a very good proposal, for array, string or other types. The only reason why it is not yet implemented is the technical complexity to do it. We need pseudo objects and the likes, and it is really not something easy to do, in an efficient enough way. Probably a silly question, but what popped into my mind was the way C++ was supposed to enhance C by adding these sort of rich functions in extra libraries. As a stepping stone, couldn't the mbstring package be re-factored as an OO library and used as a testbed for a new strings API? I would assume that this would all be natively multibyte aware from day one and I can't think of anything that is missing from mbstring? -- 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] Random string generation (á la password_make_salt)
2012/7/16 Ángel González keis...@gmail.com:
1a) If you want to support character classes, you can do it with pcre:
http://www.php.net/manual/en/regexp.reference.character-classes.php
That's more or less what I have thought.
If it's a string surrounded by square brackets, it's a character class,
else
treat as a literal list of characters.
] and - can be provided with the old trick of provide ] as first
character,
make - the first or last one.
Right thought. But introducing a new scheme of character-class
identificators or a new kind of describing character-classes is
confusing. As PHP developer I think Oh no, not again new magic
charsets.
I suggest again to use PCRE for that. The difference to your proposal
is not so big. Examples:
/[[:alnum:]]/ will return abc...XYZ0123456789. We can do this also
with /[a-zA-Z0-9]/. Or /[a-z0-9]/i. Or /[[:alpha:][:digit:]]/
You see: You can do things in much more different ways with PCRE. And
you continue to use this standard.
[And PCRE supports UTF8. Currently not important. But who knows?]
And maybe we can think about removing the beginning /[ and the
ending ]/, but a / at the end should be optionally possible to add
some regex-parameters (like /i).
Having to detect character limits makes it uglier.
Exactly. That's why I think we need not so much magic to the second
parameter. The character-list is just a list of characters. No magic.
We can extent this with a third parameter to tell the function from
which charset it is. And maybe a fourth to tell the random-algorithm,
but I think it's eventually better to have a function for each
algorithm, because that's the way how random currently works.
If I should write it with php this looks like that:
pseudofunction str_random($len, $characters, $encoding = 'ASCII', $algo)
{
$result = '';
$chlen = mb_strlen($characters,$encoding);
for ($i = 0; $i $len; $i++) {
$result .= mb_substr($characters, myrandom(0, $chlen, $algo),1);
}
return $result;
}
Without testing anything. It's just an idea.
This is a working php-function, but $encoding doesn't work (some
stupid error?) and not using $algo:
function str_random($len, $characters, $encoding = 'ASCII', $algo = null)
{
$result = '';
$chlen = mb_strlen($characters,$encoding);
for ($i = 0; $i $len; $i++) {
$result .= mb_substr($characters, rand(0, $chlen),1);
}
return $result;
}
About supporting POSIX classes, that could be cool. But you then need a way
to enumerate them. Note that isalpha() will be provided by the C
library, so you
can't count on having its data. It's possible that PCRE, which we bundle,
contains the needed unicode tables.
It works without thinking as above written in PHP code, but I dunno if
this could be done in C equally.
3. Because generating a string from character-classes is very handy in
general for some other things (many string functions have it), I
suggest that it is not part of random_string(). Make a new function
str_from_character_class(), or if you use pcre like above
pcre_str_from_character_class()?
How would you use such function? If you want to make a string out of them,
Oh, there are many cases to use it.
For example (I renamed the function to str_charset(), because it is
just a string of a charset):
// Search spacer strings
strpbrk (Hello World, str_charset('/[\s]/'));
// remove invisible chars at begin or end (not very much sense,
because a regex in this case is maybe faster)
trim(\rblaa\n, str_charset('/[^[:print:]]/'));
// remove invisible chars: when doing this with very big strings it
could be much faster than with regex.
str_replace(str_split(str_charset('/[^[:print:]]/')), \rblaa\n);
There are many other more or less useful things you can do with a
charset-string. :)
--
Alex Aulbach
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP-DEV] 6.0 And Moving Forward
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: Re: [PHP-DEV] 6.0 And Moving Forward
I like this idea a lot. I use PHP at work, and run everything on dedicated servers so I'd definitely prefer to run a pure PHP6 setup. Hosting providers on the other hand can over PHP5 support via an extension. +1 On Tue, Jul 17, 2012 at 9:51 AM, Leigh lei...@gmail.com 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 -- *Brandon Wamboldt* Programmer / Web Developer StackOverflow Careers Profilehttp://careers.stackoverflow.com/brandonwamboldt- GitHub Profile https://github.com/brandonwamboldt - LinkedInhttps://github.com/brandonwamboldt - My Blog http://brandonwamboldt.ca/
Re: [PHP-DEV] Any chance to fix php-trunk for windows?
Hi Marian, since last week current master snaps can be found here http://windows.php.net/downloads/snaps/master/ Cheers anatoliy Am Di, 19.06.2012, 20:16 schrieb Marian Kostadinov: Hello Anatoliy, https://bugs.php.net/patch-display.php?bug_id=61998patch=bug61998.patchrevision=latest seems to be the patch for a similar bug. Hopefully, this should fix the issue I found. I will try to investigate what has happened in the GIT respository. What I am sure is that this has been fixed before php 5.4.4 release. Thanks! 2012/6/19 Anatoliy Belsky a...@php.net Hi Marian, perhaps you need master, there are no snaps for that. Otherwise, did you check the date of the fix commit on 5.4 or 5.3 and of the latest snapL If it's not there, just wait a couple of days for the most recent snap and it should be there :) Anatoliy On Tue, 19 Jun 2012 20:07:18 +0300 Marian Kostadinov manchokapitan...@gmail.com wrote: Hello Anatoliy, the snaps for php-5.4 and php-5.3 doesn't work for me. I have reported a php bug that *Laruence* says it was fixed in trunk but not merged in php-5.4. So I have to check if it is fixed in trunk but I cannot do it because of the missing builds :) 2012/6/19 Anatoliy Belsky a...@php.net Hi, recent snaps can be downloaded under http://windows.php.net/downloads/snaps/php-5.4/ http://windows.php.net/downloads/snaps/php-5.3/ respectively to version you need. The snaps are created almost on daily basis. Regards Anatoliy On Tue, 19 Jun 2012 19:46:59 +0300 Marian Kostadinov manchokapitan...@gmail.com wrote: Hello, currently http://windows.php.net/downloads/snaps/php-trunk/ is empty and no windows builds can be downloaded. Are there any plans for fixing this? -- Anatoliy Belsky a...@php.net -- Anatoliy Belsky a...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP-DEV] 6.0 And Moving Forward
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 lei...@gmail.com 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] Pseudo-objects (methods on arrays, strings, etc.)
On 07/17/2012 03:07 AM, Pierre Joye wrote: hi, On Tue, Jul 17, 2012 at 2:12 AM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: Let's ignore empty arguments like make[s] PHP feel modern. That aside, the main argument advanced in this message makes no sense. This idea has been proposed many times in the past and it is actually a very good proposal, for array, string or other types. The only reason why it is not yet implemented is the technical complexity to do it. We need pseudo objects and the likes, and it is really not something easy to do, in an efficient enough way. And also because most of the proposals are simply strong-typing in disguise. If you turn scalars into objects and attach methods to those objects are you still going to be able to call floor() on a numeric string? This isn't as simple as people think on first glance and it doesn't really clean up the global namespace since we still need to be able to do type coercion which effectly implies that all scalar objects need to include the bulk of the current set of scalar functions. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP-DEV] 6.0 And Moving Forward
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 ajf...@googlemail.comwrote: 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 lei...@gmail.com 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-DEV] Re: internals Digest 17 Jul 2012 10:31:01 -0000 Issue 2723
вторник, 17 июля 2012 г. пользователь писал: internals Digest 17 Jul 2012 10:31:01 - Issue 2723 Topics (messages 61317 through 61343): Re: RFC Proposal - Attributes read/write visibility 61317 by: Amaury Bouchard 61318 by: Daniel Macedo 61319 by: Amaury Bouchard 61321 by: Daniel Macedo Re: Random string generation (á la password_make_salt) 61320 by: Andrew Faulds Re: Prototype PHP interpreter using the PyPy toolchain - Hippy VM 61322 by: Stas Malyshev Re: Random string generation (á la password_make_salt) 61323 by: Ángel González 61335 by: Pierre Joye Re: Property get/set syntax 61324 by: Bernhard Schussek Pseudo-objects (methods on arrays, strings, etc.) 61325 by: Andrew Faulds 61326 by: Ferenc Kovacs 61327 by: Adam Jon Richardson 61328 by: Gustavo Lopes 61339 by: Pierre Joye 61340 by: Andrew Faulds 61341 by: Gustavo Lopes 61342 by: Pierre Joye 61343 by: Andrew Faulds Re: 6.0 And Moving Forward 61329 by: David Muir 61332 by: Nicholas Curtis 61334 by: Andrew Faulds 61337 by: Thomas Nunninger 61338 by: Brandon Wamboldt Re: DOMDocument and script tag - XSS test 61330 by: Raymond Irving 61331 by: Anthony Ferrara 61333 by: Adam Jon Richardson Re: [proposal + pull request] Replace logo GUIDs with data URIs 61336 by: Pierre Joye Administrivia: To subscribe to the digest, e-mail: internals-digest-subscr...@lists.php.net javascript:; To unsubscribe from the digest, e-mail: internals-digest-unsubscr...@lists.php.net javascript:; To post to the list, e-mail: internals@lists.php.net javascript:; --
Re: Re: [PHP-DEV] 6.0 And Moving Forward
Aren't certain modules included in the PHP core distribution, like the mysqli extension that you enable using --with-mysqli? Could we not include the PHP5 namespace as an extension with the PHP distribution, and have it enabled by default, but provide a --disable-legacy-namespace option? Then in future versions of PHP, we could switch the option to --enable-legacy-namespace instead. Thoughts? On Tue, Jul 17, 2012 at 11:04 AM, Anthony Ferrara ircmax...@gmail.comwrote: 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 ajf...@googlemail.com 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 lei...@gmail.com 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 -- *Brandon Wamboldt* Programmer / Web Developer StackOverflow Careers Profilehttp://careers.stackoverflow.com/brandonwamboldt- GitHub Profile https://github.com/brandonwamboldt - LinkedInhttps://github.com/brandonwamboldt - My Blog http://brandonwamboldt.ca/
[PHP-DEV] Bug 55544
Hi, please can someone look into this issue. It seems that in version 5.4.4-1 the bug was fixed, but in newer versions this issue still exists. So please can someone merge the patch with the newer versions? https://bugs.php.net/bug.php?id=55544 Cheers, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP-DEV] 6.0 And Moving Forward
Well, being able to disable the fallback would allow developers to eagerly discover features that are going to be dropped (and it doesn't need to be a soft failure). Marco Pivetta http://twitter.com/Ocramius http://marco-pivetta.com On 17 July 2012 16:14, Brandon Wamboldt brandon.wambo...@gmail.com wrote: Aren't certain modules included in the PHP core distribution, like the mysqli extension that you enable using --with-mysqli? Could we not include the PHP5 namespace as an extension with the PHP distribution, and have it enabled by default, but provide a --disable-legacy-namespace option? Then in future versions of PHP, we could switch the option to --enable-legacy-namespace instead. Thoughts? On Tue, Jul 17, 2012 at 11:04 AM, Anthony Ferrara ircmax...@gmail.com 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 ajf...@googlemail.com 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 lei...@gmail.com 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 -- *Brandon Wamboldt* Programmer / Web Developer StackOverflow Careers Profilehttp://careers.stackoverflow.com/brandonwamboldt- GitHub Profile https://github.com/brandonwamboldt - LinkedInhttps://github.com/brandonwamboldt - My Blog http://brandonwamboldt.ca/
Re: Re: [PHP-DEV] 6.0 And Moving Forward
I agree, and it allows developers who don't need/want PHP5 compatibility to just disable the legacy namespace, reducing cruft and allowing them to prepare for future versions of PHP. Developers or hosting providers who need to support PHP5 can just compile/install PHP with default settings which will enable the legacy namespace. There could still be BC breaks, but I see this option working for both parties. On Tue, Jul 17, 2012 at 11:27 AM, Marco Pivetta ocram...@gmail.com wrote: Well, being able to disable the fallback would allow developers to eagerly discover features that are going to be dropped (and it doesn't need to be a soft failure). Marco Pivetta http://twitter.com/Ocramius http://marco-pivetta.com On 17 July 2012 16:14, Brandon Wamboldt brandon.wambo...@gmail.comwrote: Aren't certain modules included in the PHP core distribution, like the mysqli extension that you enable using --with-mysqli? Could we not include the PHP5 namespace as an extension with the PHP distribution, and have it enabled by default, but provide a --disable-legacy-namespace option? Then in future versions of PHP, we could switch the option to --enable-legacy-namespace instead. Thoughts? On Tue, Jul 17, 2012 at 11:04 AM, Anthony Ferrara ircmax...@gmail.com 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 ajf...@googlemail.com 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 lei...@gmail.com 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 -- *Brandon Wamboldt* Programmer / Web Developer StackOverflow Careers Profilehttp://careers.stackoverflow.com/brandonwamboldt- GitHub Profile https://github.com/brandonwamboldt - LinkedInhttps://github.com/brandonwamboldt - My Blog http://brandonwamboldt.ca/ -- *Brandon Wamboldt* Programmer / Web Developer StackOverflow Careers Profilehttp://careers.stackoverflow.com/brandonwamboldt- GitHub Profile https://github.com/brandonwamboldt - LinkedInhttps://github.com/brandonwamboldt - My Blog http://brandonwamboldt.ca/
Re: Re: [PHP-DEV] 6.0 And Moving Forward
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). I personally think this is already straying a little off topic. Discussing how legacy functions should be implemented is taking up more of the thread than discussing what actual features people want to see. I guess I feel 6 really should still be about ZE3 and full Unicode, which means pretty much a ground up rewrite. If that turns out to be the case, I think that while legacy support should be included it shouldn't influence the design of the new engine. This is version 6, BC will break, and performance and functionality improvements shouldn't be hampered due to legacy concerns. This is the sole basis for my suggestion. Write 6 how it should be. Add legacy afterwards. 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. As Brandon said, have it on by default, and let people --disable-whatever-its-called Lets get the discussion back towards features. I know I don't talk here much, but I enjoy reading what everyone has to say. Anthony I agree with all of your original suggestions. Exceptions everywhere is the big one for me. Namespaces as meta-objects and namespace private functions, definitely. -- 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.)
Whilst weak typing has its benefits, I think typing is a little too weak in places. IMO should not be equal to 0 or coercable to 0. But of course 0 should equal 0. On Jul 17, 2012 3:04 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 07/17/2012 03:07 AM, Pierre Joye wrote: hi, On Tue, Jul 17, 2012 at 2:12 AM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: Let's ignore empty arguments like make[s] PHP feel modern. That aside, the main argument advanced in this message makes no sense. This idea has been proposed many times in the past and it is actually a very good proposal, for array, string or other types. The only reason why it is not yet implemented is the technical complexity to do it. We need pseudo objects and the likes, and it is really not something easy to do, in an efficient enough way. And also because most of the proposals are simply strong-typing in disguise. If you turn scalars into objects and attach methods to those objects are you still going to be able to call floor() on a numeric string? This isn't as simple as people think on first glance and it doesn't really clean up the global namespace since we still need to be able to do type coercion which effectly implies that all scalar objects need to include the bulk of the current set of scalar functions. -Rasmus
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
On 07/17/2012 08:06 AM, Andrew Faulds wrote: Whilst weak typing has its benefits, I think typing is a little too weak in places. IMO should not be equal to 0 or coercable to 0. But of course 0 should equal 0. Which has nothing to do with this thread. On Jul 17, 2012 3:04 PM, Rasmus Lerdorf ras...@lerdorf.com mailto:ras...@lerdorf.com wrote: On 07/17/2012 03:07 AM, Pierre Joye wrote: hi, On Tue, Jul 17, 2012 at 2:12 AM, Gustavo Lopes glo...@nebm.ist.utl.pt mailto:glo...@nebm.ist.utl.pt wrote: Let's ignore empty arguments like make[s] PHP feel modern. That aside, the main argument advanced in this message makes no sense. This idea has been proposed many times in the past and it is actually a very good proposal, for array, string or other types. The only reason why it is not yet implemented is the technical complexity to do it. We need pseudo objects and the likes, and it is really not something easy to do, in an efficient enough way. And also because most of the proposals are simply strong-typing in disguise. If you turn scalars into objects and attach methods to those objects are you still going to be able to call floor() on a numeric string? This isn't as simple as people think on first glance and it doesn't really clean up the global namespace since we still need to be able to do type coercion which effectly implies that all scalar objects need to include the bulk of the current set of scalar functions. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 6.0 And Moving Forward
Hi, Some of the things I want to see in PHP 6: New designed Standard Library: * Clearly defined conventions for organization, naming and error handling. * Use Namespaces and groups functions by their purpose (net, strings, arrays,…) * Promote SPL functionality (spl_autoload_register, Data structures) to proper Core APIs by dropping the SPL prefix. * Converts all resource based APIs (file, stream,…) to Object Oriented APIs * Maybe find a way to share the standard library between multiple implementations of PHP (HipHop, Quercus, Phalanger). A better parser which is more maintainable and makes it easier to implement language features every modern programming language has. * Slicing operators for Arrays (and Strings?) * Splice Operator: splits an array into arguments for a function call. Then we can finally remove call_user_func_array(). * Optional Semicolons? I recently started doing some programming in Go and I really like this. Clean up the language: * Remove the old array() declaration syntax. * Replace some keywords with syntax constructs. For example remove list() and use multi assignment syntax like $var1, $var2 = foo(); or remove the array() syntax. Makes names like List and Array usable as Userspace class names again. Remove features which were made obsolete by the SPL: * __autoload() — was made obsolete by spl_autoload_register() * dir() — DirectoryIterator, probably make dir() just return a DirectoryIterator. * probably more. Make some runtime features more consistent: * Autoloading for all kind of missing constants (function names, namespace constants) * Function importing just like Class importing * Language Specification which makes it easier to maintain competing implementations. There's probably a lot more we could do, but these are some things from right the top of my head. -- Christoph Hochstrasser http://twitter.com/hochchristoph | http://christophh.net | https://github.com/CHH Am Freitag, 13. Juli 2012 um 17:33 schrieb Anthony Ferrara: Hey all, I know that 6.0 was originally supposed to be the unicode conversion of the engine. However it appears that all progress on that has stopped for quite some time. So, I was curious if we could start a conversation around what 6.0 would look like if we didn't go the unicode route. What would be the major changes that we'd base it on. Here are a few of the ideas that have been floating around in my head. 1. Change the error handling system from the current E_* system to typed exceptions for everything but advisory errors (E_STRICT, E_NOTICE, E_DEPRECATED). Why? Because the current error system encourages ignoring or not checking what the error was, and it makes defensive programming quite difficult. This is arguable and preference for sure, but it's a major change that could have large benefits. 2. Make namespaces first-class meta-objects. That way, you could have namespace private and protected classes, functions, variables, etc. This would allow for better scoping of modules... 3. Make all zval types pseudo-objects. Basically enabling something akin to auto-boxing allowing a significant amount of the standard library to be eventually deprecated in favor of acting on methods (not initially, but opens the door). 4. Rewrite the entire parser completely. I keep hearing about how bad PHP's parser is, and how it's growing out of control. Perhaps this is a good time to rewrite it (perhaps changing semantics slightly) to be better adapted towards future changes... I'm not saying all of them are solid. I'm not saying any of them are solid. But hopefully this can spark a discussion around it... Thoughts? Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP-DEV] 6.0 And Moving Forward
I'd really like to see full unicode support as well, scalar values as objects with methods ($intVar-abs()), and the ability to import all classes/functions from a namespace. On Tue, Jul 17, 2012 at 11:37 AM, Leigh lei...@gmail.com wrote: 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). I personally think this is already straying a little off topic. Discussing how legacy functions should be implemented is taking up more of the thread than discussing what actual features people want to see. I guess I feel 6 really should still be about ZE3 and full Unicode, which means pretty much a ground up rewrite. If that turns out to be the case, I think that while legacy support should be included it shouldn't influence the design of the new engine. This is version 6, BC will break, and performance and functionality improvements shouldn't be hampered due to legacy concerns. This is the sole basis for my suggestion. Write 6 how it should be. Add legacy afterwards. 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. As Brandon said, have it on by default, and let people --disable-whatever-its-called Lets get the discussion back towards features. I know I don't talk here much, but I enjoy reading what everyone has to say. Anthony I agree with all of your original suggestions. Exceptions everywhere is the big one for me. Namespaces as meta-objects and namespace private functions, definitely. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- *Brandon Wamboldt* Programmer / Web Developer StackOverflow Careers Profilehttp://careers.stackoverflow.com/brandonwamboldt- GitHub Profile https://github.com/brandonwamboldt - LinkedInhttps://github.com/brandonwamboldt - My Blog http://brandonwamboldt.ca/
Re: [PHP-DEV] 6.0 And Moving Forward
The problem, of course, is changing and removing things can break BC. I'd love to remove list() too, but that would break code relying on it. On Jul 17, 2012 4:23 PM, Christoph Hochstrasser christoph.hochstras...@gmail.com wrote: Hi, Some of the things I want to see in PHP 6: New designed Standard Library: * Clearly defined conventions for organization, naming and error handling. * Use Namespaces and groups functions by their purpose (net, strings, arrays,…) * Promote SPL functionality (spl_autoload_register, Data structures) to proper Core APIs by dropping the SPL prefix. * Converts all resource based APIs (file, stream,…) to Object Oriented APIs * Maybe find a way to share the standard library between multiple implementations of PHP (HipHop, Quercus, Phalanger). A better parser which is more maintainable and makes it easier to implement language features every modern programming language has. * Slicing operators for Arrays (and Strings?) * Splice Operator: splits an array into arguments for a function call. Then we can finally remove call_user_func_array(). * Optional Semicolons? I recently started doing some programming in Go and I really like this. Clean up the language: * Remove the old array() declaration syntax. * Replace some keywords with syntax constructs. For example remove list() and use multi assignment syntax like $var1, $var2 = foo(); or remove the array() syntax. Makes names like List and Array usable as Userspace class names again. Remove features which were made obsolete by the SPL: * __autoload() — was made obsolete by spl_autoload_register() * dir() — DirectoryIterator, probably make dir() just return a DirectoryIterator. * probably more. Make some runtime features more consistent: * Autoloading for all kind of missing constants (function names, namespace constants) * Function importing just like Class importing * Language Specification which makes it easier to maintain competing implementations. There's probably a lot more we could do, but these are some things from right the top of my head. -- Christoph Hochstrasser http://twitter.com/hochchristoph | http://christophh.net | https://github.com/CHH Am Freitag, 13. Juli 2012 um 17:33 schrieb Anthony Ferrara: Hey all, I know that 6.0 was originally supposed to be the unicode conversion of the engine. However it appears that all progress on that has stopped for quite some time. So, I was curious if we could start a conversation around what 6.0 would look like if we didn't go the unicode route. What would be the major changes that we'd base it on. Here are a few of the ideas that have been floating around in my head. 1. Change the error handling system from the current E_* system to typed exceptions for everything but advisory errors (E_STRICT, E_NOTICE, E_DEPRECATED). Why? Because the current error system encourages ignoring or not checking what the error was, and it makes defensive programming quite difficult. This is arguable and preference for sure, but it's a major change that could have large benefits. 2. Make namespaces first-class meta-objects. That way, you could have namespace private and protected classes, functions, variables, etc. This would allow for better scoping of modules... 3. Make all zval types pseudo-objects. Basically enabling something akin to auto-boxing allowing a significant amount of the standard library to be eventually deprecated in favor of acting on methods (not initially, but opens the door). 4. Rewrite the entire parser completely. I keep hearing about how bad PHP's parser is, and how it's growing out of control. Perhaps this is a good time to rewrite it (perhaps changing semantics slightly) to be better adapted towards future changes... I'm not saying all of them are solid. I'm not saying any of them are solid. But hopefully this can spark a discussion around it... Thoughts? Anthony -- 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 thought list() was a syntax, not standard lib, feature? Like array() (or am I thinking of isset()?) On Jul 17, 2012 4:48 PM, Dan Cryer d...@dancryer.com wrote: The problem, of course, is changing and removing things can break BC. I'd love to remove list() too, but that would break code relying on it. Isn't that kind of the point of the whole discussion? This is talking about completely rewriting the standard library for PHP 6, but providing a legacy extension/compile time option, which would bring with it almost complete backwards compatibility with PHP 5. *Dan Cryer* +Dan https://plus.google.com/101400775372325517263 @dancryer http://www.twitter.com/dancryer On 17 July 2012 16:32, Andrew Faulds ajf...@googlemail.com wrote: On Jul 17, 2012 4:23 PM, Christoph Hochstrasser christoph.hochstras...@gmail.com wrote: Hi, Some of the things I want to see in PHP 6: New designed Standard Library: * Clearly defined conventions for organization, naming and error handling. * Use Namespaces and groups functions by their purpose (net, strings, arrays,…) * Promote SPL functionality (spl_autoload_register, Data structures) to proper Core APIs by dropping the SPL prefix. * Converts all resource based APIs (file, stream,…) to Object Oriented APIs * Maybe find a way to share the standard library between multiple implementations of PHP (HipHop, Quercus, Phalanger). A better parser which is more maintainable and makes it easier to implement language features every modern programming language has. * Slicing operators for Arrays (and Strings?) * Splice Operator: splits an array into arguments for a function call. Then we can finally remove call_user_func_array(). * Optional Semicolons? I recently started doing some programming in Go and I really like this. Clean up the language: * Remove the old array() declaration syntax. * Replace some keywords with syntax constructs. For example remove list() and use multi assignment syntax like $var1, $var2 = foo(); or remove the array() syntax. Makes names like List and Array usable as Userspace class names again. Remove features which were made obsolete by the SPL: * __autoload() — was made obsolete by spl_autoload_register() * dir() — DirectoryIterator, probably make dir() just return a DirectoryIterator. * probably more. Make some runtime features more consistent: * Autoloading for all kind of missing constants (function names, namespace constants) * Function importing just like Class importing * Language Specification which makes it easier to maintain competing implementations. There's probably a lot more we could do, but these are some things from right the top of my head. -- Christoph Hochstrasser http://twitter.com/hochchristoph | http://christophh.net | https://github.com/CHH Am Freitag, 13. Juli 2012 um 17:33 schrieb Anthony Ferrara: Hey all, I know that 6.0 was originally supposed to be the unicode conversion of the engine. However it appears that all progress on that has stopped for quite some time. So, I was curious if we could start a conversation around what 6.0 would look like if we didn't go the unicode route. What would be the major changes that we'd base it on. Here are a few of the ideas that have been floating around in my head. 1. Change the error handling system from the current E_* system to typed exceptions for everything but advisory errors (E_STRICT, E_NOTICE, E_DEPRECATED). Why? Because the current error system encourages ignoring or not checking what the error was, and it makes defensive programming quite difficult. This is arguable and preference for sure, but it's a major change that could have large benefits. 2. Make namespaces first-class meta-objects. That way, you could have namespace private and protected classes, functions, variables, etc. This would allow for better scoping of modules... 3. Make all zval types pseudo-objects. Basically enabling something akin to auto-boxing allowing a significant amount of the standard library to be eventually deprecated in favor of acting on methods (not initially, but opens the door). 4. Rewrite the entire parser completely. I keep hearing about how bad PHP's parser is, and how it's growing out of control. Perhaps this is a good time to rewrite it (perhaps changing semantics slightly) to be better adapted towards future changes... I'm not saying all of them are solid. I'm not saying any of them are solid. But hopefully this can spark a discussion around it... Thoughts? Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 6.0 And Moving Forward
The problem, of course, is changing and removing things can break BC. I'd love to remove list() too, but that would break code relying on it. Isn't that kind of the point of the whole discussion? This is talking about completely rewriting the standard library for PHP 6, but providing a legacy extension/compile time option, which would bring with it almost complete backwards compatibility with PHP 5. *Dan Cryer* +Dan https://plus.google.com/101400775372325517263 @dancryer http://www.twitter.com/dancryer On 17 July 2012 16:32, Andrew Faulds ajf...@googlemail.com wrote: On Jul 17, 2012 4:23 PM, Christoph Hochstrasser christoph.hochstras...@gmail.com wrote: Hi, Some of the things I want to see in PHP 6: New designed Standard Library: * Clearly defined conventions for organization, naming and error handling. * Use Namespaces and groups functions by their purpose (net, strings, arrays,…) * Promote SPL functionality (spl_autoload_register, Data structures) to proper Core APIs by dropping the SPL prefix. * Converts all resource based APIs (file, stream,…) to Object Oriented APIs * Maybe find a way to share the standard library between multiple implementations of PHP (HipHop, Quercus, Phalanger). A better parser which is more maintainable and makes it easier to implement language features every modern programming language has. * Slicing operators for Arrays (and Strings?) * Splice Operator: splits an array into arguments for a function call. Then we can finally remove call_user_func_array(). * Optional Semicolons? I recently started doing some programming in Go and I really like this. Clean up the language: * Remove the old array() declaration syntax. * Replace some keywords with syntax constructs. For example remove list() and use multi assignment syntax like $var1, $var2 = foo(); or remove the array() syntax. Makes names like List and Array usable as Userspace class names again. Remove features which were made obsolete by the SPL: * __autoload() — was made obsolete by spl_autoload_register() * dir() — DirectoryIterator, probably make dir() just return a DirectoryIterator. * probably more. Make some runtime features more consistent: * Autoloading for all kind of missing constants (function names, namespace constants) * Function importing just like Class importing * Language Specification which makes it easier to maintain competing implementations. There's probably a lot more we could do, but these are some things from right the top of my head. -- Christoph Hochstrasser http://twitter.com/hochchristoph | http://christophh.net | https://github.com/CHH Am Freitag, 13. Juli 2012 um 17:33 schrieb Anthony Ferrara: Hey all, I know that 6.0 was originally supposed to be the unicode conversion of the engine. However it appears that all progress on that has stopped for quite some time. So, I was curious if we could start a conversation around what 6.0 would look like if we didn't go the unicode route. What would be the major changes that we'd base it on. Here are a few of the ideas that have been floating around in my head.. 1. Change the error handling system from the current E_* system to typed exceptions for everything but advisory errors (E_STRICT, E_NOTICE, E_DEPRECATED). Why? Because the current error system encourages ignoring or not checking what the error was, and it makes defensive programming quite difficult. This is arguable and preference for sure, but it's a major change that could have large benefits. 2. Make namespaces first-class meta-objects. That way, you could have namespace private and protected classes, functions, variables, etc. This would allow for better scoping of modules... 3. Make all zval types pseudo-objects. Basically enabling something akin to auto-boxing allowing a significant amount of the standard library to be eventually deprecated in favor of acting on methods (not initially, but opens the door). 4. Rewrite the entire parser completely. I keep hearing about how bad PHP's parser is, and how it's growing out of control. Perhaps this is a good time to rewrite it (perhaps changing semantics slightly) to be better adapted towards future changes... I'm not saying all of them are solid. I'm not saying any of them are solid. But hopefully this can spark a discussion around it... Thoughts? Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 6.0 And Moving Forward
You're correct, list() is a language construct. Is it still possible to add that in via an extension somehow? On Tue, Jul 17, 2012 at 1:00 PM, Andrew Faulds ajf...@googlemail.comwrote: I thought list() was a syntax, not standard lib, feature? Like array() (or am I thinking of isset()?) On Jul 17, 2012 4:48 PM, Dan Cryer d...@dancryer.com wrote: The problem, of course, is changing and removing things can break BC. I'd love to remove list() too, but that would break code relying on it. Isn't that kind of the point of the whole discussion? This is talking about completely rewriting the standard library for PHP 6, but providing a legacy extension/compile time option, which would bring with it almost complete backwards compatibility with PHP 5. *Dan Cryer* +Dan https://plus.google.com/101400775372325517263 @dancryer http://www.twitter.com/dancryer On 17 July 2012 16:32, Andrew Faulds ajf...@googlemail.com wrote: On Jul 17, 2012 4:23 PM, Christoph Hochstrasser christoph.hochstras...@gmail.com wrote: Hi, Some of the things I want to see in PHP 6: New designed Standard Library: * Clearly defined conventions for organization, naming and error handling. * Use Namespaces and groups functions by their purpose (net, strings, arrays,…) * Promote SPL functionality (spl_autoload_register, Data structures) to proper Core APIs by dropping the SPL prefix. * Converts all resource based APIs (file, stream,…) to Object Oriented APIs * Maybe find a way to share the standard library between multiple implementations of PHP (HipHop, Quercus, Phalanger). A better parser which is more maintainable and makes it easier to implement language features every modern programming language has. * Slicing operators for Arrays (and Strings?) * Splice Operator: splits an array into arguments for a function call. Then we can finally remove call_user_func_array(). * Optional Semicolons? I recently started doing some programming in Go and I really like this. Clean up the language: * Remove the old array() declaration syntax. * Replace some keywords with syntax constructs. For example remove list() and use multi assignment syntax like $var1, $var2 = foo(); or remove the array() syntax. Makes names like List and Array usable as Userspace class names again. Remove features which were made obsolete by the SPL: * __autoload() — was made obsolete by spl_autoload_register() * dir() — DirectoryIterator, probably make dir() just return a DirectoryIterator. * probably more. Make some runtime features more consistent: * Autoloading for all kind of missing constants (function names, namespace constants) * Function importing just like Class importing * Language Specification which makes it easier to maintain competing implementations. There's probably a lot more we could do, but these are some things from right the top of my head. -- Christoph Hochstrasser http://twitter.com/hochchristoph | http://christophh.net | https://github.com/CHH Am Freitag, 13. Juli 2012 um 17:33 schrieb Anthony Ferrara: Hey all, I know that 6.0 was originally supposed to be the unicode conversion of the engine. However it appears that all progress on that has stopped for quite some time. So, I was curious if we could start a conversation around what 6.0 would look like if we didn't go the unicode route. What would be the major changes that we'd base it on. Here are a few of the ideas that have been floating around in my head. 1. Change the error handling system from the current E_* system to typed exceptions for everything but advisory errors (E_STRICT, E_NOTICE, E_DEPRECATED). Why? Because the current error system encourages ignoring or not checking what the error was, and it makes defensive programming quite difficult. This is arguable and preference for sure, but it's a major change that could have large benefits. 2. Make namespaces first-class meta-objects. That way, you could have namespace private and protected classes, functions, variables, etc. This would allow for better scoping of modules... 3. Make all zval types pseudo-objects. Basically enabling something akin to auto-boxing allowing a significant amount of the standard library to be eventually deprecated in favor of acting on methods (not initially, but opens the door). 4. Rewrite the entire parser completely. I keep hearing about how bad PHP's parser is, and how it's growing out of control. Perhaps this is a good time to rewrite it (perhaps changing semantics slightly) to be better adapted towards future changes... I'm not saying all of them are solid. I'm not saying any of
Re: [PHP-DEV] Random string generation (á la password_make_salt)
On 17/07/12 13:34, Alex Aulbach wrote:
That's more or less what I have thought.
If it's a string surrounded by square brackets, it's a character class,
else
treat as a literal list of characters.
] and - can be provided with the old trick of provide ] as first
character,
make - the first or last one.
Right thought. But introducing a new scheme of character-class
identificators or a new kind of describing character-classes is
confusing. As PHP developer I think Oh no, not again new magic
charsets.
Not really new. Those escapings is how you had to work with them in
character classes of traditional regular expressions.
But I agree it can be confusing. What about a flag parameter, then?
I suggest again to use PCRE for that. The difference to your proposal
is not so big. Examples:
/[[:alnum:]]/ will return abc...XYZ0123456789. We can do this also
with /[a-zA-Z0-9]/. Or /[a-z0-9]/i. Or /[[:alpha:][:digit:]]/
You see: You can do things in much more different ways with PCRE. And
you continue to use this standard.
[And PCRE supports UTF8. Currently not important. But who knows?]
And maybe we can think about removing the beginning /[ and the
ending ]/, but a / at the end should be optionally possible to add
some regex-parameters (like /i).
Those could be in the flag. The / are not really needed, they are an
additional
syntax over regex provided by PHP (and the character can be a different
one,
although usually / is picked).
Having to detect character limits makes it uglier.
Exactly. That's why I think we need not so much magic to the second
parameter. The character-list is just a list of characters. No magic.
We can extent this with a third parameter to tell the function from
which charset it is. And maybe a fourth to tell the random-algorithm,
but I think it's eventually better to have a function for each
algorithm, because that's the way how random currently works.
If I should write it with php this looks like that:
pseudofunction str_random($len, $characters, $encoding = 'ASCII', $algo)
{
$result = '';
$chlen = mb_strlen($characters,$encoding);
for ($i = 0; $i $len; $i++) {
$result .= mb_substr($characters, myrandom(0, $chlen, $algo),1);
}
return $result;
}
Without testing anything. It's just an idea.
This is a working php-function, but $encoding doesn't work (some
stupid error?) and not using $algo:
function str_random($len, $characters, $encoding = 'ASCII', $algo = null)
{
$result = '';
$chlen = mb_strlen($characters,$encoding);
for ($i = 0; $i $len; $i++) {
$result .= mb_substr($characters, rand(0, $chlen),1);
}
return $result;
}
About supporting POSIX classes, that could be cool. But you then need a way
to enumerate them. Note that isalpha() will be provided by the C
library, so you
can't count on having its data. It's possible that PCRE, which we bundle,
contains the needed unicode tables.
It works without thinking as above written in PHP code, but I dunno if
this could be done in C equally.
The above code doesn't support POSIX character classes, just picking
characters
out of a string (which I agree is simple).
3. Because generating a string from character-classes is very handy in
general for some other things (many string functions have it), I
suggest that it is not part of random_string(). Make a new function
str_from_character_class(), or if you use pcre like above
pcre_str_from_character_class()?
How would you use such function? If you want to make a string out of them,
Oh, there are many cases to use it.
For example (I renamed the function to str_charset(), because it is
just a string of a charset):
// Search spacer strings
strpbrk (Hello World, str_charset('/[\s]/'));
So you're expanding all spacing characters, then iterating over them
with strpbrk(),
a preg_match() would have been more efficient.
// remove invisible chars at begin or end (not very much sense,
because a regex in this case is maybe faster)
trim(\rblaa\n, str_charset('/[^[:print:]]/'));
// remove invisible chars: when doing this with very big strings it
could be much faster than with regex.
str_replace(str_split(str_charset('/[^[:print:]]/')), \rblaa\n);
I don't see why expanding to a string, then converting to an array to
finally str_replace
would be faster :S
Also, that str_split() for all non-printable characters (even
considering that you
wouldn't get out of the memory limit with the many unicode chars you
will meet)
will fail with codepoints 127 (str_split works on bytes)
There are many other more or less useful things you can do with a
charset-string. :)
I'm not really convinced it's the right way to do them :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug 55544
On 07/17/2012 07:25 AM, Christian Kaps wrote: Hi, please can someone look into this issue. It seems that in version 5.4.4-1 the bug was fixed, but in newer versions this issue still exists. So please can someone merge the patch with the newer versions? https://bugs.php.net/bug.php?id=55544 Cheers, Christian Can you reproduce it using php.net's distribution of PHP and then log a new bug? Php.net doesn't do *-1 releases. On this list (and the bug system) it's better not to refer to a Linux distribution's build of PHP because that just confuses the issue. Thanks 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] Any chance to fix php-trunk for windows?
On 07/17/2012 06:22 AM, Anatoliy Belsky wrote: Hi Marian, since last week current master snaps can be found here http://windows.php.net/downloads/snaps/master/ Cheers anatoliy How does that really relate to http://windows.php.net/snapshots/ ? Are you going to make the links on http://windows.php.net/snapshots/ work? Also can you update http://snaps.php.net/ to link to Windows snaps, similar to the way http://php.net/downloads.php links to windows.php.net? Thanks, 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] Bug 55544
Hi! please can someone look into this issue. It seems that in version 5.4.4-1 the bug was fixed, but in newer versions this issue still exists. So please can someone merge the patch with the newer versions? https://bugs.php.net/bug.php?id=55544 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? 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. -- 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! This idea has been proposed many times in the past and it is actually a very good proposal, for array, string or other types. If we have $array-foo(), we should also have class foo extends array which allows to override foo() in array. This will require some serious changes, which need to be RFCed and reviewed and seen if they can really fit the language properly. Just saying let's bolt on method calls on top of arrays is definitely not very good. Having OO Array type may be good, if we will be able to figure out suitable design that will allow the same flexibility and power as regular arrays - though I'm not sure how to do it now. The only reason why it is not yet implemented is the technical complexity to do it. We need pseudo objects and the likes, and it is really not something easy to do, in an efficient enough way. I disagree - I do not think we need pseudo-objects. If the only point of the exercise is to convert a call of array_pop to $array-pop, it's not worth it. It'd just make the language more messy - you wouldn't know what - means anymore. -- 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.)
On 17.07.2012, at 21:03, Stas Malyshev wrote:
Hi!
This idea has been proposed many times in the past and it is actually
a very good proposal, for array, string or other types.
If we have $array-foo(), we should also have class foo extends
array which allows to override foo() in array. This will require some
serious changes, which need to be RFCed and reviewed and seen if they
can really fit the language properly. Just saying let's bolt on method
calls on top of arrays is definitely not very good. Having OO Array
type may be good, if we will be able to figure out suitable design that
will allow the same flexibility and power as regular arrays - though I'm
not sure how to do it now.
The only reason why it is not yet implemented is the technical
complexity to do it. We need pseudo objects and the likes, and it is
really not something easy to do, in an efficient enough way.
I disagree - I do not think we need pseudo-objects. If the only point of
the exercise is to convert a call of array_pop to $array-pop, it's not
worth it. It'd just make the language more messy - you wouldn't know
what - means anymore.
+1
I am for making array a proper class with methods.
Legacy functions can be implemented as wrappers around it:
function array_push($array, $value)
{
$array-push($value);
}
There is absolutely no sense in creating new pseudo object entity. It would
just add tons of confusion.
p.s. in case of array, we already have http://docs.php.net/ArrayObject which is
a good starting point
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
Hi!
I am for making array a proper class with methods.
Legacy functions can be implemented as wrappers around it:
function array_push($array, $value)
{
$array-push($value);
}
The problem there is that array has different semantics than object. Not
completely, but for example if you pass array to function, it is passed
by value and is not modified, but objects are always mutable when passed
to functions. Changing this semantics will break a lot of code.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
On 17.07.2012, at 21:50, Stas Malyshev wrote:
Hi!
I am for making array a proper class with methods.
Legacy functions can be implemented as wrappers around it:
function array_push($array, $value)
{
$array-push($value);
}
The problem there is that array has different semantics than object. Not
completely, but for example if you pass array to function, it is passed
by value and is not modified, but objects are always mutable when passed
to functions. Changing this semantics will break a lot of code.
Having special handling of Array objects doesn't sound good too. And I don't
see any nice solution.
Options are:
* 5-to-6 tool, similar to python's 2-to-3 converter, which will fix code.
* introduce some kind of per-file declare() option, which would enable
pass-by-reference semantics of arrays/strings/etc. in 5.5 which would let
people write the same code for 5.5 and 6.x
Well, actually, there's one more option: we can introduce Autocloned
interface (empty, without methods) and force cloning of objects, which
implement this interface, during parameter-fetching phase.
This would allow us to have 2 sets of classes: One set which implements this
interface (slower, but backwards-compatible) and another set which doesn't
(faster, but not compatible).
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
Hi! Options are: * 5-to-6 tool, similar to python's 2-to-3 converter, which will fix code. Do you know any practical way of how such tool could work? * introduce some kind of per-file declare() option, which would enable pass-by-reference semantics of arrays/strings/etc. in 5.5 which would let people write the same code for 5.5 and 6.x I don't think it's a viable option. The goal is to run existing code, if you'd need to change each file that defeats the purpose of it. Well, actually, there's one more option: we can introduce Autocloned interface (empty, without methods) and force cloning of objects, which implement this interface, during parameter-fetching phase. This would allow us to have 2 sets of classes: One set which It's not only parameter fetching. It's everywhere - assignment, access, etc. Example: $b = $a; $b[0] = 1; $a should not change in this situation, for arrays. For objects, $a and $b are the same. Different semantics. Introducing such semantics for classes would be a major complication in the engine, even if it's doable (which I doubt) I don't think it is a goo idea. -- 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.)
On 17.07.2012, at 23:01, Stas Malyshev wrote: Hi! Options are: * 5-to-6 tool, similar to python's 2-to-3 converter, which will fix code. Do you know any practical way of how such tool could work? That would be: tokenizer + static analysis (with type inference) + replacing some of the tokens. Not a trivial task, but definitely doable. And a large amount of php code (popular tools, frameworks, …) for writing tests :) signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
Hi! That would be: tokenizer + static analysis (with type inference) + replacing some of the tokens. Not a trivial task, but definitely doable. So what would this tool do with this code? $a = getFirstArrayName(); $b = getSecondArrayName(); $$a = $$b; $b[1] = 0; Or this: include 'a.inc'; $a = $b; include 'b.inc'; where a.inc has array $a and b.inc has something like $b[1] = 0; but you have no way of knowing it since by the time you run the tool a.inc and b.inc are not available to it (think config files). -- 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.)
On 17.07.2012, at 23:20, Stas Malyshev wrote:
Hi!
That would be: tokenizer + static analysis (with type inference) + replacing
some of the tokens.
Not a trivial task, but definitely doable.
So what would this tool do with this code?
$a = getFirstArrayName();
$b = getSecondArrayName();
$$a = $$b;
$b[1] = 0;
Something like this:
$a = getFirstArrayName();
$b = getSecondArrayName();
if ($$b instanceof ArrayObject) {
$$a = clone $$b;
} else {
$$a = $$b;
}
$b[1] = 0;
Or this:
include 'a.inc';
$a = $b;
include 'b.inc';
where a.inc has array $a and b.inc has something like $b[1] = 0; but you
have no way of knowing it since by the time you run the tool a.inc and
b.inc are not available to it (think config files).
well, the same as above. not pretty, but that's a safe fallback when type
inference is not available.
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] Random string generation (á la password_make_salt)
2012/7/17 Ángel González keis...@gmail.com:
Those could be in the flag. The / are not really needed, they are an
additional syntax over regex provided by PHP (and the character can be a
different
makes it a little bit like Perl. I see this as a standard. So for me
a regex is with delimiters, even if the lib doesn't need them.
one, although usually / is picked).
Think, it comes from SED. I usaly use '#' - better visibility. :)
The above code doesn't support POSIX character classes, just picking
characters out of a string (which I agree is simple).
PCRE uses the Posix classes...
[btw. off topic: I read thrugh http://www.pcre.org/pcre.txt - meiomei,
they have introduced things here... backtracking control, path
recording... incredible]
// Search spacer strings
strpbrk (Hello World, str_charset('/[\s]/'));
So you're expanding all spacing characters, then iterating over them
with strpbrk(),
a preg_match() would have been more efficient.
Of course. Every example could be done more efficient with regex. It's
not the point! Once used, str_charset() is ready, the result can be
cached and reused for much more things. And then it's faster than
pcre, even ready compiled.
Hm.
Maybe back to the roots? Using range() is not so complicated:
implode('',
array_merge(
range('a','z'),
range('A','Z'),
range('0','9'))
))
shrug So I think, if we don't need charset-encoding, we won't need
this special functionality.
--
Alex Aulbach
--
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 7:03 PM, Stas Malyshev smalys...@sugarcrm.com wrote: I disagree - I do not think we need pseudo-objects. If the only point of the exercise is to convert a call of array_pop to $array-pop, it's not worth it. It'd just make the language more messy - you wouldn't know what - means anymore. pseudo object for the reasons Rasmus mentioned in his previous post. 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. 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! 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. 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. -- 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
On Tue, Jul 17, 2012 at 8:48 AM, Dan Cryer d...@dancryer.com wrote: The problem, of course, is changing and removing things can break BC. I'd love to remove list() too, but that would break code relying on it. Isn't that kind of the point of the whole discussion? This is talking about completely rewriting the standard library for PHP 6, but providing a legacy extension/compile time option, which would bring with it almost complete backwards compatibility with PHP 5. I think any reasonable person would expect there to be a significant number of BC breaks in any major version increment. That being said, wouldn't it be possible in most of these cases to just do what we already do and use the E_DEPRECATED flag? That way, people will have a reasonable amount of time to update their code to current standards before a behavior is removed completely. And in cases where E_DEPRECATED
Re: [PHP-DEV] 6.0 And Moving Forward
On Tue, Jul 17, 2012 at 3:43 PM, Kris Craig kris.cr...@gmail.com wrote: On Tue, Jul 17, 2012 at 8:48 AM, Dan Cryer d...@dancryer.com wrote: The problem, of course, is changing and removing things can break BC. I'd love to remove list() too, but that would break code relying on it. Isn't that kind of the point of the whole discussion? This is talking about completely rewriting the standard library for PHP 6, but providing a legacy extension/compile time option, which would bring with it almost complete backwards compatibility with PHP 5. I think any reasonable person would expect there to be a significant number of BC breaks in any major version increment. That being said, wouldn't it be possible in most of these cases to just do what we already do and use the E_DEPRECATED flag? That way, people will have a reasonable amount of time to update their code to current standards before a behavior is removed completely. And in cases where E_DEPRECATED Bah just had an unfortunate sequence of unintentional keystrokes As I was saying: And in cases where E_DEPRECATED wouldn't be feasible (such as with changing function arguments), my thinking would be to just make the change without having any legacy flags that have to be maintained. Again, it's a major version change. Nobody should be getting butthurt over BC breaks. If you haven't updated your code since PHP 3, for example, my answer would be to either update your code or stick with PHP 3. The rest of us shouldn't have to maintain inferior behavior-- especially in major version increments-- just to accommodate those developers who refuse to keep their code up-to-date. --Kris
Re: [PHP-DEV] 6.0 And Moving Forward
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 ajf...@googlemail.comwrote: 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 lei...@gmail.com 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
[PHP-DEV] Docs: php.ini vs. parse_ini_file()
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
