Re: [PHP-DEV] PHP Language Specification
Hi, On 23.07.2014, at 11:22, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Another idea would be a Git repository with the specification as markdown files. This would allow creating Pull Requests via GitHub. I think facilitating discussion and feedback is more important than change tracking for now, but given github also has issues facility it may actually work. I'm not sure if markdown is expressive enough though (e.g. it does not have sub/superscripts AFAIK). maybe some of the symfony folks can say something about that? They are hosting their docs on github, using reStructuredText and it seems to work reasonably well? Cheers Jannik -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE] Uniform Variable Syntax
Hi Ferenc, On 22.07.2014, at 14:38, Ferenc Kovacs tyr...@gmail.com wrote: On Mon, Jul 14, 2014 at 6:35 PM, Nikita Popov nikita@gmail.com wrote: On Mon, Jul 7, 2014 at 4:18 PM, Nikita Popov nikita@gmail.com wrote: Hi internals! I've started the vote on the Uniform Variable Syntax RFC: https://wiki.php.net/rfc/uniform_variable_syntax#vote You can review the discussion about this RFC here: http://markmail.org/message/mr4ihbubfbdxygci The vote requires a 2/3 majority and is planned to end on 2014-07-14. The RFC targets PHP 6. The vote closed with 30 in favor and 1 against, as such the RFC is accepted. I will delay merging the patch until the situation regarding phpng and PHP 6 is more clear. Thanks, Nikita Hi Nikita, Derick mentioned in his blogpost( http://derickrethans.nl/uniform-variable-syntax.html) that You can't really write a scanner for it, as the code could already have been converted.. I know that you posted https://gist.github.com/nikic/ffd019ef78b72934c7cc which uses PhpParser\Lexer from your PHP-Parser project, so my understanding was that it is possible to detect those expressions with both the current php stable version and with the new one containing the uniform_variable_syntax changes. the point Derick was trying to make is that you can’t build a scanner that automatically checks whether you rewrote this particular piece of code already or not. You can find the code pieces which match the constructs affected by the BC, but the scanner can’t decide, whether they are already fixed (= they are ok as they stand). Which makes the burden of the update smaller, but you still need to check every match yourself, whether it will (still) work. (at least I read it like this) Cheers Jannik -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HTTP supergloblas and request body/query (was: Parsing PUT data)
Hi, wouldn’t $_BODY be better - since it is the request body? $_FORM is imho not very clear, since you can send data to $_POST without using a form. -- Cheers Jannik Am Mittwoch, 2. Oktober 2013 um 09:17 schrieb Alexey Zakhlestin: On 02.10.2013, at 10:59, Michael Wallner m...@php.net (mailto:m...@php.net) wrote: Since ever people are confused by _GET and _POST superglobals, because, despite their name, they do not (really) depend on the request method. Therefor I propose to phase out $_GET and name it $_QUERY and I propose to phase out $_POST and name it $_FORM (I'm not 100% confident with the latter yet, though). Further, I propose to remove the POST method restriction for handling request bodies and solely rely on the content type to trigger the parser(s). (*) There are already parsers for application/x-www-form-urlencoded and multipart/form-data in the core. One could think of providing an API to add content type handlers from extensions, ext/json may be an example, like it is hacked into pecl_http-v2. Thoughts, objections, insults? (*) We'd probably have to revisit all *post* INI variables, though. So, that is not one, but three proposals: 1. _GET - _QUERY, _POST - _FORM I don't think this is really necessary. Names are there historically and changing them will break a lot of stuff. +0 on aliasing, and soft-deprecation (via documentation) though 2. ignore request-method, trigger body-processing solely on Content-type +1. makes sense 3. expose body-parsers via php-level API +1. Hell, yes! Something like +1000, actually ;) -- Alexey Zakhlestin CTO at Grids.by/you https://github.com/indeyets PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc
Re: [PHP-DEV] [RFC] Keywords as identifiers
Am Mittwoch, 18. September 2013 um 16:29 schrieb Ralph Schindler: http://news.php.net/php.internals/23254 -ralph On 9/16/13 7:53 AM, Bob Weinand wrote: Hi! This is the (official) RFC thread for the patch proposed in http://php.markmail.org/message/7rn4mbwkbytqa3ig https://wiki.php.net/rfc/keywords_as_identifiers Any feedback about the RFC or the implementation? I really like the proposal. I cannot count how often I tried to create a class called „List“ and failed miserably. Cheers Jannik
Re: [PHP-DEV] [RFC] Skipping parameters take 2
Am Montag, 2. September 2013 um 11:02 schrieb Lester Caine: Ferenc Kovacs wrote: another small advantage would be that IDEs could show you the default value for the argument when hovering the default keyword. But a good IDE is already showing the full function and notes ... and will autocomplete so that this fix is not actually required :) In many cases, the 'additions' being loaded into the core would be much better handled in an IDE and already were in am ore flexible way ... Except for the case when the default changes. With `default` you will to the new default, with a (once) generated code block in the IDE it will stay the old default. And exactly this is the actual intention of this proposal (as far as I understood it). -- Cheers Jannik
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
Hi Peter, You're describing the current behaviour; unless I'm missing something obvious, the warning is only displayed when you try to do something date-related. Your example script should not be presenting any warnings, regardless of the date.timezone INI setting or lack thereof. you are right (I obviously missed some hidden [inside a library] date/time calls when encountering this error). This makes the following statement from Leszek interesting: Also, the check if timezone not set show warning would have to be shifted from initialization to call of each and every datetime function. It seems, like this is the case then. -- Cheers Jannik
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
Hello, Am Montag, 27. Mai 2013 um 09:27 schrieb Pierre Joye: On Mon, May 27, 2013 at 9:20 AM, Sanford Whiteman swhitemanlistens-softw...@cypressintegrated.com (mailto:swhitemanlistens-softw...@cypressintegrated.com) wrote: I am simply making the point that UTC is not the default default even when sysops or devs put their hands in. The choice isn't just UTC or what the end user personally sets. Domain time exists, no matter if Pierre has experienced it or not. Ok, let me rephrase it in a more understandable way. We had it the way you are wishing it. It caused hundred of side effects, bugs reports, bad behaviors, etc. This is something we don't want to see again. Not because either the system administrators or the application developers are not willing to add one line to php.ini or to their application. For all the reasoning behind this choice, please check the numerous bugs reports and discussions on internals. would it be hard to just show the notice as soon as the user actually uses a function regarding to date/time (and not before)? Currently the message is shown all the time, at the start of the script - even if the script is as simple as ?php echo 1; Wouldn't it be more useful if the notice only appears, if I actually use a date/time-function? -- Cheers Jannik Cheers. -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] property de-referencing
Hi,
Lazare Inepologlou
Mittwoch, 1. Mai
2013 10:55
Hello,2013/5/1
Stas Malyshev smalys...@sugarcrm.comThe
result is the same with "new ReplectionMethod('foo','bar')". The addedvalue
is that it can be statically checked.
well... yes and no.
Take the Symfony2 example:
you want to reference ^$task-task with autocompletion in your IDE?
This won't work, because Task::$task is a protected property. Symfony2
does the magic for you and automagically accesses the getters and
setters.
This probably won't work with property references, since you can't get
the getters and setters for it (except relying on the name of the
property as string and manipulating it).
Soo... I guess, for this feature, to be useful, we need object accessors
first (which were recently rejected by vote)?
Cheers
Jannik
Lazare INEPOLOGLOUIngnieur Logiciel
Stas Malyshev
Mittwoch, 1. Mai
2013 01:12
Hi!PHP
has functions that can be result of __call or arbitrary code thatimplements
fcall handler in an extension. What would be returned then?
Lazare Inepologlou
Mittwoch, 1. Mai
2013 00:20
2013/4/30 Rasmus Lerdorf
ras...@lerdorf.comIn C#, they had the
intention to introduce the operator infoof(...) to getthe
reflection, not only of properties, but of virtually everything in thelanguage.
They abandoned the idea because it is really hard to do that foroverloaded
functions and they did not want to do all that work for a halfbaked
feature:http://blogs.msdn.com/b/ericlippert/archive/2009/05/21/in-foof-we-trust-a-dialogue.aspxHowever,
PHP does not have overloaded functions, which makes thingssignificantly
easier, so maybe it is worth examining the idea.Lazare
INEPOLOGLOUIngnieur Logiciel
Rasmus Lerdorf
Dienstag, 30.
April 2013 23:00
It is certainly
not worth overloading the XOR operator for.-Rasmus
Stas Malyshev
Dienstag, 30.
April 2013 22:58
Hi!You
probably have use case for that, and it should be pretty easy towrite
a class that does that, but why it should be in the language? Itcertainly
doesn't look like something sizeable portion of PHP devs woulddo
frequently.
Re: [PHP-DEV] Object Type Casting
Hi,
I guess it would work like an inline type-hint.
Something along the lines of:
$circle = ShapeFactory::createShape('circle');
if (!$circle instanceof Circle)
{
throw …;
}
I would like something like this, since it saves quite some code.
Cheers
Jannik
Am Mittwoch, 24. April 2013 um 19:19 schrieb Stas Malyshev:
Hi!
Are there any plans to add object type casting support in PHP?
For example:
$circle = (Circle) ShapeFactory::createShape('circle');
$circle-radius = 10;
echo $circle-getArea();
What is this supposed to do? I.e. what createShape returns and what
(Circle) operator is doing to it?
It would be great if this feature could be added to 5.5 :)
5.5 is in feature freeze, so it won't happen in any case.
--
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] is GD being actively maintained?
Am Donnerstag, 6. September 2012 um 15:05 schrieb Alexey Shein: Hi, Rasmus, Just wanted to note that I've tested your script from http://fontjazz.com/metrics/test.php and couldn't reproduce the bug. I'm on the Ubuntu 12.04 with PHP 5.3.10-1ubuntu3.2 with Suhosin-Patch Have you tried upgrading your FreeType library and recompiling latest stable PHP with it? Good luck. P.S. I'm not a GD developer. Hi Alexey, I just tested it on PHP 5.4.4 on OSX and I can confirm, that the issue is still present. (used font: Open Sans Regular/Bold/Italic, screenshots: http://min.us/mM2c5yyBU ) Cheers Jannik Zschiesche
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
Am Dienstag, 4. September 2012 um 15:09 schrieb Lester Caine: I keep being told that there is nothing wrong with E_STRICT, and again someone has said that it does NOT cause crashes. I beg to differ here - IT DOES! Now if you are saying that I need to document these crashes as they SHOULD not be happening then I'll roll things back and start doing that, but *I* thought that these crashes were simply a known effect of using E_STRICT? And so I followed the directions, and switched E_STRICT off. On production machines of PHP5.3 with E_STRICT enabled and on PHP5.4 one gets white screen crashes using older code ... as far as I was concerned that was a known fact. Switch it off and everything runs fine! Hi Lester, did you actually check the error messages or did you stop with the white screen? If it is the later one, please try to reproduce such issues, so that one can investigate it further. Because the current situation is: - you say: it crashes - somebody else says: it doesn't And I don't think that this will lead anywhere... Cheers Jannik
Re: [PHP-DEV] Re: Support negative indexes for arrays and strings
Am Sonntag, 2. September 2012 um 02:43 schrieb sle...@pipeline.com: The idea was originally proposed by Marc Easen who created a patch and asked for help with putting together an RFC. I have yet to see a formal proposal but on the list Easen modified his idea so that it should apply to strings alone. With that in mind, would it really cause problems to have code like this: $string = Roses are red; $string[-3] = R; // modifying $string[10] echo $string; // Roses are Red The negative indexing provides a pleasurable way to easily access part of a string; it's simple and should be fast, too. I think Easen's proposal is laudatory and I for one would like to see it happen for PHP and provide users with more ease and satisfaction in working with the language. SL Hi, as I understood, a lot of people seem to have problems with this proposal, since arrays and strings could (and maybe should) behave the same. The main problem arises from the ambiguity for $array[-1] for arrays. But this is easily solvable: just introduce a slice operator. $array[:-1] and the ambiguity is gone. -- Cheers Jannik Zschiesche
Re: [PHP-DEV] Error handling brainstorming
Hi all,
Am 06.08.2012 20:41, schrieb Stas Malyshev:
Hi!
Because checking that the returned variable is `!== FALSE` is *way*
better than throwing an exception, right?
Yes, it is. You can control it, unlike the exception which you can not,
unless, again, you wrap everything into try/catch on every kind of
exception possible.
Well, if you use return codes, you have to wrap everything in
if-statements (maybe more than one, for multiple error codes), so you
don't actually gain anything here.
If you really need very fine-grained error reporting, you can also use
error codes in the exceptions (although you might get a strange mix of
both then - I would rather use typed exceptions... I mean, how many
functions do you know, where you actually have to deal with 20 different
types of errors [without using exceptions for control flow]).
You can avoid the mentioned problems with accidentally missing an
exception by just using multiple catch blocks:
try {
// ...
}
catch (FileNotFoundException $e)
{
// do something for this exact error message
}
catch (Exception $e)
{
// catch all other errors
}
What I really like when working with exceptions is that you have a
natural way of error bubbling. If you have a call stack of about 10
functions and the last one returns null as error value, every of the
other 9 functions needs to check for null and return null too (or do
something else to hint for an error). If you use exceptions, all this
work is done for you, so that you can handle the error on exactly the
level, where you want it to be handled.
What Andrew also tried to say is, that with some kind of errors you just
want the execution of your application to stop (and probably present an
error message to the user by using a try-catch around your complete
application) and not keep running, just because you forget to check a
single return value and the program keeps running in an undefined state.
But I guess this boils down to the quite old question: do I want my
application to crash (hard) to prevent bugs/corrupt data but create a
bad UX for the user; or do I want it to keep running by any means, even
if the handled and produced data may be just garbage? In the past, PHP
did choose the second alternative (which can be - depending on the case
- be both good and bad).
Just my thoughts.
Cheers,
Jannik
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: internals Digest 13 Apr 2012 01:23:19 -0000 Issue 2650
Am 15.04.2012 08:20, schrieb John LeSueur: Since you're looking for input, specifically on the compromise, let's try to figure out what's possible. The RFC proposes .phpp files that can only include other .phpp files. Others want .phpp files that can include .php files. There are two ways I can think of to accomplish this. 1. an ini switch. This is a bad idea, because it causes code written under one setting to be impossible to use in the other setting. 2. 3 file types.?php,?phpp,?php~p (read:?php almost pure) We'd need something better than that last one, but what it means is that _this_ file is pure php, but it may include an embedded script somewhere. Between those two options, I would choose 2. Just to be clear, if I had a third choice, which was to make no change, it would be #3. The second thing that still needs nailing down as far as implementation is how to determine parsing mode. If it has to be specified at include time, then we're putting the burden on whoever writes the autoloader to know what kind of file it is. If it has to be specified in php.ini, or in the sapi configuration, then I'm putting the burden on the administrator. I want to allow the developer who writes the file to specify its parsing mode. The two ways I see for developers to do so is to use variations on the ?php header of the file, or by file extension. I prefer variations on the ?php header, because file extension still depends on configuration in order to work, so involves admins in the decision of how to parse the php files that I write. ?php means just what it does now. ?phpp means, disallow ?, and error if there is anything before the header. The RFC specifies an additional restriction, throw error if I include file with?php header. ?phpo (open to suggestions for the text of this header) means disallow ?, and error if there is anything before the header. John Hi, I normally only read the discussions, instead of participate but I have a short question about #2: What is, if you mix the specified open tags? Look at this file: --- test.php ?php /* ...snip... */ ? ...snip... ?phpp /* ...snip... */ --- EOF Would this error out? Would this be ignored? (not that this kind of file should be written like this, but theoretically, it is possible) Cheers, Jannik -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] max_file_uploads INI_PERDIR
Hi Stas, with HTML5 you can also do input type=file multiple=multiple / and thereby upload many files with just one file upload element. Regards Jannik Am 17.02.2012 23:41, schrieb Stas Malyshev: Hi! I'd like to add PHP_INI_PERDIR to max_file_uploads before 5.4.0 and also in the next 5.3 release. This setting is very similar in scope to I think the change is good, I just want to understand - why before 5.4.0? I understand the change itself - though the problem has rather easy workaround, as it seems: don't put that many file uploads on the page if you're not using them - but why the urgency? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: another fix for max_input_vars.
Hi Johannes,
as far as I understood the issue, this error would be triggered before the
application's code is executed, so that would not solve this issue.
Cheers
Jannik
Am 04.01.2012 um 21:46 schrieb Johannes Schlüter:
On Wed, 2012-01-04 at 12:29 -0800, Stas Malyshev wrote:
Hi!
But there is a very valid security concern here. People can usually run
safely with display_errors enabled if their code is well-written. They
Oh no. Nobody should or can safely run production with display_errors.
Everybody thinks their code is well-written, but display_errors should
never be enabled in production, however high is your opinion of the code.
I'm afraid people now will start quoting this saying ok, yeah, if
you're a bad programmer, disable display_errors, but I'm a good
programmer, my code is solid, I even have a dozen of unit tests, so I
just go ahead and enable display_errors and then we have this sad state
of affairs where sites spill out error messages that are never supposed
to be seen by clients because developers thought it can never happen.
On shared hosts display_errors typically is on, but the application can
do ini_set('display_errors', 0) or such ...
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] Re: another fix for max_input_vars.
Hi again, Am 04.01.2012 um 21:52 schrieb Johannes Schlüter: On Wed, 2012-01-04 at 21:49 +0100, Jannik Zschiesche wrote: Hi Johannes, as far as I understood the issue, this error would be triggered before the application's code is executed, so that would not solve this issue. That's the point. Thanks for making it clear. :-) what could work nevertheless (if the server is an apache and htaccess is enabled) is setting display_errors to off with `php_flag display_errors off`, I guess. Cheers Jannik johannes Cheers Jannik -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php signature.asc Description: Message signed with OpenPGP using GPGMail
