Re: [PHP-DEV] Operator overloading for userspace objects

[Olumide Samson]

Would there be an RFC to push this feature(with the right handler, POC)
into PHP?

Or something would stop it from happening?



On Wed, 29 Jan 2020, 10:20 am Nikita Popov,  wrote:

> On Wed, Jan 29, 2020 at 12:14 AM  wrote:
>
> > Hello everybody,
> >
> >
> >
> > the last days I have experimented a bit with operator overloading in
> > userspace classes (redefing the meaning of arithmetic operations like +,
> -,
> > *, etc. for your own classes).
> >
> > This could be useful for different libraries which implements custom
> > arithmetic objects (like money values, tensors, etc.) or things like
> > Symfony
> > string component (concatenate) operator, because it improves readability
> > much:
> >
> > $x * ($a + $b) instead of $x->multiply($a->add($b))
> >
> >
> >
> > 4 years ago, there was a RFC about this topic (
> > 
> > https://wiki.php.net/rfc/operator-overloading), which was discussed a
> bit
> > (
> >  https://externals.io/message/89967
> ),
> > but there was no real Outcome.
> >
> >
> >
> > I have tried to implement a proof of concept of the RFC, I encountered
> some
> > problems, when implementing the operator functions as (non-static) class
> > members and pass them only the “other” argument: What happens when we
> > encounter an expression like 2/$a and how can the class differ this from
> > $a/2. Also not every operation on every structure is e.g on commutative
> > (e.g. for matrices A*B =/= B*A). So I tried a C#-like approach, where the
> > operator implementations are static functions in the class, and both
> > arguments are passed. In my PHP implementation this would look something
> > like this:
> >
> >
> >
> > Class X {
> >
> > public static function __add($lhs, $rhs) {
> >
> > //...
> >
> >}
> >
> > }
> >
> >
> >
> > The class function can so decide what to do, based on both operands (so
> it
> > can decide if the developer wrote 2/$a or $a/2). Also that way an
> > implementor can not return $this by accident, which could lead to
> > unintended
> > side effect, if the result of the operation is somehow mutated.
> >
>
> Using static methods sounds reasonable to me.
>
> I have taken over the idea of defining a magic function for each operation
> > (like Python does), because I think that way it is the clearest way to
> see,
> > what operators a class implements (could be useful for static analysis).
> > The
> > downside to this approach is that this increases the number of magic
> > functions highly (my PoC-code defines 13 additional magic functions, and
> > the
> > unary operators are missing yet), so some people in the original
> discussion
> > suggest to define a single (magic) function, where the operator is
> passed,
> > and the user code decides, what to do. Advantageous is very extensible
> > (with
> > the right parser implementation, you could even define your own new
> > operators), with the cost that this method will become very complex for
> > data
> > structures which use multiple operators (large if-else or switch
> > constructions, which delegate the logic to the appropriate functions). An
> > other idea mentioned was to extract interfaces with common functionality
> > (like Arithmetically, Comparable, etc.) like done with the ArrayAccess or
> > Countable interfaces. The problem that I see here, is that this approach
> is
> > rather unflexible and it would be difficult to extract really universal
> > interfaces (e.g. vectors does not need a division (/) operation, but the
> > concatenation . could be really useful for implementing dot product).
> This
> > would lead to either that only parts of the interfaces are implemented
> (and
> > the other just throw exceptions) or that the interfaces contain only one
> or
> > two functions (so we would have many interfaces instead of magic
> functions
> > in the end).
> >
>
> Yes, i don't think it makes sense to group these operations in interfaces,
> the use-cases are just too diverse. It's possible to define one interface
> per operator (e.g. what Rust does), though I don't think this is going to
> be particularly useful in PHP. I would not want to see functions accepting
> int|float|(Add) show up, because someone is trying to be overly generic
> in their interfaces ;)
>
> As to whether it should be a single method or multiple, I would go for
> multiple methods, as that makes it more clear which operators are
> overloaded from an API perspective.
>
> On the topic which operators should be overloadable: My PoC-implementation
> > has magic functions for the arithmetic operators (+, -, *, /, %, **),
> > string
> > concatenation (.), and bit operations (>>, <<, &, |, ^). Comparison and
> > equality checks are implement using a common __compare() function, which
> > acts like an overload of the spaceship operator. Based if -1, 0 or +1 is
> > returned by the  comparison operators (<, >, <=, >=, ==) are evaluated. I
> > think this way we 

Re: [PHP-DEV] Adding TypeError and ValueError to count() function

[Olumide Samson]

Only lazy developers would complain about updating legacy code, perhaps the
code itself is worthless and need not be updated.

Then, what's the point of pursuing latest features or PHP version when a
individual or a company can't pursue code upgrade before version update?




On Tue, Jan 21, 2020, 8:41 PM Philip Hofstetter 
wrote:

> Hi,
>
>
> On Tue, Jan 21, 2020 at 6:17 PM Nikita Popov  wrote:
>
> >
> > In the cases you encountered, do you know what type count() was used on?
> > Was it null? false? Or something else?
> >
> > Nikita
>
> we were in a similar boat as Björn to the point where we manually
> patched PHP in production in order to not emit that warning so we
> could update PHP while we were migrating the code-base. This made the
> 7.1 to 7.2 update the most painful update in the history of this
> application (which was first released when 5.0.0 came out).
>
> The most common case was `count(null)` which unfortunately was
> happening all the time because of functions deciding to return an
> array with elements or null if there was no elements to be found. Yes,
> that's bad form, but hey - this is a nearly 20 years old application.
>
> Of all the changes I've seen happening in PHP, this was the most painful.
>
> Philip
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement

[Olumide Samson]

"namespace_lookup"

On Sat, Jan 18, 2020, 10:32 PM Mark Randall  wrote:

> On 18/01/2020 18:05, tyson andre wrote:
> >which is now declare(disable_ambiguous_element_lookup=1) at the top
> of a file.
>
> I_suspect_these_long_declares_might_get_tedious
>
> Can we at least agree on internals that a declare doesn't have to have a
> negative default value that is toggled on?
>
> I'd much rather have something like:
>
> declare(ambiguous_element_lookup=0)
> declare(ambiguous_element_lookup=off)
>
> --
> Mark Randall
> marand...@php.net
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

RE: [PHP-DEV] Warn when declaring required parameter afteroptionalone

[Olumide Samson]

Error(in PHP 8) after warning or deprecation in 7.xnything more preferred…

---
Sent from Mail for Windows 10

From: Olumide Samson
Sent: Saturday, January 11, 2020 2:42 PM
To: Niklas Keller; Nikita Popov
Cc: Bob Weinand; PHP internals
Subject: RE: [PHP-DEV] Warn when declaring required parameter afteroptionalone

Should it be a warning or an error?
---
Sent from Mail for Windows 10

From: Niklas Keller
Sent: Saturday, January 11, 2020 2:35 PM
To: Nikita Popov
Cc: Bob Weinand; PHP internals
Subject: Re: [PHP-DEV] Warn when declaring required parameter after optionalone

Hi Nikita,

while this is a rather small change, it has quite some BC impact, as
not all old code has been adjusted to run on PHP 7.1+ only using
nullable types.

I'd like to see an RFC with a vote for this.

Regards,
Niklas

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Typed array properties V2

[Olumide Samson]

On Fri, Jan 17, 2020, 2:54 PM Robert Hickman  wrote:

> > So essentially we are talking about generics. I think it's the best time
> to
> > do so... Maybe our wishes come true soon? ;)
> >
>
> Given that the general trend is towards making PHP more statically
> typed and very java/C# like, why not just ditch PHP and use one of the
> aforementioned languages?
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

Who's this?

How does this feature means PHP becoming more static type language?

Does adding strict typing features remove any dynamic type features of the
language?
Nope, this still dynamic typing coz it can do both as the need demands.

RE: [PHP-DEV] Who are the current eligible voters?

[Olumide Samson]

From: Mike Schinkel
Sent: Wednesday, January 15, 2020 9:23 PM
To: Nikita Popov
Cc: PHP Internals List
Subject: Re: [PHP-DEV] Who are the current eligible voters?


> On Jan 15, 2020, at 3:15 PM, Nikita Popov  wrote:
> 
> Based on master.php.net data, the number of people who are eligible for
> voting is approximately 1900. The usual turnout for RFC votes is more like
> 30. If it's something very controversial, maybe 100.

Wow. From a participation standpoint that seems pretty pathetic. If 30 is the 
average that means most people never vote. 

I would have assumed that having a vote would mean that people would be 
expected to vote periodically or if not then loose the privilege.  

#jmtcw

-Mike
-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Maybe this should be the case?
Not voting within 6 months or 12 months on a single RFC would mean you’ve 
either moved on with your life and lost the voting right… I think that’s 
similar to parliament systems…

You stop having a senator vote as soon as you leave the senate(doing something 
else with your life), you can pick it up whenever you’re back to be active…
---
Sent from Mail for Windows 10

RE: [PHP-DEV] Warn when declaring required parameter after optionalone

[Olumide Samson]

Should it be a warning or an error?
---
Sent from Mail for Windows 10

From: Niklas Keller
Sent: Saturday, January 11, 2020 2:35 PM
To: Nikita Popov
Cc: Bob Weinand; PHP internals
Subject: Re: [PHP-DEV] Warn when declaring required parameter after optionalone

Hi Nikita,

while this is a rather small change, it has quite some BC impact, as
not all old code has been adjusted to run on PHP 7.1+ only using
nullable types.

I'd like to see an RFC with a vote for this.

Regards,
Niklas

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bump required libcurl version to 7.17.1

[Olumide Samson]

Why not the most recent and stable version?

I'm thinking modern version has many bugs fixed and many vulnerabilities
fixed, even with improvements that make things more faster and lighter...

Just My thoughts.

On Sat, Jan 11, 2020, 1:55 AM Pierre Joye  wrote:

> Good morning Christoph,
>
> I would even bump it to a much more recent version for 8.x or we will
> have the same issue during 8.x lifetime (we may anyway but starting
> with a 10+ years old version makes it much more likely).
>
> Best,
>
> On Wed, Jan 8, 2020 at 9:50 PM Christoph M. Becker 
> wrote:
> >
> > Hi all,
> >
> > quite a while ago I've submitted
> > , but received no feedback on
> > that so far, so I'm writing this mail.
> >
> > The pull request is about bumping the required libcurl version for
> > ext/curl to 7.17.1, which has been released twelve years ago.  The main
> > reason for the bump is to remove most of the obsolete constants which
> > have been scheduled for removal from libcurl for more than ten years.
> > The fact that we still use them, has almost bitten us not long ago[1],
> > so I think that PHP 8 is a good opportunity to finally remove them.
> >
> > If there are no objections, I'll merge PR #4917 in a week.
> >
> > [1] 
> >
> > Thanks,
> > Christoph
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
>
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] exit() via exception

[Olumide Samson]

I'm thinking exit() shouldn't be catchable to maintain status quo, and it
should be focused on the reason it was suggested(Unwinding stacks and
cleaning up memories instead of longjmp'ing to shutdown).

If there's any need to catch it's exception, that can be handled later
through maybe a RFC discussion.

This can be implemented directly without having any user land interaction
since the throwing and catching can't be caught by any user land
code(top-most hierarchy without possibility to be caught, which might
result in compile time error).

All the best

Re: [PHP-DEV] Warning for "confusable" types

[Olumide Samson]

On Fri, Oct 11, 2019, 6:47 PM Larry Garfield  wrote:

> On Fri, Oct 11, 2019, at 8:54 AM, Nikita Popov wrote:
> > Hi internals,
> >
> > Something I've seen play out a couple of times: Newbies try to use
> > something like "integer" or "resource" as a type, and then get a
> confusing
> > error message along the lines of "must be an instance of resource,
> resource
> > given".
> >
> > I would like to throw a compiler warning in this case, that looks as one
> of
> > the following:
> >
> > > Warning: "integer" will be interpreted as a class type. Did you mean
> > "int"? Use qualified name or "use" to suppress this warning
> >
> > > Warning: "resource" is not a supported builtin type and will be
> > interpreted as a class type. Use qualified name or "use" to suppress this
> > warning
> >
> > This warning only triggers if the type is lowercase (integer but not
> > Integer), is unqualified (integer but not \integer) and is not imported
> > (there is no "use integer"). This provides multiple ways to avoid the
> > warning for code that does legitimately want to use lowercase "integer"
> as
> > a class type.
> >
> > Implementation: https://github.com/php/php-src/pull/4815
> >
> > Thoughts?
> >
> > Nikita
>
> Can you clarify where exactly "compiler warning" would be displayed?  Is
> that an E_WARNING?  How would I as a user see a message when I write
>
> function foo(integer $a) { ... }
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php


As a warning I think, seems I've encountered those errors many times ago.

The solution Nikita propose is good, it doesn't deal with too much.

These errors are there already, only just giving it a properly meaningful
description.

+1 for the proposed description.

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

[Olumide Samson]

On Fri, Oct 11, 2019, 9:29 AM Benjamin Morel 
wrote:

> >
> > As people have expressed interest in hearing about direct technical
> > benefits that these kinds of changes have ... let me give you an example
> > that came up yesterday.
>
>
>
> Too bad this example comes after the vote has been made, and failed.
> This would be a very strong argument in favour of using exceptions
> everywhere in the next major version: codebase cleanup, room for more
> optimization.
>
> Nikita, please fork PHP, we'll follow you ;-)
>
> — Benjamin
>

I think I'm always available to contribute to a fork of a better PHP, coz I
love the syntax not the garbages included in the current one.

>

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[Olumide Samson]

On Thu, Oct 10, 2019, 4:35 AM Stanislav Malyshev 
wrote:

> Hi!
>
> > it into some kind of proxy war. Yes, "it breaks backwards compatibility
> for
> > questionable benefit" is an argument against this proposal, it is even a
> > *very good* argument against it, but it's also no mandate to shut down
> the
> > discussion entirely.
>
> Well, anyone is free to continue the discussion forever and ever
> (there's no real way of "shutting down" it), but if there a *very good*
> argument against it, then the point of continuing would be ?
>
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.ph
> 


For as long as I can recall, there would always be an argument against and
for a debate.

An argument against doesn't stop the RFC from going on, coz if it does
there won't be anything to vote on since the RFC started to become a thing.

Even unanimous votes still have argument against it that didn't get to show
up in the vote, either because those arguing against it isn't voting or
something changed along the way.

Argument is a good way to life.


>

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[Olumide Samson]

On Wed, Oct 9, 2019, 3:41 PM Bishop Bettini  wrote:

> On Mon, Oct 7, 2019 at 5:21 PM Olumide Samson 
> wrote:
>
>> On Mon, Oct 7, 2019, 9:20 PM Claude Pache  wrote:
>>
>> > > Le 7 oct. 2019 à 22:06, Olumide Samson  a
>> écrit :
>> > >
>> > > What's the goal of PHP?
>> >
>> > One important goal is (like many programming languages) to get work
>> done.
>> >
>> I disagree, coz this seems to be a goal cooked up by you(even if I might
>> believe in the general idea of that goal, I still can't believe it until I
>> see where it was outlined).
>>
>
> I think the PHP web-site[1] supports Claude's statement:
>
> "PHP is a popular general-purpose scripting language that is especially
> suited to web development.
> Fast, flexible and pragmatic, PHP powers everything from your blog to the
> most popular websites in the world."
>
> The adjectives used:
>
>- General-purpose
>- Fast
>- Flexible
>- Pragmatic
>
> The last one, pragmatic, applies to Claude's point. Various definitions of
> pragmatic include:
>
>- "solving problems in a sensible way that suits the conditions that
>really exist now, rather than obeying fixed theories, ideas, or rules" [2]
>- "of or relating to a practical point of view or practical
>considerations." [3]
>- "involving or emphasizing practical results rather than theories and
>ideas" [4]
>
> With respect to Mark's proposal, deprecating back-ticks: maybe it's more
> pragmatic to have a single, well-defined, and obvious way to invoke an
> external process. Sure, yet PHP isn't just "pragmatic". It's also flexible
> and general-purpose. Flexible is the opposite of rigid, meaning there are
> circumstances where a second way, or even a third way, may provide more
> practical utility than the single canonical interface. General-purpose
> means a language is useful in many ways. PHP while "especially suited for
> web-development" is also useful as an ad-hoc shell scripting language and,
> in that context, back-ticks are welcomed.
>
> If we take back-ticks away, we hobble the "quick-scripting for personal
> use" flexibility in favor of the enterprise-grade "distributed development,
> high code-reuse and review" architecture. That seems to run counter to the
> nature of PHP.
>
> [1]:https://www.php.net
> [2]:https://dictionary.cambridge.org/us/dictionary/english/pragmatic
> [3]:https://www.dictionary.com/browse/pragmatic
> [4]:https://www.macmillandictionary.com/us/dictionary/american/pragmatic
>

That's written as "features" not "goals", you know what goal is?

Goal is like a mission, a statement written to be taken seriously.
Checkout python.org you will see an example of what goal is, written
clearly as "mission" not "features and what it is/does".

I rest my case.

>

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[Olumide Samson]

On Wed, Oct 9, 2019, 12:59 AM M. W. Moe  wrote:

> Hello,
>
> the point Stanislav is really not about whom; that's about thinking, work,
> effort, personal walk thru a problem;
> and I am sorry he is fully right; live example:
>
> "I think that's been inconsistencies from the part of early contributors
> which is the same reason we are having "haystack and needle" problem and
> I'm not sure there's a problem fixing those old days mistake."
>
> is this embodiment of arrogance, vulgarity hence stupidity because to me
> they are synonyms helps anyone?
>
> Regards.
>
> On Tue, Oct 8, 2019 at 4:39 PM Mark Randall  wrote:
>
> > On 09/10/2019 00:26, Stanislav Malyshev wrote:
> > > That's part of the problem. RFC should be for something that is
> > > necessary and beneficial for the whole community, doubly and triply so
> > > when we're talking about BC breaks. It shouldn't be just "whatever I
> > > want, let me put it to a vote". RFCs are not a twitter poll where
> > > anybody can vote on anything and anything goes. It should be used
> > > responsibly, and if people don't understand this responsibility maybe
> > > it's too early for them to propose any RFCs.
> >
> > Might I request that you please stick to discussing the actual topic of
> > the RFC, rather than trying to shift the conversation towards who can
> > and cannot propose RFCs :-)
> >
> > If you want to discuss changing the RFC mechanics and who is entitled to
> > make them, please make your own RFC.
> >
> > Thank you.
> >
> > Mark Randall
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
I think you've been using too much of "vulg**, stup**, etc" that makes
absolute nonsense since yesterday.
Can you just tone down or watch what you write if you're vexing out about
someone else's opinion?

Even I can do same back to you, but won't stoop so low to that level.

I think this list should be for mature minds that can agree or disagree
peacefully without stupidity in becoming.

>

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[Olumide Samson]

On Tue, Oct 8, 2019, 3:30 PM Chase Peeler  wrote:

> On Sun, Oct 6, 2019 at 9:18 AM Reinis Rozitis  wrote:
>
> > > -Original Message-----
> > > From: Olumide Samson [mailto:oludons...@gmail.com]
> > >
> > > it should be deprecated  for exec usage since they both do same thing
> >
> > With that logic  > does the same thing and is hard to find in internet search engines (was
> in
> > some other argument).
> >
> >
> And we should deprecate the "print" command, since it's the same as echo.
> We should deprecate 'printf', since you can just do 'echo sprintf' and, now
> that I think about it, we should deprecate sprintf as well, since you can
> just use vsprintf. It's a simple change too... sprintf($s,$a,$b,$c) =>
> vsprintf($s,[$a,$b,$c]);. I'm just it can be done with just a simple regex
> search/replace.
>
> The fact that are SO many different ways to output text is REALLY confusing
> for new developers. I think it's imperative we fix all of these items RIGHT
> NOW. By doing so, I'm sure all the .NET developers that are talking smack
> about PHP will suddenly denounce c# and start using PHP as well!
>
>
> >
> > > This isn't high cost breaking changes coz it has a verifiable, ready
> > alternative to upgrade to without huge Regex searches.
> >
> > Since `` are used for literal strings (for poorly chosen reserved words
> as
> > field, table names (which happens from time to time)) in MySQL
> (multiline)
> > queries I doubt there is a simple way to distinguish and 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


If you feel you want all those functions deprecated in favor of any other,
put up a RFC whenever you want to(No one is stopping you from that).

I think that's been inconsistencies from the part of early contributors
which is the same reason we are having "haystack and needle" problem and
I'm not sure there's a problem fixing those old days mistake.

The major issues I'm seeing now is that, those who did bring up those
functions back then are the one leading the fight against correcting them,
maybe it helps them stay relevant IDK.

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[Olumide Samson]

On Mon, Oct 7, 2019, 9:20 PM Claude Pache  wrote:

>
> > Le 7 oct. 2019 à 22:06, Olumide Samson  a écrit :
> >
> >
> > What's the goal of PHP?
>
> One important goal is (like many programming languages) to get work done.
>
> —Claude
>
I disagree, coz this seems to be a goal cooked up by you(even if I might
believe in the general idea of that goal, I still can't believe it until I
see where it was outlined).

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[Olumide Samson]

On Mon, Oct 7, 2019, 7:53 PM Stanislav Malyshev  wrote:

> Hi!
>
> > That is the purpose of the eventual vote, is it not? To allow the
> > community to make that determination.
>
> Not exactly - there should be a good reason before the RFC comes to a
> vote. If you're not sure there's a VERY good reason, there shouldn't be
> the RFC about it at all, at least not in voting phase. RFC process
> shouldn't be just "let's throw it against the wall and see if anything
> sticks", it should be used responsibly.
>
> > Regardless of the outcome of this specific RFC, I am of the firm belief
> > that it's important to be able to re-visit past choices every now and
> > then. That applies to most things, not just PHP.
>
> In abstract, this a banality, yes, it is important, sometimes. In
> specific, I've seen a torrent of BC-breaking proposals lately that seem
> to have no good reason except for removing stuff because... I'm not even
> sure because of what, most of it seems to be vague stuff like
> "unintuitive" and "you can do it in other way". I think effort spent on
> breaking BC without a VERY good reason is a wasted effort. Having as
> little syntax constructs and functions as absolutely possible has never
> been the goal of PHP, and I am surprised why it is in fashion now.
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php


What's the goal of PHP?

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[Olumide Samson]

I think something that deals with system commands should be highly obvious
and should not be allowed through shortcut syntax that made it easy to be
hidden amongst codes for many security reasons.

There's already a popular way without hidden syntax and which speaks of
itself in a verifiable way called "exec", I'm not saying we should have it
removed just because it isn't obviously popular or it doesn't affect
anything for now; my argument is since we are moving to Version 8 of PHP,
it should be deprecated for exec usage since they both do same thing and
exec is highly obvious as a command function.

This isn't high cost breaking changes coz it has a verifiable, ready
alternative to upgrade to without huge Regex searches.

Thanks,
Samson.

On Sat, Oct 5, 2019, 9:26 PM Andreas Hennings  wrote:

> The first time I saw the backtick operator in code, I thought it must
> be some kind of ancient alternative syntax for string literals.
> (and no, I did not know that these are called "backticks")
>
> When I learned that code "quoted" in this way is immediately executed
> as shell commands, this seemed like a completely insane and reckless
> language design.
>
> In most projects, executing shell commands should be something rare,
> and the few cases where it happens should be visible and searchable.
>
> Perhaps a legitimate use case would be a file that is essentially a
> shell script with some PHP sprinkled in.
>
> But overall I think we should rather get rid of this feature.
>
>
> On Sat, 5 Oct 2019 at 22:02, Lynn  wrote:
> >
> > > Hi!
> > >
> > > > This is true, if you know they are called a backtick. It's not a
> > >
> > > I think it's reasonable to expect some minimal level of knowledge from
> > > the user. We're not targeting infants in the kindergarten here. So
> while
> > > we aim to not present too many obstacles to the novice user, we can
> > > reasonably expect from them at least basic middle-school level
> knowledge
> > > and abilities - and occasional read of the documentation never killed
> > > anybody either.
> > >
> >
> > Hi,
> >
> > I didn't know the name of this character until several years after I
> > started PHP, and I only found out because a colleague pointed it out to
> me.
> > I don't think it's a good idea to assume people know the name of this
> > operator or known how to find it easily. Googling is a skill on its own
> > that not everyone masters, as much as I'd like to see this in our field.
> I
> > also don't see how school knowledge is important here, especially as I
> went
> > to school and I did not learn about it there. Besides of this, there are
> > also keyboard( layout)s that don't have a backtick character present.
> >
> > Regards,
> > Lynn van der Berg
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] Within 2 weeks, everything In PHP internals questioned

[Olumide Samson]

Hi Zeev,

Not trying to be a distraction(I shouldn't even have messaged), but I guess
you might be waking everyone up to some facts these recent days(probably in
the wrong way, and to some; positive).

Why did i write this?

I've been following closely lately and have seen you(Zeev Suraski)
question *RFC
authority*(what it was meant for or not, even though your facts weren't
written as facts anywhere).

You've questioned the *mailing list* rules(be it binding or not), maybe it
should be followed or disregarded and just follow my/your-style rules.

You've questioned the *RFC votes*(majority can never be 2/3 but only
7/1),even thousands of majority votes can never push a deprecation through
to the php-src because you didn't agree to that and possibly there's a veto
somewhere which can be used because you are one of those listed in the PHP
Group.



Is this not mocking PHP internal developers to the outside world when you
could just sit at home and chill or take a coffee when you can?

Like Dan said, some old members are not following the mailing list
rules(what you call moral etiquette), maybe since everything in the PHP
internals has been going without a goal, why not just have the initial
developer(Rasmus ledorf) or a group of people write out one(clear mission,
goal statement, milestones, rules, etc) and stop the easy confusion going
on in this mailing list?


On Wed, Sep 18, 2019, 11:11 PM Zeev Suraski  wrote:

> On Wed, Sep 18, 2019 at 8:33 PM Dan Ackroyd 
> wrote:
>
> > # Problem 3 - Newcomers to the mailing list aren't following our
> > etiquette.
>
> # Problem 4 -  Senior project members aren't following our email etiquette.
>
>
> This too isn't directed so much at Dan, but rather the list at large.
>
> Some facts about the Mailing List Rules:
>
> Fact #1:  The list rules were never a binding document.  It wasn't voted on
> or otherwise agreed upon as binding at any point at any point.  In fact, I
> can't even find any reference that it was even ever discussed (my email
> archive dates back to 1999).  It was written by Lukas Kahwe Smith, and with
> the exception of some whitespace and typo fixes - it's literally in an
> "initial commit .. feedback appreciated" stage (
> https://github.com/php/php-src/blame/master/docs/mailinglist-rules.md).
> Fact #2:  It contains three chapters.  The first chapter - which includes
> the goals of the document - i.e., what the other rules are aimed to
> ultimately facilitate - is concluded with "Increase the general level of
> good will on planet Earth". This rule is clearly violated time and
> again by several recent folks and proposals.
> Fact #3: Chapter 2 contains the rules, i.e., the supposedly binding rules
> (see Fact #1). I think they're all healthy and non controversial, and we
> should all strive to abide by them. That said, interestingly, some
> of the folks who most clearly violate the first item on this chapter appear
> to eagerly want to enforce this document as binding.
> Fact #4: Chapter 3 contains "general hints", which are clearly non-binding
> even if the document itself was (see Fact #1). Specifically, the first two
> items in the 3rd chapter are purposely phrased as suggestions on what to do
> as opposed to Thou Shalt or Thou Shalt Not, even if one ignores the
> 'general hints' label that is applied to this entire section. These items
> appear to be repurposed by some here as a way to silence opposition to
> extremely controversial proposals. A "you should try to do X" request in a
> "general hints" section in a document that was apparently never agreed upon
> as binding will not do that, nor will anything else.
> Bonus fact:  Decision was only achievable through near-consensus back in
> the day these rules were written; Substantial opposition wasn't facing the
> risk of being ignored and overrun as it does today..
>
> There's another fact about what RFCs can or cannot do, but I think I've
> spent enough digital ink on that already.
>
> The recent discussions we've had on this list were not pleasant for anyone.
> To say I took no pleasure at the discussions of the last few months would
> be a top contender for the understatement of the century. However, from my
> POV - I had no choice in the matter - and had to react to discussions that
> were imposed on me. The alternative - which I view as betraying countless
> users - isn't a real alternative from my point of view. I know for a fact
> that many others had similar thoughts (yes, beyond just Chase and Stas) -
> but were wary about voicing their opinions when they saw the 'summary
> trials' I faced in certain forums, or just didn't have the energy to fight
> what appeared to be a sisyphic task against an internals@ majority that
> doesn't seem to care.
>
> There are very few folks on internals@ that are actively working to
> protect
> PHP's excellent BC track record, as well as keeping it from severing its
> roots.  It does mean that they are disproportionately represented in such
> discussions.  

Re: [PHP-DEV] Defining the PHP Group

[Olumide Samson]

I don't think there is a valid way to define "fundamental BC breaks" or
"mere BC breaks", all votes will always be a reasonable vote as much as
there are people to vote on it.

Whats special or different about BC break that would require slim margin or
consensus votes on where this is dealing with people from various
continent, language and ethnic?

Would that imply you don't want any BC breaks at all?


I think if there's any valid arguments against or for any RFCs or votes,
the internals at that time can determine how best to make the voting work.

I don't see any good or valid reason to make a kind of change requiring a
special kind of vote that looks like it was intended to never pass, why 10
to 1?

Does that mean everyone must agree to some kind of change and because
there's 3 people not agreeing, such votes must be counted invalid?

I think this isn't a good decision IMO.

Majority should always be majority regardless of who seems to be in the
minority.

Why don't some people like being in the minority group, which whenever such
happens they would look for a way to gather public minorities to argue
their cause or probably edit RFCs to notify newer voters about who is
disagreeing?

Re: [PHP-DEV] Defining the PHP Group

[Olumide Samson]

On Sun, Sep 15, 2019, 11:41 PM Olumide Samson  wrote:

>
>
> On Sun, Sep 15, 2019, 8:33 PM Stanislav Malyshev 
> wrote:
>
>> Hi!
>>
>> > Does anyone object to any of those words ?
>>
>> Yes. I do not think precommitting to implement anything that has been
>> put on wiki and passed the vote is a good thing. Its a good conflict
>> resolution mechanism when we're talking about where or not to implement
>> certain technical feature. But IMO it would be terrible as a sole
>> governance mechanism for the whole project.
>>
>> > Do we need to vote on changing the introduction (I'm happy to start an
>> rfc
>> > for this, if necessary) ?
>>
>> I don't think RFCs were meant to essentially remake all project
>> governance structure.
>
>
> Hi Stanislav, I would expect you to reply with what can be done, not
> saying the RFC is not meant to do this and that, my common sense is telling
> me you are either deliberately omitting some details on what the process
> would be, if not the RFC.
>
> Everyone else - what was the process that brought about the RFC?
>
> If its mails through the mailing list(that brought about the RFC), then
> mails with majority agreed on signify the changes required to change the
> RFC itself.
>
> I don't like it when people say parliament was created by constitution yet
> the parliament can't still change constitution; then what else can change
> the constitution, maybe voice vote?
>
> The RFC was created years ago and IMO can't be there forever, so what
> would change it? The RFC itself recently changed some scope of itself.
>
> GCC would call this bootstrapping
>
> They were meant for solving technical questions,
>> not governance model.
>> I am not sure which way would be the best (haven't thought about it) but
>> certainly neither just putting some words on wiki nor voting on it
>> within the RFC process looks like a good way to do it.
>>
>> --
>> Stas Malyshev
>> smalys...@gmail.com
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>

Re: [PHP-DEV] PHP's declining(?) popularity

[Olumide Samson]

I also don't agree with the index and all its statistics, yet I'm not
invalidating it as it is a much-viewed index globally.

Though, what caught my eyes was this quote which I thought would be obvious
and Mike would have based those fact replies on(Yet I'm also not
invalidating his facts list and IMHO those as well would make sense in
PHP).

According to the index :
 "Till the end of 2009 everything went fine, but soon after that PHP was
going downhill from 10% to 5% market share in 2 years’ time. In 2014 it
halved again to 2.5%.

So what happened to PHP?
>From its start PHP was the Visual Basic for web design: easy to learn, easy
to deploy, but mainly used by web designers with a limited software
engineering background.

The downside of PHP’s simplicity was that it was relatively easy to shoot
security holes in it.

 PHP has been struggling with this for a long time. In 2014 PHP’s biggest
supporter Facebook launched Hack as an alternative for PHP because it was
not scalable.

And after that, JavaScript, TypeScript and Python became the linguas franca
for web development."


These lines caught my eye more than the rest of the quote :

"The downside of PHP’s simplicity was that it was relatively easy to shoot
security holes in it. PHP has been struggling with this for a long time."

These other quotes seems good to watch as it mention one of the biggest
supporters creating an alternative because PHP wasn't scalable at its
current growth stage, maybe we might have been bothering too much about the
past while not remembering the present and future(Which is 100s of years to
come, if PHP is still a thing on the top 50) matters most than the
past(which is just some 15-20 years gone) :

" In 2014 PHP’s biggest supporter Facebook launched Hack as an alternative
for PHP because it was not scalable. And after that, JavaScript, TypeScript
and Python became the linguas franca for web development"

On Sun, Sep 15, 2019, 8:18 AM Zeev Suraski  wrote:

>
>
> On Sun, Sep 15, 2019 at 6:33 AM Mike Schinkel 
> wrote:
>
>> > On Sep 14, 2019, at 5:18 PM, Olumide Samson 
>> wrote:
>> >
>> > https://jaxenter.com/php-tiobe-sept-2019-162096.html
>> > I think this is one of those things we get from voting no...
>> >
>> > I might be wrong anyways :-?
>>
>
> First of all, Olumide, this is in fact wrong, although the general topic
> (language popularity and the reasons to it) is definitely worthy of
> discussion.
>
> The reason it's wrong is that TIOBE is a meaningless 'index' with a
> methodology that's not only questionable - but is rather downright
> idiotic.  It's not just off or inaccurate - it's practically a random
> number generator.
> See for yourself:
> https://www.tiobe.com/tiobe-index/programming-languages-definition/
>
> The RedMonk Language Rankings has a much more reasonable methodology, is a
> lot more stable, and there, PHP is repeatedly at the top 5 languages and
> not losing any steam in both absolute and comparative measures:
> https://redmonk.com/sogrady/2019/07/18/language-rankings-6-19/
>
>
>> If those specific rankings are legitimately a cause for concern then it
>> would make sense to do some objective analysis to determine why the
>> languages that are growing marketshare are growing.
>>
>
> Mike - even though specifically the TIOBE index isn't a cause for
> virtually anything, the rest of your analysis is still relevant - as the
> key takeaway you're basing it on - Python's growth - is also reflected in
> RedMonk rankings.
>
> Thomas - I also wholeheartedly agree with your suggestion.  That's why we
> worked on FFI - to open the door for PHP to enter new areas.  Even JIT is,
> for the most part, not really relevant to the common Web case and would be
> a lot more impactful in other types of workloads.  And there may be other
> things we can do.  But you're right - if we don't find a way to position it
> for these use cases in people's minds - it won't move the needle.
>
> Zeev
>

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

[Olumide Samson]

https://jaxenter.com/php-tiobe-sept-2019-162096.html
I think this is one of those things we get from voting no...

I might be wrong anyways :-?

On Sat, Sep 14, 2019, 12:43 AM Kosit Supanyo  wrote:

> Hi internals
>
> This maybe a little bit late but I would like to propose alternative to
> this RFC.
>
> What if we add `strict_errors` declare to make every function/method in
> files that declared `strict_errors` throw ErrorException on Notice/Warning.
>
> Example:
>
> File: Test.php
>  declare(strict_errors=1); // does not support block declare like
> 'strict_type'
>
> class Test {
> public function __construct()
> {
> echo $a; // ErrorException will be thrown from here
> }
> }
>
> File: main.php
>  require 'Test.php';
> $test = new Test(); // Fatal error: Uncaught ErrorException: Undefined
> variable: a
>
> But if `set_error_handler()` is in use nothing will happen.
>
> File: main.php
>  require 'Test.php';
> set_error_handler(function () {
>
> });
> $test = new Test(); // silent
>
> I've just made a naive implementation to demonstrate this approach at
> https://github.com/webdevxp/php-src.
> What I've done was just adding new ZEND_ACC_STRICT_ERRORS flag to top level
> function and modified `php_error_cb` to check if there is a caller with
> `strict_errors` defined. (by simply checking `EG(current_execute_data)` and
> its all `prev_execute_data`)
>
> I think this approach might satify both 'strict camp' and 'bc camp'.
>
> P.S. I myself agree with this RFC and would vote YES if I can vote. And I'm
> grateful for Nikita's (and others) contributions that make PHP awesome
> today.
>
> Cheers :)
>
> On Wed, Aug 28, 2019 at 4:33 PM Nikita Popov  wrote:
>
> > Hi internals,
> >
> > I think it's time to take a look at our existing warnings & notices in
> the
> > engine, and think about whether their current classification is still
> > appropriate. Error conditions like "undefined variable" only generating a
> > notice is really quite mind-boggling.
> >
> > I've prepared an RFC with some suggested classifications, though there's
> > room for bikeshedding here...
> >
> > https://wiki.php.net/rfc/engine_warnings
> >
> > Regards,
> > Nikita
> >
>

Re: [PHP-DEV] Evolving PHP

[Olumide Samson]

On Fri, Sep 13, 2019, 3:10 PM Rasmus Lerdorf  wrote:

> Lots of drama on internals lately. Not that different from 15-20 years ago.
> A couple of things to keep in mind for everyone.
>
> It is not that hard to write a tool that perfectly fits your own needs and
> people who are very similar to you in terms of skillset, background and
> overall experience. What PHP has always strived to do is to be much broader
> than that. Writing a tool that is very approachable to beginners that can
> still scale to some of the largest sites in the world is a much harder and
> more interesting problem and requires some compromises on both ends.
>
> The people writing the code get to call the shots, for better or worse. In
> the beginning I called all the shots. As more people started to contribute
> it took me a while to let go and accept contributions I didn't agree with.
> We wouldn't be here today if I hadn't done that.


Sorry if I'm asking the wrong question, was this quote/line intended for
Zeev?


Since the people currently writing the code(majority of them) are calling
some shots lately and he don't seem to want to agree to any of it
democratically.

-Rasmus
>

Re: [PHP-DEV] Changing fundamental language behaviors

[Olumide Samson]

I'm thinking this thread is receiving much attention than really required.

Irrespective of the left and right argument, I think everyone wants a
better language, the leftist are just arguing on a very lazy fact, not that
they don't see anything bad in their wrong argument they are all just
trying to hide behind "We know it is bad or can be devastating, let's just
leave it as it is and hope nobody ever have reasons to clean it since it is
still working" but me and those rightist are all like, this is wrong let's
save billions of codes that could still be added to this buggy behavior
than leaving it and hoping it would be one of the best dynamism people want
from PHP.

How does bug translate to dynamism?

Why were there notices if something wasn't wrong somewhere with the
behavior?

If I'm to argue as php-src(being human), I would never allow those leftist
to use me to write code again coz it is highly straining to pretend to know
what an undefined variable meant( to be an int or string, or even an
object) or even if it was a typo.

We are straining the language performance even more by making it guess what
the undefined variable would have been.

Even a string would still go up as integer the moment you add ++($i++) to
it.

Why don't you people see it is safe and would be in everyone's best
interests if we could clean this garbage behavior once and for all to live
peacefully, and possibly reduce the amount of baggage behavior lying around
in millions of codes out there, coz the counts increase every single day
because everyone thinks it is the right behavior yet their error_log keep
on getting notices?


Zeev said the RFC was never meant to deprecate things and as such the
voting would eventually not pass on to implementation even if it was
accepted -

"why then do you vote no on the RFC if it was never a valid vote to count?"

I think voting on the RFC validates the RFC for all you've voted it for
which means it's a valid way to deprecate features, else all formerly
deprecated features can be reverted since they are invalidated by the
current situation(or eye opening statement you just made).

I think we all need to see from the right spot how many people and code we
would save if this garbage were reported as Warning or error as early as
possible than waiting for never yet still giving me notice in my error_log
everytime PHP hit an undefined variable.

One thing some people are forgetting is that this is an open source
community and people(myself included) coming here to pull, push, commit,
test, manage and even join the mailing list are not getting paid by anyone
to do so(there might be an exception), and being an open source project we
all need to agree to disagree no one has any authority over anyone.

If there's been some laid out rules about some chairmen and the authorities
they posses to always swing things in their favor, I'm very sure this
project would have been dead on arrival( while there are so many projects
wanting attention), since a open source project needs help from
contributors I think we all need to think properly about rules or
guidelines that might hurt the project's contribution.

I don't pray to see PHP 9 timelines not posted by anyone(coz there's no one
around to do so) or even php-src to be one of those languages where their
contribution reduced drastically based on some people's bad influence
affecting the other contributors.

Let's argue rightly and expect other people to not agree with us, that's
the default.

Thanks,
Samson(noobshow)

On Fri, Sep 13, 2019, 9:11 AM Robert Korulczyk  wrote:

> > Upgrading the ~68,000 open source plugins available on wordpress.org <
> http://wordpress.org/>, thousands of commercial plugins, and and an
> untold number of custom-developed bespoke plugins and custom themes is
> where the concern lies.
>
> Many of these are ticking bombs - unmaintained extensions with possible
> security issues. Right now the biggest problem of WordPress ecosystem is
> quality of community extensions and themes. Cutting of all old and
> unmaintained extensions may be not that bad...
>
>
> Regards,
> Robert Korulczyk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Changing fundamental language behaviors

[Olumide Samson]

On Thu, Sep 12, 2019, 10:15 PM Chase Peeler  wrote:

>
>
> On Thu, Sep 12, 2019 at 4:59 PM Alexandru Pătrănescu 
> wrote:
>
>> Hi guys,
>>
>> > Many of us don't consider it bad code. I've also always initialized
>> > variables when it was required (and many times when it wasn't) even
>> though
>> > I wasn't forced to do so. A lot of other people do as well. If it's so
>> > important to you, start a program to teach people how you think they
>> should
>> > code.
>>
>> One problem that needs to be understood is that PHP is used by a lot of
>> users.
>> Because it's easy to pick up and you have fast feedback it probably have
>> a higher percentage of juniors than average.
>>
>
> I don't think "new developers might do it wrong" is a very compelling
> argument. We shouldn't handcuff the language because some people might use
> the flexibility improperly.
>
>
>> How language was 10 years ago it didn't helped them much in learning and
>> they did lot of mistakes. Some of those mistakes cost companies lots of
>> money and, in time, people got to the conclusion that PHP is bad.
>> This is a very important thing!, Yes you can write working great code in
>> PHP but it's very easy to write working bad code as well. And it's not
>> about you and me or the other persons chatting here, it's about the rest of
>> the world.
>>
>>
> And I don't think we should take away the flexibility that makes PHP great
> because some people don't use it correctly. "Billy can't code properly
> unless the the application crashes whenever he doesn't initialize a
> variable" isn't any more compelling when it's in the third person than it
> was in the first person.
>

I hate to see people taking PHP dynamic bug-friendly pattern as great
flexibility. Why would something be great and same time be bad?
Isn't that a contradiction?
PHP is great in flexibility for things like being dynamically typed, fast
to launch(major hosts always have it enabled), easier to understand but not
for allowing bugs that can cost huge money in the long run.

PHP is a very good friendly language when it comes to learning, yet the
worst language when it comes to ideology or roadmap.

Most companies only prefer PHP to make fast MVP, but as soon as that stage
passed, their HR would start searching for developers in other better
languages.

Check out stackoverflow and see how many buggy questions are asked daily.

>
>
>> PHP improved on it's bad image in the later years but this needs to
>> continue. IMO, one thing that we need to also do is to make the language
>> image better.
>> With this in mind, I believe the "undefined variable" error will be a
>> step forward.
>>
>>
> But it won't. People that won't a stricter language aren't going to start
> using PHP because it suddenly throws more errors than it used to. As I
> mentioned before, some non-PHP developers I knew find it appalling that
> such a massive BC break was even being considered. As much as they don't
> like the idea of uninitialized variables, the fact that they've been around
> for 20 years and now there is talk of them making applications crash was
> much bigger issue.
>
> The way we improve PHPs image is we show why the things that make it
> unique are actually good things, while adding NEW features to the language.
> No matter how much we try to make PHP like Java, c#, python, etc., it isn't
> going to entice those developers over to PHP when PHP doesn't offer them
> anything different than what they already have.
>
>
>
>> It's not about if you don't consider it bad code and that apparently the
>> majority consider it good.
>> It's that if language wouldn't allow you to write that code it will
>> benefit the language image and the rest of the PHP comunity.
>>
>> Also, I would also like to remind of this:
>> https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md
>> I think some parts might have been violated multiple time in this thread.
>>
>>
> I can take the hint. This will likely be my last post on the topic. I
> think there are few others on this thread that can take up the fight from
> here on out.
>
>
>> Regards,
>> Alex
>>
>>
>> On Thu, Sep 12, 2019 at 10:29 PM Chase Peeler 
>> wrote:
>>
>>> On Thu, Sep 12, 2019 at 3:17 PM Olumide Samson 
>>> wrote:
>>>
>>> > On Thu, Sep 12, 2019 at 8:11 PM Michael Babker <
>>> michael.bab...@gmail.com>
>>> > wrote:
>>> >
>>> > > On Thu, Sep 12, 2019 at 2:06 PM Olumide Samson >> >
>

Re: [PHP-DEV] Changing fundamental language behaviors

[Olumide Samson]

On Thu, Sep 12, 2019 at 8:29 PM Chase Peeler  wrote:

>
>
> On Thu, Sep 12, 2019 at 3:17 PM Olumide Samson 
> wrote:
>
>> On Thu, Sep 12, 2019 at 8:11 PM Michael Babker 
>> wrote:
>>
>> > On Thu, Sep 12, 2019 at 2:06 PM Olumide Samson 
>> > wrote:
>> >
>> >> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker <
>> michael.bab...@gmail.com>
>> >> wrote:
>> >>
>> >>> On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot 
>> >>> wrote:
>> >>>
>> >>> > Just a dumb idea, since there clearly is a majority in favor of the
>> >>> > change with these warnings and strictness and all that now... Why
>> not
>> >>> > making something like an LTS PHP 7.x where all the legacy code would
>> >>> > work OK as long as practically possible and 8.x+ would be the future
>> >>> > of what the developers want and not what business wants? One who
>> won't
>> >>> > upgrade due to the BC breaks also won't need the new features anyway
>> >>> > very realistically.
>> >>> >
>> >>>
>> >>> Please don't tie the notion of LTS with the idea that a new major can
>> >>> break
>> >>> BC at will or create larger scale breaks because the previous major
>> has
>> >>> extended support.  Sooner or later that will end up back at the ++
>> idea
>> >>> and
>> >>> fragmentation encouraged by the language is a bad idea.
>> >>>
>> >>
>> >> Not sure you are really seeing the goal...
>> >>
>> >> Why is LTS not a good idea?
>> >>
>> >
>> > I'm not saying LTS is a bad idea.  I'm saying using LTS to justify
>> > shipping larger scale BC breaks, such as the changes suggested in the
>> last
>> > couple of "contentious" RFCs in a major version because "hey, we have a
>> LTS
>> > version you can use that until you're ready to deal with the backlog of
>> BC
>> > breaks created" is a bad idea.
>> >
>>
>>
>> > For the record, I happen to agree with as these RFCs would have minimal
>> > impact on my day-to-day work, but having also been in the role of a
>> > maintainer of open source libraries and applications I also grasp why
>> these
>> > types of changes can be problematic to the ecosystem (both end users of
>> > those libraries and applications and the maintainers of them) and
>> wouldn't
>> > jump the gun to ship them without careful consideration.
>> >
>>
>> Most of these changes wouldn't have been problematic to you if the
>> language
>> has prevented you from writing what we can now consider bad code, so
>> please
>> allow the new PHP developer that newly start using PHP to not follow that
>> your path that will/might hunt him later in the future...
>>
>>
> Many of us don't consider it bad code. I've also always initialized
> variables when it was required (and many times when it wasn't) even though
> I wasn't forced to do so. A lot of other people do as well. If it's so
> important to you, start a program to teach people how you think they should
> code.
>
>
>> There a notices, warning and errors to inform you that this shouldn't have
>> been the use case of this feature and you chose to ignore it and now, we
>> are simplifying things and making those your errors teach you how to write
>> proper codes in the future, you're objecting..
>
>
> As has been discussed before, notices are not the same as warnings and
> errors.  Also, if those things are so wonderful, why can't you use them to
> catch the issues you are complaining you can't catch right now? Again, you
> are telling me there is something out there which will allow you to force
> yourself to write "good code" without forcing me to follow the same
> restrictions. Yet, you still feel it's necessary to not use those tools,
> and instead modify the entire language so that I am forced to follow what
> you deem best practices, even if I don't?
>
>
>
>> Why not just stay in PHP 7.x?
>>
>> Because other features that I want to utilize will also be added in PHP
> 8.
>
> I think it's all up to you to decide if those features you need would be
worth it moving to PHP 8(perhaps helping you clean up some codes i would
seem as bad practice IMO) or those features are not worth cleaning up for(
then  you can stay on PHP 7, even 5 for as long as you wan to)...

In all of these,

Re: [PHP-DEV] Changing fundamental language behaviors

[Olumide Samson]

On Thu, Sep 12, 2019 at 8:15 PM Chase Peeler  wrote:

>
>
> On Thu, Sep 12, 2019 at 3:06 PM Olumide Samson 
> wrote:
>
>> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker 
>> wrote:
>>
>> > On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot 
>> wrote:
>> >
>> > > Just a dumb idea, since there clearly is a majority in favor of the
>> > > change with these warnings and strictness and all that now... Why not
>> > > making something like an LTS PHP 7.x where all the legacy code would
>> > > work OK as long as practically possible and 8.x+ would be the future
>> > > of what the developers want and not what business wants? One who won't
>> > > upgrade due to the BC breaks also won't need the new features anyway
>> > > very realistically.
>> > >
>> >
>> > Please don't tie the notion of LTS with the idea that a new major can
>> break
>> > BC at will or create larger scale breaks because the previous major has
>> > extended support.  Sooner or later that will end up back at the ++ idea
>> and
>> > fragmentation encouraged by the language is a bad idea.
>> >
>>
>> Not sure you are really seeing the goal...
>>
>> Why is LTS not a good idea?
>> And, if the majority want this or that, can we just blow everything into
>> full dictatorship where i can host my fork of PHP doing uncountable
>> unwanted things i can call it..?
>>
>> Any which way, i think the majority of us are tired of writing bad codes,
>> but since the language is allowing it we don't have choices than to spend
>> some hours or weeks later debugging the wrong or right line we did that
>> last "big mistake", who knows there might be another line smiling coz i
>> haven't detected it...
>>
>
> I can write good code without sacrificing the flexibility provided by PHP.
> Don't force ME to write code a specific way because you aren't disciplined
> enough to not write bad code without the compiler forcing you to do things
> a certain way.
>
> Of all of the justifications for this RFC I've heard, "I can't stop
> writing bad code as long as I'm allowed to" has to be the worst.
>
> Yea, that's just one of the popular reasons, there are more if you go on
Stack Overflow and see what this dynamism(my foot) has caused to real-world
codes and fortunes that has been lost due to it(Which i'm also a testimony
to the fact).

> --
> Chase Peeler
> chasepee...@gmail.com
>

Re: [PHP-DEV] Changing fundamental language behaviors

[Olumide Samson]

On Thu, Sep 12, 2019 at 8:11 PM Michael Babker 
wrote:

> On Thu, Sep 12, 2019 at 2:06 PM Olumide Samson 
> wrote:
>
>> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker 
>> wrote:
>>
>>> On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot 
>>> wrote:
>>>
>>> > Just a dumb idea, since there clearly is a majority in favor of the
>>> > change with these warnings and strictness and all that now... Why not
>>> > making something like an LTS PHP 7.x where all the legacy code would
>>> > work OK as long as practically possible and 8.x+ would be the future
>>> > of what the developers want and not what business wants? One who won't
>>> > upgrade due to the BC breaks also won't need the new features anyway
>>> > very realistically.
>>> >
>>>
>>> Please don't tie the notion of LTS with the idea that a new major can
>>> break
>>> BC at will or create larger scale breaks because the previous major has
>>> extended support.  Sooner or later that will end up back at the ++ idea
>>> and
>>> fragmentation encouraged by the language is a bad idea.
>>>
>>
>> Not sure you are really seeing the goal...
>>
>> Why is LTS not a good idea?
>>
>
> I'm not saying LTS is a bad idea.  I'm saying using LTS to justify
> shipping larger scale BC breaks, such as the changes suggested in the last
> couple of "contentious" RFCs in a major version because "hey, we have a LTS
> version you can use that until you're ready to deal with the backlog of BC
> breaks created" is a bad idea.
>


> For the record, I happen to agree with as these RFCs would have minimal
> impact on my day-to-day work, but having also been in the role of a
> maintainer of open source libraries and applications I also grasp why these
> types of changes can be problematic to the ecosystem (both end users of
> those libraries and applications and the maintainers of them) and wouldn't
> jump the gun to ship them without careful consideration.
>

Most of these changes wouldn't have been problematic to you if the language
has prevented you from writing what we can now consider bad code, so please
allow the new PHP developer that newly start using PHP to not follow that
your path that will/might hunt him later in the future...

There a notices, warning and errors to inform you that this shouldn't have
been the use case of this feature and you chose to ignore it and now, we
are simplifying things and making those your errors teach you how to write
proper codes in the future, you're objecting.. Why not just stay in PHP 7.x?

Or were you implying you want hitch-free, no-modification upgrade to PHP 8
from PHP 7.0?
If yes, follow the best practices and not suppress error notices.

Just My Opinion

Re: [PHP-DEV] Changing fundamental language behaviors

[Olumide Samson]

On Thu, Sep 12, 2019 at 8:00 PM Michael Babker 
wrote:

> On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot  wrote:
>
> > Just a dumb idea, since there clearly is a majority in favor of the
> > change with these warnings and strictness and all that now... Why not
> > making something like an LTS PHP 7.x where all the legacy code would
> > work OK as long as practically possible and 8.x+ would be the future
> > of what the developers want and not what business wants? One who won't
> > upgrade due to the BC breaks also won't need the new features anyway
> > very realistically.
> >
>
> Please don't tie the notion of LTS with the idea that a new major can break
> BC at will or create larger scale breaks because the previous major has
> extended support.  Sooner or later that will end up back at the ++ idea and
> fragmentation encouraged by the language is a bad idea.
>

Not sure you are really seeing the goal...

Why is LTS not a good idea?
And, if the majority want this or that, can we just blow everything into
full dictatorship where i can host my fork of PHP doing uncountable
unwanted things i can call it..?

Any which way, i think the majority of us are tired of writing bad codes,
but since the language is allowing it we don't have choices than to spend
some hours or weeks later debugging the wrong or right line we did that
last "big mistake", who knows there might be another line smiling coz i
haven't detected it...

Re: [PHP-DEV] Changing fundamental language behaviors

[Olumide Samson]

On Thu, Sep 12, 2019 at 7:10 PM Lynn  wrote:

> On Thu, Sep 12, 2019 at 7:59 PM Mike Schinkel  wrote:
>
> >
> >
> > Just a few weeks ago I was refactoring some particularly horrible code
> > developed by previously employed developers — a code based that has a
> 1400
> > line function and many other functions 100s of lines long, and I added
> some
> > initialization for variable and array elements prior to their use.
> >
> > Unfortunately my changes broke the code because the original developer
> > using isset($var) as branching criteria.  After finding this bug, I
> > realized that this code base uses that technique frequently.  I am know
> > from lots of experience that this is a common technical among WordPress
> > plugins.
> >
> >
> The bug is not that you initialized the variable, it's that you initialized
> it with a different value: https://3v4l.org/8mB8B
> ```
> var_dump(isset($a));
> $a = null;
> var_dump(isset($a));
>
> // gives
> bool(false)
> bool(false)
> ```
>
> Whenever one of these errors will occur, you can initialize either the
> array key or variable with null and it will work again without changing
> behavior. If anything, Wordpress shouldn't be an argument to not improve
> PHP, though I think it's important to consider the impact of a change,
> including for the Wordpress community. However, I think most people agree
> that the quality of Wordpress code and Plugins is highly debatable. I don't
> like the idea of not being able to progress because Wordpress users won't
> upgrade PHP.
>
> even without a statistics to back the word is plainfully meaningless...

I guess we tend to use the word "HUGELY","NEVER","EVER","COMPANY", etc
wrongly on the list just to prove some points.

And, we're better off than that IMO...

> Regards,
> Lynn van der Berg
>

Re: [PHP-DEV] Changing fundamental language behaviors

[Olumide Samson]

I think it would do this list more good than not, if we talk or assume
about some people who will ever or never upgrade...
Seriously?
How do you know if they would never or ever upgrade, you can only and
should probably speak for yourself...

If they want more customers(translating to revenue), they can upgrade and
if they don't it's all up to them...

On Thu, Sep 12, 2019 at 6:59 PM Mike Schinkel  wrote:

> > On Sep 12, 2019, at 10:37 AM, Lynn  wrote:
> >
> > On Thu, Sep 12, 2019 at 7:22 PM Chase Peeler 
> wrote:
> >
> >> There are valid reasons for not always initializing variables or array
> >> keys. It might be a bad
> >> reason in your opinion, but others view it as perfectly acceptable.
> >>
> >
> > I recently had to fix a bug where a variable was renamed, caused a merge
> > conflict and resulted in months long of changing a business process with
> a
> > subtle bug, as null was not the intended initialized value. Whether or
> not
> > people should initialize variables is debatable from a programming
> > perspective. From a reader's perspective it's really important to have
> > variables initialized with a default value, even if it's just null, to
> > prevent missing certain assignment branches and avoid bugs. From my
> > perspective, this should've thrown an error, so we would've fixed it the
> > same day. Now PHP simply broke our business process for months.
> >
> > Yes, we hide notices, even in production as our logging server would die
> > within a minute if we'd turn it on. Yes, this is a massive legacy code
> base
> > where lots of tests are lacking. Can we change this? Sure, will take
> years
> > though. Would we have benefited from PHP throwing an error in this case?
> > Most certainly, would've saved us a lot of headache, and money.
> >
> > You argue that it's a fundamental language change, I -and seemingly a lot
> > of others- argue that this is more of a bug fix.
>
> Just a few weeks ago I was refactoring some particularly horrible code
> developed by previously employed developers — a code based that has a 1400
> line function and many other functions 100s of lines long, and I added some
> initialization for variable and array elements prior to their use.
>
> Unfortunately my changes broke the code because the original developer
> using isset($var) as branching criteria.  After finding this bug, I
> realized that this code base uses that technique frequently.  I am know
> from lots of experience that this is a common technical among WordPress
> plugins.
>
I think they could switch to using null instead, or perhaps get something
else to differentiate what they have initialized or not, that shouldn't
stop them from using PHP, probably it will only make them not upgrade to
PHP if they think their bad coding practice is the way forward and the best
way to code..

If PHP8 were to change to require variables and/or array elements to be
> initialized then this code base and any similar to it will be broken.
> Companies with these code bases almost certainly will simply not upgrade to
> PHP 8.  Probably ever.
>
> This is merely assumptions and you can't speak for companies you don't
know, what's the statistics backing these your use of "ever and never"?


> BTW, prior to gaining this company as a client, the internal people felt
> that the codebase needed to be completely rewritten rather than
> incrementally refactored. And because rewriting would have been such a
> large project they have been putting it off for several years.  In their
> case, we will be cleaning up the code base (although doing so will be very
> costly for them.)
>
> And I estimate there are a large number of similar scenarios in the wild
> that do not currently have plans the people or the funds to clean up their
> similar code.
>
> It's up to them, PHP 7 is still available and will always be available for
them to use...

> #jmtcw
>
> -Mike
>
>

Re: [PHP-DEV] Changing fundamental language behaviors

[Olumide Samson]

On Thu, Sep 12, 2019 at 6:54 PM Chase Peeler  wrote:

> On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown 
> wrote:
>
> > What if Java suddenly said that all properties are suddenly private, and
> >> can only be accessed through getter/setter methods?
> >>
> >
> > If Java announced that the next major version was to make the change
> after
> > 95% of userland developers favoured it and over 2/3rds of their internals
> > team did, I'd think "huh ok I guess they have good reasons".
> >
> >
> I call shenanigans on that 95% number. Can you please back that up?
> Personally, I don't think it's even possible to gauge userland
> support because the vast majority of userland developers aren't involved in
> the community at all. Those people don't even know this is being discussed,
> and probably won't until they start looking to upgrade to PHP 8.
>
> I'm sure you need to read the message properly before replying, he ain't
talking about PHP there...

Even 95% can be called anything(of users who are involved in the community,
who knows, who are actual users, etc)

>
> > For 20 years people have developed code based on that feature. It was
> >> never considered an error, and often not even considered bad practice
> >
> >
> > You seem to be arguing against *ever* changing something that a majority
> > once thought was good, and fundamental to a given system. Lots of things
> > fall into that category - restricting voting to men, segregation, etc.
> >
> >>
>
> --
> Chase Peeler
> chasepee...@gmail.com
>

Re: [PHP-DEV] Changing fundamental language behaviors

[Olumide Samson]

On Thu, Sep 12, 2019 at 6:22 PM Chase Peeler  wrote:

> On Thu, Sep 12, 2019 at 1:05 PM Matthew Brown 
> wrote:
>
> > that don't fundamentally change the language
> >
> >
> > There's clearly a big disagreement about whether this is a fundamental
> > change or not.
> >
> > Preventing something that the entire field of software engineering frowns
> > upon (and that most PHP developers avoid like the plague) doesn't seem
> like
> > a *fundamental* change.
> >
> >
> I would argue that this is exactly such a change. The flexibility of PHP
> has often been touted as a feature and something that sets it apart.
> Whether that's good or bad is, frankly, irrelevant. There are valid reasons
> for not always initializing variables or array keys.

 The major valid reason i see is creating a bolierplate or being lazy to
initialize the variable with even null or similar null-type depending on
its context.

It might be a bad reason in your opinion, but others view it as perfectly
> acceptable.

 Who are those "others"?
I think he(me included) is also one of those "others" that view it as bad
programming style...

For 20 years people have developed code based on that feature. It was never
> considered an error, and often not even considered bad practice.

 It was considered an error, that's why you were been warned or given
notice that "Hey dude, you're writing a bad code here @ line 1427(l4zy) of
already-problematic-file.php" and only if we want to remove Notice,Warning
or Error in the language.


> To suddenly define it as such is the exact definition of a fundamental
> change
> to the language itself.
>
Fundamental is always "fundamental", i think there's no good definition for
it in this context, so leave fundamental changes out of this discussion as
something totally bad been cleaned up is a fundamental change and something
new but not used right and changed to be used right is also fundamental...


>
> What if Java suddenly said that all properties are suddenly private, and
> can only be accessed through getter/setter methods? The fact that you
> should make properties private and use such methods is a practice that was
> drilled into me from day one. Would that justify making such a change,
> though?
>
> I'm not sure how this relates, i think Java would let you see the good or
bad, it's up to you to see or not from their view, let the majority move
forward and don't be a stopping stone in moving this language past the 1993
bondage(needle-haystack, inconsistent naming and many issues we couldn't
count)...

Re: [PHP-DEV] [RFC] Object Initializer

[Olumide Samson]

The RFC is a beautiful feature suggestion, but something is telling me as
beautiful and straightforward the syntax is, what can the use case be?

I really love Constructor or Object initialization to be implemented in
PHP, but is there something I think you're missing in the RFC?

Thanks for the RFC.

On Thu, Sep 12, 2019, 4:02 PM Lynn  wrote:

> On Thu, Sep 12, 2019 at 4:00 PM Michał Brzuchalski <
> michal.brzuchal...@gmail.com> wrote:
>
> > Hi internals,
> >
> > I'd like to open discussion about RFC: Object Initializer.
> >
> > This proposal reduces boilerplate of object instantiation and properties
> > initialization in case of classes without required constructor arguments
> as
> > a single expression with initializer block.
> >
> > https://wiki.php.net/rfc/object-initializer
> >
> > I appreciate any feedback you all can provide.
> >
> > Thanks,
> > --
> > Michał Brzuchalski
> > brzuc...@php.net
> >
> >
> Heya,
>
> What's the added benefit of this compared to implementing a constructor?
>
> The part I like is that this can be used to replace stdClass/structured
> arrays. Perhaps something like this would nice to have in PHP:
>
> ```
> $people = [];
>
> foreach ($peopleFromDatabase as [$id, $username, $name]) {
> $people[] = {
> Uuid id => $id,
> string username => $username,
> string name => $name,
> };
> // and possible automatic assignment:
> $people[] = {Uuid $id, string $username, string $name};
> }
> ```
>
> Regards,
> Lynn van der Berg
>

Re: [PHP-DEV] Changing fundamental language behaviors

[Olumide Samson]

You first me on that reply Dan, I guess I should just say "the naysayers
are back", I can see their footprint all around.

The RFC is Request for Comment on any changes, is there an explicit or
implicit mention about what kind of proposed changes can be made?

Mr/Mrs Zeev are you for PHP or against it?
I know you are one of the authors of Zend Engine, but please follow the
rules and don't make rules simply because something is going the way you
don't want it to.

That's why there's this called "vote".

On Thu, Sep 12, 2019, 3:52 PM Dan Ackroyd  wrote:

> On Thu, 12 Sep 2019 at 15:44, Zeev Suraski  wrote:
> >
> > The RFC process was never, ever meant to handle fundamental changes to
> the
> > language.
>
> The only appropriate response to this is "lolwat?".
>
> You keep making up rules...that don't exist. You can't expect people
> to suddenly stop using RFCs to change the language just because you
> say so.
>
> Please stop this behaviour. It's really not appropriate.
>
> sincerely
> Dan
> Ack
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

[Olumide Samson]

On Thu, Sep 12, 2019, 2:59 PM Chase Peeler  wrote:

>
>
> On Thu, Sep 12, 2019 at 8:33 AM Olumide Samson 
> wrote:
>
>> Thanks to those who can vote, all in all I hope for a better language
>> where
>> we can proudly post jobs(even intern) for on our company's website without
>> been looked down on as inferior.
>>
>> If you're so embarrassed by the language, then why not use something
> else, instead of trying to force such massive changes on the entire user
> base?
>
Anything considered through vote is opinion based, not the way you could
call "force" and I think you can also ask those who are not embarrassed by
the current language situation to stick to whatever is their current
version. Upgrading can't be for everyone.
Only those who like major features/changes  of a new version upgrade.

>
> Also, if you really think this is going to change how non-PHP developers
> view PHP, you're sorely mistaken. The few I've talked to about this, in
> order to gauge how the languages they work in handle BC breaks, were
> appalled that such a major breakage would be forced on users, even though
> they personally don't like the fact that PHP supports uninitialized
> variables.
>
I'm sure you are the one mistaken here, cos you don't speak for non-PHP
developers likewise I don't.

You can in all utmost speak for yourself like I did In my last email.

>
> Again, I implore everyone to stop trying and make everyone else like us.
> Our language is awesome because of the fact that it is different and
> flexible. That flexibility allows you to be strict if you want. If we just
> want to turn PHP into another language that is like everything else out
> there, then what's the point of even using PHP to begin with?
>
>
I'm sure you are insulting the Project through those written words. If the
project still want to be what it has always been, then there's no want or
need for anything called @internals cos the language can actually still
stick to PHP 3 and become what it has always been without any updates or
changes.

Like I said, since I can't vote I can only hope for the best.

Since I can't vote, I can only hope for the best.
>>
>> <3
>>
>> On Thu, Sep 12, 2019, 1:17 PM Nikita Popov  wrote:
>>
>> > Hi internals,
>> >
>> > I've opened the vote on //wiki.php.net/rfc/engine_warnings.
>> >
>> > There are 4 votes, all of them independent. The first 3 are for specific
>> > cases that were controversial during the discussion, the last one is for
>> > the remainder of the proposal.
>> >
>> > Voting closes 2019-09-26.
>> >
>> > Regards,
>> > Nikita
>> >
>>
>
>
> --
> Chase Peeler
> chasepee...@gmail.com
>

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

[Olumide Samson]

Thanks to those who can vote, all in all I hope for a better language where
we can proudly post jobs(even intern) for on our company's website without
been looked down on as inferior.

Since I can't vote, I can only hope for the best.

<3

On Thu, Sep 12, 2019, 1:17 PM Nikita Popov  wrote:

> Hi internals,
>
> I've opened the vote on //wiki.php.net/rfc/engine_warnings.
>
> There are 4 votes, all of them independent. The first 3 are for specific
> cases that were controversial during the discussion, the last one is for
> the remainder of the proposal.
>
> Voting closes 2019-09-26.
>
> Regards,
> Nikita
>

Re: [PHP-DEV] Make error_reporting=E_ALL the default

[Olumide Samson]

+1

On Fri, Aug 30, 2019, 11:13 AM Javier Spagnoletti  wrote:

> Great step! +1
> Thank you so much Nikita.
>
> El vie., 30 de ago. de 2019 07:02, Arvids Godjuks <
> arvids.godj...@gmail.com>
> escribió:
>
> > пт, 30 авг. 2019 г. в 11:33, Nikita Popov :
> >
> > > Hi internals,
> > >
> > > Relating to the recent discussions on undefined variables & co. One
> thing
> > > that is particularly annoying about the undefined variable case is that
> > our
> > > default error_reporting level (without a php.ini) does not include
> > > E_NOTICE.
> > >
> > > Thankfully distros do tend to have more reasonable defaults, but if you
> > > spend as much time with custom PHP builds as I do, not seeing
> *anything*
> > > for undefined variables is a pretty big annoyance.
> > >
> > > Does anyone see an issue with making error_reporting=E_ALL the default
> in
> > > PHP 8? It can of course still be manually downgraded via php.ini and
> > > php.ini-production will retain the existing recommendation that
> excludes
> > > E_DEPRECATED/E_STRICT.
> > >
> > > PR: https://github.com/php/php-src/pull/4659
> > >
> > > Regards,
> > > Nikita
> > >
> >
> > +1 from userland.
> >
> > I always have edited the php.ini for production. I also usually edit
> > development too to include all error levels, but yeah - having shipped
> > php.ini with sane defaults would be very welcome.
> > I do agree with Zeev that production file should probably resemble what
> > php.ini-development is right now, so I'd say we need to go deeper ;)
> >
> > --
> > Arvīds Godjuks
> >
> > +371 26 851 664
> > arvids.godj...@gmail.com
> > Skype: psihius
> > Telegram: @psihius https://t.me/psihius
> >
>

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

[Olumide Samson]

On Thu, Aug 29, 2019, 12:33 AM Stanislav Malyshev 
wrote:

> Hi!
>
> On 8/28/19 4:23 PM, Matthew Brown wrote:
> > $foo++ becoming 1 when $foo is undefined is not intuitive to me.
>
> I guess we have different intuition.
>
> > To take a very trivial example, that behaviour causes “for ($i = 0;
> > $i < 10; $I++) {}” to loop indefinitely.
> This is rather shallow issue, which any modern IDE would highlight for
> you in about 0.5 seconds. No need to change the language for that.
> Frankly, I have hard time remembering when any of such typos ever get
> past IDE check since I started using IDEs.
> And, of course, it's completely obvious issue - you could as well forget
> to write $i++ at all, or write $j++ and have $j defined somewhere...
> there's a lot of artificial scenarios one could think of. No reason to
> change rules of the whole language because of it.
>

Can you point me to an IDE that runs on the server?
I think you are mixing static analysis error with dynamic runtime analysis.

IDE can't point to an error it doesn't know about(which I didn't code using
IDE but use notepad, where I didn't run full test before publishing to
production).

I don't think it makes sense to allow the language be a home of "anything
goes, no innovation".

A language without specification.

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

[Olumide Samson]

On Wed, Aug 28, 2019, 5:12 PM Mark Randall  wrote:

> On 28/08/2019 16:37, Chase Peeler wrote:
> > I'm also not the one that built it on the eggshells - I'm just the one
> that
> > is now in charge of developing the system that someone else left sitting
> > eggshells.
>
> That's a challenge which at some point or another will face all
> technical leads.
>
> You have to go to the people making the decisions and say:
>
> "Okay, look, we've got ourselves a problem here. We've dug ourselves
> into a hole by cutting corners, building up debt, and we've never made
> it a priority to fix it, and now it's causing us problems. It's not one
> person's fault, it's something that has collectively developed over
> time, but the reality is, the problem is there and needs fixing."
>
> And when the manager asks "What problems?" you say something like:
>
> "The language we use is moving towards a much stricter approach to
> handling ambiguous or error prone code. This can only be considered a
> good thing, but it is going to mean that a lot of our technical debt is
> going to manifest as errors that will stop our site from function..."
>
> Then the manager will go "Can't we just keep using the version we are on?"
>
> You reply:
>
> "We can for a short period, perhaps an extra year or two, but the
> reality is that PHP is moving forward, and the current version won't be
> supported forever, and even if it were, we would be missing out on major
> performance enhancements and new features that could help us to build
> new features".
>
> The manager says: "Lay this out to me"
>
> You reply:
>
> "It's like our company car still works, but it no longer tighter meets
> emissions standards so they won't let us take it into the city any more"
>
> "Crap", the boss replies "Okay, we had best fix that"
>
> --
> Mark Randall
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php


This is the best reply with all possible good reasons laid out in few
sentences per line ever I've seen on this mailing list.


>

Re: [PHP-DEV] Re: VCS Account Request: noobshow

[Olumide Samson]

Hi internals@,
Figured I could contribute without the vcs account.

Request canceled.
Thanks,
Samson.

On Tue, Aug 20, 2019, 12:38 PM Olumide Samson  wrote:

> Hi internals@,
> I'm Olumide Samson, lead developer at Zapay Inc(a financial service
> provider).
>
> All of our backend codes are written majorly in PHP(which is a language
> i've been programming in since 2007) and C(since 2006) which i write
> advance sys-related programs in...
>
> I'm hoping i could contribute to PHP Core in various ways and help grow the
> Project alongside the Core Contributors we have in the Community.
>
> I've been working on the Core code while getting familiar with the Zend
> engine for over 3 weeks now, though i've commited few changes, and hoping
> to do more as the Project grows...
>
> I hope we all can make this project grow better.
>
> Thanks,
> Samson.
>

[PHP-DEV] Re: VCS Account Request: noobshow

[Olumide Samson]

Hi internals@,
I'm Olumide Samson, lead developer at Zapay Inc(a financial service
provider).

All of our backend codes are written majorly in PHP(which is a language
i've been programming in since 2007) and C(since 2006) which i write
advance sys-related programs in...

I'm hoping i could contribute to PHP Core in various ways and help grow the
Project alongside the Core Contributors we have in the Community.

I've been working on the Core code while getting familiar with the Zend
engine for over 3 weeks now, though i've commited few changes, and hoping
to do more as the Project grows...

I hope we all can make this project grow better.

Thanks,
Samson.

Re: [PHP-DEV] Removing old branches in php-src

[Olumide Samson]

>
> Maybe it might necessarily not need be removed, if this might be a better
> idea, why shouldn't there be a php-archive or something like that as a git
> account or repository where all those historical branches may be kept for
> historical access?
>
> I think removing isn't making sense to me as well, but archiving them
> should be without not much justification like currently requested.
>
>

[PHP-DEV] VCS Account Request: noobshow

[Olumide Samson]

Contributing to the PHP Core and PHP Windows code

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Olumide Samson]

On Fri, Aug 16, 2019, 5:08 PM Mark Randall  wrote:

> On 16/08/2019 11:18, Christoph M. Becker wrote:
> > It is not necessarily required to have an implementation for an RFC
> > available, see item (6) in .
>
> I have enormous respect for Derick, but I can't help but feel this "RFC"
> was bodged from the start.
>
> There's certainly a place for straw polls, the ability to receive quick
> feedback on opinions and sentiment can be a positive thing in a lot of
> circumstances. This however, seemed more like an invitation for
> internals developers to express that they wouldn't entertain spending
> any time on the proposal, in effect forcefully slamming the door shut on
> it before a proper discussion had been had.
>
> The end result did seem to be like watching Zeev be thrown to the lions
> in the colosseum. While entertaining for a short time, I believe it left
> something of a sour taste in the mouth, and it certainly did not present
> internals well to the outside world. The hasty edits to the Wiki then
> made it worse, and so on.
>

On this last paragraph written below, I'm seriously with you on this.

I believe for anything remotely positive to come out of this whole
> affair.


Things need to quickly and visibly pivot to a meaningful
> discussion about the long term game plan for PHP, and build a consensus
> on things such as strict typing(Optional through declare directive) ,
> overloading in the core functions, and
> perhaps most divisively, if "cleaning up the language" is in itself a
> viable justification for backwards compatibility breaks, and if so, what
> weight(the biggest weight ever) it should carry.
>

Just in case a poll is needed, I added my +1 on the whole section you wrote
last.

>

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Olumide Samson]

Power of democracy, maturity and love(for this same project PHP), I guess.

If this same love and energy could be put in place to know the directions
and future PHP hold(like are we moving forward or not), that will seriously
be a game changer.

On Thu, Aug 15, 2019, 2:00 PM Kris Craig  wrote:

>
>
> On Thu, Aug 15, 2019, 3:20 AM Olumide Samson 
> wrote:
>
>> On Thu, Aug 15, 2019, 10:52 AM Peter Kokot  wrote:
>>
>> > On Wed, 14 Aug 2019 at 22:41, Zeev Suraski  wrote:
>> > >
>> > > On Wed, Aug 14, 2019 at 6:14 PM Derick Rethans 
>> wrote:
>> > >
>> > > > Hi,
>> > > >
>> > > > In the last week(s) there has been a lot of chat about Zeev's P++
>> idea.
>> > > > Before we end up spending this project's time and energy to explore
>> > this
>> > > > idea further, I thought it'd be wise to see if there is enough animo
>> > for
>> > > > this. Hence, I've created a document in the wiki as a poll:
>> > > >
>> > >
>> > > All,
>> > >
>> > > Using a humoristic tone, I'm happy that finally internals@ is so
>> > unified.
>> > > I almost get the feeling that you may not like the idea...
>> > >
>> > > On a more serious note, I'll keep the feedback on the validity of this
>> > vote
>> > > in just about every aspect (process, jurisdiction, anything really) to
>> > > myself, and say just two things:
>> > >
>> > > - The P++ idea makes absolutely no sense in vacuum.  The reception
>> around
>> > > this idea implied a decision between 'one big happy family' and 'a
>> > split'.
>> > > Since at this stage these are the perceived choices - I'd vote
>> against it
>> > > too (which I just did, why not).  However, I believe it's a false
>> choice.
>> > >
>> > > - It will absolutely make sense to discuss it when it'll start
>> becoming
>> > > clearer to everyone that 'one big happy family' is really not an
>> option.
>> > > We'd be choosing how to soft split the family - granularly (2^n
>> > dialects),
>> > > into many editions (n dialects), or into two separate dialects with
>> > clearer
>> > > mandates (2 dialects).  I get it that it's intangible for many of us
>> > > (myself included, to a degree), which is why this idea is perceived as
>> > the
>> > > 'evil splitter' for everyone to unite and rally against.  Maybe I'm
>> > wrong,
>> > > and the changes/features that I think are about to make it into PHP
>> > aren't
>> > > going to require any sort of split.  If that's the case - it's indeed
>> a
>> > > horrible idea.  We'd only be able to see that a but further down the
>> > road.
>> > > It's definitely too early to spend that level of energy on it at this
>> > stage
>> > > - but at the same time, it will definitely make sense to explore it
>> if &
>> > > when the reality I think we're going to be facing would begin to
>> unfold.
>> > >
>> > > I will not be responding to any further emails on this thread;  I'll
>> > > happily reply to private messages though.
>> > >
>> > > Thanks,
>> > >
>> > > Zeev
>> >
>> > Hello @everyone,
>> >
>> > this then also means that PHP will now never be a consistent language
>> > and short tags will be forever in so we will all be able to support
>> > Chase's gigantic legacy project forever?
>> >
>>
>> Solution would be if we can make this issue that was mentioned:
>> > - elephpant vs elep++ant
>> >
>> > into a similar issue as is now:
>> > - elephpant vs elephpantwithstricttypes
>> > (non existent issue - all part of the one PHP itself)
>> >
>>
>> Zeev(Or anyone with such energy) can take up the game with same energy
>> he(Zeev) took the *elep++ant *up and I bet everyone (or the majority)
>> would
>> really love the newer idea(elephpant vs elephpantwithstricttypes) and
>> probably take it up as a non issue coz it is all in the same part of the
>> one PHP itself(which already have its niche and brand).
>>
>> And, IMHO the strict type or cleaner version of PHP would improve many
>> sections of the language and even help with future implementations(maybe
>> sooner we might even implement more evolved and consistent aliases of
>> current C styled function naming) all of these and more in the same PHP
>> we've known.
>>
>> Or perhaps, an idea is to take a break on new implementations and make
>> some
>> great changes which will pave way for great ideas and innovations.
>>
>> All of this are good ideas internals@ should be debating, I guess.
>>
>
> Current vote is 39 - 0 in favor of rejection.  Who would've guessed this
> discussion would wind up being an exercise in unity lol
>
>

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Olumide Samson]

On Thu, Aug 15, 2019, 10:52 AM Peter Kokot  wrote:

> On Wed, 14 Aug 2019 at 22:41, Zeev Suraski  wrote:
> >
> > On Wed, Aug 14, 2019 at 6:14 PM Derick Rethans  wrote:
> >
> > > Hi,
> > >
> > > In the last week(s) there has been a lot of chat about Zeev's P++ idea.
> > > Before we end up spending this project's time and energy to explore
> this
> > > idea further, I thought it'd be wise to see if there is enough animo
> for
> > > this. Hence, I've created a document in the wiki as a poll:
> > >
> >
> > All,
> >
> > Using a humoristic tone, I'm happy that finally internals@ is so
> unified.
> > I almost get the feeling that you may not like the idea...
> >
> > On a more serious note, I'll keep the feedback on the validity of this
> vote
> > in just about every aspect (process, jurisdiction, anything really) to
> > myself, and say just two things:
> >
> > - The P++ idea makes absolutely no sense in vacuum.  The reception around
> > this idea implied a decision between 'one big happy family' and 'a
> split'.
> > Since at this stage these are the perceived choices - I'd vote against it
> > too (which I just did, why not).  However, I believe it's a false choice.
> >
> > - It will absolutely make sense to discuss it when it'll start becoming
> > clearer to everyone that 'one big happy family' is really not an option.
> > We'd be choosing how to soft split the family - granularly (2^n
> dialects),
> > into many editions (n dialects), or into two separate dialects with
> clearer
> > mandates (2 dialects).  I get it that it's intangible for many of us
> > (myself included, to a degree), which is why this idea is perceived as
> the
> > 'evil splitter' for everyone to unite and rally against.  Maybe I'm
> wrong,
> > and the changes/features that I think are about to make it into PHP
> aren't
> > going to require any sort of split.  If that's the case - it's indeed a
> > horrible idea.  We'd only be able to see that a but further down the
> road.
> > It's definitely too early to spend that level of energy on it at this
> stage
> > - but at the same time, it will definitely make sense to explore it if &
> > when the reality I think we're going to be facing would begin to unfold.
> >
> > I will not be responding to any further emails on this thread;  I'll
> > happily reply to private messages though.
> >
> > Thanks,
> >
> > Zeev
>
> Hello @everyone,
>
> this then also means that PHP will now never be a consistent language
> and short tags will be forever in so we will all be able to support
> Chase's gigantic legacy project forever?
>

Solution would be if we can make this issue that was mentioned:
> - elephpant vs elep++ant
>
> into a similar issue as is now:
> - elephpant vs elephpantwithstricttypes
> (non existent issue - all part of the one PHP itself)
>

Zeev(Or anyone with such energy) can take up the game with same energy
he(Zeev) took the *elep++ant *up and I bet everyone (or the majority) would
really love the newer idea(elephpant vs elephpantwithstricttypes) and
probably take it up as a non issue coz it is all in the same part of the
one PHP itself(which already have its niche and brand).

And, IMHO the strict type or cleaner version of PHP would improve many
sections of the language and even help with future implementations(maybe
sooner we might even implement more evolved and consistent aliases of
current C styled function naming) all of these and more in the same PHP
we've known.

Or perhaps, an idea is to take a break on new implementations and make some
great changes which will pave way for great ideas and innovations.

All of this are good ideas internals@ should be debating, I guess.

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Olumide Samson]

I would say, PHP needs a direction(where're we headed?) than having a split
language.

Seriously, the core team have *tons of kudos* from the outside world(even
outside of PHP) and i think something called for those serious
implementation and i believe everyone(or simply put, the majority) one day
would see the need to make many improvements where necessary.

P++(Or other name it gets) is another project.

On Wed, Aug 14, 2019 at 4:58 PM Chase Peeler  wrote:

> On Wed, Aug 14, 2019 at 11:27 AM Sara Golemon  wrote:
>
> > On Wed, Aug 14, 2019 at 10:14 AM Derick Rethans  wrote:
> >
> > > https://wiki.php.net/rfc/p-plus-plus
> > >
> > > To follow up my no vote; What I'm against is splitting the language on
> > hard boundaries that never disappear, only widen. I'm also a 'No' on
> > Editions, but slightly less of a 'No', and possibly a 'Yes', if those
> > editions are clearly intended to fade over time.
> >
> > -Sara
> >
> I'd vote "No" if I had a vote. I appreciate Zeev proposing the idea. I've
> been as vocal as he has on the short tag issue, and generally fall into the
> "avoid BC unless there are overwhelming positives" camp. Maybe I don't have
> the complete picture since I don't actually do core development, but I have
> been a professional PHP developer for 14 years (Thursday is my 14th
> anniversary) and I've been using it for fun/school work for 20 years. From
> what I've seen, there isn't near as much contention on BC breaks in general
> as a solution like this would require in order to be justified. As someone
> mentioned in another thread, the majority of the features discussed (union
> types, annotations, enums, etc.) don't require BC breaks at all. Among
> things that do require them (both new features and clean up of older
> features), I see that most people, myself included, willing to accept them
> once they have passed.
>
> I definitely think it's possible to more PHP forward with lots of new
> features, and even cleaning up some old and obsolete parts, without moving
> too far in either extreme in terms of BC breaks. I also think that
> internals has done a pretty good job of that up to this point, and have no
> doubt they will continue to do so.
>
> I don't know if it was just a coincidence in timing, but it feels to me
> like this proposal was spurred, at least in part, by the discussions over
> short tags. If so, I definitely think that it is an overreaction. I also
> think the discussions on short tags show why even taking this proposed path
> wouldn't solve anything in the long run. The discussion over short tags
> have got pretty heated at times, but it seems to me that it is mainly
> because both sides are just repeating their talking points without
> discussing or answering the points made by the other side. I think that is
> partly due to the discussion medium, and partly due to the diversity of the
> participants. Without immediate feedback in a manner you expect, it's hard
> to tell if the point you just typed out over 5 paragraphs actually made
> sense to others that will read it. Bottom line, though, is that there will
> be contentious debates about topics no matter what. You might be able to
> avoid the debate on whether or not to require strict typing in P++, but
> you've still got to decide on which types you're going to support. Strict
> typing might never again need to be discussed in legacy PHP, but, there
> will always be discussions about some of the more controversial ways that
> types are juggled.
>
> There might be a time in the future where I do feel like a proposal like
> this is justified or even needed. I just don't feel we are at that point
> right now, nor do I think we are headed towards it.
>
> --
> Chase Peeler
> chasepee...@gmail.com
>

Re: [PHP-DEV] Deprecate PHP's short open tags, again

[Olumide Samson]

On Wed, Aug 14, 2019, 5:23 PM Robert Korulczyk  wrote:

> > While possibly a bit hyperbolic, most of the arguments basically come
> off that way to me as well. I've definitely viewed most of what you've said
> in
> > that manner.
>
> I guess we're in some kind of limbo where half of the people do not
> consider problems which short open tags create as serious, and other half
> does not
> consider BC break implications as serious.
> I already migrated some quite big legacy apps from ` existing tools for this, and I can't even image simpler BC break to deal
> with.


So for me "it will be so hard to upgrade" arguments are also exaggerated,
> and that's why I'm concerned about future BC breaks - if such simple
> change encounters such fierce resistance, then what kind of BC break can
> be accepted?
>
This was exactly my reason for participating in this discussion, if such
simple BC break encounters fierce and lengthy-weighted resistance, I'm not
sure there will ever be a BC break, only additions without a necessary
cleanup.

That's just like, there's a precedent to resist all kinds of BC break
simply because there's no positive impact on the change.

Millions of code can be migrated through many existing libraries in short
time frame to comply with the short tag depreciation.

I think the resistance is actually the reason this discussion(thread) gets
this lengthy.

At the end of all, we either have it or leave it.
Happy coding.

>
> Regards,
> Robert Korulczyk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Deprecate PHP's short open tags, again

[Olumide Samson]

On Wed, Aug 14, 2019, 11:24 AM Peter Kokot  wrote:

> On Wed, 14 Aug 2019, 12:09 Reinis Rozitis,  wrote:
>
> > > It is surprising how thing that is considered by one to be a security
> > risk, is treated
> > > as nothing relevant by others. This dichotomy is quite disturbing - in
> > what case
> > > removing security risk is "no real gain"?
> >
> > It's questionable that a misconfigured environment is a "security" risk
> > caused by language rather than ignorance of the administrator.
> >
> > On that matter you could ask why are all the exec/passthru/proc_open etc
> > functions/features are allowed by default while every other guide on
> > hardening web suggests those to be disabled (added to disable_functions)?
> > I would bet there have been a lot more (actual) security breaches because
> > of unsanitized/unescaped parameters to those.
> >
> > Just to repeat some other people - there are a lot other things to work
> on
> > than this.
> >
> > rr
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
>
> Appologies if these short tags are bumped so many times and cause so much
> issues but we are at the very starting discussions of PHP 8 also. Major
> version, where breaking thing was supposed to be possible. So that is one
> of the reasons why this and similar cleanups are mentioned in the first
> place. With closing the door to even talk and work on cleanups, or being
> ashamed of it, or bully others because they want to have a better structure
> with using PHP 8+, nothing good can come out of it.
>
> >
> >
> >
>
I'm with you on this PHP 8 argument.
I think many of this popular languages that's making my PHP professional
coding look like kids play make sure their major version shake up many old
things, to cleanup old things that's either better not released or would
cause some developers to write environment-tied programs.
Since we don't have any good cause to leave it be, let it go.

Let the user land developers see PHP as a major language they are hoping
for.

Currently, it's easy to learn, use, break or make.
Let them see the intern devs are strict and mature enough to break things
when needed and when possible.

Break it off if it's not useful or would allow the possibility to write
environment tied code(where short tag is not a general idea) and what are
we saying? PHP 8 needs major shake up, let's start it from PHP 7 and let
the world wow at the internals courage, focus and super ability to
implement what's needed. Why wait for a time, when we have little time?
Should we wait for cleanups until PHP 9 or PHP 10?
Im sure javascript would have moved on around that time as the same
language for web, mobile and desktop application, while PHP a major
language still keep in doing its stuff at the server side(and the user land
get booed as boring programmer who would have to learn multiple languages
to get a desktop, mobile and web application designed).

Please,clean up.

>

[PHP-DEV] Re: Deprecate PHP's short open tags, again

[Olumide Samson]

Not sure what the counter argument is really driving at.
So, because some people are using a function or an unworthy directive, then
there can't be a major change in that aspect?
Many languages clean up many unused functions, directives and so more just
to meet some proper standard.
I'm been shamed whenever I read about PHP on blogs comments, e.g people
saying PHP is a trash language, everything goes and proper changes are not
ready until nothing happen.

Not sure where this project is headed, some will want a code to stay
because they want easy version upgrade(must everyone upgrade? ) and those
who want to shake things up won't be allowed to do so.

That's why the internals dev are reducing everyday while other languages
are increasing in dev.
PHP isn't going the right direction, coz there's not even a direction,
everything is based on argument and counterargument.

[PHP-DEV] Re: Deprecate PHP's short open tags, again

[Olumide Samson]

Not sure what the counter argument is really driving at.
So, because some people are using a function or an unworthy directive, then
there can't be a major change in that aspect?
Many languages clean up many unused functions, directives and so more just
to meet some proper standard.
I'm been shamed whenever I read about PHP on blogs comments, e.g people
saying PHP is a trash language, everything goes and proper changes are not
ready until nothing happen.

Not sure where this project is headed, some will want a code to stay
because they want easy version upgrade(must everyone upgrade? ) and those
who want to shake things up won't be allowed to do so.

That's why the internals dev are reducing everyday while other languages
are increasing in dev.
PHP isn't going the right direction, coz there's not even a direction,
everything is based on argument and counterargument.