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
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() al
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 val
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
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 t
On Fri, Feb 6, 2015 at 2:01 AM, Yasuo Ohgaki wrote:
> Hi Dmitry,
>
> On Fri, Feb 6, 2015 at 3:58 AM, Dmitry Stogov wrote:
>
>> I don't think we should chose "right" approach right now.
>> It's better to collect few possible solutions e.g. statements,
>> expressions, doc-comments, attributes...
>
annotations might be useful for DbC, but I doubt if they are more readable.
< 0)>>
< 0)>>
< 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 this is a right road.
Thanks. Dmitry.
On Fri, Feb 6, 20
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 Annota
> 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
Just a thought: may be we can reuse part of PHP syntax and ask standard PHP
parser to do the work and provide AST.
<>
<>
I don't know if it's possible to implement...
Thanks. Dmitry.
On Fri, Feb 6, 2015 at 7:04 AM, Pierre Joye wrote:
> On Thu, Feb 5, 2015 at 11:44 PM, Dmitry Stogov wrote:
>
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 import
Hi Lester and all,
On Fri, Feb 6, 2015 at 5:30 PM, Lester Caine 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 points
Hi Francois,
On Fri, Feb 6, 2015 at 6:55 PM, François Laupretre
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 please give your
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 car
Hi Francois,
On Fri, Feb 6, 2015 at 7:34 PM, Yasuo Ohgaki 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.
> It's only 3 year
Hi Xinchen,
On Fri, Feb 6, 2015 at 12:00 PM, Xinchen Hui wrote:
> > On Feb 6, 2015, at 9:38 AM, Yasuo Ohgaki wrote:
> >
> > Hi Rasmus,
> >
> >> On Fri, Feb 6, 2015 at 7:28 AM, Rasmus Lerdorf
> wrote:
> >>
> >> Having just finished porting php-memcached (with help from Xinchen) to
> >> PHP7 I w
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
On 6 February 2015 at 12:02, Yasuo Ohgaki 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().
>
> https://wiki.ph
> 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
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 tryi
Hey:
On Fri, Feb 6, 2015 at 7:06 PM, Yasuo Ohgaki wrote:
> Hi Xinchen,
>
> On Fri, Feb 6, 2015 at 12:00 PM, Xinchen Hui wrote:
>>
>> > On Feb 6, 2015, at 9:38 AM, Yasuo Ohgaki wrote:
>> >
>> > Hi Rasmus,
>> >
>> >> On Fri, Feb 6, 2015 at 7:28 AM, Rasmus Lerdorf
>> >> wrote:
>> >>
>> >> Having
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 level.
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 6
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 "use"s to allow
importing inside of doc blocks. We also had to build a top-down rec
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", FILTER_VALIDATE_EMA
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
propose
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 pro
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
On 5 February 2015 at 22:28, Rasmus Lerdorf 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 don't understand on
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 wel
>> 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 b
On Fri, Feb 6, 2015 at 6:02 AM, Yasuo Ohgaki 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 code, but at the
> 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 famili
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
Hi Leigh,
On Fri, Feb 6, 2015 at 9:53 PM, Leigh wrote:
> On 6 February 2015 at 12:02, Yasuo Ohgaki 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 eli
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 cases,
Hi Matthew,
On Sat, Feb 7, 2015 at 1:45 AM, Matthew Leverton wrote:
> On Fri, Feb 6, 2015 at 6:02 AM, Yasuo Ohgaki 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-b
Hi Leigh,
On Sat, Feb 7, 2015 at 3:46 AM, Yasuo Ohgaki 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, including p
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 Dan,
On Fri, February 6, 2015 17:16, Dan Ackroyd wrote:
> On 5 February 2015 at 22:28, Rasmus Lerdorf 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 p
Hi all,
On Fri, Feb 6, 2015 at 9:02 PM, Yasuo Ohgaki 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().
>
> https://wiki.p
On Thu, Feb 5, 2015 at 9:14 PM, Andrea Faulds 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 fully.
> Pl
On Fri, Feb 6, 2015 at 1:02 PM, Yasuo Ohgaki 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 wouldn't rea
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 A
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 shou
> On Feb 6, 2015, at 12:42 PM, Stelian Mocanita 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
> customers
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 every
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
type
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 -
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 conclusi
On Feb 6, 2015 6:45 AM, "Rasmus Lerdorf" 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 poss
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
> 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 wit
On Sat, Feb 7, 2015 at 9:57 AM, François Laupretre 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 useful but
Hi Andrea,
> On 05 Feb 2015, at 21:14, Andrea Faulds 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 RFCs’ sak
On Fri, Feb 6, 2015 at 9:17 PM, François Laupretre 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 later, only 2 y
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 t
On Sat, Feb 7, 2015 at 10:59 AM, Marcio Almada 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
>
> I'll start
> 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 t
61 matches
Mail list logo
