Re: [PHP-DEV] Defining the PHP Group
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] Re: [RFC] DOM Living Standard API
On Mon, Sep 16, 2019 at 10:01 AM Peter Bowyer wrote: > Hi Benjamin, > > I like the proposal. > > On Mon, 16 Sep 2019 at 01:40, Benjamin Eberlei > wrote: > >> I am asking about feedback especially on the section "Implementation >> Details", that explains some key differences to "PHPify" the DOM Living >> Standard API to PHP and ext/dom. Do you have any comments about the >> reasonability of the choices? >> > > I don't have feedback, other than to ask what choices other languages have > made when bringing in the DOM Living Standard API? > good question! the only other non javascript languages that have ext/dom equivalents (i found) are java and python and both haven't changed their APIs to the new living standard yet. > > >> Also the section on "Not adopting Nodes for now" is new and I need some >> feedback on this issue: To keep the proposal slim with respect to changing >> existing behavior, the improved behavior of the DOM Living Standard over >> Level 1-2 tof automatically adopting nodes instead of throwing a WRONG >> DOCUMENT DOMexception is not considered for now. Do you think this is a >> reasonable approach to go forward with? >> > > If I understand correctly, the issue is the behaviour of a method has > changed significantly. > No, actually it behaves mostly the same. It only added a new use case that previously lead to an exception, when you appendChild a node from a different document. Since this is not really a line of code that happens dynamically, this code will not be in the wild, instead you will find the workaround $element->appendChild($element->ownerDocument->importNode($otherNode)); which will not be affected by the new behvavior at all. > > If not implemented in PHP 8, where BC breaks are expected, when would be a > better time? > This is no BC break in my opinion. Changing an exception that essentially says "don't do this, you connected the wrong things" into the behavior that people would expect anyways is not a BC break in my opinion and therefore could be done at any time. > > Would deviating and implementing the new behaviour with a different method > name e.g. appendAndAdoptChild(); or guarded by a version flag (so users > choose whether they want the 'Living' behaviour or the 'Level 2' behaviour > in this method) be options? > > Peter >
Re: [PHP-DEV] Defining the PHP Group
Thank you Zeev, I would say it's something to start a more productive discussion. Maybe not everybody would agree from the start with what you mentioned but after resonable talks, it would get to some common conclusions. If I were to summarize, there needs to be defined the voting process for: 1. RFCs for new features or changes with no or very small BC breaks. 2. RFCs for new features and changes with small BC breaks and/or breaks that can be fixed with ease. 3. RFCs for new features and changes with medium BC breaks and/or breaks that can be fixed with some effort. 4. RFCs for how voting process takes place including structural or governance change. For now, possibly the 1. and 2. voting can stay at 2/3. Voting for 3. can be moved to 4/5 or higher. Voting for 4. can be moved to 6/7 or higher or can be splitted if different acceptance would be required after discussion. That's closer to consensus. One other thing to define would be who is the PHP group and who are the voting members. This can be something based on code activity in the last 4, 5 years or someting similar, top 30/40 persons by number of commits/lines changed/something measurable. As Rasmus put it, "The people writing the code get to call the shots, for better or worse." And to have relevant people for voting, they can vote somehow on another 15/20 persons from relevant companies/frameworks. Now it would be great if someone would take the time to draft a proposal of defining what's not defined, of course with more relevant options and numbers as I don't think I have proper expertise here. And of course including all the other details about how a RFC should look like for each type. Let's try as much as possible to be constructive as otherwise everybody has something to lose. Thank you, Alex On Tue, Sep 17, 2019 at 6:42 PM Zeev Suraski wrote: > On Tue, Sep 17, 2019 at 3:32 PM Larry Garfield > wrote: > > > Simple question for those that keep arguing that the RFC process is only > > applicable to a certain subset of issues: > > > > OK, so what's the alternative? > > > > If we wanted to make a structural or governance change to PHP, what is > the > > process? > > If we really did feel there was a reason to make a fundamental change to > > the language (whatever that means), what is the process? > > If we wanted to change the RFC process, what is the process? > > If we don't have those, and want to set them up, what is the process for > > defining the process? > > > For the first and last one (which are kind of the same) - the answer is > simply the (informal) process we had before the RFC process was enacted. > That effectively meant consensus based decision making. > Since we have a lot more people today, we can and probably should reuse the > voting mechanism, and a pass would have to look along the lines of this: > > https://web.archive.org/web/20120527111218/https://wiki.php.net/rfc/voting/vote > > or > https://wiki.php.net/rfc/abolish-short-votes > > If you look at all the 'Process and Policy' RFCs we've voted on, other than > a couple that are miscategorized technical RFCs - they virtually all > cleared a 15 to 1 bar, most of them well above that. When changing the > rules - or extending the scope of the RFC process to handle things it never > has before, this is what it takes. We haven't implemented any rules that > bind everyone without that level of widespread agreement to this date. > > Consensus based decisions would work for the 3rd one as well and would > probably be the simplest to enforce. It may be that for RFCs that place > new limits on it (like the recent Abolish votes) a 2/3 bar would suffice - > although I think it's healthy for everyone that the ratio that was reached > was more along the lines of 20 to 1 than 2 to 1, in terms of everyone > accepting the validity of the policy change (including the fingerful who > voted against). But since determining whether a policy RFC falls in that > category or not can in itself be challenging, having a single, clear high > bar for introducing both changes to the Voting RFC, as well new policy > rules, would probably be the simplest and probably healthiest outcome. > > Regarding the 2nd (fundamental / high impact changes) - the solution here > too would be consensus based decision making. That's the bar we cleared in > previous major changes - the deprecation of register_globals, magic_quotes > and safe_mode. Now, I think Nikita does have a point that defining what > constitutes a 'high impact' break vs. one that isn't very easy - especially > in a formal manner. So it may make sense to have a single bar for all > compatibility breaking changes, instead of a separate one for high impact > ones and low impact ones. The solution might be to simply gauge the level > of caring through the number of voters who took the time to vote. For > instance, a change proposal that garnered 10 votes, 7 to 3, is probably not > a high-impact one and it may be reasonable to accept it
Re: [PHP-DEV] Evolving PHP
On Tue, 17 Sep 2019, 09:43 Christian Schneider, wrote: > Just because there are now policy and process RFCs does not mean we could > take a step back and limit RFCs again. > I don't recall seeing anybody suggesting we can't do this. However the established process to limit RFCs would be to propose a new RFC that defines what future RFCs can be used for. I'd also expect that RFC to include a proposal on how future "policy and process" changes would be handled once RFCs had been limited. >
Re: [PHP-DEV] Defining the PHP Group
I agree with pretty much everything Zeev has said. I've added a few additional thoughts On Tue, Sep 17, 2019 at 11:42 AM Zeev Suraski wrote: > On Tue, Sep 17, 2019 at 3:32 PM Larry Garfield > wrote: > > > Simple question for those that keep arguing that the RFC process is only > > applicable to a certain subset of issues: > > > > OK, so what's the alternative? > > > > If we wanted to make a structural or governance change to PHP, what is > the > > process? > > If we really did feel there was a reason to make a fundamental change to > > the language (whatever that means), what is the process? > > If we wanted to change the RFC process, what is the process? > > If we don't have those, and want to set them up, what is the process for > > defining the process? > > > For the first and last one (which are kind of the same) - the answer is > simply the (informal) process we had before the RFC process was enacted. > That effectively meant consensus based decision making. > Since we have a lot more people today, we can and probably should reuse the > voting mechanism, and a pass would have to look along the lines of this: > > https://web.archive.org/web/20120527111218/https://wiki.php.net/rfc/voting/vote > > or > https://wiki.php.net/rfc/abolish-short-votes > > If you look at all the 'Process and Policy' RFCs we've voted on, other than > a couple that are miscategorized technical RFCs - they virtually all > cleared a 15 to 1 bar, most of them well above that. When changing the > rules - or extending the scope of the RFC process to handle things it never > has before, this is what it takes. We haven't implemented any rules that > bind everyone without that level of widespread agreement to this date. > > Consensus based decisions would work for the 3rd one as well and would > probably be the simplest to enforce. It may be that for RFCs that place > new limits on it (like the recent Abolish votes) a 2/3 bar would suffice - > although I think it's healthy for everyone that the ratio that was reached > was more along the lines of 20 to 1 than 2 to 1, in terms of everyone > accepting the validity of the policy change (including the fingerful who > voted against). But since determining whether a policy RFC falls in that > category or not can in itself be challenging, having a single, clear high > bar for introducing both changes to the Voting RFC, as well new policy > rules, would probably be the simplest and probably healthiest outcome. > > Regarding the 2nd (fundamental / high impact changes) - the solution here > too would be consensus based decision making. That's the bar we cleared in > previous major changes - the deprecation of register_globals, magic_quotes > and safe_mode. Now, I think Nikita does have a point that defining what > constitutes a 'high impact' break vs. one that isn't very easy - especially > in a formal manner. So it may make sense to have a single bar for all > compatibility breaking changes, instead of a separate one for high impact > ones and low impact ones. The solution might be to simply gauge the level > of caring through the number of voters who took the time to vote. For > instance, a change proposal that garnered 10 votes, 7 to 3, is probably not > a high-impact one and it may be reasonable to accept it even if it only > cleared a 2 to 1 ratio. A change proposal that garners 50 votes and is 35 > in favor and 15 against (exactly the same ratio, but with a lot more > voters) - is most probably a high impact one, and should clear a much > higher consensus-level bar. In the meantime, formality aside, it's easy > enough to 'know it when you see it'. I don't think anybody contends that > changing our undefined variable behavior or deprecating short tags are > high-impact breaks - in terms of the lines of code in the combined > universal PHP code base that would have to be changed as a result. > > I think everything needs to be properly defined before a vote starts. So, I don't think you can base the level of consensus required on how many people vote. I also think that high impact changes (if not all BC breaking changes) should require a certain minimum number of votes as well (a quorum, so to speak). > Other than the higher bar - I think such proposals should be required (or > at the very least encouraged) to do a better impact analysis regardless. > They should be tested on a set of apps (one that will attempt to represent > the PHP codebase at large, not just the cutting-edge framework > development), and the results should be available as a part of the RFC. > Even if we can't formally compute from that data whether it constitutes > high-impact or not, having that data as a part of the RFC will likely help > voters determine their opinion on it - first at the level of whether they > care or not, and secondly - whether they're in favor or not. This will, in > turn, effect voter turnout - and help determine whether this is indeed a > major change or not. > > I think this wo
Re: [PHP-DEV] Defining the PHP Group
On Tue, Sep 17, 2019 at 3:32 PM Larry Garfield wrote: > Simple question for those that keep arguing that the RFC process is only > applicable to a certain subset of issues: > > OK, so what's the alternative? > > If we wanted to make a structural or governance change to PHP, what is the > process? > If we really did feel there was a reason to make a fundamental change to > the language (whatever that means), what is the process? > If we wanted to change the RFC process, what is the process? > If we don't have those, and want to set them up, what is the process for > defining the process? For the first and last one (which are kind of the same) - the answer is simply the (informal) process we had before the RFC process was enacted. That effectively meant consensus based decision making. Since we have a lot more people today, we can and probably should reuse the voting mechanism, and a pass would have to look along the lines of this: https://web.archive.org/web/20120527111218/https://wiki.php.net/rfc/voting/vote or https://wiki.php.net/rfc/abolish-short-votes If you look at all the 'Process and Policy' RFCs we've voted on, other than a couple that are miscategorized technical RFCs - they virtually all cleared a 15 to 1 bar, most of them well above that. When changing the rules - or extending the scope of the RFC process to handle things it never has before, this is what it takes. We haven't implemented any rules that bind everyone without that level of widespread agreement to this date. Consensus based decisions would work for the 3rd one as well and would probably be the simplest to enforce. It may be that for RFCs that place new limits on it (like the recent Abolish votes) a 2/3 bar would suffice - although I think it's healthy for everyone that the ratio that was reached was more along the lines of 20 to 1 than 2 to 1, in terms of everyone accepting the validity of the policy change (including the fingerful who voted against). But since determining whether a policy RFC falls in that category or not can in itself be challenging, having a single, clear high bar for introducing both changes to the Voting RFC, as well new policy rules, would probably be the simplest and probably healthiest outcome. Regarding the 2nd (fundamental / high impact changes) - the solution here too would be consensus based decision making. That's the bar we cleared in previous major changes - the deprecation of register_globals, magic_quotes and safe_mode. Now, I think Nikita does have a point that defining what constitutes a 'high impact' break vs. one that isn't very easy - especially in a formal manner. So it may make sense to have a single bar for all compatibility breaking changes, instead of a separate one for high impact ones and low impact ones. The solution might be to simply gauge the level of caring through the number of voters who took the time to vote. For instance, a change proposal that garnered 10 votes, 7 to 3, is probably not a high-impact one and it may be reasonable to accept it even if it only cleared a 2 to 1 ratio. A change proposal that garners 50 votes and is 35 in favor and 15 against (exactly the same ratio, but with a lot more voters) - is most probably a high impact one, and should clear a much higher consensus-level bar. In the meantime, formality aside, it's easy enough to 'know it when you see it'. I don't think anybody contends that changing our undefined variable behavior or deprecating short tags are high-impact breaks - in terms of the lines of code in the combined universal PHP code base that would have to be changed as a result. Other than the higher bar - I think such proposals should be required (or at the very least encouraged) to do a better impact analysis regardless. They should be tested on a set of apps (one that will attempt to represent the PHP codebase at large, not just the cutting-edge framework development), and the results should be available as a part of the RFC. Even if we can't formally compute from that data whether it constitutes high-impact or not, having that data as a part of the RFC will likely help voters determine their opinion on it - first at the level of whether they care or not, and secondly - whether they're in favor or not. This will, in turn, effect voter turnout - and help determine whether this is indeed a major change or not. In addition, I don't think we should be grouping any deprecations together into a single vote - unless that's absolutely required from a technical standpoint (i.e. doing one without the other would lead to an inconsistency). With the recent engine errors reclassification RFC, initially - the deprecation of default values for uninitialized variables wasn't even viewed as a very big deal and was grouped with the rest. It's true that this quickly became apparent and Nikita separated it after a couple of days - but I think that should be a requirement, and not up to the RFC author. I also agree with Christian - the fac
[PHP-DEV] State of mhash?
Hi, I just noticed that the hash extension has a default-disabled --with-mhash option, that enables a couple of additional mhash_* functions. From what I was able to gather, mhash was an old extension that was superseded by hash, and hash provides a compatibility layer for mhash. Should these functions be deprecated? Should this compatibility layer be kept indefinitely? Regards, Nikita
Re: [PHP-DEV] Features related to Object Initializers
On Mon, Sep 16, 2019, at 7:10 PM, Mike Schinkel wrote:
> > On Sep 16, 2019, at 6:20 PM, Larry Garfield wrote:
> >
> > I think everyone's in agreement about:
> >
> > 1) Making objects easier to work with.
> > 2) Devs should use objects more.
>
> I am glad we are reaching some common ground. :-)
>
> > (Side note: I have an article submitted to php[architect] entitled "Never*
> > use arrays" that goes into this topic in much more detail. I am 100% on
> > board with getting developers using objects more and arrays less.)
>
> Yes, I saw the article on your blog that you linked. Very nice. :-)
I have a presentation on the subject that I keep submitting to conferences.
I'm waiting for one to pick it up. :-)
> > However, why do we want devs to use objects more? If we just want the
> > arrow-like syntax, then this works today:
> >
> > $val = (object)[
> > 'foo' => 'bar',
> > 'baz' => 5,
> > ];
> >
> > And now developers are using an anonymous "object". However, that offers
> > basically no meaningful improvement except funnier passing semantics.
> > ...
>
> > 2) They're more self-documenting and statically analyzable (by your IDE or
> > any other tool)... but that's true only if you have an explicitly defined
> > class!
> > ...
> > So for me, the entire "easier to use anonymous one-off classes" argument
> > falls apart, because there's no material benefit there other than saying
> > "but now it's using objects". For that, as noted, we already have an ample
> > syntax that accomplishes just as much.
>
>
> I can envision several benefits you do not mention, maybe because
> you've forgotten them, were not aware of them, or they did not occur to
> you?
>
> In descending order of significance:
>
> 1. IDEs could validate local uses for stdClasses — Given the following
> syntax, PhpStorm could and likely would implement an inspection that
> displayed a warning on the line with $val->bazoom because everything it
> needs to validate is there. And I see no reason other IDEs could not
> do the same:
>
> $val = stdClass{
> foo => 'bar',
> baz => 5,
> };
> echo $val->bazoom;
Can they? In the super-narrow case of the object being defined in the same
scope as it's used, potentially. But once I pass it elsewhere, the static
analyzer will have a really hard time figuring out what it's supposed to be.
Example:
$val = stdClass{
foo => 'bar',
baz => 5,
};
echo $val->bazoom; // IDE can tell this is wrong.
function thingie(object $params) {
echo $object->bazoom;
}
thingie($val); // we know this will break, but the IDE can't really tell
thingie(stdClass{bazoom: 5}); // This won't break.
Granted, I have not written a static analyzer myself so it's possible I'm
speaking out of my butt here, but I don't see how an analyzer could reasonably
tell if the echo statement in the function was correct or not because it has no
local information on which to base that decision absent a defined class or
interface.
> 2. Empowering beginners — If you are a beginner, or a work-to-live[1]
> programmer then I think there is a good chance you will find the syntax
> (object)[..] foreign and confusing. I think they would find the
> following syntax easier to tackle and thus more likely to use,
> especially if they came from Javascript (note I omitted stdClass in
> hopes we could land on using such syntax for stdClass or anonymous
> classes):
>
> $val = {
> foo => 'bar',
> baz => 5,
> };
>
> By empowering beginners they would be more likely to objects they can
> later refactor instead of arrays (see #5 below.)
To clarify: I virtually never use (object)[] syntax myself. I think it's been
a decade or more since I did so. I would not endorse such a thing. My point
is that what's being proposed here, in relation to anon classes, has no
meaningful benefit over that.
> 3. Simplifying refactoring — It will be easier to refactor an object
> initializer for stdClass to a declared class than to refactor from the
> hybrid array/object syntax.
Citation needed? And why not just define your data types in the first place?
> 4. Simplified syntax — I tend to make a lot more typos when
> initializing array keys in PHP than I do when initializing objects in
> GoLang (the proposed PHP syntax is very similar to the equivalent in
> Go.) Maybe I am unique in that, but I doubt it.
You're definitely not unique because I do that too, and it's one of the
examples I call out in presentations on why defined classes are superior to
arrays.
I'd noticed the Go inspiration as well. I think it works well in Go, but less
so in PHP. Also bear in mind that in Go, you're instantiating an explicitly
defined structure; even if you're defining that structure inline at
instantiation, you're first defining the structure types. (And the syntax for
doing so inline is really funky.) So that's no help at all for the anon class
case.
> I also find array keys with quotes harder to
Re: [PHP-DEV] Defining the PHP Group
On Mon, Sep 16, 2019, at 6:56 PM, Stanislav Malyshev wrote: > Hi! > > > For there to be a veto, of the kind that anyone can actually use, it must > > be established somewhere. > > And that's what I am concerned about. Once we start assuming the RFC > process is not for solving technical questions for everything, we get > into this kind of rule lawyering and nitpicking into the texts which > never were intended to be able to serve as something that can work while > being base for rule-lawyering and nitpicking. It's not a constitution > (not that lawyers don't find all kinds of things all the time there that > were never written there either) and the fact that voting RFC or > whatever document is on wiki now does or does not have certain words in > there does not have any sacred meaning, because it wasn't even meant for > that. These are utilitarian documents which were written for specific > purposes, and should be understood within that context. And if they do > not match what we want to do now, they can and should be changed. > > -- > Stas Malyshev > smalys...@gmail.com Simple question for those that keep arguing that the RFC process is only applicable to a certain subset of issues: OK, so what's the alternative? If we wanted to make a structural or governance change to PHP, what is the process? If we really did feel there was a reason to make a fundamental change to the language (whatever that means), what is the process? If we wanted to change the RFC process, what is the process? If we don't have those, and want to set them up, what is the process for defining the process? --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Object Initializer
чт, 12 сент. 2019 г. в 16:00, Michał Brzuchalski < michal.brzuchal...@gmail.com>: > 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 > Thank you Michał for the RFC, I've have been keeping up with the thread and at this point, I do somewhat agree with people that maybe the RFC should go into V2 version development. It really seems like the scope of the RFC is just too small for the feature and it might be a good idea to expand it a bit. Also, I have this question - is there any performance to be gained here? Cause right now object hydration is an issue and is somewhat slow. Can it be optimised? Also, usually I don't really want properties to be public (aka writeable), so that means `private/protected` and I need to use the methods to set the properties or reflection. I might have missed or don't remember it, but I don't think I saw a discussion about that use-case. Value object, DTO's - all have a big use case for it. -- Arvīds Godjuks +371 26 851 664 arvids.godj...@gmail.com Skype: psihius Telegram: @psihius https://t.me/psihius
Re: [PHP-DEV] Features related to Object Initializers
On Tue, 17 Sep 2019 at 00:21, Larry Garfield wrote:
> [..]
> I think everyone's in agreement about:
>
> 1) Making objects easier to work with.
> 2) Devs should use objects more.
>
> (Side note: I have an article submitted to php[architect] entitled "Never*
> use arrays" that goes into this topic in much more detail. I am 100% on
> board with getting developers using objects more and arrays less.)
>
> However, why do we want devs to use objects more? If we just want the
> arrow-like syntax, then this works today:
>
> $val = (object)[
> 'foo' => 'bar',
> 'baz' => 5,
> ];
>
> And now developers are using an anonymous "object". However, that offers
> basically no meaningful improvement except funnier passing semantics.
I would argue they can even be inferior to arrays.
Arrays have a big advantage over anonymous object, or even over any
mutable object:
They can be passed "by value", which protects them against pollution /
poisoning.
Objects are always passed as an instance pointer (I am not going to
say by reference here), which means they can always be modified in the
called function, unless they have been actively cloned beforehand.
Even classes that are designed to be immutable can still be poisoned
by setting anonymous properties.
Perhaps a future RFC could suggest a syntax to prevent that from happening :)
There are some other advantages of arrays, but they depend a lot on
the use case:
- Array syntax is more smooth for some use cases.
- Arrays can be counted, and compared vs the empty array.
- A type hint "array" excludes anything else. A type hint "\stdClass"
still allows any subclass of \stdClass, which could have its own
methods.
Otherwise, I agree: Objects with defined classes have many advantages
vs arrays or anonymous objects.
Depends on the use case of course. Arrays are still good for mapping
arbitrary keys to arbitrary values.
-- Andreas
>
> As I see it, the advantages of using objects over arrays are two fold:
>
> 1) The PHP engine is able to make dramatic optimizations when working with
> *defined* classes with *defined* properties. I think (although have not
> verified) that anonymous classes get the same benefit but iff their
> properties are explicitly defined like any other class.
>
> 2) They're more self-documenting and statically analyzable (by your IDE or
> any other tool)... but that's true only if you have an explicitly defined
> class!
>
> So I see really no advantage whatsoever in replacing this:
>
> function doSomething(int $a, array $options = []) { ... }
>
> with this:
>
> function doSomething(int $a, object $options = {}) { ... }
>
> It's only an advantage if I do this:
>
> function doSomething(int $a, SomethingOptions $options = null) { ... }
>
> Doing that has many advantages, I think we all agree. But going halfway
> doesn't give us any benefits other than swapping [' '] for ->.
>
> What we want to do is make it easier to create $options inline in a
> self-documenting way. I'm all for that. But that first requires the
> developer still define SomethingOptions somewhere.
>
> So for me, the entire "easier to use anonymous one-off classes" argument
> falls apart, because there's no material benefit there other than saying "but
> now it's using objects". For that, as noted, we already have an ample syntax
> that accomplishes just as much.
>
> So rather than making it easier for people to make "anonymous structs that
> use object syntax", we should be making it easier for people to define
> for-realsies named classes and using them, because *that* is where the
> benefit comes from.
>
> And for that part of the problem (making named struct-like classes easier to
> work with), as noted in the other thread I find the named
> parameters/auto-promotion combination to solve the problem just as well, and
> then some.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [i...@ch2o.info] Re: [PHP-DEV] PHP's declining(?) popularity
Hi, One of the IT futur, is Container (docker like and kubernetes like) and Single Page Application... On the other language the tendancy is to simplify the start time and single start of the application (only one process start the application runc) and simplify configuration; and simplify logging (all on the stdout/err of the container) to work better in this type of infrastructure. On java side for exemple the tendency is bootstraping the servelet engine (of tomcat or jetty) in standalone process... no complex configuration... With PHP you must use apache+mod_php, or nginx + php-fpm in the same container they are very comlex to configure (you must configure php, apache/nginx, some time +htaccess)... to package... The ideal way is to embed the http server in php to be abel to start directly the php from php cli (php -S localhost:8000) ... The actual http server implementation are minimal... and not very performante (lake of event/thread/process manager, and lake of http2 support)... Swoole is perfect exemple of this tendency... but need some addition to permit standard php application like wordpress to work directly on the type of packaging And also abscence of concurrency (coroutine or thread, native simple multi process pool like process manager in swoole) are a real obstacle to the progression of php... Swoole add this with the event model (not real threading, user mode thread)... but real thread while be a must... Unit project from nginx are good exemple of that and good exemple of these tendency... Mathieu Daniel Martín Spiridione , 16/09/2019 20:56: The lack of concurrent PHP features in 2019 is, in my opinion, sufficient reason not to use it for CLI projects. Some companies do not welcome installing extensions like Swoole, the language should have native concurrent features. Daniel El dom., 15 sept. 2019 a las 0:33, Mike Schinkel () escribió: > > 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 :-? > > 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. > > From the list it seems Python stands out as having the most growth as a > percentage. > > Googling for "why has python become so popular" I get these articles. > > I have copied their top level points but also included the text for the > one point they all seem to have in common, that Python is simple, easy to > use and easy to learn for new users (emphasis mine in all cases): > > > https://medium.com/@trungluongquang/why-python-is-popular-despite-being-super-slow-83a8320412a9 > > < > https://medium.com/@trungluongquang/why-python-is-popular-despite-being-super-slow-83a8320412a9 > > > > 1. End-users just don’t care (about slower performance) > 2. More Productive > "First and foremost reason why Python is much popular because it is highly > productive as compared to other programming languages like C++ and Java. It > is much more concise and expressive language and requires less time, > effort, and lines of code to perform the same operations. The Python > features like one-liners and dynamic type system allow developers to write > very fewer lines of code for tasks that require more lines of code in other > languages. This makes Python very easy-to-learn programming language even > for beginners and newbies. For instance, Python programs are slower than > Java, but they also take very less time to develop, as Python codes are 3 > to 5 times shorter than Java codes. Python is also very famous for its > simple programming syntax, code readability and English-like commands that > make coding in Python lot easier and efficient." > 3. Execution Speed does not matter as much as Business Speed > > > > https://www.kdnuggets.com/2017/07/6-reasons-python-suddenly-super-popular.html > > < > https://www.kdnuggets.com/2017/07/6-reasons-python-suddenly-super-popular.html > > > > 1. Python Has a Healthy, Active and Supportive Community > 2. Python Has Some Great Corporate Sponsors > 3. Python Has Big Data > 4. Python Has Amazing Libraries > 5. Python Is Reliable and Efficient > 6. Python Is Accessible > "For newcomers and beginners, Python is incredibly easy to learn and use. > In fact, it’s one of the most accessible programming languages available. > Part of the reason is the simplified syntax with an emphasis on natural > language. But it’s also because you can write Python code and execute it > much faster." > > > https://www.techrepublic.com/article/why-python-is-so-popular-with-developers-3-reasons-the-language-has-exploded/ > > < > https://www.techrepublic.com/article/why-python-is-so-popular-with-developers-3-reasons-the-language-has-explo
Re: [PHP-DEV] Features related to Object Initializers
On Tue, 17 Sep 2019 at 01:10, Mike Schinkel wrote: > But as I said before, naming is hard — except for abstract examples where > you can just name it "Something" :-) — and developers often don't know what > object schema they will need until they have written much of the code. So > the ability to have a syntax that supports stepwise refinement rather than > starting with one and having to switch to the other makes a lot more sense > to me. > > Allowing developers to start with doSomething(int $a, object $options = > null) and then later refine the code to doSomething(int $a, > SomethingOptions $options = null) creates less discontinuity for development > There is a tip that I picked up somewhere that if you're struggling to name something (e.g. a function or a class), it may be because you've defined its responsibilities poorly, and it needs splitting or merging. I, too, work with a legacy codebase that makes heavy use of $params arrays, and I frequently see things like `$params = array_merge($product, $customer); $params['sendEmails'] = true;` and then a bunch of functions whose docblocks say basically "@param array $params No idea what's in this, we just pass it on somewhere else". There is no better name for the $params array because it has no particular responsibility, it's just a bag of data. So I'm unconvinced by the anonymous class -> named class refactoring path (and even more so with some of your further proposals like populating named parameters from an object), because I don't actually want to end up with a SomethingOptions object with 50 unrelated properties. What I want to end up with is a function signature like doSomething(Product $product, Customer $customer, bool $sendEmails). The step in between might look like doSomething(Product $product, array $params) or even doSomething(array $product, array $customer, bool $sendEmails) rather than doSomething(object $params). > rather than giving them only one option for anonymous class initializer, e.g. the array initializer syntax? I'm not a fan of (object)$array, or of stdClass in general, but I think the solution to that is to expand the existing "new class" syntax with a way to capture lexical variables. I understand the desire to make a new syntax that does as much as possible, but I think we have a few different combinations to achieve that: - object initializers & simple anonymous class initializers look the same; named parameters may or may not look similar; complex anonymous classes have to use a different syntax - object initializers are just constructors with named parameters; anonymous class definitions don't look similar, but support both simple and complex cases in one syntax Either way, the whole set of features isn't going to be implemented in one go, so we don't need to work out all the details, just a direction of travel. Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] Evolving PHP
Am 16.09.2019 um 21:32 schrieb Nikita Popov : > Thanks for chiming in Rasmus. A few brief thoughts on recent discussions: > > * The RFC process encompasses language changes (breaking or non-breaking), > as well as policy and process decisions. We have a very wide selection of > precedent cases that affirm this. It feels to me that it gradually changed into that. And while the initial RFCs seemed innocuous policy and process decisions they are now used as a precedent. Should the first non-technical RFCs have been examined more closely due to this? Maybe. But just because it wasn't done doesn't mean the situation cannot be reassessed again. Just because there are now policy and process RFCs does not mean we could take a step back and limit RFCs again. Just to be clear: I'm not demanding anything, I'm just wary of the "that's just the way it is, look at previous examples" argument. > * The "undefined variables" vote that sparked the current controversy > currently sits at 29 in favor of exception and 20 against. That's > significantly below the acceptance threshold for RFCs. Things are working > as they should: The question has been discussed, put up to vote, and the > vote has decided against this course of action (as of this writing, though > I expect this to be representative of the final result.) I agree but disagree at the same time: First of all the discussion was unpleasant which I don't see as "working as it should". And while I do think the discussion about undefined variables did clear some things up I also think it distracted from other points in the RFC. I personally chose my battle to focus on undefined variables because it was the biggest pain point. But there are lots of other conversions to Exceptions which were left in the main bulk of things even though they have similarities with undefined variables. A foreach over null might indicate a problem but it is well defined and might occur in correctly working code. Yes, a warning might be appropriate but stopping execution is a different beast again. > * As a personal failure, I should have made the voting option for "undef > vars throw exception" be "undef vars throw warning in PHP 8 and exception > in PHP 9", which would have provided for a long-term migration timeline for > affected code. I apologize for pushing an unnecessarily aggressive option > here. Maybe it was quite the opposite: It forced the discussion to happen now. And while it was unpleasant I'm worried that otherwise it would have legitimised making undefined variables an Exception because "we already promoted it to a warning so we all agree that it is bad" which would be wrong. Sure, maybe by the time PHP 9 comes around people agree that an Exception is the right thing to do. But using warnings as a door-opener for exceptions is something to be considered very carefully. - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
