anguages like Python can do. If this is the case, we don't reverse the
trend by making our language more syntactically or behaviorally like the
other languages out there. We reverse it by supporting the features that
are currently lacking, or, adding features that other languages don't have.
--
Chase Peeler
chasepee...@gmail.com
On Mon, Sep 16, 2019 at 10:12 AM Benjamin Eberlei
wrote:
>
>
> On Mon, Sep 16, 2019 at 3:47 PM Chase Peeler
> wrote:
>
>> On Sun, Sep 15, 2019 at 8:14 AM Zeev Suraski wrote:
>>
>> > On Sun, Sep 15, 2019 at 1:15 PM Olumide Samson
>> > wrote:
ity' happening there. Putting each in a separate vote
> would have likely not thoroughly solved this, but it would have probably
> been a good first step, allowing more granular choice. I think that this
> particular change (requiring separate votes for each change) can be done
> relatively easily within our existing framework - similar to the Abolish
> RFCs, if there's widespread agreement. In the context of Ben's email from
> a few weeks ago, I'll defer to someone else to propose it if they think it
> makes sense.
>
> Zeev
>
--
Chase Peeler
chasepee...@gmail.com
t we were OK with - which
goes back to something else Zeev mentioned, which is not putting so many
changes into a single RFC and/or a separate vote for each proposed change.
I personally favor limiting the number of changes in an RFC because I think
it's hard to focus the discussion, even if the votes are separated out.
> —Claude
--
Chase Peeler
chasepee...@gmail.com
>
> > > > Voting closes 2019-09-26.
> > > >
> > > > Regards,
> > > > Nikita
> > > >
> > >
> > > I just realized that I missed one notice here, because it is generated
> > from
> > > a different location: "Const
tentioned but accidental disruption people who are new to the
> group are causing, and so should be handled separately.
>
> # Problem 4 - Senior project members aren't following our email etiquette.
>
> Solution: I'll post an RFC to address this.
>
> cheers
> Dan
> Ack
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
On Wed, Aug 7, 2019 at 1:00 PM Peter Kokot wrote:
> Hello.
>
> On Wed, 7 Aug 2019 at 18:56, Chase Peeler wrote:
> >
> >
> >
> > On Wed, Aug 7, 2019 at 12:45 PM Peter Kokot
> wrote:
> >>
> >> On Wed, 7 Aug 2019 at 16:14, Zeev Suraski wrote
passes, then it will be implemented as proposed. If it fails, then
treatment of short tags will remain as it currently is.
I hope you will reconsider your decision to not vote on this new RFC. I
understand your concerns. As someone that didn't like the outcome of the
first vote either, I also didn't feel that a revote just because a lot of
people decided to speak up after the fact was the correct course of action.
I don't think that is what is happening here, though.
--
Chase Peeler
chasepee...@gmail.com
o upgrade
would be so high that it's likely I would never get approval from my
superiors to spend that much time on it.
> I don't have a vote, but if I were I would vote "yes". Instead, I encourage
> "no"-voters to reconsider, and others to vote "yes" too :)
>
> Cheers,
> Nicolas
>
--
Chase Peeler
chasepee...@gmail.com
> Best regards
>
> George P. Banyard
>
> [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2
>
--
Chase Peeler
chasepee...@gmail.com
On Tue, Aug 6, 2019 at 1:19 PM G. P. B. wrote:
>
>
>
> On Tue, 6 Aug 2019 at 19:12, Rowan Collins
> wrote:
>
>> On Tue, 6 Aug 2019 at 17:59, Chase Peeler wrote:
>>
>> > I'm not a voter, but, I have a question. If this fails, does that mean
>&g
ng them, no matter how painful
that might be. That's actually an OK thing to do if the reasons for doing
so justify it. I have yet to see the justification. All I've seen is people
attempt to mitigate the cost of the break, or, say the cost doesn't really
matter.
> --
> Arvīds Godjuks
>
> +371 26 851 664
> arvids.godj...@gmail.com
> Skype: psihius
> Telegram: @psihius https://t.me/psihius
>
--
Chase Peeler
chasepee...@gmail.com
On Thu, Aug 8, 2019 at 10:42 AM Peter Kokot wrote:
> Hello,
>
> On Thu, 8 Aug 2019 at 16:17, Chase Peeler wrote:
> >
> > On Thu, Aug 8, 2019 at 9:35 AM Zeev Suraski wrote:
> >
> > > On Thu, Aug 8, 2019 at 3:17 PM Brent wrote:
> > >
> > &
kfully, it's not nearly that big of a Thing for us to be concerned
> about.
>
> We need to get rid of the display_errors ini directive as well. It
definitely shouldn't default to "1" or be set to "1" in the sample files
distributed with PHP. I would think this is a much greater security risk
than short tags. While we're at it, we need to get rid of the ability to
even set custom error handlers. If a programmer doesn't use that correctly,
they could still end up exposing error messages that contain sensitive
data.
> Zeev
>
--
Chase Peeler
chasepee...@gmail.com
union types and reflection, a method which returned one string would
> > need to return an array, or just the first, and so on.
> >
> > A "separate" version would certainly be easier. The ability to rip out
> > everything which wasn't kept would no doubt simplify a lot of t
yet to see anyone give an actual example where they have been
negatively impacted by their existence. I've given you my personal story of
how removing them will negatively impact my company. I welcome anyone that
can provide an actual incident where the existence of short tags hurt them,
or, the continued existence is likely to have a large negative impact on
them in the future.
> Zeev
>
--
Chase Peeler
chasepee...@gmail.com
Frankly I
> think that's *super cool*, and a great way of balancing the prototyping
> benefits of dynamic languages (which are most seen at small scale
> codebases) and the robustness/safety of more refined type system (which are
> most seen in larger code bases) within a single ec
ink this RFC
handles the deprecation process much better. My objections to the previous
RFC were two-fold: 1.) benefits didn't outweigh harms and 2.)
deprecation/removal path was dangerous and harmful.
I still think #1 applies to this RFC. I do not think #2 does. While I agree
with some others that the it might be better to postpone the decision about
the ultimate removal to a later date, I don't think slating it for 9.0 is
that big of a deal. I think it also gives people much more time to adapt
than previous road maps.
--
Chase Peeler
chasepee...@gmail.com
, visit: http://www.php.net/unsub.php
>
>
Would the removal votes be limited to the same people able to vote on RFCs,
or open to all list members?
--
Chase Peeler
chasepee...@gmail.com
On Thu, Sep 19, 2019 at 1:36 PM Dan Ackroyd wrote:
> On Thu, 19 Sep 2019 at 18:33, Chase Peeler wrote:
> >
> > Would the removal votes be limited to the same people able to vote on
> RFCs,
>
> Yes, that's correct.
>
> cheers
> Dan
>
So, in other words, if
I've copy/pasted Kalle's email at the bottom so that I can address points
made in both emails without risking someone getting distracted from the
myriad of emails relating to coordination of work on PHP.
On Thu, Sep 19, 2019 at 2:11 PM Mark Randall wrote:
> On 19/09/2019 18:38, Chase Pee
to contribute.
> Anyway, the vote is done, I said my piece and will shut up about it now,
> - Chris
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
t; >> case 'x', 'y', 'x' => 3,
> >> default => null,
> >> };
> >>
> >
> > That's exactly my proposal with commas, see here:
> >
> https://wiki.php.net/rfc/switch-expression-and-statement-improvement#switch_expression_introduction
> > Unfortunately, this RFC needs more work cause it mixes switch statement
> > enhancement with comma-separated list syntax and of switch statement - I
> > need to split it into two RFC's
> >
> > This is nice hearing that this idea has an interest.
> > As soon as the RFC will be split and finished I can start a discussion
> > thread.
> >
> > Cheers,
> > Michał Brzuchalski
> >
>
--
Chase Peeler
chasepee...@gmail.com
nd voting. I think there
are many ways it could be done, but all of them would require additional
time and dedication from people already putting in a lot of time and
dedication to the development process itself.
By keeping the review process manual, we can also easily revoke someone's
> voting rights if the application turned out to be fraudulent (accepted by
> mistake).
>
> — Benjamin
>
--
Chase Peeler
chasepee...@gmail.com
compromising with the side
that doesn't want to go there.
> Walter
>
> --
> The greatest dangers to liberty lurk in insidious encroachment by men of
> zeal, well-meaning but without understanding. -- Justice Louis D.
> Brandeis
>
--
Chase Peeler
chasepee...@gmail.com
be wrong,
and welcome examples where we've deprecated something where the end goal
wasn't removal. Assuming I'm correct though, that provides a pretty strong
reason for why we wouldn't start doing it now.
--
Chase Peeler
chasepee...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
that you use it to output text. cout <<
"Hello World"; It was SO confusing, because they also have printf which can
be used to output text. I decided that c++ is obviously a garbage language
and gave up. Not sure why anyone would ever use it!
> --
> Stas Malyshev
> smalys...
they provide, since it still exists in the hash_file function.
If you don't like the function, then don't use it.
--
Chase Peeler
chasepee...@gmail.com
in the
> user land for general array behavior when reading or looping.
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
, though, anything about
the immutable type hints. That's really the only thing that I think is
applicable to operator overloading.
--
Chase Peeler
chasepee...@gmail.com
ersonally in favor of anything that is going to allow us to create
array-like objects that can be treated like arrays. I personally hate
having to write:
if(is_object($var)){
$x = [$var];
} else {
$x = (array)$var;
}
No, the other question is whether we do it with a magic method, like
__toArray() or an interface. I personally like magic methods, but, in the
end I'm ambivalent on that.
--
Chase Peeler
chasepee...@gmail.com
ion;'? Everything that
I can think of that accepts a function name, also accepts a callable (e.g.
array_map), but I could be forgetting something.
If not, then I think it makes sense to return a callable. It might not be
entirely consistent with the behavior of ::class, but, a class isn't
entirely consistent with a method/function either, so I think there is some
latitude for small differences.
As for the ::func vs ::function. I think ::function is safer, since it's a
reserved word. Otherwise you might run into issues with something like this:
class foo {
const func = "bar";
}
function foo(){}
echo foo::func;
Probably not something that happens very often, but, I think the 4 extra
characters to prevent it would be worth it.
--
Chase Peeler
chasepee...@gmail.com
mjo...@pmjones.io
> http://paul-m-jones.com
>
> Modernizing Legacy Applications in PHP
> https://leanpub.com/mlaphp
>
> Solving the N+1 Problem in PHP
> https://leanpub.com/sn1php
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
e
some of the justifications that have been used so far" someone might better
be able to determine if their RFC for such a topic is justifiable, and if
so, preempt some of the objections.
--
Chase Peeler
chasepee...@gmail.com
e git churn would be horrific. Do not want. If we really
> wanted "pretty var_export", then there'd be no real choice BUT to use a
> library script to do the serializing.
>
> -Sara
>
I'm with Sara on this, which shouldn't be a big surprise.
Just out of curiosity, is there any reason we
em" arguments pop up. While
the chances of a BC break might be minimal using "Attribute" - I don't
think that PhpAttribute is an undue burden in an attempt to avoid such
instances, nor is it logically inconsistent with other Php* named classes.
--
Chase Peeler
chasepee...@gmail.com
y);
foreach($keys as $key){
That would obviously break the optimization we're talking about though.
Which makes me wonder if there are other places like that.
> Thus not iterating the array twice and creating a temporary array of key
> names.
>
> -Sara
>
--
Chase Peeler
chasepee...@gmail.com
generation is
> > expensive. But that is out of scope for this RFC.)
> > >
> > > If this is something we'd like for PHP 8.1 and there are no major
> > objections to the idea, then after 8.0 is released, I can move the RFC
> out
> > of Draft and into Under Discussion, and presuming a vote passes, I'll
> > update the patch as necessary to work against 8.0. But my time is limited
> > and I'm not willing to put further time into the code unless an RFC vote
> > passes.
> > >
> > > Thoughts anyone?
> >
> > +1 from me.
> >
> > BTW, your RFC says "Next PHP 7.x" for Proposed Version; might need to
> > update that?
> >
> > -Mike
>
--
Chase Peeler
chasepee...@gmail.com
aven’t seen many people using
> the single underscore to represent instance variables anymore.
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Isn't the underscore an alias for gettext()?
--
Chase Peeler
chasepee...@gmail.com
l_functions_via_new_opcode_instructions
>
That's a good starting point, thanks.
>
> Best regards,
> Benas
>
> On Tue, Sep 15, 2020, 4:44 PM Chase Peeler wrote:
>
>> I wasn't proposing that my example be supported. I'm totally okay with
>> the fact that it doesn
as an
> optimized `strlen` function works.
>
> That means that the optimization is only going to be applied if the
> `array_keys` function is used directly in the `foreach` loop and only if a)
> either the namespace is global b) or `\array_keys(...)`/`use function
> array_keys` is used.
t I was wondering, is if there are other optimizations I might be
missing out on, and if so, are they documented anywhere?
--
Chase Peeler
chasepee...@gmail.com
> closure. I don't really see a need to do that in C.
> >
> > --Larry Garfield
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
s. As the RFC says, the
> pragmatic decision was taken to defer these errors to runtime.
> >
> > It's worth noting that since PHP doesn't have checked exceptions, a
> child method throwing an error that it's parent wouldn't is already
> possible and not considered a violation: https://3v4l.org/3m7eo
> >
> > Regards,
> >
> > --
> > Rowan Tommins (né Collins)
> > [IMSoP]
--
Chase Peeler
chasepee...@gmail.com
eason
building it is pretty easy is because it was developed to be built on
Windows. If that stops happening, then building it myself, with or without
PGO, will become pretty much impossible as well.
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
g.
I have no problem changing these terms if they are changed industry wise
and the new terms are needed to keep up with industry standards. I might
not agree with why they were changed in other arenas, but, at the point new
terms become standard, the reason they became standard doesn't really
matter. So, as others have said, this and other discussions about renaming
terms because some might find them offensive is not something we should be
doing. Renaming terms in order to align with changes to industry standards,
while something we should do, is premature at this point as those standards
have yet to change.
--
Chase Peeler
chasepee...@gmail.com
://lsces.uk/wiki/Contact
> L.S.Caine Electronic Services - https://lsces.uk
> Model Engineers Digital Workshop - https://medw.uk
> Rainbow Digital Media - https://rainbowdigitalmedia.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
think it is time
> > to rename this token.
> >
> > This is backwards compatible with PHP 7 and 5.
> > This RFC does not lay out a plan for deprecating T_PAAMAYIM_NEKUDOTAYIM
> > and leaves this as a future scope.
> >
> > As the matter on hand is a relati
es. I'm somewhat sympathetic to the symbolic reasons for keeping it
around. I don't think such reasons outweigh the benefits though. The only
valid solution I would support that didn't rename the token would be if we
removed that token from the error messages altogether. I think that would
be more likely to cause issues, though, since there could be tests that
need SOME sort of token specified.
--
Chase Peeler
chasepee...@gmail.com
ice.
>
>
I agree with this. I'd also add that in this case, we aren't even feeding
this troll. He lurks on the list and sends private replies to people.
Usually those replies nitpick on something that isn't even the main point
of the discussion. The only way to "not feed" this troll would be to not
participate at all.
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
eplies
humorous because they are just SO out there and unwarranted. They take
trolling to a whole new level in my opinion. If we want to avoid possible
legal issues, I think we could still send the replies to the list, after
removing any contact information that is included, and no one would have
any trouble figuring out who it is.
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
the body was intended but never actually done. I know
that when I'm writing new classes I often will set up the method signature
but leave the method body empty while I finish the code that utilizes that
method. I don't know if that is justification for the proposal, but it is
one reason why ; might be preferred over {}.
--
Chase Peeler
chasepee...@gmail.com
also be useful to document somewhere, so people
> > like me can actually use it :)
> >
> > Even then, I also don't think it offers an option to bottom-post by
> > default - which K-9 and Thunderbird do.
> > (No idea about the Gmail web client - I don't use it regularly.)
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
> >
>
--
Chase Peeler
chasepee...@gmail.com
d a number of strong arguments why it should not happen,
> but I also think this deserves its chance to be fleshed out and voted on,
> so by all means, do work the RFC.
>
> -Sara
>
--
Chase Peeler
chasepee...@gmail.com
> <mailto:mrtrei...@gmail.com>> wrote:
> > > If there are no super strong arguments on why this should not
> > happen or go
> > > to RFC, I will draft a RFC and from there, the usual process
> > applies.
> > >
> >
> > I think you've heard a number of strong arguments why it should not
> > happen, but I also think this deserves its chance to be fleshed out
> > and voted on, so by all means, do work the RFC.
> >
> > -Sara
>
>
--
Chase Peeler
chasepee...@gmail.com
On Tue, May 11, 2021 at 10:36 AM Sara Golemon wrote:
> On Tue, May 11, 2021 at 9:21 AM Chase Peeler
> wrote:
> > On Tue, May 11, 2021 at 2:34 AM Mel Dafert wrote:
> > > (Gmail certainly can't, it can't even send non-HTML mails, and even
> with
> >
say that mobile clients don't matter - if we want to make
> it easy for new people to join,
> we should also make sure we support using mobile.
>
> Regards,
> Mel
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
> --
Chase Peeler
chasepee...@gmail.com
e. The
flexibility that PHP offers has always been one of its greatest strengths
and this just further erodes that.
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
t; > > > final class None extends Maybe {}
> > >
> > > This is exactly the thing I'm worried about.
> > >
> > > Say I want to add something like logging to the None type.
> > > Now your sealed and final classes prevent me from defining MyNone
> > > extending None even though it would be 100% compatible with None.
> > >
> >
> > I just want to note that this has nothing to do with Maybe made sealed
> > (which seems legit), only with None made final (which... could be
> debated,
> > but unrelated to the RFC at hand).
> >
> > Regards,
> >
> > --
> > Guilliam Xavier
> >
>
--
Chase Peeler
chasepee...@gmail.com
On Tue, Apr 27, 2021 at 2:57 PM Olle Härstedt
wrote:
> 2021-04-27 20:17 GMT+02:00, Chase Peeler :
> > On Tue, Apr 27, 2021 at 1:56 PM Levi Morrison via internals <
> > internals@lists.php.net> wrote:
> >
> >> I think the conversation on final classes being &qu
of the ways classes can be used in PHP,
then we should make them available even if that means they end up getting
used with the ways that they don't make sense. My feeling is that we
shouldn't introduce something that would cause restrictions where they
don't make sense just so we can have them where they do.
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
ToString() method instead of requiring me to also add "implements
> Stringable" to the class definition.
>
> Those three features are all killer language features and would make great
> additions to PHP. IMO, of course.
>
> #fwiw
>
> -Mike
>
> [0] https://stackify.com/solid-design-open-closed-principle/
> [1] https://travix.io/type-embedding-in-go-ba40dd4264df
> [2] https://go101.org/article/type-system-overview.html
> [3]
> https://blog.carbonfive.com/structural-typing-compile-time-duck-typing/ <
> https://blog.carbonfive.com/structural-typing-compile-time-duck-typing/>
--
Chase Peeler
chasepee...@gmail.com
it's very much just a personal anecdote, but since
I don't turn deprecation notices on until I'm ready to actually look for
and fix them, I don't find them obtrusive at all.
--
Chase Peeler
chasepee...@gmail.com
changing is `Spl$thing` to `Spl\$thing`.
>
>
I think Spl makes sense (there might be a debate over whether it should be
Spl or SPL though). How feasible is it to create generate a deprecation
notice when the global version is used? I assume the hope is to eventually
move away from using those, and I don't think that's a horrible BC break
given that users have enough time to prepare for it.
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
these RFCs?
>
> Nikita
>
I guess my one question would be why we didn't support auto-capture when we
first implemented anonymous functions, and if there was a reason, why does
that no longer apply?
--
Chase Peeler
chasepee...@gmail.com
On Wed, Mar 24, 2021 at 1:34 PM Christian Schneider
wrote:
> Am 24.03.2021 um 18:15 schrieb Chase Peeler :
> > I guess my one question would be why we didn't support auto-capture when
> we
> > first implemented anonymous functions, and if there was a reason, why
> does
>
y behave differently like that is
great in my opinion. I use function(){} when I want the changed context
(like event listener callbacks) and () => {} when I know I only need access
to the parent context and don't care about any possible redefinition.
>
> For me auto capture is a solid +1.
>
>
tant than
> writable.
>
I'm a bit confused on why "shorter" is such an important requirement as
well. We aren't in a situation where memory is at a premium and we have to
take shortcuts to get our code to fit in the available storage. I also
assume that none of us are such slow typers that there is a material
difference between the options. On top of that, most IDEs worth anything
have autocomplete options that make it moot.
I agree that shorter definitely does not always mean more readable. If so,
we'd be taught to give all of our functions and variables single character
names instead of names that were descriptive.
I'm totally in favor of auto capture with the fn() syntax, but I think the
fact that its shorter is not the best argument to support it.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
coping, but the
fact that PHP has never been blocked scoped means there would be a LOT of
code that would break if it was.
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
gt; --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
with a defined
signature. "Use function() use()" in that case might be a valid solution,
but just wanted to throw it out there. Silly example:
$counter = 0;
array_map(fn($a) => {$counter++; return $a+1},$array);
If you tried to pass in $counter as a parameter, it would fail.
> -Mike
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
e few cases where this isn't a code smell, it's
> unnecessary.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
ercanonlybeusedintheamphpframeworkandisof
> novaluetootherphpprojects.
>
>
> Hi,
>
>
> Idliketoseeyouelaborateonthispoint.Areyouabletoprovide
> anythingtobackupthisclaim?
>
>
> Idontseeanythingthatisspecifictoamphp,notanythingtolimititto
>
> theiruse.FibersalsoexistoutsideofPHP,whileamphpdoesnt.
>
> Thanks,
> Peter
--
Chase Peeler
chasepee...@gmail.com
P Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
rhaps neverreturn would be an option that would be
less likely to have BC risks.
Just to throw out some additional ideas, why not two possible types: throws
and exits? Don't have any strong opinions on that, but figured I'd add it
to the discussion.
> Best wishes,
>
> Matt
>
--
Chase Peeler
chasepee...@gmail.com
, and bears no relationship to the original
> string; it is what is generally referred to as "mojibake".
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
tw I would prefer that all RFC votes were longer (e.g. 4 weeks for
> all decisions that don't have an external time constraint), but
> changing the end time during the vote is bogus.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
On Wed, Feb 24, 2021 at 11:35 AM Mike Schinkel wrote:
>
> On Feb 24, 2021, at 11:27 AM, Chase Peeler wrote:
>
> On Tue, Feb 23, 2021 at 11:27 PM Mike Schinkel
> wrote:
>
>> > On Feb 23, 2021, at 2:05 PM, Rowan Tommins
>> wrote:
>> >
>>
To emphasize this feature address templating use-cases one might argue
> that dropping the "or" case of the trinary might only be supported when
> between single-line "" delimiters.
>
> -Mike
>
> P.S. Of course making it work differently between single-line delimiters
> and elsewhere would create inconsistency in the language so I probably
> would not actually argue that, I was just trying to make a rhetorical point.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
ugar, and we already have
> ?:, ??, ??=, ?->. I don't think there's space for yet another shorthand
> conditional syntax.
>
>
I don't really have any strong feelings on this either way, but ?! seems
like a logical choice if it was to be implemented.
> Note that => cannot be used for this purpose, as it is already used for
> array literals.
>
> Regards,
> Nikita
>
--
Chase Peeler
chasepee...@gmail.com
|
> | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
> | https://andreas.heigl.org |
> +-+
> | https://hei.gl/appointmentwithandreas |
> +-+
>
>
--
Chase Peeler
chasepee...@gmail.com
ad no idea that it was double-sending messages to folks when I did
> reply-all. My mail client must filter the messages appropriately so that I
> only see one message, and I don’t have a reply-to-list option.
>
> Cheers,
> Ben
>
>
>
The gmail web client has the sender as the reply-to, and the list in the cc
(at least in this case). On the receiving side, I don't get duplicates, so
I assume gmail is smart about filtering those out.
--
Chase Peeler
chasepee...@gmail.com
the lack of that would be a
reason to vote against it - especially since the possibility is still open
in the future and adding it wouldn't cause any BC issues.
--
Chase Peeler
chasepee...@gmail.com
On Wed, Feb 17, 2021 at 12:41 PM Ben Ramsey wrote:
> > On Feb 17, 2021, at 09:26, Chase Peeler wrote:
> >
> > On Wed, Feb 17, 2021 at 10:09 AM Rowan Tommins
> > wrote:
> >
> >> On 17/02/2021 14:30, Larry Garfield wrote:
> >>> The Enum RFC ha
> > > example floor() outputs a float, but in the context of the domain I'm
> > > working I might know that the result is never going to exceed a certain
> > > value and want the result explicitly as an int.
> >
> >
> > Perfect, so (int) floor() would work wonders for you, even with the
> strict
> > casting I'm talking about.
> > And if the result does overflow an integer one day, I'm sure you'd be
> happy
> > to know it by getting an exception, rather than getting silently ZERO:
> >
> > echo (int) 1e60; // 0
> >
> > — Benjamin
> >
>
--
Chase Peeler
chasepee...@gmail.com
; Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Please don't do this. Call it bad coding practices or not, but this was
something I've considered a feature of PHP and have actually built things
around it. It's not something that can be easily refactored since it was
part of the design.
--
Chase Peeler
chasepee...@gmail.com
;001" casted to 1 will then get casted back to "1" not "001".
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
On Mon, Jan 3, 2022 at 10:48 AM Rowan Tommins
wrote:
> On 3 January 2022 15:41:48 GMT, Chase Peeler
> wrote:
> >But "001" casted to 1 will then get casted back to "1" not "001".
>
> "001" would not be cast to an integer in this context:
ger through libraries.
> Like, I'm pretty sure the OpenApiGenerator templates used dynamic
> properties for some things so how many little internal libraries are going
> to have to be regenerated? What other lightly maintained library are people
> going to be stuck waiting to update because someone's CI didn't catch the
> deprecation?
>
By design my REST API utilizes dynamic properties. I've always found it to
be a feature of PHP, not a bug.
>
> I think this sort of change is probably for the better, but I worry about
> how disruptive this could end up being.
>
--
Chase Peeler
chasepee...@gmail.com
ers.
Why is this surprising? It's been available since classes were introduced
to PHP.
> Making it attribute-only from 9.0
> onwards seems incredibly sensible.
>
> Best wishes,
>
> Matt
>
--
Chase Peeler
chasepee...@gmail.com
On Mon, Nov 15, 2021 at 3:11 PM Deleu wrote:
> By design my REST API utilizes dynamic properties. I've always found it to
>> be a feature of PHP, not a bug.
>>
>> --
>> Chase Peeler
>> chasepee...@gmail.com
>>
>
> I am in the unfortunate posit
o a reminder that deprecations are not errors; PHPUnit very recently
> changed to not complain about deprecations by default. And anyone running
> with deprecations on in production is doing it wrong and will get bitten
> whenever the deprecation is enabled.
>
> I have to agree with Nikita here. Give people as much deprecation time as
> possible; if people are misunderstanding deprecations and abusing them,
> that's... a different problem that cannot be solved by not issuing
> deprecations.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
I don't think this should be deprecated or removed at all. However, I agree
that if it is going to be removed, the more time/versions that exists
between deprecation and removal, the better.
--
Chase Peeler
chasepee...@gmail.com
e number of commits, projects worked on, etc.,
can be easily gamed. Allowing those that already have voting karma the
final decision over who gets voting karma is also problematic. Like Tobias,
I have gotten the "elitist" feeling at times from the group.
Finally, I think the idea of "approvals outweighing objections" is not
good. While it definitely is a purely objective measurement, it shows why I
think it is so hard (if not impossible) to find good measurements that are
purely objective. What if we get one objection that rightly says "This
person shows that they have no knowledge of how PHP actually works"
compared to two approvals saying "I like this person, so I'm OK with it"
--
Chase Peeler
chasepee...@gmail.com
lizing the interface automatically
within the type system. The more I think about it, the less I like this
idea, since it doesn't require that much additional work to make the code
clearer by explicitly implementing the interface on the class if you want
it implemented. However, I'll go ahead and leave it here because it might
help generate some other ideas.
--
Chase Peeler
chasepee...@gmail.com
troduces a meaningless choice that people can
> argue about in their code style, and have pointless git commits where
> they add or remove the modifier based on preference.
> Of course the same could be said about "public" in interface methods.
>
>
I personally don't like it when I don't have a consistent look to my code.
One of the things that bother me is code like:
function foo(){}
protected function bar(){}
function baz(){}
I want everything to have a visibility indicator for visual consistency.
That's why I always use public in my interface methods as well. So, even
though it won't cause confusion if omitted for an operator, since it can
only be public, I still think it should be allowed.
> -- Andreas
>
> >
> > Jordan
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
y it in any measure.
>
> Evil is a powerful word - one I do not use lightly. When one side calls
> another evil they say that there can be no more dialog, no more compromise,
> no more cooperation. The only correct response to evil is opposition.
>
--
Chase Peeler
chasepee...@gmail.com
beyond rational that it doesn't deserve a
> gentle
> > response.
> >
> > --Larry Garfield
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
>
>
> 100% agree with Larry. Banning people from PHP based solely on their
> ethnicity is easily the stupidest, most blatantly racist idea I have ever
> seen proposed here.
>
> Absolutely shameful.
>
>
> >
I took this as a satirical take on how many other sectors are reacting to
Russian invasion, not an actual position being advocated for.
> --
Chase Peeler
chasepee...@gmail.com
th of {$:strlen($name)}.";
>
>
Out of curiosity, why not:
$name = "Theodore Brown";
echo "{$name} has a length of ".strlen($name).".";
or even
$name = "Theodore Brown";
$len = strlen($name);
echo "{$name} has a length of {$len}.";
>
> Sincerely,
>
> Theodore
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
ys "PHP is against war". I would have absolutely no
> objection to that one.
>
As I’ve said before, I would have a problem with this. War is terrible and
should be avoided at all costs. However, there are times it is justified.
--
Chase Peeler
chasepee...@gmail.com
101 - 200 of 215 matches
Mail list logo
