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 "fo
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
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 havin
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
it
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 c
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
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
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
also
be a shame 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 claime
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:
https://github.com/php/php-src/commit/0adfa0339
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 vote
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 s
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 Ackroyd
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 11:
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:
> >
> >> I'd like to add a new T
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
-
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
>
> $ sapi/cli/php -r
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 06/12/16 16:30, Adam Barat
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 the WHATWG URL standard [1]? Quoting the fi
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
> true that anonymous c
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. So even if the use case
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, Class visibility, Collecti
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
Augu
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.
Her
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 vote.
> >
> > https:
@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
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
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 dev
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,
On Fri, Apr 29, 2016 at 4:55 AM, Jesse Schalken
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 about Generics in Doctrine
>&
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, 2016 at 4:54 AM, Levi Mor
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 understood
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...@gmail.com
On Mon, Apr 25, 2016 at 3:42 AM, Dmitry Stogov wrote:
>
>
> On 04/22/2016 06:39 PM, guilhermebla...@gmail.com wrote:
>
>
> On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov wrote:
>
>>
>>
>> On 04/22/2016 04:05 AM,
>> guilhermebla...@gmail.com wrote:
&
On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov 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 used metadata library writte
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 requi
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 B,
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 ne
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 used
g else),
> because 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
> *Sen
ke .NET and Swift).
Regards,
On Wed, Apr 20, 2016 at 11:01 AM, Rowan Collins
wrote:
> guilhermebla...@gmail.com wrote on 20/04/2016 03:54:
>
>> 1- Even though mentioned, I'd still use "extends" or "implements" instead
>> of "is" (which woul
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, facto
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 be
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 c
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 doctrine/annotations (
>> htt
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 uses
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 not
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
My code version is not complete, as the references changed when you include
the optional_type.
It shouldn't be hard to change though... like $$ = $3 and also hold $2
somewhere.
On Thu, Mar 31, 2016 at 2:09 PM, Zeev Suraski wrote:
>
> > On 31 במרץ 2016, at 20:48, "guilhe
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,
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, Matthew
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
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 for
Answers inline
On Thu, Nov 26, 2015 at 11:58 AM, Chris Riley 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 other
>> situations (
update the RFC.
[]s,
On Thu, Nov 26, 2015 at 10:53 AM, Rowan Collins
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.
>
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 u
ee this natively
available and just exposes your lack of interest into language improvement.
Regards,
On Wed, Nov 25, 2015 at 5:03 PM, Rowan Collins
wrote:
> On 25 November 2015 19:02:37 GMT, "guilhermebla...@gmail.com" <
> guilhermebla...@gmail.com> wrote:
> >Hi Rowa
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 do
the beginning about shared hosting, you just entered
in an infinite loop.
On Wed, Nov 25, 2015 at 1:50 PM, Pedro Cordeiro
wrote:
> On top of it, it'd break obfuscators like Zend Guard.
>
> 2015-11-25 15:58 GMT-02:00 guilhermebla...@gmail.com <
> guilhermebla...@gmail.com>:
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 docblocks, but I don't think t
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 a
+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
> > b) do RC8, assume there are no bugs, s
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 Drupal core developers I n
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 cla
ssary to finalize 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 wrote:
> Hi Guilherme,
>
> guilhermebla...@gmail.com wrote:
>
> Currently, ther
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 to
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
> wrote:
>
> > Hi Frank,
> >
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
wrote:
> The Additional function you have proposed seems like the easiest and best
> way to do it currently without changing the language. I was thi
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 wrote:
> On Mar 14, 2015 9:24 AM, "Zeev Suraski" wrote:
> >
> > > -Original Message-
> > > From: stelian.
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 wrote:
> Zeev, allow me to understand how this goes. Bob's discussions on the R
, 2015 at 9:44 PM, Zeev Suraski wrote:
> >
> > > > -Original Message-
> > > > From: Derick Rethans [mailto:der...@php.net]
> > > > Sent: Friday, March 13, 2015 10:34 PM
> > > > To: guilhermebla...@gmail.com; Stelian Mocanita
+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 wrote:
> So to get it clear for everyone: the right way is for internals to ignore
> community as a
> whole, stick to their own views and imple
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
eve
@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 wrote:
> ... well that's a constructive way of going about it. I don't think Yasuo
> did anythi
+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:4
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 ge
Hi Dmitry,
> Are you (and Doctrine team) interested in this annotation idea?
I'd say that Benjamin nailed in our possible usage:
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 consistency in default
map
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
wrote:
> Hi A
gt;
> > On 9 Feb 2015, at 18: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
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
, Yasuo Ohgaki 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
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 foll
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
hould 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
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
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
ly changed over time and we now have it return only its FQCN.
[]s,
On Thu, Feb 5, 2015 at 11:10 PM, Pierre Joye wrote:
> On Fri, Feb 6, 2015 at 11:08 AM, guilhermebla...@gmail.com
> wrote:
> > Hi all,
> >
> > I already said before and I'm happy to say it again...
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 wro
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 nev
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
wrote:
> Hi!
>
> > -1 on this proposal
> >
> > +1 on named parameters
>
> Come on, we've already talked about it
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 t
Hi Robert,
Answers inline.
On Tue, Dec 23, 2014 at 7:59 AM, Robert Stoll wrote:
>
>
> > -Ursprüngliche Nachricht-
> > Von: Leigh [mailto:lei...@gmail.com]
> > Gesendet: Dienstag, 23. Dezember 2014 04:34
> > An: guilhermebla...@gmail.com
> > Cc: PHP
+1 for adding E_DEPRECATED and removing support in PHP 8.
On Mon, Dec 22, 2014 at 11:17 PM, Ferenc Kovacs wrote:
> On Sat, Dec 20, 2014 at 11:01 PM, F & N Laupretre
> wrote:
>
> > Hi,
> >
> >
> >
> > I don't know if this was discussed before. So, tell me what you think
> > before
> > I write an
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, interfa
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” mod
at 6:54 PM, 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_fin
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" wrote:
> On 17/12/2014 22:05, Rowan Collins wrot
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, D
> On Tue, Dec 16, 2014 at 9:39 AM, Matteo Beccati
wrote:Hi Guilherme,
>
>> On 16/12/2014 12:34, Guilherme Blanco wrote:
>> Hi,
>> All I can say is that the lack of this feature is one of the main
reasons why Doctrine doesn't fully work with composite keys.
>> With this enhancement it would now bec
RFC is updated exposing both possible usages with both explanations.
Hope it doesn't confuse even more.
On Fri, Dec 12, 2014 at 11:30 AM, Florian Margaine
wrote:
>
> Hi,
>
> Le 12 déc. 2014 17:28, "guilhermebla...@gmail.com" <
> guilhermebla...@gmail.com>
1 - 100 of 221 matches
Mail list logo
