[PHP-DEV] Re: Unable tor reset Wiki password

Thank you! I am able to access my account now. Regards, On Tue, Jul 19, 2022 at 12:22 PM Christoph M. Becker wrote: > > On 19.07.2022 at 17:29, guilhermebla...@gmail.com wrote: > > > I am currently unable to reset my password on Wiki. > > Following the process of &qu

[PHP-DEV] Unable tor reset Wiki password

Hi team, I am currently unable to reset my password on Wiki. Following the process of "forgot password", email with link, click, open page, getting a temporary password. When I attempt to use this temporary password, I experience "Sorry, username or password was wrong.". Is there anything else I

Re: [PHP-DEV] Namespace-private class properties

This should answer your question: https://github.com/php/php-src/pull/947#issuecomment-224912697 On Tue, Sep 22, 2020 at 7:38 AM Olle Härstedt wrote: > > 2020-09-21 21:50 GMT, Rowan Tommins : > > On 21/09/2020 17:13, Michael Morris wrote: > >> Next thing to consider - we have the problem of

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

Hi Sara, I'd like to explain my rationale. Most of the time I end up using "#[todo] Whatever" while documenting my code... my intentions are "# [todo] ...", but you know... missing that space char doesn't break anything today... In any case, BC is broken and FC would also not work. Now I assume

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

Hi, One question I'd like answered is that, like me, a few people have voted NO on the question to re-vote the syntax. If that is true, shouldn't their first primary choice be implied to be <<>> instead of anything else? I see 7 votes for no, but I'm the only one that still kept the first voting

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

On Thu, Jul 30, 2020 at 12:30 PM Rowan Tommins wrote: > > On Thu, 30 Jul 2020 at 17:18, guilhermebla...@gmail.com < > guilhermebla...@gmail.com> wrote: > > > > > I bet a search/replace wouldn't be that hard to be achieved > > > > > Find-and-repl

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

Question: The key factor of not using @ is due to conflict of suppression symbol. While we are in a major (where BC breaks are not encourage, but tolerable), have we considered the possibility of BC breaking suppression symbol (@ would become @@) and using @ for Attributes? I bet a search/replace

Re: [PHP-DEV] Re: [RFC] Amendments to Attributes

Hi Benjamin, Overall, all these amendments are good in my opinion, but I'd like to challenge a few things: 1- On item 3, the acceptable targets would be: class, function, method, property, class constant, parameter or all. If possible, I'd like to ask if it's possible to expand this list and

[PHP-DEV] Re: Question about merged PR #937

to not be considered as a valid voter for "lack of recent contribution" to the language. Cheers, On Thu, Sep 19, 2019 at 12:58 PM Christoph M. Becker wrote: > > On 19.09.2019 at 17:01, guilhermebla...@gmail.com wrote: > > One of my old PRs to PHP that was claimed to be merged disap

[PHP-DEV] Question about merged PR #937

Hi internals! One of my old PRs to PHP that was claimed to be merged disappeared from master. However, the upgrade note is still there in master and 7.4beta1. Here is the PR: https://github.com/php/php-src/pull/937 Here is the commit referencing it:

Re: [PHP-DEV] Re: [VOTE] Reclassifying engine warnings

Nikita, I'd suggest to wait until the current vote ends and then open a new RFC to vote this one, otherwise it'll be disrupting. Cheers, On Wed, Sep 18, 2019 at 12:29 PM Nikita Popov wrote: > > On Thu, Sep 12, 2019 at 2:17 PM Nikita Popov wrote: > > > Hi internals, > > > > I've opened the

Re: [PHP-DEV] Re: P++: FAQ

Hi all, I tried as much as I could to stay away from this discussion. My personal take is that breaking the language in two is a *really bad idea* (shouldn't I have put caps here instead?). Anyway, people are commenting a lot on features that adds a feature to the language, but nothing was being

Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax

threat /THret/ noun: a statement of an intention to inflict pain, injury, damage, or other hostile action on someone in retribution for something done or not done. Anyway, can we vote on this RFC? On Wed, Jul 31, 2019 at 9:54 AM Zeev Suraski wrote: > > On Wed, Jul 31, 2019 at 4:31 PM Dan

Re: [PHP-DEV] [RFC] [VOTE] Preloading

Hi, Besides the yet-another naming convention, I'm quite optimistic about this RFC. Now on the convention, is there any reason why single underscore (_) is used instead of double underscores (__)? We already have __autoload, __sleep, __toString, __wakeup, etc. Regards, On Tue, Nov 6, 2018 at

Re: [PHP-DEV] Re: TOKEN_AS_OBJECT for token_get_all()

Thanks Fleshgrinder! You expressed exactly what I thought, but was too busy... cough... lazy to put in an email. Cheers, On Fri, Mar 24, 2017 at 2:35 PM, Fleshgrinder wrote: > On 3/24/2017 4:23 PM, Andrea Faulds wrote: > > Hi Nikita, > > > > Nikita Popov wrote: > > > >>

[PHP-DEV] PHP's support to contravariance and covariance

Hi internals, During my regular open source work, I realized that PHP yet do not support contravariance and covariance for user classes. Some examples that I found that could be really easy to implement and useful to end user are highlighted here: - contravariance.php - https://3v4l.org/I3v0u -

Re: [PHP-DEV] Typed properties problems

Where can I see progress of this work? On Tue, Jan 17, 2017 at 5:03 AM, Dmitry Stogov wrote: > Hi Bob, > > > I've found a number of problems: > > > $ sapi/cli/php -r 'class Foo {public bool $b = false;} $x = new Foo; > $x->b->ops += 5; echo gettype($x->b),"\n";' > > object > >

Re: [PHP-DEV] Re: [RFC] Debugging PDO Prepared Statement Emulation v2

Hi Adam, Providing my input on why I voted "NO". Your proposed new method is not pure. This means it does have distinct responses depending on where it's located in the code. That's a big no-no for me. Cheers, On Tue, Dec 6, 2016 at 12:15 PM, Lester Caine wrote: > On

Re: [PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()

I'd suggest URL to be immutable and have a URLBuilder (obtainable through URL::createBuilder()) for that... On Fri, Oct 7, 2016 at 10:45 AM, David Walker wrote: > Hi Nikita, > > On Fri, Oct 7, 2016 at 4:37 AM Nikita Popov wrote: > > > Are you aware of

Re: [PHP-DEV] Namespaces internal refactoring

Hi Stas, I'll comment your PS, since I'm the author of the PR. On Sun, Aug 14, 2016 at 6:11 PM, Stanislav Malyshev wrote: > Hi! > > > - PHP 7 has private classes through anonymous/inner classes. > > It's not exactly the same, and I suspect the same is true for Ruby. It's >

Re: [PHP-DEV] Namespaces internal refactoring

Hi Stas, On Sun, Aug 14, 2016 at 6:35 PM, Stanislav Malyshev wrote: > Hi! > > > A realization that needs to be made is that beginners would be using > > libraries that requires to make valid restrictions, preventing those > > beginners to mess up with code they shouldn't.

Re: [PHP-DEV] Namespaces internal refactoring

Hi Stas, Answers inline. On Sun, Aug 14, 2016 at 5:14 AM, Stanislav Malyshev wrote: > Hi! > > > Today I see 2 sides in PHP Internals. One that truly believes that PHP > > should adopt more concepts of object orientation, such as Annotations, > > Generics, Overloading,

Re: [PHP-DEV] Namespaces internal refactoring

Hi Stas, I'll answer your message as it directly refers to links with my name. I understand the reasons of why namespaces were implemented that way, as I follow this list for quite a long time. I never complained about the implementation itself as it was publicly introduced originally back in

Re: [PHP-DEV] Set object properties inline

Hi, I very much liked the proposal, specially if we do consider a potential reusability if anyone ever decide to revisit Attributes RFC. It's out of scope how I'd see this implemented, so let me focus on the proposal only. There're some edge cases that need to be discussed and considered here.

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Joe, I fixed a minor typo in the RFC, hope you didn't mind. =) On Fri, May 20, 2016 at 5:25 AM, Lester Caine wrote: > On 20/05/16 07:05, Joe Watkins wrote: > > Morning internals, > > > > Since we have our answer on nullable types, typed properties can now > go > > to

Re: [PHP-DEV] [RFC] Simple Annotations

@Rasmus: This approach is too broad, allowing situations like Marco pointed out. I'd have to vote -1 on it too if you move forward, specially if you consider things like << "How do I grab this?" >> and other weirdness. @Rowan: Annotations should be immutable by nature. Still, I would love if you

[PHP-DEV] Assess acceptability of having php-ds into core

Hi internals, PHP 7 leverages a lot the performance internally and many PHP applications in the wild. Much of these improvement came by experimentation through PHPNG and the usage of efficient data structures internally. This idea of performance improvements are crucial to handle more requests,

Re: [PHP-DEV] PHP Attributes -> docBloc alternatives ...

Lester, I understand that IDEs are doing a nice job over the toolset already created around documentation. That's what phpdoc and friends do. Also, if you take PHPStorm, it also helps you add Doctrine annotations with ease. But this is just one IDE, and that's what they're supposed to do; help

Re: [PHP-DEV] [RFC:generics]

Sorry for top-posting... it looks like GMail top-posts everything that doesn't have a reply character right before the inherited (replied email), which i just did. On Fri, Apr 29, 2016 at 10:26 AM, guilhermebla...@gmail.com < guilhermebla...@gmail.com> wrote: > > > On Fri, Apr 2

Re: [PHP-DEV] [RFC:generics]

On Fri, Apr 29, 2016 at 4:55 AM, Jesse Schalken <m...@jesseschalken.com> wrote: > > > On Wed, Apr 27, 2016 at 6:50 AM, guilhermebla...@gmail.com < > guilhermebla...@gmail.com> wrote: > >> Hi all, >> >> Yesterday I spent a considerable 2h talking

Re: [PHP-DEV] [RFC] Intersection Types

Nice! I've read the RFC and there's only one missing thing that is either undocumented or missed during patch creation: instanceof. I'd be amazing if we could do: $foo instanceof Foo & Bar Cheers, On Thu, Apr 28, 2016 at 5:00 AM, Josh Di Fabio wrote: > On Thu, Apr 28,

Re: [PHP-DEV] [RFC:generics]

Hi all, Yesterday I spent a considerable 2h talking about Generics in Doctrine channel. We discussed the specifics of each boundary that PHP's implementation could take advantage. Here are our findings, which I'll illustrate using Java equivalents: 1- Upper bounds (T extends A) We all

Re: [PHP-DEV] [RFC] PHP Attributes

Another thing that looks odd to me i that every time you call new ReflectionClass, a new reflection_object gets created. Isn't there a way to get this "cached" somehow in zend_class_entry? On Mon, Apr 25, 2016 at 10:11 AM, guilhermebla...@gmail.com < guilhermebla...@gma

Re: [PHP-DEV] [RFC] PHP Attributes

On Mon, Apr 25, 2016 at 3:42 AM, Dmitry Stogov <dmi...@zend.com> wrote: > > > On 04/22/2016 06:39 PM, guilhermebla...@gmail.com wrote: > > > On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov <dmi...@zend.com> wrote: > >> >> >> On 04/22/2016 04

Re: [PHP-DEV] [RFC] PHP Attributes

On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov <dmi...@zend.com> wrote: > > > On 04/22/2016 04:05 AM, guilhermebla...@gmail.com wrote: > > Hi Dmitry, > > As a previous suggester of metadata information built-in into PHP, and > also one of developers of the most

Re: [PHP-DEV] [RFC] PHP Attributes

Hi Dmitry, As a previous suggester of metadata information built-in into PHP, and also one of developers of the most used metadata library written in PHP, I understand this feature implementation requires several design decisions and also a good understanding of specific situations users may

Re: [PHP-DEV] [RFC:generics]

I see that some of you are confusing union types with intersecting types here. The idea is not an OR, but an AND. I'll repeat the same example again to try to exemplify what I mentioned: class AA {} interface B {} interface C {} class BB extends AA implements B {} class CC extends AA implements

Re: [PHP-DEV] Quick sanity check ...

The question here is how type strictness would benefit the language. I agree with you on most parts. But still... if the class was declared like this: class CancelOutdatedOrdersDTO { public int $olderThan; } Wouldn't that be solved entirely? Code would crash (through a TypeError), it would

Re: [PHP-DEV] Quick sanity check ...

I might answer you by given a scenario that happened this week here at work. Because our non-broken language relies on a loose type system, a developer of my company wrote a property that accepts null, int, string, object, whatever as a property. This property was declared in a class that is

Re: [PHP-DEV] [RFC] Nullable Types

ecause we already may use NULL default value. > > However usage of "?" for arguments also may make sense. Someone may like > this, someone not. > > > Thanks. Dmitry. > > ------ > *From:* guilhermebla...@gmail.com <guilhermebla...@gmail.

Re: [PHP-DEV] [RFC:generics]

wift). Regards, On Wed, Apr 20, 2016 at 11:01 AM, Rowan Collins <rowan.coll...@gmail.com> wrote: > guilhermebla...@gmail.com wrote on 20/04/2016 03:54: > >> 1- Even though mentioned, I'd still use "extends" or "implements" instead >> of "i

Re: [PHP-DEV] [RFC] Nullable Types

I read the RFC and I want to highlight why I'll vote -1 on it even before it goes to voting. IMHO, it looks backwards to what the language is progressing. The introduction of nullable type hint as a separate notation than a simple type hint makes it *very* hard to implement typed properties,

Re: [PHP-DEV] [RFC:generics]

I don't know if mid-thread answering may lead to top-posting, but if it does, I'm sorry... =\ Answer inline: On Wed, Apr 20, 2016 at 5:10 AM, Dominic Grostate < codekest...@googlemail.com> wrote: > I've made an amendment to the RFC to clarify on the Nested Types, which is > indeed supposed to

Re: [PHP-DEV] [RFC:generics]

Hi, Here are a couple of comments towards Generics support to PHP. 1- Even though mentioned, I'd still use "extends" or "implements" instead of "is" (which would be a new pseudo-reserved keyword) to enforce data type consistency and prevent developers to potentially referring to one thing while

Re: [PHP-DEV] Trying to fix "use" language inconsistencies

: > I thought there was one already? > https://wiki.php.net/rfc/group_use_declarations > > On Sat, Apr 16, 2016 at 9:01 AM, guilhermebla...@gmail.com < > guilhermebla...@gmail.com> wrote: > >> Hi internals, >> >> >> It all started with a PR over

[PHP-DEV] Trying to fix "use" language inconsistencies

Hi internals, It all started with a PR over doctrine/annotations ( https://github.com/doctrine/annotations/pull/69), where a contributor decided to propose supporting group use support. The issue starts with this, which it is perfectly supported: use Foo\Bar, Foo\Woo; While multiple group

Re: [PHP-DEV] Re: Typed properties patch

Hi, Unsetting properties is used by a range of libraries I am aware of, including Doctrine (actually any project that relies on proxy generation). Breaking this "feature" would be a catastrophe to a lot of projects. There is an alternative though, which would help: property getter/setter would

Re: [PHP-DEV] Access and Visibility Modifiers

Hi, I was working on a private-class support for PHP an year ago, until I hit a problem I couldn't fix myself. Now I have some more expertise of what I could do to resolve it, but I still didn't start on rebase/update of patch yet. However, I'd like to describe my line of thinking here, so people

Re: [PHP-DEV] [RFC Discussion] Typed Properties

, "guilhermebla...@gmail.com" < > guilhermebla...@gmail.com> wrote: > > > > To me it's simply as that: > > > > > > class_statement: > >variable_modifiers optional_type property_list ';' { $$ = $2; > > $$->attr = $

Re: [PHP-DEV] [RFC Discussion] Typed Properties

To me it's simply as that: class_statement: variable_modifiers optional_type property_list ';' { $$ = $2; $$->attr = $1 } | ... property_list: property_list ',' property { $$ = zend_ast_list_add($1, $3); } | property { $$ = zend_ast_create_list(1, ZEND_AST_PROP_DECL,

Re: [PHP-DEV] Proposal for a new array function

My personal take on this: Let's add just more 1 function over a 9 function's array API, because I want to optimize 3 lines in my PHP code, and language lack of Generics while we still refuse to carefully think about a proper OO Collection API. Regards, On Tue, Feb 9, 2016 at 6:19 AM,

Re: [PHP-DEV] Re: [RFC][VOTE] Allow specifying keys in list()

Here is my reasons for no: 1- Non-intuitive behavior 2- Hard to read code, takes more time to understand underlying logic/flow 3- YAANPI => Yet Another Alternate Named Parameters Implementation (when I look at future scope) 4- Most common usage form (first example) still forces you to type almost

Re: [PHP-DEV] Class Friendship in PHP

Hi, My biggest concern about supporting friend classes is the ability to access non-intentional to be accessed code outside of the original class's knowledge. This by itself is very dangerous. I do see however package-private classes as a possibility (I actually have a partially running patch

Re: [PHP-DEV] Native Annotation Syntax

Let's be clear. I haven't seen any user asking for traits, which introduced almost the same amount of performance cost and complexity to ZE. It was proposed by a "long term contributor" and everybody said yay. When multiple userland people ask about the same feature, every single major framework

Re: [PHP-DEV] Native Annotation Syntax

n Thu, Nov 26, 2015 at 10:53 AM, Rowan Collins <rowan.coll...@gmail.com> wrote: > guilhermebla...@gmail.com wrote on 26/11/2015 15:14: > >> I haven't seen any user asking for traits >> > > Just because you didn't see it, doesn't mean it didn't happen. > > I

Re: [PHP-DEV] Native Annotation Syntax

Answers inline On Thu, Nov 26, 2015 at 11:58 AM, Chris Riley <t.carn...@gmail.com> wrote: > > On 26 November 2015 at 16:05, guilhermebla...@gmail.com < > guilhermebla...@gmail.com> wrote: > >> Ok then. I'll pretend that lack of interest didn't happen many

Re: [PHP-DEV] Native Annotation Syntax

Hi, I'm the co-author of RFC of Annotations, co-author of Annotations in docblock which I abandoned for being conceptually wrong and co-author of Doctrine Annotations. Comments such as the one from Lester Caine "In previous discussions it was pointed out that a substantial amount of legacy code

Re: [PHP-DEV] Native Annotation Syntax

ared hosting, you just entered in an infinite loop. On Wed, Nov 25, 2015 at 1:50 PM, Pedro Cordeiro <pedronar...@gmail.com> wrote: > On top of it, it'd break obfuscators like Zend Guard. > > 2015-11-25 15:58 GMT-02:00 guilhermebla...@gmail.com < > guilhermebla

Re: [PHP-DEV] Native Annotation Syntax

15 at 5:03 PM, Rowan Collins <rowan.coll...@gmail.com> wrote: > On 25 November 2015 19:02:37 GMT, "guilhermebla...@gmail.com" < > guilhermebla...@gmail.com> wrote: > >Hi Rowan, > > > >If you're in a shared hosting, you can't "simply" remove the

Re: [PHP-DEV] Native Annotation Syntax

Hi Rowan, I'm avoiding drilling down as much as I can to explain every single decision motivation of the 2010's patch, which hints every time why docblocks are bad. Maybe another example may help you to illustrate the problem; all I want is to add a multi-lined text in an annotation (using your

Re: [PHP-DEV] Native Annotation Syntax

I can give you a good argument. opcache.save_comments=0 Make it work. On Wed, Nov 25, 2015 at 12:48 PM, Rowan Collins wrote: > Larry Garfield wrote on 25/11/2015 17:39: > >> On 11/25/15 11:00 AM, Rowan Collins wrote: >> >>> I don't feel that strongly in favour of

Re: [PHP-DEV] 7.0.0 release

+1 on (a) It's perfectly normal to have issues fixed between last RC and GA. []s, On Tue, Nov 24, 2015 at 10:51 AM, Bishop Bettini wrote: > On Mon, Nov 23, 2015 at 4:10 PM, Anatol Belski > wrote: > > > a) release on 26th including all known bug fixes > >

Re: [PHP-DEV] Package / namespace visibility

Hi, I am currently working on class visibility support aiming PHP 7.1. Spoke with Derick to give me some north to finalize the patch and write the RFC. Your wishes are being listened, my friend! =) On Nov 10, 2015 19:25, "Karoly Negyesi" wrote: > Hi, > > As one of the

Re: [PHP-DEV] Friend class/function

Hi, One thing that should be worth mentioning is that my approach of private classes is decoupled in 2 parts. The first one as the ability to prevent instantiation outside of namespace and sub-namespaces. The second is the ability to access protected members, which matches your wish of friend

Re: [PHP-DEV] Re: Support execution scope realization at runtime (or last pieces forprivate class support)

the patch (this is the last missing piece as it currently stands), so I could officially propose for discussion by everyone here. Regards, On Thu, Oct 29, 2015 at 2:41 PM, Andrea Faulds <a...@ajf.me> wrote: > Hi Guilherme, > > guilhermebla...@gmail.com wrote: > > Currently, there's no w

[PHP-DEV] Support execution scope realization at runtime (or last pieces for private class support)

Hi internals! I want to revive an old patch I was working on last year, and open for discussion the last missing piece to make it fully complete, allowing me to write a RFC. Link to patch introducing support to private classes: https://github.com/php/php-src/pull/947 Currently, there's no way

Re: [PHP-DEV] Some words about the basic ideas of PHP

Finally someone understood precisely what PHP needs to evolve as a language for the next 35 years! #not On Mon, Oct 26, 2015 at 8:26 AM, Joe Watkins wrote: > This brightened up my Monday morning. > > Cheers > Joe > > On Mon, Oct 26, 2015 at 11:43 AM, Michael Kliewe

Re: [PHP-DEV] JsonSerializable New Interface method Proposal

What about JsonDeserializable? I would like to have the choice to have a serialize-only operation. On Mon, Jul 13, 2015 at 10:13 AM, Dean Eigenmann dean.eigenm...@icloud.com wrote: The Additional function you have proposed seems like the easiest and best way to do it currently without changing

[PHP-DEV] STH and the 3 RFCs

Hi internals, I carefully read all 3 proposed RFCs related to scalar type hints. As an end user and enthusiast of the language, I want PHP to always improve. STH is *the* major inclusion for PHP 7 and no matter how many people say about phpng performance, STH is the one that will impact mostly

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

+1 on this, as this is more inline with how ZPP currently works, creating less headaches to end users. On Fri, Mar 13, 2015 at 2:33 PM, Stelian Mocanita steli...@php.net wrote: So to get it clear for everyone: the right way is for internals to ignore community as a whole, stick to their own

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

PM, Zeev Suraski z...@zend.com wrote: -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 Types

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

I'll switch my vote on STH v5 to YES. If we get Basic STH into voting phase, I change my vote to NO and vote on YES on Basic STH. []s, On Fri, Mar 13, 2015 at 6:35 PM, Pierre Joye pierre@gmail.com wrote: On Mar 14, 2015 9:24 AM, Zeev Suraski z...@zend.com wrote: -Original

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

And none answered me... is this RFC gonna be allowed to enter on voting phase for 7.0 or not? This drastically changes my voted on STH v5 which ends EOD today. []s, On Fri, Mar 13, 2015 at 6:17 PM, Stelian Mocanita steli...@php.net wrote: Zeev, allow me to understand how this goes. Bob's

Re: [PHP-DEV] Consistent function names

@Rasmus: I don't see what's the problem of aliasing functions for the next 1-2 majors, deprecate the inconsistent one in the following and remove later. On Wed, Mar 4, 2015 at 10:33 AM, Trevor Suarez ric...@gmail.com wrote: ... well that's a constructive way of going about it. I don't think

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

+1 on Sebastian's suggestion. =) I volunteer to either update the RFC or create a new one to resolve this once Exceptions in the engine passes (which looks like a reality already to me). Just tell me which approach I should take and I'll happily write the RFC. []s, On Fri, Feb 27, 2015 at 9:47

[PHP-DEV] Getting function namespace at runtime

Hi internals, I came really close to reach the final state of my to be proposed private class, interface and trait support here. However, I have a bug under this circumstance: https://gist.github.com/guilhermeblanco/3392925014c9f8374acc I'd love if someone could give me a hand on how could I get

Re: [PHP-DEV] Annotations in PHP7

Hi Dmitry, Are you (and Doctrine team) interested in this annotation idea? I'd say that Benjamin nailed in our possible usage: orm(new Entity(foo)) class Foo { } Now I do feel we need to elaborate some sort of named parameters. Doctrine tries to simplify a lot developer's life by using

Re: [PHP-DEV] Annotations in PHP7

François, Doctrine relies on nested annotations for a variety of mapping information. One example: http://doctrine-orm.readthedocs.org/en/latest/reference/association-mapping.html#one-to-many-unidirectional-with-join-table []s, On Tue, Feb 17, 2015 at 4:33 PM, François Laupretre

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

Hi, I read again and again the RFC and I just decided to switch my vote. Originally a YES voter, I'm now a NO voter. I still want strict types to exist in PHP, and not only at the end-user level, but also at the internals level (I can see so many optimizations around...). However, I think it's

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

:12, guilhermebla...@gmail.com wrote: I read again and again the RFC and I just decided to switch my vote. Originally a YES voter, I'm now a NO voter. I still want strict types to exist in PHP, and not only at the end-user level, but also at the internals level (I can see so many

Re: [PHP-DEV] Design by Contract

Hi Yasuo, Design by Contract could be used at the top of Annotation if (and only if) it also had support for Interceptors. Since it could potentially be a nightmare for PHP, I don't think it's time to propose something at the top of another thing that is still far from being reality. It would

Re: [PHP-DEV] Design by Contract

...@ohgaki.net wrote: Hi Guilherme, On Mon, Feb 9, 2015 at 11:58 AM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Design by Contract could be used at the top of Annotation if (and only if) it also had support for Interceptors. Since it could potentially be a nightmare for PHP, I don't

Re: [PHP-DEV] Design by Contract

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

Re: [PHP-DEV] Design by Contract

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

Re: [PHP-DEV] Design by Contract

be placed. []s, On Fri, Feb 6, 2015 at 10:12 AM, 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

Re: [PHP-DEV] Design by Contract

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

Re: [PHP-DEV] Design by Contract

over time and we now have it return only its FQCN. []s, On Thu, Feb 5, 2015 at 11:10 PM, Pierre Joye pierre@gmail.com wrote: On Fri, Feb 6, 2015 at 11:08 AM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi all, I already said before and I'm happy to say it again

Re: [PHP-DEV] Design by Contract

Hi all, I already said before and I'm happy to say it again... Whenever you feel ready to get true, complete Annotations into core, just tell me and I'll be ready to work on previously suggested Annotations in sync with current internals. Cheers, On Thu, Feb 5, 2015 at 11:00 PM, Pierre Joye

Re: [PHP-DEV] Annotated PHP 5-7 extension diff

Hi Rasmus, Thanks for the highlight. My biggest concern about all this breakage done for NG could somehow be minimized by providing possible alternate implementations that could work both backwards compatible and forwards compatible? I just don't want to work on extensions I support that would

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

Hi Stas, As I said, we should look at that patch as we implemented Named Parameters there with everything you mentioned. Cheers, On Wed, Jan 14, 2015 at 3:23 PM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! -1 on this proposal +1 on named parameters Come on, we've already talked

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

Hi, -1 on this proposal +1 on named parameters As of for this... handy and easier. I could dig the archives but I don't remember what was the reason why we rejected the idea back then. Bikeshedding about the syntax mostly, but that all pales compared to amount of work that needs to be

Re: [PHP-DEV] [RFC] Package private class

Hi Robert, Answers inline. On Tue, Dec 23, 2014 at 7:59 AM, Robert Stoll p...@tutteli.ch wrote: -Ursprüngliche Nachricht- Von: Leigh [mailto:lei...@gmail.com] Gesendet: Dienstag, 23. Dezember 2014 04:34 An: guilhermebla...@gmail.com Cc: PHP internals Betreff: Re: [PHP-DEV

Re: [PHP-DEV] [VOTE] Abstract final / Static classes

2014, at 00:35, guilhermebla...@gmail.com wrote: RFC is updated exposing both possible usages with both explanations. Hope it doesn't confuse even more. Hi, in your As static class” example, it doesn’t really demonstrate that you can omit the “static” modifier from the function declarations

[PHP-DEV] [RFC] Package private class

Hi internals, I finalized a new proposal for PHP. It consists into adding support for package-private classes in the language. A package private class is basically a class that can only be instantiated in its declared namespace. This means that you cannot extend, implement or use a class,

Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols

+1 for adding E_DEPRECATED and removing support in PHP 8. On Mon, Dec 22, 2014 at 11:17 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Sat, Dec 20, 2014 at 11:01 PM, F N Laupretre nf.laupre...@yahoo.fr wrote: Hi, I don't know if this was discussed before. So, tell me what you think

Re: [PHP-DEV] [VOTE] Abstract final / Static classes

, Pascal Martin, AFUP mail...@pascal-martin.fr wrote: On 12/12/2014 17:12, guilhermebla...@gmail.com wrote: Patches are now complete and voting phase starts now and will be active until 12/19/2014. https://wiki.php.net/rfc/abstract_final_class Hi, After speaking about this RFC with other

Re: [PHP-DEV] [RFC][VOTE] Objects as Keys

Hi, Answering the question of Christopher Becker. It is not possible to traverse and get your desired elements. How would you achieve a foreach by key (returning object) without having to store a separate list and track by hash or through an interface? Cheers, On Wed, Dec 17, 2014 at 10:04 AM,

Re: [PHP-DEV] [RFC][VOTE] Objects as Keys

Hi, I originally considered you could retrieve the object key, but if it is not possible by this RFC, I will switch my vote to no. By storing hash one way it introduces a huge wtf to the language. Cheers, On Dec 17, 2014 8:40 PM, Rowan Collins rowan.coll...@gmail.com wrote: On 17/12/2014

[PHP-DEV] [VOTE] Abstract final / Static classes

Hi internals, After a good round of discussion, I updated the original abstract final class proposal into a static class proposal. However, I kept both patches online so it's up to voters decide which one it could be implemented. Patches are now complete and voting phase starts now and will be

Re: [PHP-DEV] [VOTE] Abstract final / Static classes

It's part of the history of that RFC, accessible here: https://wiki.php.net/rfc/abstract_final_class?rev=1417060830 On Fri, Dec 12, 2014 at 11:18 AM, Florian Margaine flor...@margaine.com wrote: Hi, On Fri, Dec 12, 2014 at 5:12 PM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote

  1   2   3   >