rating system that the code is running on, then what about if I need
to generate a *nix style path even though I'm running on Windows, or vice
versa? My feeling is that for the function to be easy to use, you have to
cut out too many scenarios which causes users to have to fallback to their
own implementations anyway. Finally, there aren't going to be any
meaningful performance gains which would possibly justify not implementing
it in userland.
--
Chase Peeler
chasepee...@gmail.com
HP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
For those of us that don't know the finer details of the build process,
will that have any impact on the final product such as reduced binary sizes
or better performance? I'm not saying that code cleanup isn't a good enough
reason to do this on its own, just curious if there are other advantages
beyond that.
--
Chase Peeler
chasepee...@gmail.com
es,
especially in light of the fact it's really easy to accomplish this without
changes.
> —Claude
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
{$name} has a length 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
o far 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
On Sun, Mar 6, 2022 at 5:32 PM Kris Craig wrote:
>
>
> On Sun, Mar 6, 2022, 12:53 PM Chase Peeler wrote:
>
>>
>>
>> On Sun, Mar 6, 2022 at 3:40 PM Kris Craig wrote:
>>
>>>
>>>
>>> On Sun, Mar 6, 2022, 12:36 PM Chase Peeler
&g
On Sun, Mar 6, 2022 at 3:40 PM Kris Craig wrote:
>
>
> On Sun, Mar 6, 2022, 12:36 PM Chase Peeler wrote:
>
>>
>>
>> On Sun, Mar 6, 2022 at 3:23 PM Kris Craig wrote:
>>
>>> On Sun, Mar 6, 2022, 10:17 AM Victor Bolshov
>>> wrote:
>
that says "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
r Putin's War or try to justify 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
issue tracker:
> > https://github.com/facebook/react/issues - you can bet your life on it
> > that this will happen to the PHP project as soon as there is anything on
> > this topic done. Does the project has resources to deal with it? I mean,
> > this is basically a DDoS that can be solved only by closing off issue
> > creation from public.
> >
> > It's just impractical and will ruin maintainers and contributors ability
> to
> > do their work for the foreseeable future.
> > --
> >
> > Arvīds Godjuks
> > +371 26 851 664
> > arvids.godj...@gmail.com
> > Telegram: @psihius https://t.me/psihius
> >
>
--
Chase Peeler
chasepee...@gmail.com
gt; +44 (0) 787 668 0256 https://www.phcomp.co.uk/
> Parliament Hill Computers Ltd. Registration Information:
> https://www.phcomp.co.uk/Contact.html
> #include
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
ct, are against the war and for
> the freedom of Ukraine, might have an impact.
>
> This is not the time to "stay away from politics", we are experiencing
> an attack on humanity itself. Take example from
> <https://junit.org/junit5/> and their clear statement.
>
> Say NO to war!
>
>
--
Chase Peeler
chasepee...@gmail.com
On Tue, Jan 25, 2022 at 5:11 PM Rowan Tommins
wrote:
> On 25/01/2022 19:44, Chase Peeler wrote:
> > If we start throwing exceptions, which can't be suppressed, it will make
> > this much more difficult to read since the constants.php will have to be
> > updated:
>
low constants to be
redefined. My setup actually works because you can't redefine them. The
idea is that the local configuration file is processed first.
> +1 to remove it in PHP 9.0
>
--
Chase Peeler
chasepee...@gmail.com
fix up my patch and do a proper RFC.
>
> https://wiki.php.net/redefine_constants_exception_strawpoll
>
> Mark Randall
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
val);
if ($added->isPositive()) {
// Do stuff
}
return $n;
}
abstract protected function getNumberInterface(): NumberInterface;
}
class Foo {
use ArithmeticTrait;
protected NumberInterface $n;
protected function getNumberInterface() : NumberInterface
r it's added complexity to the
tool itself. If PhpStorm allows me to reference
$this->someMethodFromAnInterface() without defining
someMethodFromAnInterface() as an abstract method in the trait because I
include "expects ", then that means things are "simpler" for me
as a developer. I don't really think this makes things that much simpler
though.
--
Chase Peeler
chasepee...@gmail.com
her than "Stringable", whose purpose and implementation continue to
> baffle me
>
> 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 Wed, Jan 5, 2022 at 6:05 PM Larry Garfield
wrote:
> On Wed, Jan 5, 2022, at 2:35 PM, Chase Peeler wrote:
>
> > First, I'm someone that mainly uses traits to implement the functionality
> > defined in an interface. I think that's one of the best uses for them.
>
quot;public" introduces 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
define a() and b() as abstract in the trait. However, this
doesn't give you the added benefit of utilizing 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
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:
But "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
any PHP developers.
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
f earthquake this might trigger 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
rds,
> > Nikita
>
> Also 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
--
> 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
ould we base
that on? Anything around the 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
oes, that might 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
On Tue, May 11, 2021 at 8:59 AM Matīss Treinis > <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
>
> >
>
> 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
d please don't 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
at
implementation of 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
s are useful for at least one 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
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
don't care. 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
Maybe permits Some, None {
> > > ...
> > > > }
> > > >
> > > > 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
es a ToString():string method then
> structural typing would allow me to implement that interface simply by
> adding a 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
ne in a way that works with block scoping, 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
expects a callback 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
tation.
> 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
does not mean more readable, and readable is more important 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
es not. The fact that they 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 aut
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
> doe
ate threads for 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
gt; btw 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
erish, 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
class2.php'
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
return $bar * 2;
> }
>
> So basically, in the 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
:
>
>
> > I am afraid that fiber can only be used in the amphp framework and is of
> > no value to other php projects.
> >
>
> Hi,
>
>
> I'd like to see you elaborate on this point. Are you able to provide
> anything to back up this claim?
>
>
> I don't see anything that is specific to amphp, not anything to limit it to
>
> their use. Fibers also exist outside of PHP, while amphp doesn't.
>
> Thanks,
> Peter
--
Chase Peeler
chasepee...@gmail.com
er is more clear, perhaps 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
-ooO-(_)-Ooo-+
> | Andreas Heigl |
> | 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
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:
>> >
>>
uld be a really nice addition for templating.
>
> 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
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
tax sugar, 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
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
think 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
ith you. I know 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
greement; all we are 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
itimate cases for explicitly casting floats to int. For
> > > 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
ductive and destructive advice.
>
>
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
t of me actually finds their replies
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 linked discussion of rejected alternatives. 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
ng_internal_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
>> t
`\array_keys` optimization will work the same way 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) o
at 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
rray_keys($array);
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
, especially if value 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
.
> >
> > Any boolean function can be inverted with a simple ! in a short
> 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
veloped with windows in mind. One reason
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
different. However, it does not, just like glob does not have origin in
fat-shaming.
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
--
> Contact - https://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
ation on this list for being rather conservative about
changes. 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
ce we 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 r
it breaks stuff" or "Well,
they shouldn't be doing it that way, so screw them" 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
s, and here are
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
dating this file using different
> versions? The 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&#x
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
d 'echo "I'm calling ".myfunction::function;'? 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
y to perform the functionality
that 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
s a new rule. I don't see in that RFC, 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
t simpler 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
ifferently when cast to an
array.
I'm personally 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
t; case 'foo' => 1,
> >> case 'bar' => 2,
> >> 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
erent ways to get there isn't 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
;t think there is an EASY way to allow userland 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
;ve been involved with PHP, nothing is
ever deprecated unless the eventual goal is to remove it. I could 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
d to look it up. It ends up 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!
> --
>
d replace everything
> to exec().
>
> rr
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
them feel reluctant
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
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,
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 word
cribe, 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
it difficult for us to have productive conversations on this
> mailing list, then that would be a different problem than the
> well-intentioned 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
is
> > for
> > > > the remainder of the proposal.
> > > >
> > > > Voting closes 2019-09-26.
> > > >
> > > > Regards,
> > > > Nikita
> > > >
> > >
> > > I just realized that I missed one notic
here are a few things that 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
1 - 100 of 216 matches
Mail list logo
