On 06/02/15 05:01, Yasuo Ohgaki wrote:
But it is the key point. It is not PHP role to do it. PHP is not
alone. It is a server configuration job. But I have said that already
many times, we got our points :)
I understand your point.
We need both OS and PHP feature for perfection. Both of
I may give my opinion, but it's going to be only mine.
May be it's better to write all these question in RFC and make everyone to
expose their opinion.
It shouldn't be a final voting, just a survey that would help us make a
decisions, where to go.
don't dive into implementation details, use
Hi all,
On Fri, Feb 6, 2015 at 9:02 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
This RFC was renamed from script() and script_once().
Original proposal had defect. It wasn't perfect.
This RFC proposes script_path INI directive to eliminate
file/script inclusion at all via require().
Hi Matthew,
On Sat, Feb 7, 2015 at 1:45 AM, Matthew Leverton lever...@gmail.com wrote:
On Fri, Feb 6, 2015 at 6:02 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
https://wiki.php.net/rfc/script_path
It's work in progress, but I would like to start discuss.
I don't really like it; but I
Hi Dan,
On Fri, February 6, 2015 17:16, Dan Ackroyd wrote:
On 5 February 2015 at 22:28, Rasmus Lerdorf ras...@lerdorf.com wrote:
Any suggestions for how to handle annotating it? We could turn it into
a fake PR and mark it up using github's PR comments.
I think that's a good idea. It is very
On Thu, Feb 5, 2015 at 9:14 PM, Andrea Faulds a...@ajf.me wrote:
Good evening,
At long last, I’m going to put the RFC to a vote. It’s been long enough -
I don’t think there needs to be, or will be, much further discussion.
I’d like to make sure that everyone voting understands the RFC
Sending people who want to have more structure in the language to Java
is downright bad, not to mention that it sounds completely dictatorial. I
would just put that in the next Zend newsletter to make it clear for your
customers that there is a saner option.
Stelian
On Fri, Feb 6, 2015 at 12:57
On Fri, Feb 6, 2015 at 1:02 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Basically, it's administrative solution. Application should set these
setting
or administrator should.
Library shouldn't touch the setting, otherwise they hit their own foot.
If this was a PHP_INI_PERDIR setting, then I
On Feb 6, 2015, at 12:42 PM, Stelian Mocanita steli...@php.net wrote:
Sending people who want to have more structure in the language to Java
is downright bad, not to mention that it psounds completely dictatorial. I
would just put that in the next Zend newsletter to make it clear for your
Dear Internals,
I have updated the RFC for removing PHP 4 constructors[1]. Notably, I
have pushed off the removal to PHP 8, and instead only deprecate them
in PHP 7. The rationale is that eventual consistency in this matter is
good enough for now, and going slow may help avoid a Python 2 vs 3
Am 06.02.2015 um 21:22 schrieb Nikita Popov:
After much initial reluctance, I've voted in favor of this RFC.
Thank you Nikita for this decision. I would really like to have any kind
of scalar type hints introduced into PHP. I think most want this, but do
not agree if and how type conversion
Hi,
De : guilhermebla...@gmail.com [mailto:guilhermebla...@gmail.com]
Envoyé : vendredi 6 février 2015 19:22
À : Dennis Birkholz
Cc : PHP internals
Objet : Re: [PHP-DEV] Design by Contract
Hi Dmitry,
So, can we start drafting out some things?
Simple questions would help everybody to
On Fri, Feb 6, 2015 at 9:17 PM, François Laupretre franc...@tekwire.net wrote:
De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
Personally, backward compatibility is not too important.
PHP5 is dead by PHP 7.2 release... This is the reason why.
It's only 3 years
Hi,
FYI, the RFC was simplified and updated with opinions gathered during
discussion phase:
RFC: https://wiki.php.net/rfc/group_use_declarations
Along with its pull request: https://github.com/php/php-src/pull/1005
I'll start the voting phase on *Wednesday (February 11, 2015)* if no new
points
On Sat, Feb 7, 2015 at 10:59 AM, Marcio Almada marcio.w...@gmail.com wrote:
Hi,
FYI, the RFC was simplified and updated with opinions gathered during
discussion phase:
RFC: https://wiki.php.net/rfc/group_use_declarations
Along with its pull request: https://github.com/php/php-src/pull/1005
Please create a new thread to be sure everyone sees it.
Oh, thanks for the warning. I also noticed that a good amount of people
replied to me without without CC the mailing list. Hope this won't be an
issue.
Regards.
Hi,
FYI, the RFC was simplified and updated with opinions gathered during
discussion phase:
RFC: https://wiki.php.net/rfc/group_use_declarations
Along with its pull request: https://github.com/php/php-src/pull/1005
I'll start the voting phase on *Wednesday (February 11, 2015)* if no new
points
OK slowly getting back into raw code again ...
Looking at imagick phpinfo problem ...
if (supported_formats) {
for (i = 0; i num_formats; i++) {
smart_string_appends(formats, supported_formats[i]);
if (i != (num_formats - 1)) {
On 02/06/2015 10:22 PM, Nikita Popov wrote:
After much initial reluctance, I've voted in favor of this RFC.
After reading your email, Nikita, I deleted my vote (it was no before).
I will review the RFC again, with your arguments (and others) in mind
and maybe I'll come to a different
On Feb 6, 2015 6:45 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On Feb 5, 2015, at 17:41, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
Hi Rasmus,
Thanks for the highlight.
My biggest concern about all this breakage done for NG could somehow be
minimized by providing
De : Pierre Joye [mailto:pierre@gmail.com]
What do you think about the creation of an example extension covering
almost everything one would do in an extension?
The class, methods or functions do not have to be useful but to have simple
clear examples to display the differences with
Hi Andrea,
On 05 Feb 2015, at 21:14, Andrea Faulds a...@ajf.me wrote:
[...]
Voting starts today (2015-02-05) and ends in two weeks’ time (2015-02-19). In
addition to the vote on the main RFC, there is also a vote on the type
aliases issue, and a vote to reserve the type names for future
Lester,
If you are having issues with Imagick please report them here:
https://github.com/mkoppanen/imagick
Not only is that the right place to report issues with unreleased
versions of Imagick, but also I tend to monitor issues there more
closely than I do a mailing list.
This one of the few
On Sat, Feb 7, 2015 at 9:57 AM, François Laupretre franc...@tekwire.net wrote:
De : Pierre Joye [mailto:pierre@gmail.com]
What do you think about the creation of an example extension covering
almost everything one would do in an extension?
The class, methods or functions do not have to be
Hi Leigh,
On Fri, Feb 6, 2015 at 9:53 PM, Leigh lei...@gmail.com wrote:
On 6 February 2015 at 12:02, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
This RFC was renamed from script() and script_once().
Original proposal had defect. It wasn't perfect.
This RFC proposes script_path
Hi Leigh,
On Sat, Feb 7, 2015 at 3:46 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
I think this is a better solution than script{,_once}. I definitely
prefer it over the previous RFC
I thought script()/script_once() is enough, but it's not.
There are modules uses custom script loaders,
Hi Dmitri,
Yes, unfortunately, PHP features not compatible with the PHP 5 interpreter will
be harder to adopt for most developers, even if they are not technically BC
breaks.
I agree with your POV, as I now think that it shouldn't be included in the
core, provided we have the needed hooks. I
Hi Stas,
On Thu, February 5, 2015 21:41, Stanislav Malyshev wrote:
Hi Anatol!
Your recent fixes to headers_list() -
55cefb2814bde5815a92e8820fff45e037fa8d4f and
b5d3c5ca8dee6303498849448e3574cc3642eeea - broke head.phpt test and also
are BC-breaking since previously headers_list() always
Hi Ivan,
On Fri, Feb 6, 2015 at 4:44 PM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:
On Thu, Feb 5, 2015 at 11:25 PM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:
I just would like to point out some stuff.
tl;dr: Contracts can be used to validate code
Hello
PHP 5.6.6 RC1 is available for testing.
You can download it from
https://downloads.php.net/~jpauli/
The Windows binaries are available at http://windows.php.net/qa/
This release contains a number of bugfixes.
For the list of bugfixes that you can target in your
testing, please refer to
De : Ivan Enderlin @ Hoa [mailto:ivan.ender...@hoa-project.net]
Exactly, phpdoc is used as annotation (or comments with some similar
syntax) but is definitively not aimed to be annotations.
Exact. Annotations !== comments. Because PHP has no annotation system,
we used to use comments for
Hi Yasuo,
De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
Do you think of any negative impact on PHP if we implement D like
in{}/out{} which allow any PHP syntax?
Can you please give your opinion about the BC break a D-like syntax would
introduce ? It is
Hi Xinchen,
On Fri, Feb 6, 2015 at 12:00 PM, Xinchen Hui larue...@gmail.com wrote:
On Feb 6, 2015, at 9:38 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Rasmus,
On Fri, Feb 6, 2015 at 7:28 AM, Rasmus Lerdorf ras...@lerdorf.com
wrote:
Having just finished porting php-memcached
On Fri, Feb 6, 2015 at 2:01 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Dmitry,
On Fri, Feb 6, 2015 at 3:58 AM, Dmitry Stogov dmi...@zend.com wrote:
I don't think we should chose right approach right now.
It's better to collect few possible solutions e.g. statements,
expressions,
Just a thought: may be we can reuse part of PHP syntax and ask standard PHP
parser to do the work and provide AST.
requre(PHP_EXPRESSION)
weight(PHP_NUMBER)
I don't know if it's possible to implement...
Thanks. Dmitry.
On Fri, Feb 6, 2015 at 7:04 AM, Pierre Joye pierre@gmail.com wrote:
Hi,
do you have a link to old proposal and/or implementation?
Thanks. Dmitry.
On Fri, Feb 6, 2015 at 7:08 AM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
Hi all,
I already said before and I'm happy to say it again...
Whenever you feel ready to get true, complete Annotations
this is not going to be a BC break, this is going to be a Forward
Compatibility break, that won't allow PHP code that use this feature work
on PHP5.
Scalar type hints and attributes are also going to introduce such breaks.
On the other hand if we keep constraints in phpdoc, PHP core shouldn't
On 06/02/15 15:17, François Laupretre wrote:
You probably didn't live the PHP 4/5 migration
Now, this seems to become a habit.
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Dmitry,
Last time we discussed was this one: https://wiki.php.net/rfc/annotations
The ideal one was the version before:
https://wiki.php.net/rfc/annotations?rev=1300089833
To have this in core, we need to step back and re-evaluate how we could
achieve 80% minimum. My original proposal was
Hey:
On Fri, Feb 6, 2015 at 7:06 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Xinchen,
On Fri, Feb 6, 2015 at 12:00 PM, Xinchen Hui larue...@gmail.com wrote:
On Feb 6, 2015, at 9:38 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Rasmus,
On Fri, Feb 6, 2015 at 7:28 AM, Rasmus
De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
Personally, backward compatibility is not too important.
PHP5 is dead by PHP 7.2 release... This is the reason why.
It's only 3 years later, only 2 years later after PHP 7.0 release.
That's where we disagree, as I
I see your point, and, of course, it makes sense, but it also means that no
new PHP7 features might not be used in these frameworks and libraries for a
long time. Should we stop add new features in major releases?
As I said, according to DbC, I'm not sure if it should be defined on
language
Hello
PHP 5.5.22 RC1 is available for testing.
You can download it from
https://downloads.php.net/~jpauli/
The Windows binaries are available at http://windows.php.net/qa/
This release contains a number of bugfixes.
For the list of bugfixes that you can target in your
testing, please refer to
annotations might be useful for DbC, but I doubt if they are more readable.
reguire(is_numeric($a) $a 0)
reguire(is_numeric($b) $b 0)
ensure($ret 0)
function foo ($a, $b) {
return $a + $b;
}
Also, to use them, we will have to develop them first (not a trivial task
as well), but may be
Hi Lester and all,
On Fri, Feb 6, 2015 at 5:30 PM, Lester Caine les...@lsces.co.uk wrote:
On 06/02/15 05:01, Yasuo Ohgaki wrote:
But it is the key point. It is not PHP role to do it. PHP is not
alone. It is a server configuration job. But I have said that already
many times, we got our
Hi Francois,
On Fri, Feb 6, 2015 at 6:55 PM, François Laupretre franc...@tekwire.net
wrote:
De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo
Ohgaki
Do you think of any negative impact on PHP if we implement D like
in{}/out{} which allow any PHP syntax?
Can you
Hi Francois,
On Fri, Feb 6, 2015 at 7:34 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
I can understand motivation to write script runs in older release.
It's nice, I agree.
Personally, backward compatibility is not too important.
PHP5 is dead by PHP 7.2 release... This is the reason why.
On 6 February 2015 at 12:02, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
This RFC was renamed from script() and script_once().
Original proposal had defect. It wasn't perfect.
This RFC proposes script_path INI directive to eliminate
file/script inclusion at all via require().
Dmitry,
Doc comments are terrible. I really want you to spend some time looking at
what we had to do inside of Doctrine Annotations to make it work. We have
to token_get_all() the file to be processed and track for uses to allow
importing inside of doc blocks. We also had to build a top-down
On Fri, Feb 6, 2015 at 6:12 PM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
Dmitry,
Doc comments are terrible. I really want you to spend some time looking at
what we had to do inside of Doctrine Annotations to make it work. We have
to token_get_all() the file to be processed
On 06/02/15 16:16, Dan Ackroyd wrote:
Also, I found it useful when converting Imagick to have a checklist of
everything that needed to be done, in a simple format, rather than the
full explanation of the changes at
Is that in a publishable format Dan?
I'm looking to pull magickwand up as well
Hi all,
This RFC was renamed from script() and script_once().
Original proposal had defect. It wasn't perfect.
This RFC proposes script_path INI directive to eliminate
file/script inclusion at all via require().
https://wiki.php.net/rfc/script_path
It's work in progress, but I would like to
in my opinion, RFC looks reasonable.
can you remember main arguments against it.
why it was declined?
For PHP7, it may be possible to change RFC to accept any PHP expression as
annotation value.
Then this expression may be captured as AST or evaluated to constant.
Thanks. Dmitry.
On Fri, Feb
Hi Dmitry,
Actually the RFC was approved by 1 or 2 votes more than needed, but the
overall response from core maintainers was that it was overly complex,
adding features the language did not support until that point (named
parameters, short array syntax as examples), it was broken with the
I think the original proposal is more consistent then the simple one.
Most probably, it just came not in right time.
In case @internals really like annotations and we came to consensus how it
should look like, I may take care about efficient implementation.
Thanks. Dmitry.
On Fri, Feb 6, 2015 at
j adams wrote on 06/02/2015 00:05:
Please let me know which mailing list address to use if I have sent this to
the wrong list.
filter_var does not properly validate emails with international characters.
For example, this returns FALSE:
var_dump(filter_var(Pelé@example.com,
On the other hand you have a working solution.
You won't be able to use annotations for PHP5 projects anyway.
Except, if we put them into comments or doc-comments.
/**[Attribute(Value)]*/
Why not /**@ Attribute Value */ or /**@ Attribute(Value) */? No []
required and @ looks more familiar
On 5 February 2015 at 22:28, Rasmus Lerdorf ras...@lerdorf.com wrote:
Any suggestions for how to handle annotating it? We could turn it into a
fake PR and mark it up using github's PR comments.
I think that's a good idea. It is very easy for people to ask
questions about any change that they
I’ve rewritten the RFC for pecl_http and hopefully addressed most of the
things mentioned previously.
I you still find anything lacking, please let me know, so I can expand
the
RFC accordingly.
And of course, everything else is up for discussion.
I may not have been clear before, but just
On Fri, Feb 6, 2015 at 6:02 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
https://wiki.php.net/rfc/script_path
It's work in progress, but I would like to start discuss.
I don't really like it; but I don't really like most INI-based solutions.
I agree that this is a problem with poorly written
Hi Dmitry,
So, can we start drafting out some things?
Simple questions would help everybody to get this moving forward.
I'll compile a simple list of questions to answer that would drive the
direction on how it would be implemented.
Please ignore the formatting on HOW they are defined. Tokens can
61 matches
Mail list logo
