i dunno, i found that kind of special functions which are actually language constructs like list(), isset(), etc always ugly. Ok, some more syntax sugar to let these things not look like normal functions is of course an improvement, but i wish they would do some more radical changes to the language. Why not add multiple return values like in golang to achieve that syntax? Isn't exactly that list() should emulate in some way? Than deprecate that list() crap and throw it away in 7.2. But instead they will keep that list "function" forever along that new bracket syntax because they are afraid some code from the 90s would break. On the other hand they don't stop adding minor complete irrelevant changes that break existing code from yesterday.
Off topic, but curious - Is there any discussion on whether there will be a support for a good concurrent programming in PHP in the future? (e.g. channels in Go & Elixir) - of course, you might say "you're using the wrong tool.."
If I were you I'd explore a language that goes beyond those low level concurrency constructs because they can be extremely tricky to get right. Clojure and Elixir would be my top choices and the final choice depends on the kind of system you're trying to build.
... Note the syntax isn’t the usual double pipe ||
operator that we associate with or, rather a single pipe | character ...
... PHP 7.1 introduces visibility modifiers to constants ...
... With PHP 7.1 it is now possible to specify that a function has a void return type, i.e. it performs an action but does not return anything ...
... Example four contains numeric values, so everything else is stripped out, and the sum of those are used to calculate the total of 10. But it would still be nice to see a warning, as this may not be intended behaviour ...
Good to see PHP continues to introduce new inconsistencies while striving to break existing code by fixing old ones. Best of both worlds!
edit: OK this was uncharitable and technically some of them are not inconsistencies, just things I thought were weird. I know PHP is widely used and considered useful and will stay with us forever. But I found those snippets interesting.
I wonder why PHP includes more and more type checks and visibility features, when all those checks are performed at runtime. What good does it do when your code suddenly throws a fatal error at runtime because you did not respect the type specification. I mean, I get that type checks are useful for IDEs, but enforcing these rules at runtime using fatal errors just does not make any sense to me.
If they're not enforced at runtime, then they're unsound if you have typed code calling untyped code. And as the maker of the sibling comment notes, runtime type checks still catch errors earlier than no type checks.
Moreover, having these declarations actually be part of the language, even if the interpreter itself cannot enforce them ahead-of-time, means tooling can be built around it, and we can use them for optimisations in the VM (which PHP 7.1 does: we elide type checks on certain arithmetic operations for operands of known types).
If you want to ensure type safety before the program actually runs, you can of course let your IDE or static analyser check that for you.
> If they're not enforced at runtime, then they're unsound if you have typed code calling untyped code.
I think types specifications in interpreted (not compiled) languages should be only hints (for IDEs, code analyzers and JIT compilation etc.). This type checking for every method probably also adds some overhead does it not?
Yes, it adds overhead. But it means the type declaration can actually be relied upon: the code inside the function always gets the type it wants, the optimiser can elide type checks safely, and humans and computers reading the code don't have to worry about the type declaration being a lie.
Unenforced type hints don't give these guarantees. They have no requirement to be accurate because the runtime won't enforce them, so they're essentially documentation, not code. They can't be safely relied upon by the optimiser because they're unenforced. The code inside the function body can break at runtime if given the wrong type, so if having a specific type is particularly important, you have to add manual type checks or coercions yourself.
But these checks could also be performed by a code analyzer/compiler, removing this burden from the runtime. (Performing the checks at runtime, means the code is only checked when it is executed, which could be at any random time.)
Ahead-of-time type checking can only really work if the entire program has type declarations everywhere, and if you know what constitutes the entire program. This isn't the case for the vast majority of existing PHP code. Furthermore, PHP's dynamic features mean that there are cases where ahead-of-time checks will always be impossible. So you have to have at least some runtime checks, at the boundaries between typed and untyped code.
Furthermore, doing ahead-of-time checking would require infrastructure we don't currently have for providing information to the PHP interpreter about whether or not PHP files have passed type checks. But again, most code is not fully typed, and so this doesn't provide all that many guarantees to the interpreter.
I've seen quite a few JavaScript bugs and potential bugs exposed after adding incomplete type annotations in TypeScript, so I really don't think it's all or nothing, at least not as a general rule. I've been away from PHP too long to speculate how much it would help here.
If you're using type signatures, the alternative is probably going to be that your program crashes at a later time. "Foo is not a Bar" is a better error message than "$foo->xyz() isn't a function", and this happens much closer to the point where you've messed up.
I disagree. I think that this type of "late type binding" is actually an advantage of dynamically typed languages. That way it does not matter if you pass a map/array/dictionary or an instance of a class as long as the properties are the same.
PHPDoc is supported by most IDE's. Using this you can specify parameter types without using the actual type system.
Visibility and typing features are good. Visibility helps to design and write better code. The typing features are also welcomed in my view. I would rather a request completely fails because a variable is the wrong type rather than PHP's type coercion leading to an unexpected result with no errors or warnings.
That said, I use PHP for my day job. I see no reason to start new projects in it. I never use it in my side projects. Introduction of the single pipe operator to represent OR instead of a double pipe operator is baffling in my opinion.
7.1 does more work to improve consistency and error handling which is definitely welcomed. The problem is there is much legacy crap in PHP. It only exists for web applications and there are a growing number of languages which do this better.
>I wonder why PHP includes more and more type checks and visibility features
Because they are easy to implement (function type hints, typed properties) and the php community have a collective, insatiable, perpetual hardon for features that are supposed to enhance correctness..
So the core devs are eager to propose these kinds of features. And the community is eager to accepts them without much thought..
To see how child like this mentality towards these type of features, see this comment, where a Php expert makes a big deal regarding when a user omitted mentioning the type of a value....
> What good does it do when your code suddenly throws a fatal error at runtime because you did not respect the type specification.
The good it does is it stops your application from possibly continuing on with buggy code.
This is especially important in something like billing code. Imagine if your code was expecting an integer (bill amount) but got a string instead that via the types system evaluated to 0 or 1 instead of the real integer... In that case you might charge customers less or more than you should have and its a big deal trying to get all that fixed.
Better to just throw an error which you can see in an exception handling system like Sentry and take care of the problem.
This hot take is both pretty uncharitable and largely incorrect.
... "catch (FooException | BarException" is new syntax that would be a include-time fatal in existing code
... "public const FOO" is new syntax that would be a include-time fatal in existing code; public is the default modifier in the language when no visibility modifier is present, so existing code functions exactly the same as before
... ": void" return type only conflicts with existing code if a class is named Void, which becomes an error for the file declaring the class ... this is vanishingly unlikely [0] and an easy grep to fix; if you're looking at some code "$var = i_return_void();", the annotation is a clear sign that the "$var =" part is obviously confused.
... " 5 + 'a string' " is nonsense code which codebases that care about warnings currently want to be aware of.
I don't like PHP either, but that doesn't mean kneejerk reactions are excusable, and at the least on the first point you are wrong. Using | instead of || is not an inconsistency, but actually quite consistent.
|| is a short-cutting or comparison operator which returns the first true thing it encounters.
| is a bitwise or combinator, which takes two sets of flags, and combines them into one set of flags that has all flags activated which were also active in the input sets.
Semantically, | is absolutely the correct choice here.
A better question would be why there's a $2 there, though i hope that's just a typo and means $e.
Commas would require changing the syntax and implementation of catch. This way exception names just become first class subjects that can be combined with an overloaded operator.
Commas are used in PHP as a sequence of things, not multiple options. This single-pipe notation is already established as the further-up comments states.
Choosing a pipe because it's easier for an obscure language feature, is not least astonishment. Commas are used for lists. The pipe is a bad choice among a nice feature.
The reason I added this was because most developers are used to using a double pipe when writing code that has 'or' conditions.
I understand the use of pipes for bitwise, but in this case if you read the code in the example, we're basically saying "if the exception is of type A or of type B", personally I'd be inclined to use || if I didn't already know the syntax.
Wow. OK, I am a big user of the ternary operator, but I hadn't come across omission of the middle part until now. To be honest, it's not the most accessible syntax (especially if you're coming from another language), but at least I have the option now - thanks!
edit: Just to clarify for anyone else unfamiliar with it:
I know all too well, and you'd never catch me running that on any of my own systems. With a large enough install base, it's not uncommon to have a decent number of people on those older versions though.
It can, though it doesn't have to, at all. PHP still has a very low entry barrier compared to Java. You can opt in to all of the syntactic sugar, or none at all, which is the way it should be.
I'm more excited by some features not detailed in the article.
Return type declarations, which were introduced in PHP 7.0, are being enhanced somewhat.
First, it's now possible to declare nullable return types (previously all return types did not permit null):
public function getFoo(): ?int;
(You can also use ? on parameter and property types.)
Second, we now have a void return type for functions where there is no useful return value:
public function handle(): void;
(Disclaimer: I wrote the void return type RFC and implementation, so I'm biased here.)
We're also getting type declarations for class properties:
class Person
{
public string $name;
public int $age;
public bool $isEmployee;
}
There's a few other things as well. The list() syntax (destructuring assignment) has been shortened to [] and now lets you specify keys (disclaimer: I was involved in both of these). Also, trying to add non-numeric strings together with + now produces a warning (disclaimer: also me).
It's pretty amusing to read some of the PHP RFCs and see the verbal gymnastics taken to avoid saying "look, we're just taking this directly from Hack" :)
There's certainly a lot of stuff inspired by Hack. If Hack did something well, sometimes PHP copies it. The syntax of all PHP 7's new type stuff is very close to Hack's.
Though the details may differ significantly. Hack and PHP's type systems are only superficially the same (AOT rather than runtime validation, disabling or ignoring type checks versus using "weak" type checks, type inference vs. no type inference, etc.), for example.
Some of this could also be attributed to the fact that Hack also borrowed heavily. While I'm sure a lot of it came from playing with Hack and saying "wow, this should be how PHP7 does things," it might also be recognition from use in other languages (Java specifically).
What's wrong with that? Hack was based on PHP, no? It's like CoffeeScript and JavaScript - lots of the incredibly useful features in CoffeeScript found their way into ES6.
Self-documenting code. I'm already using return types wherever I can, and it's nice to keep things consistent.
Also, it helps prevent the abuse of interfaces. I can say "this method does not return values" and enforce it. That can be useful on a big project, with junior devs.
I was talking more about the inconsistency between return type void when it returns null. I'm asking whether this behavior has changed and functions without a return will now return void or ???. It's a pretty big inconsistency IMHO.
It's a good point, and one which I personally hadn't thought about. The RFC specifically mentions it, so it's obviously a concern:
> Choosing one over the other suggests intent. If you specify a value, it suggests the value is significant. In a void function, the return value is insignificant: it's always the same and has no actual usefulness.
https://wiki.php.net/rfc/void_return_type#why_isn_t_return_n...
I guess this 'pragmatism over consistency' fits in with the general ethos of PHP. I guess it's why so many people hate it, but I can't imagine a situation in which this will actually cause a problem.
This is completely incorrect. Java's null value is only valid as a value of an object type (e.g, Object x = null), and void functions don't return an object.
Functions with a `: void` return type will still give you a NULL if you use them in an expression. I didn't want to break the property of existing PHP functions that they can always be used as expressions. I reasoned that your IDE or whatever can always warn you if you mistakenly try to use the result of such a function.
PHP's built-in functions documented as "void" also return NULL, so I suppose there's an argument from consistency.
The point I was trying to make is that PHP does not have -- nor should it have, I think -- a concept of void. Functions without a return statement already return null. "return;" is already equivalent to "return null;" as well, as you pointed out. It would be more consistent to type-hint return null instead of introducing a new return type (void) into the language. I know PHPDoc already uses "@return void", and I have never liked it for the same reason. It is not a concept used anywhere else in PHP, AFAIK.
I'll be honest that I was firmly in the /r/lolphp camp for years, but PHP7 shows real promise. There's a real AST parser and the core team seems to be doing a lot to shore up the language.
I still think adding a string to a number should error instead of giving a warning, but one thing at a time. PHP7 and the future roadmap makes it look like PHP is on a path to not turning into Perl.
What do you think of the Perl 6 approach of providing both DWIM (weaker) and DWIS (stronger) typing?
* Numeric and string operators are kept distinct. For example `+` means numeric addition, never concatenation or some other string operation. To compare two strings, use `eq`, to compare two numbers use `==`. Etc. This sets things up nicely for supporting both DWIM and DWIS typing.
* DWIM typing: If you write something like `a + b`, you always get numeric addition. If need be the compiler tries to coerce `a` and `b` to numbers. `"12"` or `" 12" will both successfully coerce to 12. `"123foo"` and `"bar456"` will fail to coerce. If the coercion fails the program crashes at run-time.
* DWIS typing: To tighten type checking, add a type constraint. For example, `my Numeric (\a, \b) = ...` ensures that `a` and `b` only ever contain a numeric value.
From a grammar perspective, it seems odd to declare property types as prefixes instead of matching the return type syntax. Were suffixed types considered?
class Person
{
public $name : string;
public $age : int;
public $isEmployee : bool;
}
Reminds me of what Rob Pike once said, "[Java, JavaScript (ECMAScript), Typescript, C#, C++, Hack (PHP), and more] are converging into a single huge language".
It makes me really envious of those who went deep down the Lisp path and haven't had to look back. They don't have to spend time keeping up with the latest developments instead of pursuing some other goal, they have it all already.
PHP should actually renamed to Javascript, but there is already that weird Lisp like scripting language claiming that name. If u ask me, there is somethin wrong in our matrix...
I don't know PHP 7 yet, but I'd say there's plenty to learn just in PHP 5 if you haven't kept up since PHP 4. Perhaps a piecewise approach would be best, starting with the 'proper' C++/Java-esque version of OOP that I'd say is the biggest feature of PHP 5...
It is a stupid, stupid piece of crap. It is very hard, even for people with more than 10 years of experience, to know all the potential gotchas that are hidden deep inside this death trap of a language [1]
You will be surprised how casual the actual core development of the language is. Tiny behaviours are added, modified and removed with little or no thought and with as little justification as "This doesn't make sense to me" or without any sort of notice at all [3]..
[2] Here is how Php 7 tries to "improve" security of a function...
And the community. Is there a more shittier community than that of this language? It is dominated by people with drama loving, infantile minds.
Keep as far as possible from this language, if you have to work with it, wear on a mental condom before you start and never involve in any kind of Php discussions.
PHP is a widely-used mature tool for website development. It can be used in good or bad ways by good or bad people. Nothing more, nothing less. No need for the fanatical absolutism.
PHP community is huge and you are generalizing things from your limited experience.
The language is not perfect (is any?) but it works and delivers business value.
If it's not your cup of tee, that is fine, but I don't see you promoting better solutions, just bashing on PHP. Some people think that that is cool, well, it's not.
Bashing Php should be encouraged just like bashing any other bad practice..
For example. Take the case of MySQL injection. People does not hand wave SQL injection vulnerabilities by saying. "Na, It haven't happened to me ever, even after 10 years of making websites using mysql". Just like that.
A: That isn't what you said. You said: "Take the case of MySQL injection."
Second, bringing up MySQL when talking about SQL injection is rather odd, and I don't see any reason you added that except that you don't realize MySQL is irrelevant.
> to derail arguments against the language?
Your "arguments" were very poor. There was no need to detail them.
"Yeah, well, you know, that's just, like, your opinion, man."
Seriously though, it's just a tool. Sometimes it's the right tool. I come from working with other dynamic languages to using (modern) PHP daily in my current job and it's fine. Absolutely fine to work with. Does it have gotchas? Sure, just as much as any other language.
I don't see something like this happening this in any main stream language.
That example illustrates one thing very clearly. How you believe you KNOW the language, and how it pulls the rug from under your feet in the most unexpected way.
You can wait for it to happen to you. Or you can learn from the experience of others.
There's always some "here be dragons" area/library in any language. I've had it with Ruby, JavaScript, Clojure, Scheme and PHP.
It's really easy to pick on PHP's array methods. Sure there are problems there. What that means though is that when I'm using them I refer to the documentation frequently. I do this anyway, with any language.
The language never made or broke any promises to you, except where the specification is incorrect. Create a ticket when you find it. Notice how in the example you linked that the documentation is explicit about that caveat.
Programming languages are just tools. They are not your girlfriend. They are not your religion. There is no one tool to rule all tools and you're not entering into some major commitment in life to use them.
You haven't convinced anyone for either your eloquence or your argumentative skills.
All your comments in this post, furthermore, suggest a teenager or close. Not to be ageist, but "stupid piece of crap", "shittier community", "drama loving, infantile minds" show neither deep thinking on the subject nor much maturity.
even when the language shows its true color in front of their very own eyes, people continue to be in denial. (See arguments of /u/betterphpguy).
I don't bother to polish my arguments regarding this, because I know how futile it really is. A programmer who "likes" or Php cannot be convinced otherwise by arguments. If he/she is lucky, their own experience with the language and outside of it, will take them to that realisation.
I do this only for the benefit of any newcomer who might come across these thread, and might think that Php is on par with the other languages.
Part of growing up is not caring for BS like this, because you can find this, and even worse caveats in any popular language (and worse stuff in non populars).
You will also realize that such caveats never prevented people from creating billion dollar companies with PHP (or C++, or JS, etc), and perfectly workable code, powering 40% of the internet.
I know you're trying to be clever, but seriously, please stop. He is a KNOWN plagiarist. All of his articles are copy-pasted from elsewhere (even if he does sometimes credit others in his posts).
He has even stolen content from other Laravel books and published it as his own book.
I don't get why they do it. Leave the fact that is unthetical, it's just annoying for users who can't read the whole post and at the same time very unproductive from a SEO perspective
I was wondering if that site was some sort of aggregator and amazed that it would carry over the code examples so well from the actual article. This explains so much.
I'm saying this in the nicest possible way: I hate PHP and hope the project dies tomorrow.
And it's funny because I use it at my job everyday. I suppose that's why I've grown to loath it that much.
I should say that it is great for some things and it is very easy to stage and cheap to maintain, but it is a language from the previous century that has massively failed to adapt to current programmatic trends and patterns.
And I shouldn't even start on its API, which to this day seems like the equivalent of a two year old child's drawing.
Laravel and Eloquent made things a bit better, but still... Man, this language is a hot mess.
Supporting http/2 SERVER_PUSH seems cool at first glance, but doesn't it significantly increase the attack service for RCE vulnerabilities, being that it accepts arbitrary content from remote servers and passes it into a callback function?
It looks like PHP implemented SERVER_PUSH [0] via libcurl [1], openly described as a "work in progress."
I'm sure all the code is "well written", both in PHP and libcurl, but I can't shake the feeling that we'll see at least one significant vulnerability as a result of this new feature. The two github issues on the feature, one referencing a segfault caused by a double-free [2], and one caused by server-specific protocol issues [3], do not help to assuage my worry.
Deprecating mcrypt this way is clearly a mistake regardless of how ineffective it is as an extension or how unmaintained it is. Almost every framework I've seen makes use of it. In almost 9 years, it was not communicated to the community at all that this was based on unmaintained, buggy code, and now they just want to yank it in a minor upgrade? WTF? At the very least, there should be collaboration with people who maintain frameworks that use mcrypt as pretty much every major framework (ZF, Symfony, Laravel, etc.) does. This should be done in a major version upgrade like the one that just happened.
The release process specifically allows an extension to be deprecated and then punted to PECL.
As for frameworks, I and others have already been going around (for years before the mcrypt deprecation came up) switching things to use OpenSSL (and, for that matter, authenticated encryption) instead of mcrypt.
136 comments
[ 3.2 ms ] story [ 233 ms ] threadEDIT "pthreads v3 is restricted to operating in CLI only" - from the project page.
1: http://amphp.org/
2: https://github.com/async-interop
... PHP 7.1 introduces visibility modifiers to constants ...
... With PHP 7.1 it is now possible to specify that a function has a void return type, i.e. it performs an action but does not return anything ...
... Example four contains numeric values, so everything else is stripped out, and the sum of those are used to calculate the total of 10. But it would still be nice to see a warning, as this may not be intended behaviour ...
Good to see PHP continues to introduce new inconsistencies while striving to break existing code by fixing old ones. Best of both worlds!
edit: OK this was uncharitable and technically some of them are not inconsistencies, just things I thought were weird. I know PHP is widely used and considered useful and will stay with us forever. But I found those snippets interesting.
Moreover, having these declarations actually be part of the language, even if the interpreter itself cannot enforce them ahead-of-time, means tooling can be built around it, and we can use them for optimisations in the VM (which PHP 7.1 does: we elide type checks on certain arithmetic operations for operands of known types).
If you want to ensure type safety before the program actually runs, you can of course let your IDE or static analyser check that for you.
I think types specifications in interpreted (not compiled) languages should be only hints (for IDEs, code analyzers and JIT compilation etc.). This type checking for every method probably also adds some overhead does it not?
EDIT: correction
Unenforced type hints don't give these guarantees. They have no requirement to be accurate because the runtime won't enforce them, so they're essentially documentation, not code. They can't be safely relied upon by the optimiser because they're unenforced. The code inside the function body can break at runtime if given the wrong type, so if having a specific type is particularly important, you have to add manual type checks or coercions yourself.
Furthermore, doing ahead-of-time checking would require infrastructure we don't currently have for providing information to the PHP interpreter about whether or not PHP files have passed type checks. But again, most code is not fully typed, and so this doesn't provide all that many guarantees to the interpreter.
Having methods that just have the right names is a pretty weak assurance, isn't it?
Visibility and typing features are good. Visibility helps to design and write better code. The typing features are also welcomed in my view. I would rather a request completely fails because a variable is the wrong type rather than PHP's type coercion leading to an unexpected result with no errors or warnings.
That said, I use PHP for my day job. I see no reason to start new projects in it. I never use it in my side projects. Introduction of the single pipe operator to represent OR instead of a double pipe operator is baffling in my opinion.
7.1 does more work to improve consistency and error handling which is definitely welcomed. The problem is there is much legacy crap in PHP. It only exists for web applications and there are a growing number of languages which do this better.
I kind of understand it since it's not a traditional OR operation and intends to keep and associate the matching values, but maybe something like
catch (Exception $e in (Exceptions...))
would make it clearer. Either way, it's so close to feeling like an OR operation that I feel like it will be a lot of debugging when you forget this.
Because they are easy to implement (function type hints, typed properties) and the php community have a collective, insatiable, perpetual hardon for features that are supposed to enhance correctness..
So the core devs are eager to propose these kinds of features. And the community is eager to accepts them without much thought..
To see how child like this mentality towards these type of features, see this comment, where a Php expert makes a big deal regarding when a user omitted mentioning the type of a value....
https://www.reddit.com/r/PHP/comments/4k2htl/ive_just_given_...
The good it does is it stops your application from possibly continuing on with buggy code.
This is especially important in something like billing code. Imagine if your code was expecting an integer (bill amount) but got a string instead that via the types system evaluated to 0 or 1 instead of the real integer... In that case you might charge customers less or more than you should have and its a big deal trying to get all that fixed.
Better to just throw an error which you can see in an exception handling system like Sentry and take care of the problem.
... "catch (FooException | BarException" is new syntax that would be a include-time fatal in existing code
... "public const FOO" is new syntax that would be a include-time fatal in existing code; public is the default modifier in the language when no visibility modifier is present, so existing code functions exactly the same as before
... ": void" return type only conflicts with existing code if a class is named Void, which becomes an error for the file declaring the class ... this is vanishingly unlikely [0] and an easy grep to fix; if you're looking at some code "$var = i_return_void();", the annotation is a clear sign that the "$var =" part is obviously confused.
... " 5 + 'a string' " is nonsense code which codebases that care about warnings currently want to be aware of.
[0] even the few hits for https://github.com/search?utf8=%E2%9C%93&q=%22class+Void+%22... are mostly false positives.
|| is a short-cutting or comparison operator which returns the first true thing it encounters.
| is a bitwise or combinator, which takes two sets of flags, and combines them into one set of flags that has all flags activated which were also active in the input sets.
Semantically, | is absolutely the correct choice here.
A better question would be why there's a $2 there, though i hope that's just a typo and means $e.
Choosing a pipe because it's easier for an obscure language feature, is not least astonishment. Commas are used for lists. The pipe is a bad choice among a nice feature.
I understand the use of pipes for bitwise, but in this case if you read the code in the example, we're basically saying "if the exception is of type A or of type B", personally I'd be inclined to use || if I didn't already know the syntax.
I wish. The fact that it actually doesn't is one of the things that really bugs me about PHP:
The above example will output:edit: Just to clarify for anyone else unfamiliar with it:
Return type declarations, which were introduced in PHP 7.0, are being enhanced somewhat.
First, it's now possible to declare nullable return types (previously all return types did not permit null):
(You can also use ? on parameter and property types.)Second, we now have a void return type for functions where there is no useful return value:
(Disclaimer: I wrote the void return type RFC and implementation, so I'm biased here.)We're also getting type declarations for class properties:
There's a few other things as well. The list() syntax (destructuring assignment) has been shortened to [] and now lets you specify keys (disclaimer: I was involved in both of these). Also, trying to add non-numeric strings together with + now produces a warning (disclaimer: also me).Though the details may differ significantly. Hack and PHP's type systems are only superficially the same (AOT rather than runtime validation, disabling or ignoring type checks versus using "weak" type checks, type inference vs. no type inference, etc.), for example.
In a less facetious spirit, it's interesting to see languages converge a lot. Darwinian gene dynamics.
Also, it helps prevent the abuse of interfaces. I can say "this method does not return values" and enforce it. That can be useful on a big project, with junior devs.
> Choosing one over the other suggests intent. If you specify a value, it suggests the value is significant. In a void function, the return value is insignificant: it's always the same and has no actual usefulness. https://wiki.php.net/rfc/void_return_type#why_isn_t_return_n...
I guess this 'pragmatism over consistency' fits in with the general ethos of PHP. I guess it's why so many people hate it, but I can't imagine a situation in which this will actually cause a problem.
PHP's built-in functions documented as "void" also return NULL, so I suppose there's an argument from consistency.
There's a lot of code that uses "return;" to mean "return null;" and honestly I don't see it as a big problem.
https://github.com/facebook/hhvm/blob/HHVM-3.13/hphp/hack/te...
... has an obvious code smell detectable statically:
https://github.com/facebook/hhvm/blob/HHVM-3.13/hphp/hack/te...
I'll take this opportunity to say thank you, for this, and all the other hard work you put into PHP internals.
Thank you for getting these added to the language, I think it's a fantastic improvement.
Maybe you can answer this for me.
Will this work:
i.e. set $c and $d to 1 and 2, then return the array and store in $f.Plus:
is 3;I still think adding a string to a number should error instead of giving a warning, but one thing at a time. PHP7 and the future roadmap makes it look like PHP is on a path to not turning into Perl.
* Numeric and string operators are kept distinct. For example `+` means numeric addition, never concatenation or some other string operation. To compare two strings, use `eq`, to compare two numbers use `==`. Etc. This sets things up nicely for supporting both DWIM and DWIS typing.
* DWIM typing: If you write something like `a + b`, you always get numeric addition. If need be the compiler tries to coerce `a` and `b` to numbers. `"12"` or `" 12" will both successfully coerce to 12. `"123foo"` and `"bar456"` will fail to coerce. If the coercion fails the program crashes at run-time.
* DWIS typing: To tighten type checking, add a type constraint. For example, `my Numeric (\a, \b) = ...` ensures that `a` and `b` only ever contain a numeric value.
Hack doesn't do this either.
I do think the idea came up.
> Support class constant visibility
Reminds me of what Rob Pike once said, "[Java, JavaScript (ECMAScript), Typescript, C#, C++, Hack (PHP), and more] are converging into a single huge language".
Bob says "I wish PHP had this thing from Java" and Alice says "I wish Java had this thing from PHP". I don't think it's necessarily a bad thing.
Also, https://wiki.php.net/rfc/libsodium
https://bugs.php.net/bug.php?id=72188
Is there any good introduction for people how "know" PHP4 and want to get started with PHP7, using best practises?
It is a stupid, stupid piece of crap. It is very hard, even for people with more than 10 years of experience, to know all the potential gotchas that are hidden deep inside this death trap of a language [1]
You will be surprised how casual the actual core development of the language is. Tiny behaviours are added, modified and removed with little or no thought and with as little justification as "This doesn't make sense to me" or without any sort of notice at all [3]..
[2] Here is how Php 7 tries to "improve" security of a function...
And the community. Is there a more shittier community than that of this language? It is dominated by people with drama loving, infantile minds.
Keep as far as possible from this language, if you have to work with it, wear on a mental condom before you start and never involve in any kind of Php discussions.
[1] https://www.reddit.com/r/PHP/comments/41bm7j/new_rfc_allow_s...
[2] https://www.reddit.com/r/PHP/comments/3j88v4/something_about...
[3] http://stackoverflow.com/questions/14703363/why-is-the-stand...
The language is not perfect (is any?) but it works and delivers business value.
If it's not your cup of tee, that is fine, but I don't see you promoting better solutions, just bashing on PHP. Some people think that that is cool, well, it's not.
For example. Take the case of MySQL injection. People does not hand wave SQL injection vulnerabilities by saying. "Na, It haven't happened to me ever, even after 10 years of making websites using mysql". Just like that.
Use of PHP IS a bad practice today.
Get a few more years of experience then come back.
What? Where did I say so?
I said "people does not hand wave SQL injection vulnerabilities by saying they haven't encountered it in their 10 years of experience with MySQL".
That does not mean all sql injection vulnerabilities are limited to MySQL!
Is this one of those of tactics that are frequently employed by php apologists to derail arguments against the language?
Second, bringing up MySQL when talking about SQL injection is rather odd, and I don't see any reason you added that except that you don't realize MySQL is irrelevant.
> to derail arguments against the language?
Your "arguments" were very poor. There was no need to detail them.
Seriously though, it's just a tool. Sometimes it's the right tool. I come from working with other dynamic languages to using (modern) PHP daily in my current job and it's fine. Absolutely fine to work with. Does it have gotchas? Sure, just as much as any other language.
Did you see the thread I just linked?
https://www.reddit.com/r/PHP/comments/41bm7j/new_rfc_allow_s...
I don't see something like this happening this in any main stream language.
That example illustrates one thing very clearly. How you believe you KNOW the language, and how it pulls the rug from under your feet in the most unexpected way.
You can wait for it to happen to you. Or you can learn from the experience of others.
Your pick.
It's really easy to pick on PHP's array methods. Sure there are problems there. What that means though is that when I'm using them I refer to the documentation frequently. I do this anyway, with any language.
The language never made or broke any promises to you, except where the specification is incorrect. Create a ticket when you find it. Notice how in the example you linked that the documentation is explicit about that caveat.
Programming languages are just tools. They are not your girlfriend. They are not your religion. There is no one tool to rule all tools and you're not entering into some major commitment in life to use them.
You haven't convinced anyone for either your eloquence or your argumentative skills.
All your comments in this post, furthermore, suggest a teenager or close. Not to be ageist, but "stupid piece of crap", "shittier community", "drama loving, infantile minds" show neither deep thinking on the subject nor much maturity.
Even in this thread,
https://www.reddit.com/r/PHP/comments/41bm7j/new_rfc_allow_s...
even when the language shows its true color in front of their very own eyes, people continue to be in denial. (See arguments of /u/betterphpguy).
I don't bother to polish my arguments regarding this, because I know how futile it really is. A programmer who "likes" or Php cannot be convinced otherwise by arguments. If he/she is lucky, their own experience with the language and outside of it, will take them to that realisation.
I do this only for the benefit of any newcomer who might come across these thread, and might think that Php is on par with the other languages.
You will also realize that such caveats never prevented people from creating billion dollar companies with PHP (or C++, or JS, etc), and perfectly workable code, powering 40% of the internet.
The rest are child games.
"Learning Laravel" is a known plagiarist, who has a habit of ripping off content from other Laravel sites.
The "ads by carbon" certainly don't cast this particular website in a good light, either.
Facebook and other sites make it clear that what you're looking at is a summary meant to lead you to another site - they don't disguise it as content.
Don't ignore all the things.
He has even stolen content from other Laravel books and published it as his own book.
EDIT: Dang to the rescue.
It looks like PHP implemented SERVER_PUSH [0] via libcurl [1], openly described as a "work in progress."
I'm sure all the code is "well written", both in PHP and libcurl, but I can't shake the feeling that we'll see at least one significant vulnerability as a result of this new feature. The two github issues on the feature, one referencing a segfault caused by a double-free [2], and one caused by server-specific protocol issues [3], do not help to assuage my worry.
[0] https://wiki.php.net/rfc/curl_http2_push
[1] https://daniel.haxx.se/blog/2015/06/03/server-push-to-curl/
[2] https://github.com/curl/curl/issues/529
[3] https://github.com/curl/curl/issues/530
As for frameworks, I and others have already been going around (for years before the mcrypt deprecation came up) switching things to use OpenSSL (and, for that matter, authenticated encryption) instead of mcrypt.
https://paragonie.com/blog/2015/05/if-you-re-typing-word-mcr...
To date: ZF, CodeIgniter, Symfony, Laravel, and CakePHP all support OpenSSL instead of Mcrypt, as do many, many more.
You get E_DEPRECATED in 7.1 then in 7.2 you can still
...if you really have a need to support abandonware.