Re: [PHP-DEV][RFC][DISCUSSION] Group Use Declarations

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

Re: [PHP-DEV][RFC][DISCUSSION] Group Use Declarations

> 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.

[PHP-DEV][RFC][DISCUSSION] Group Use Declarations

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

[PHP-DEV][RFC][VOTE] Group Use Declarations

Hi internals! Since no new discussion topics appeared, the voting on the Group Use Declarations RFC for PHP7 is now open: RFC: https://wiki.php.net/rfc/group_use_declarations#votes Patch: https://github.com/php/php-src/pull/1005 As requested I've split the vote into two slightly different syntax

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

Hi Peter, > I like the idea (reducing the repeated namespace parts), but am not too keen on the syntax. > If I may offer a hastily thought out, and probably terrible, idea... how about something like "from prefix use ..." ? [...] > That's my two cents. Some people suggested the *"from* ... *use *

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

> Thanks for the RFC! > We discussed a little bit with the Hoa [1]'s and fruux [2]'s community and we have a question. > Why not pretending we have an array of symbols, something like: >use Foo\Bar\[Baz, Qux]; > instead of >use Foo\Bar\{Baz, Qux}; > This is a list vs. block debate. Whil

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

> Yup sure. We are going to vote yes (behind my nickname). > However, while I agree with all your arguments, we have more syntax and more semantics, it's kind of confusing. > But it's a small one, > so +1 for us. I bet there is no way to add such a feature without adding at least a small amount of

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

Hi Stellan, >Hello Marcio, > I am inclined to vote no for a couple of reasons: > 1. This is not a BC-break, I would move the vote to PHP 7.1. The reasoning behind this is that the tools in the ecosystem will have a lot > of work to get on par with PHP 7 (talking here about stuff like phpmd, phpcp

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

Hi, > I like use Foo\Bar\(Baz, Qux); > For Human type experience, {} is harder than () to type, see your > keyboard, can you easier type {} or easier type () > I hate {} > If you like to use {} as the group symbols, i would not like it. > It hurts my fingers. Your suggested syntax was cons

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

Hi, Yasuo I think {} is better than []. > Using array operator for this seems a little strange to me. > I think this syntax is more like with block, not array. > > Regards, > Thanks for supporting the sintax choice, we tried a plethora of possibilities during research phase and "{" "}" seemed the

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

Hi, Ralph The current namespace implementation is there to group code, which is > already does fairly successfully. > > I have to wonder if it is PHPStorm, IDE's and the like that have > "encouraged" people to only _use_ class names instead of a particular part > of a namespace (even if it is up t

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

Hi, Lester >> Can't we restore the simple way of working in PHP7 > >> where it does not need to wrap around other things quite so closely? > > > > Hi Lester, > > > > This way if doing things on php didn't go anywhere, people just stopped > > using it because they saw better alternatives. > > I cou

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

2015-02-13 13:50 GMT-03:00 Nikita Popov : > On Fri, Feb 13, 2015 at 5:24 PM, Nikita Popov > wrote: > >> On Wed, Feb 11, 2015 at 9:50 PM, Marcio Almada >> wrote: >> >>> Hi internals! >>> >>> Since no new discussion topics appeared, the voting

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

Hi Markus, > > - cognitively *I* can much easier glance through to "find" something. > Because my eyes just have to scan up/down on the same character column > That's very subjective. Have you seen the use case regardless of patch diffs on the RFC? Or the other examples given? > - It's not alph

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

Hi, Ralph 2015-02-14 12:43 GMT-03:00 Ralph Schindler : > > 1. We aimed for maximum readability. The block syntax delimited with >> bracket `{` ... `}` pairs is definitely easier to keep track in >> comparison with a colon and semicolon `:`...`;` >> >> 2. A block delimited by a double colon and a

Re: [PHP-DEV] I quit.

Thanks for all you've done for PHP in so short time! You've been representing a big part of the community with your remarkable work. You are quitting internals but will stay as a reference on PHP community. Márcio

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

2015-02-12 20:55 GMT-03:00 Stelian Mocanita : > > > >> I could compromise to send pull requests and update some of these tools >> (at >> least the open source ones) in time for PHP7 release. >> > > Print screen taken, will hold you to your words. > > Please do ;) If the RFC passes I'll be happy to

[PHP-DEV] [RFC][DISCUSSION] Context Sensitive lexer

Hi internals, I'd like to put the "Context Sensitive Lexer" RFC into discussion phase: RFC: https://wiki.php.net/rfc/context_sensitive_lexer TL;DR commit: https://github.com/marcioAlmada/php-src/commit/c01014f9 PR: https://github.com/php/php-src/pull/1054 PHP currently has ~64 globally reserved

Re: [PHP-DEV] [RFC][DISCUSSION] Context Sensitive lexer

Hi, Nikita 2015-02-20 9:26 GMT-03:00 Nikita Popov : > > I think we all agree that it would be nice to not be so strict about > reserved keywords in some places. As such this RFC hinges on questions of > implementation. > > The RFC uses a purely lexer-based approach, which is nice in principle, >

Re: [PHP-DEV] Coercive Scalar Type Hints RFC

Hi, 2015-02-21 14:22 GMT-03:00 Zeev Suraski : > All, > > I’ve been working with François and several other people from internals@ > and the PHP community to create a single-mode Scalar Type Hints proposal. > > I think it’s the RFC is a bit premature and could benefit from a bit more > time, but g

Re: [PHP-DEV] [RFC][DISCUSSION] Context Sensitive lexer

Hi, Stas 2015-02-22 19:20 GMT-03:00 Stanislav Malyshev : > Hi! > > I like the idea. But we need to examine the cases carefully so we don't > block some future routes - especially this is with regards to such > things as type names which we wanted to reserve. > > I.e. method names resolution is pr

Re: [PHP-DEV] Proposal: deprecate undefined passed arguments

2015-02-23 16:32 GMT-03:00 Marc Bennewitz : > Hi all, > > Because the feature freeze for PHP 7 is near I like to know your thoughts > about one more change in passing arguments. Sure this one would introduce > one more deprecated message / BC break but this one s for reducing BC break > in the fut

Re: [PHP-DEV] Proposal: deprecate undefined passed arguments

Hi, 2015-02-23 17:41 GMT-03:00 Marc Bennewitz : > Hi Marcio > > Wow, nice to see this - didn't noted it before. > > But I have to questions/notes: > 1. Why you throw only a warning and not an error (deprecating this feature > first). I don't see the benefit. > Because https://github.com/search?

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

Hi internais, This is just a friendly reminder that, according the the previously established voting duration of 14 days, the voting for Group Use declarations will close in exactly 17 hours counting from now. Thanks.

[PHP-DEV][RFC][DISCUSSION] Context Sensitive Lexer v0.4

Hi, I'd like to put the "Context Sensitive Lexe" RFC into discussion again. As promised, the RFC was reverted to it's previous less ambitious version, this time offering no drawbacks like the one pointed by Nikita. RFC: https://wiki.php.net/rfc/context_sensitive_lexer PR: https://github.com/php/

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

Hi 2015-02-25 8:45 GMT-03:00 Pascal MARTIN, AFUP : > > > We've discussed this RFC with other people of AFUP, and even though there > have been quite a few mails exchanged, I'm sorry to say we didn't reach a > consensus -- and, as such, are neither -1 nor +1. > > Trying to summarize a few points:

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

Hi, The voting for Group Use Declarations is now closed with 39 "yes" and 19 "no" votes. According to the established 2/3 majority requirement, it passed. https://wiki.php.net/rfc/group_use_declarations#votes If you voted "no": your feedback is still as important as before, specially in case you

[PHP-DEV][RFC][VOTING] Context Sensitive Lexer

Hi, Since no more issues appeared on discussion, the voting for the "Context Sensitive Lexer" is now open. The voting will close in exactly 14 days counting from now: RFC: https://wiki.php.net/rfc/context_sensitive_lexer#votes Since so few people participated on discussions, if you decide to vot

[PHP-DEV][RFC][DISCUSSION] Strict Argument Count

Hi, internals I'm moving the "Strict Argument Count" RFC into discussion phase: RFC: https://wiki.php.net/rfc/strict_argcount PR: https://github.com/php/php-src/pull/1108 Many different opinions were collected during research phase and the RFC was updated with real BC break measurements and othe

Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count

Hi Yasuo, 2015-03-02 1:43 GMT-03:00 Yasuo Ohgaki : > Hi Marcio, > > On Mon, Mar 2, 2015 at 8:02 AM, Marcio Almada > wrote: > > I like the idea. > > /** fn expects a variable-length argument lists */ > function fn($arg) { > $arg = func_get_arg(); > $arg

Re: [PHP-DEV][RFC][VOTING] Context Sensitive Lexer

Hi 2015-03-04 5:52 GMT-03:00 Nikita Popov : > > After reviewing the implementation, I've decided to vote "no" on this RFC. > > I had originally assumed that if this proposal is limited to method names > and class constants only the implementation should be pretty simple and > robust. However it t

Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count

Hi, 2015-03-03 16:48 GMT-03:00 Yasuo Ohgaki : > Hi Marcio, > > I understand your reasons. Compatibility is important, but detecting > function body contents and > suppressing errors by engine is too hacky. Raising E_DEPRECATE/E_STRICT by > function definition seems > the way to go. IMO. > > Just

Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count

Hi, 2015-03-04 21:51 GMT-03:00 Yasuo Ohgaki : > > I don't think we need to deprecate func_get_args(). We may have > > function f($a, ...) { > var_dump(func_get_args()); > } > > f(1,2,3); > ?> > > "...$a" packs arguments. Using "..." as variable parameter indication may > be allowed. > Strictl

Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count

Hi, 2015-03-05 20:08 GMT-03:00 Yasuo Ohgaki : > Hi Marcio, > > On Fri, Mar 6, 2015 at 6:36 AM, Marcio Almada > wrote: > >> It would be nothing new or weird. It's just a simple compile time check. >> We already "inspect" code in many other situations

Re: [PHP-DEV] [RFC] Anonymous Classes

Hi, 2015-03-07 8:28 GMT-03:00 Robert Stoll : > > > -Ursprüngliche Nachricht- > > Von: Patrick Schaaf [mailto:p...@bof.de] > > Gesendet: Samstag, 7. März 2015 08:22 > > An: Philip Sturgeon > > Cc: internals; Robert Stoll > > Betreff: Re: [PHP-DEV] [RFC] Anonymous Classes > > > > Am 06.03.2

Re: [PHP-DEV][RFC][VOTING] Context Sensitive Lexer

rs to vote for the feature as the new implementation is already on it's way. There still some work to be done, please refer to the task list on the pull request to see what still needs to be done. It would be nice to have the new patch reviewed too. Thanks, Márcio 2015-03-04 14:29 GMT-03

Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count

Hi, This is a remainder that the voting for the "Strict Argument Count" RFC is scheduled to start on March 14th, so we still have this week for discussion and it's still a good time to give feedback. Thanks, Márcio 2015-03-01 20:02 GMT-03:00 Marcio Almada : > Hi, internals

Re: [PHP-DEV] Voting choice for language changes (Was: "Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count")

2015-03-10 13:52 GMT-03:00 Anthony Ferrara : > Dan, > > On Tue, Mar 10, 2015 at 11:45 AM, Dan Ackroyd > wrote: > > On 10 March 2015 at 15:02, Anthony Ferrara wrote: > >> > >> Can we please come down to a single RFC, with a single vote yes/no? > >> It's easier to understand, easier to manage and

Re: [PHP-DEV] Voting choice for language changes (Was: "Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count")

Hi, 2015-03-10 12:45 GMT-03:00 Dan Ackroyd : > On 10 March 2015 at 15:02, Anthony Ferrara wrote: > > > > Can we please come down to a single RFC, with a single vote yes/no? > > It's easier to understand, easier to manage and has less possibility > > of gaming. > > > While I generally agree, in t

[PHP-DEV] Re: Voting choice for language changes (Was: "Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count")

Hi, 2015-03-10 11:39 GMT-03:00 Patrick ALLAERT : > Hello, > > Le ven. 6 mars 2015 à 00:44, Marcio Almada a > écrit : >> >> You are right about this. I'll setup a yes/no vote + a vote to decide >> between E_WARNING (for consistency), E_DEPRECATED or E_STRICT.

Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count

Hi, 2015-03-10 21:31 GMT-03:00 Stanislav Malyshev : > Hi! > > >- Even if you already read the RFC in the past, read it again now. > >- Don't claim **possible** massive BC breaks before read the > >measurements already done. No matter how seasoned you are with PHP, > real > >number

Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count

Hi 2015-03-11 1:49 GMT-03:00 Stanislav Malyshev : > Hi! > > > related to the proposed RFC. *But* after some heuristics it was > > noticeable that most warnings had a common cause. I parsed the output > > It doesn't matter if it has common cause or not. If I have a system of > Wordpress-like size,

Re: [PHP-DEV][RFC][VOTING] Context Sensitive Lexer

Hi, 2015-03-11 11:49 GMT-03:00 Nikita Popov : > On Mon, Mar 9, 2015 at 6:47 AM, Marcio Almada > wrote: > >> Hi, >> >> Just passing by to announce I already have a working version of the new >> patch: https://github.com/php/php-src/pull/1158 >> >> T

Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count

2015-03-11 6:27 GMT-03:00 Lester Caine : > On 11/03/15 09:05, wp12173047-156224 wp12173047-156224 wrote: > >>> BTW, the current PHP silent behavior should be considered even more > >>> > > confusing otherwise we > >>> > > wouldn't have these measurements: > >>> > > > >>> > > > https://wiki.php.net

Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count

Hi 2015-03-11 6:50 GMT-03:00 Patrick ALLAERT : > Le mar. 10 mars 2015 à 21:04, Marcio Almada a > écrit : > >> >> >> 2015-03-10 12:31 GMT-03:00 Patrick ALLAERT : >> >>> Hello, >>> >>> Le lun. 2 mars 2015 à 00:03, Marcio Almada a >

Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count

2015-03-10 12:31 GMT-03:00 Patrick ALLAERT : > Hello, > > Le lun. 2 mars 2015 à 00:03, Marcio Almada a > écrit : > > > I'm globally +0.5, however I have some concerns: > > What about constructors? > > Children classes may have a bigger number of argument

Re: [PHP-DEV] A plea for unity on scalar types

Hi, 2015-03-13 12:45 GMT-03:00 Anthony Ferrara : > All, > [...] > I respectfully ask Zeev to retract his current proposal as it's > currently failing with 68% of voters voting against it (currently > 16:34). Without extending the timeline for 7, there's very little > chance of it passing. So rath

Re: [PHP-DEV] [RFC] Basic Scalar Types

Hi, 2015-03-13 17:44 GMT-03:00 Zeev Suraski : > > -Original Message- > > From: Derick Rethans [mailto:der...@php.net] > > Sent: Friday, March 13, 2015 10:34 PM > > To: guilhermebla...@gmail.com; Stelian Mocanita > > Cc: Eli; PHP Internals List > > Subject: Re: [PHP-DEV] [RFC] Basic Scalar

Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count

Hi 2015-03-13 6:02 GMT-03:00 Patrick ALLAERT : > Le mer. 11 mars 2015 à 22:44, Marcio Almada a > écrit : > >> 2015-03-11 6:27 GMT-03:00 Lester Caine : >> >> > On 11/03/15 09:05, wp12173047-156224 wp12173047-156224 wrote: >> >> > Most of the ex

[PHP-DEV][RFC][VOTE] Strict Argument Count On Function Calls

Hi, The "Strict Argument Count" RFC is now on voting phase: RFC: https://wiki.php.net/rfc/strict_argcount PR: https://github.com/php/php-src/pull/1108 The voting will close in exactly 14 days counting from now (using the date/time from this email as a reference). If you have any doubt about wha

Re: [PHP-DEV][RFC][VOTE] Strict Argument Count On Function Calls

quot; and 3 "no" votes. If you already voted, don't worry, it's just some minor changes and the voting will be restarted by the end of the day (March 15) so we don't loose the schedule. Another email will follow with a summary of what changed. Thanks for the comprehension.

Re: [PHP-DEV][RFC][VOTE] Strict Argument Count On Function Calls

Hi 2015-03-15 8:33 GMT-03:00 Dan Ackroyd : > On 15 March 2015 at 06:59, Marcio Almada wrote: > > Hi, > > > > I received some requests to update the RFC with more information about BC > > breaks + possible minor adjustments regarding dynamic function calls. > >

[PHP-DEV][RFC][VOTE][RESTART] Strict Argument Count On Function Calls

Hi, As promised, the "Strict Argument Count" RFC vote was restarted: RFC: https://wiki.php.net/rfc/strict_argcount PR: https://github.com/php/php-src/pull/1108 There was no need to update the BC break section. The only minor change was the addition of the following section: https://wiki.php.net

Re: [PHP-DEV][RFC][VOTE] Strict Argument Count On Function Calls

Hi, I had no time to reply all emails since yesterday, but right now we are having a voting with 2 "yes" votes vs 16 "no" votes. I think we all agree that the RFC won't pass and I'm withdrawing the RFC for the following reasons: 1. The sooner we end the voting period the better for the PHP ti

Re: [PHP-DEV] New RFC draft "static class constructor"

Hi, 2015-04-13 10:37 GMT-03:00 Johannes Ott : > Hi, > > finally I managed to do my first RFC draft. > > https://wiki.php.net/rfc/static_class_constructor > > I hope I have done everything correct so far and I'm looking forward to > your feedback on it. > > As I already mentioned in the prediscussi

[PHP-DEV] Context Sensitive Language RFC - Implementation Candidate

Hi, The Context Sensitive Lexer RFC passed :) and by the time of the voting phase, we decided to vote for the feature only and later discuss quality analysis on the implementations aimed to fulfill the RFC. First, I'd like to thank you all for th

Re: [PHP-DEV] Re: [RFC] Reserving More Types in PHP 7

Hi, 2015-04-26 17:00 GMT-03:00 Joshua Holmer : > There is the approved RFC at > https://wiki.php.net/rfc/context_sensitive_lexer which is listed as > "pending implementation" which should alleviate these BC breaks > significantly. The linked RFC mentions this one specifically under the > "Impact

Re: [PHP-DEV] [VOTE] Exceptions in the engine

Hi Stas, 2015-04-30 13:51 GMT-03:00 Stanislav Malyshev : > Hi! > > > We could make an exception (sic !) and add the Throwable interface to > PHP7, > > even after feature freeze, because it is an easy pick and having a clear > > Exception model for 7.0 is to my opinion very important. > > I'm OK w

Re: [PHP-DEV] Context Sensitive Language RFC - Implementation Candidate

Hi! > Sorry for late response, forgot about this RFC. I've only glanced over it, > but the patch looks okay from the technical side. > > No problem :) there are other more important issues being discussed that should be prioritized, specially your engine exception RFC. > The thing that's bother

Re: [PHP-DEV] Soft-reserve "void" class name

Hi, I think that not reserving "void" by spec now is actually going against the "Request For Comments" process. If we don't soft reserve now we won't even have the possibility to discuss it later, this kills the discussion before it starts. The soft reservation has zero impact over PHP7.0, no one

Re: [PHP-DEV] [RFC] Throwable Interface

Hi, 2015-06-15 19:25 GMT-03:00 Aaron Piotrowski : > >> On Jun 15, 2015, at 4:02 PM, Anatol Belski wrote: >> I would then suggest Aaron to stick to the minimal voting period (announcing >> this as early as possible), if the voting passes - then merge the branch on >> Wednesday. This way we would

Re: [PHP-DEV] PHP7 and types

Hi, 2015-07-11 15:41 GMT-03:00 Sebastian Bergmann : > Am 11.07.2015 um 19:53 schrieb S.A.N: >> It will be useful for autocomplete in IDE > > That argument is bogus since proper IDEs (PhpStorm, fex.) leverage > docblock annotations for that already. > > -- > PHP Internals - PHP Runtime Developmen

Re: [PHP-DEV] PHP7 and types

Stas, 2015-07-12 5:10 GMT-03:00 Stanislav Malyshev : > Hi! > >> Not completely bogus. At least with typed properties you won't need to >> actually write the docblocks to have the IDE "hints". It's a minor win >> for IDE users too. > > I don't see "not needing to write docblocks" as a win, quite th

Re: [PHP-DEV] PHP7 and types

Lester, 2015-07-12 5:27 GMT-03:00 Lester Caine : > On 12/07/15 09:10, Stanislav Malyshev wrote: >>> Not completely bogus. At least with typed properties you won't need to >>> > actually write the docblocks to have the IDE "hints". It's a minor win >>> > for IDE users too. >> I don't see "not needi

Re: [PHP-DEV] Re: Voting choice for language changes (Was: "Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count")

Hi, you replied to the wrong thread ;) 2015-07-22 19:38 GMT-03:00 S.A.N : > I am satisfied, the possibility of group declarations, but the that lack: > > > use App\RestException\ // name "RestException", not imported to > current namespace :( > { > Gone, > NotFound, > BadRequest > }

Re: [PHP-DEV] Move internals discussion to a better medium

Hi, 2015-08-02 9:01 GMT-03:00 Dor Tchizik : > Hello internals! > > I wanted to propose a change to how PHP discussions are made. > > Currently, PHP discussions are held on the various mailing lists, managed > by an old mailing list system, without any proper alternative interface to > follow and r

Re: [PHP-DEV] Move internals discussion to a better medium

Hi 2015-08-02 16:52 GMT-03:00 Rowan Collins : > On 02/08/2015 20:10, Marcio Almada wrote: >> >> As you pointed github issues, it's worth noting that Rust internals >> already use github to manage RFCs: >> https://github.com/rust-lang/rfcs/pulls?q=is%3Aopen+is%

Re: [PHP-DEV] Move internals discussion to a better medium

Hi, 2015-08-02 17:46 GMT-03:00 Rowan Collins : > On 02/08/2015 21:19, Marcio Almada wrote: >> >> Hi >> >> 2015-08-02 16:52 GMT-03:00 Rowan Collins : >>> >>> On 02/08/2015 20:10, Marcio Almada wrote: >>>> >>>> As you pointed

Re: [PHP-DEV] Move internals discussion to a better medium

Hi, Rowan 2015-08-03 4:31 GMT-03:00 Rowan Collins : > On 2 August 2015 23:35:38 GMT+01:00, Marcio Almada > wrote: >>This is their email announce the end of their mailing list back in >>2015 >>https://mail.mozilla.org/pipermail/rust-dev/2015-January/011558.html > >

Re: [PHP-DEV] Syntactical inconsistency with new group use syntax

Hi, 2015-08-18 17:47 GMT-03:00 Arne Blankerts : > Hi everyone, > > while playing around with the new group use syntax, I stumbled upon an > inconsistency of which I'm not sure whether or not it is expected. > For the "classic" syntax, while technically pointless, a leading \ for > the name is cons

[PHP-DEV] VCS Account Request: @marcioAlmada

Hi, I've been contributing with language RFCs and bug fixes in the past. A VCS account would be handy for the very obvious fixes. Thanks! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Syntactical inconsistency with new group use syntax

Hi, 2015-08-18 19:18 GMT-03:00 Christoph Becker : > On 18.08.2015 at 22:47, Arne Blankerts wrote: > >> while playing around with the new group use syntax, I stumbled upon an >> inconsistency of which I'm not sure whether or not it is expected. >> For the "classic" syntax, while technically pointle

Fwd: [PHP-DEV] Annotation PHP 7

Hi! > PHP7 has a wonderful parser, maybe it's possible to provide a general > syntax for annotations with userland hooks for arbitrary data. This > approach can give a tool for framework developers to define a node visitor > for annotations. Alternative way is to define simple key-value storage an

Re: [PHP-DEV] Annotation PHP 7

> Reading it - > http://doctrine-common.readthedocs.org/en/latest/reference/annotations.html - > it looks pretty big - strictly typed values, named > parameters, default constructors linked to properties, support for enum > types, support for typed arrays, separate constant syntax within > annotat

Re: [PHP-DEV] Annotation PHP 7

> One problem with using *just* array syntax, without any new keyword or > symbols, > is that it is extremely close to being existing valid syntax. This may well > cause problems in the parser, > and would certainly be confusing to users. Not sure how sacred is `$`, but it could be a good candid

Re: [PHP-DEV] [VOTE][RFC] Safe Casting Functions

> Not a voter, but I don't really see the usefulness of this in core either. True. This could be on packagist or a php ext, but should not be in core. Main problem is that it carries too much ambiguity between validation and coercion while doesn't solve the real problem: strict typing. -- PHP In

Re: [PHP-DEV] [RFC] Additional splat operator usage

> I always wanted to have an analog XPath to access the array elements. > Something like: > $array = ['x' => ['p' => ['a' => ['t' => ['h' => 'value']; > $xpath = ['x', 'p', 'a', 't', 'h']; > $value = $array[...$xpath]; > var_dump($value); // string(5) "value" > ?> What would happen if some k

Re: [PHP-DEV] [RFC] Scalar Type Hints

The battle between strict type declarations vs coercive has been here for a while. My problem with coercion in detriment of strictness is that sometimes you DON'T WANT TYPE CASTING AT ALL. This new feature would create serious impediments. So I wonder if we couldn't have both (strict and coercive t

Re: [PHP-DEV] [RFC] Scalar Type Hints

a https://github.com/marcioAlmada 2015-01-01 13:36 GMT-03:00 Ferenc Kovacs : > > > On Thu, Jan 1, 2015 at 4:59 PM, Marcio Almada > wrote: > >> The battle between strict type declarations vs coercive has been here for >> a >> while. My problem with coercion in de

Re: [PHP-DEV] [RFC] Parameter skipping, take 3

Hi, Stanislav, great RFC. A huge part of core PHP API would benefit of parameter skipping. Andrea Faulds, > It’s not that I don’t need this… there are some horrible APIs I’ve used which would be slightly (but only slightly) more pleasant to use with this feature. But I don’t think we should add

Re: [PHP-DEV] [RFC] Parameter skipping, take 3

way. But I still disagree when you say that parameter skipping would instantly "encourage horrible APIs". That's a huge stretch, IMMO, unless you have any real case to support such statement. 2015-01-05 20:17 GMT-03:00 Andrea Faulds : > Hi Marcio, > > > On 5 Jan 2015,

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

Andrea, With all the respect this RFC is way worst than the v0.1: We still have a BC break but now we also have code with **mutant** behavior that might become buggy (do unexpected things) if a `declare` is used. As a language user and a package maintainer it would be a huge problem. Imagine how

Re: [PHP-DEV] [RFC][Vote] Return Types

Hi Levi, It's nice to see this RFC in voting phase again so quickly :) I just have one question. Since we had some changes in the implementation will the previous votes be discarded? 2015-01-14 6:18 GMT-03:00 Levi Morrison : > Dear Internals, > > I have moved the Return Types RFC[1] into voting

Re: [PHP-DEV] [RFC] Skipping parameters take 2

Marc Bennewitz, Stas, > But I think adding "default" as new keyword is a big BC break! > I personally also don't like it and asked myself why can't the parameter simply skipped? Default is already a reserved word AFAIK. But I've been thinking about alternatives to parameter skipping syntax which

[PHP-DEV] [PHP_DEV] Possible RFC

cause a minor BC break for programs already running with malformed regexp, but that's the hole purpose of this discussion. Do you think such RFC would be a good idea? Regards, Marcio Almada.

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

Hi, I would like to call everyone's attention, specially people contributing directly to this RFC series, to what S.A.N just said: > Many developers PHP offers dual syntax: > > 1. Strict > function bar(int $num){} > > 2. Lax > function bar((int) $num){} > > Maybe it makes sense to put this option

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

S.A.N, > The main advantage of the two syntaxes: > > 1. Strict > function bar(int $num){} > > 2. Weak > function bar((int) $num){} > > Any junior-middle PHP developer, seeing this syntax in the code can > understand how it works, without studying the documentation and without > your complex conver

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

Stanislav Malyshev, > I would rather have int $num for coercive typing - given that close to > 100% of existing typed functions - namely internal functions - mean > exactly that and are actually documented with this exact syntax. > [...] > As for strict, maybe it can be int! $num or something like

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

> That's how all internal functions work. It looks like you didn't > actually read my argument but just repeated "I want my use case". Sorry, I read all you said and understood it perfectly. > I know you want strict typing. I even proposed the option for it. No, you're wrong. I NEVER EVER said w

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

Stanislav Malyshev, >> detriment of coercive types simply because there is no general >> consensus about what "strict" means :) > > I don't see any place for "consensus" and "non-consensus" here - > unless you want to redefine words to have arbitrary meanings so nobody > understands you, it is pre

Re: [PHP-DEV] [RFC] Skipping parameters take 2

> Cryptic notation is not a PHP way. IMHO.I like original "default" proposal > and it is good enough. > Regards, When I suggested `_` it was more as a feature wandering. I like `default` too. The RFC looks good enough as it is now :) 2015-01-17 22:14 GMT-03:00 Yasuo Ohgaki : > Hi all, > > On Fri

Re: [PHP-DEV] [RFC] Skipping parameters take 2

2015-01-17 22:52 GMT-03:00 Marcio Almada : >> Cryptic notation is not a PHP way. IMHO.I like original "default" proposal >> and it is good enough. >> Regards, > > When I suggested `_` it was more as a feature wandering. I like > `default` too. The RFC looks go

Re: [PHP-DEV] [RFC] Skipping parameters take 2

Andrea, > For consistency with list(), we could also just put nothing: > >foo($bar, , $baz); > > Which is like: > > list($bar, , $baz) = $arr; > > Thoughts? Not sure. Do we consider both contexts (list assignment skipping and parameter skipping) as assignments? If so, then the consistency a

Re: [PHP-DEV] [RFC] Skipping parameters take 2

negatively, feature is cool. 2015-01-18 0:32 GMT-03:00 Rasmus Lerdorf : > On Jan 17, 2015, at 17:52, Marcio Almada wrote: > > >> Cryptic notation is not a PHP way. IMHO.I like original "default" > proposal and it is good enough. > >> Regards, > > > &

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

> Perhaps there should be a new rule which says that invoking a constructor > with anything other than "new" or "parent::__contruct()" > should be illegal, in which case this situation would generate an error. Now this would break a lot of code that $obj->__construct(); or $this->__construct();

Re: [PHP-DEV] in Operator

Hi, Mike, the use of "in" as `for ($var in $object) {};` could be the subject for another distinct RFC since it's doing something different from the original proposal: var_dump("PHP" in ["PHP", "C", "Java"]); // true 2015-01-20 10:41 GMT-03:00 Mike Willbanks : > Hello Pierre, Andrea and Niklas,

Re: [PHP-DEV] in Operator

Mike, > Also FYI - in the future please try not to top post and instead post under > where you are commenting as it makes it more difficult for > people coming later to the thread to see the scope of the conversation. Thanks for the tip! I read to "do not top post" on the guidelines but had no c

Re: [PHP-DEV] in Operator

llow up RFC to allow "in" on "for" context could be a win/win here as long as one feature doesn't block each other? 2015-01-20 11:10 GMT-03:00 Marcio Almada : > Mike, > >> Also FYI - in the future please try not to top post and instead post under >> whe

[PHP-DEV][RFC][DISCUSSION] Group Use Declarations

;m open to suggestions that could improve the proposal. Thanks! Marcio Almada https://github.com/marcioAlmada -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecate INI set/get aliases.

> Hi all, > > This is the RFC for INI set/get alias function deprecation. > > https://wiki.php.net/rfc/deprecate_ini_set_get_aliases > > Open issue is exception. Almost all aliases should be deprecated, but there > may > be exceptions. I hope everyone agrees to deprecation by document at least. > >

  1   2   >