Note this is just Zend's take on what's important in PHP 7: it's not a complete list. A more comprehensive list: - Dual-mode scalar type hints (weak by default, toggleable to strict via a per-file syntax) ( https://wiki.php.net/rfc/scalar_type_hints_v5 ) - Return type declarations ( https://wiki.php.net/rfc/return_types ) - operator ( https://wiki.php.net/rfc/combined-comparison-operator ) - Null coalesce operator (?…
Things you should know about PHP 7
111–120 of 124 posts
Re: Things you should know about PHP 7
#112Note this is just Zend's take on what's important in PHP 7: it's not a complete list. A more comprehensive list: - Dual-mode scalar type hints (weak by default, toggleable to strict via a per-file syntax) ( https://wiki.php.net/rfc/scalar_type_hints_v5 ) - Return type declarations ( https://wiki.php.net/rfc/return_types ) - operator ( https://wiki.php.net/rfc/combined-comparison-operator ) - Null coalesce operator (?…
...Abstract syntax tree? I didn't know it was implemented without using AST. It surprises me, as I've been always told that ASTs are necessary to implement a compiler. Maybe there seem to be some alternatives?
This is not meant to be an endorsement of this method, but PHP Like a lot of extant PHP, there's no real reason it was done this way: it's just the method Rasmus et al happened to program the original engine, and it's grown organically since then. With the AST, phpng, and the uniform variable syntax, I'd argue PHP7's main feature is finally getting around to correcting the sins of the past.
Re: Things you should know about PHP 7
#113Earlier quoted context omitted.
I just checked out and seems like pypy has made some good progress database driver wise! So I went ahead and installed pypy 2.5.1 to compare the json performance. It got better but ujson is just crazy fast. CPython (w/ ujson) is 70% faster to loads and 50% faster to dumps a sample json from my project (50~156kb json). I expect msgpack to be the same. Unfortunately seems like Pypy still doesn't pay off in this app, bu…
ujson breaks the spec btw ;-) We tried doing the same thing but cffi callbacks are slow. We should maybe revisit that (and make callbacks faster, we did get better on that)
Re: Things you should know about PHP 7
#114Earlier quoted context omitted.
Lol, I'm in the middle of doing this - moving from shared hosting to a DO droplet. It is painful. Setting up the server isn't so bad but email is a nightmare. Unfortunately the large email providers are moving to block a lot of smaller servers it seems which might make it harder in the future at present using an SPF seems to get mails through. DO of course have a Wordpress appliance which makes it pretty easy to set…
I've been having all my clients sign up for a Mandrill account for sending email since it's so unbelievably cheap (usually free) and it completely fixes the email problem.
>"You represent and warrant that you either own or have permission to use all of the material in your Emails." //
Fair use isn't permission, nor ownership, it is statutory right of use though.
They bring in Spamhaus' definition of spam too, which on first reading appears to be self-contradictory - requiring each message sent to be explicitly requested. Taken by the letter this would mean I couldn't, for example, send out a message to a group of customers with whom I had a standing relationship to let them know of a change to terms & conditions, for example, without explicit consent. That means anticipating every email. Catchall phrases like "agree to receive all email" wouldn't work as the customer "has not verifiably granted deliberate, explicit, and still-revocable permission for it to be sent".
Indeed "still-revocable" permission means that as soon as a mass email is sent it becomes spam regardless, it's no longer revocable. There are other problems too - verifiable opt in means an alternate system needs to be used for the verification emails.
In turn that means that any email I send to multiple recipients puts me in breech of Mandrill's T&Cs.
Mandrill have a circular reference from the Terms "You retain ownership of the materials you upload to the Service. We may use or disclose your materials only as we describe in these Terms and our Privacy Policy." and in the Privacy Policy:
>"Information You Provide to Us: When you register to use the Services, communicate with our customer service team, send us an email, or post on our blog, you’re giving us information that we collect. That information may include your IP address, name, physical address, email address, phone number, credit card information, and other details like gender, occupation, and other demographic information. By giving us this information, you consent to your information being collected, used, disclosed, and stored by us, only as described in our Terms of Use and Privacy Policy."
In short the policies allow them to harvest data from emails sent with the service and to use it as they wish. They go as far as to intimate that because they do use the message data internally that the service is not for personal email. There's also a clause Terms 5.f that allows doxing and combining the info with your account data.
The "protections" for selling of your info with the business don't work as there are standard "we can alter this agreement unilaterally" conditions.
tl;dr law - it's complicated. This service is absolutely not for "personal" emails however.
Re: Things you should know about PHP 7
#115Earlier quoted context omitted.
I've been having all my clients sign up for a Mandrill account for sending email since it's so unbelievably cheap (usually free) and it completely fixes the email problem.
Ah, free for up to 12k emails, or something close - looking at this now. Thanks for the tip. One thing I have noticed is their terms preclude the sending of material under Fair Use terms of copyright law ... but I'm assuming that is a mistake. >"You represent and warrant that you either own or have permission to use all of the material in your Emails." // Fair use isn't permission, nor ownership, it is statutory righ…
Re: Things you should know about PHP 7
#116Earlier quoted context omitted.
Ah, free for up to 12k emails, or something close - looking at this now. Thanks for the tip. One thing I have noticed is their terms preclude the sending of material under Fair Use terms of copyright law ... but I'm assuming that is a mistake. >"You represent and warrant that you either own or have permission to use all of the material in your Emails." // Fair use isn't permission, nor ownership, it is statutory righ…
Yes, definitely not for personal emails. But for everything else (password resets, confirm your account, etc) it's pretty great.
Sensitive emails contravene the T&C; I think those examples would be included in that definition.
Re: Things you should know about PHP 7
#117Earlier quoted context omitted.
...Abstract syntax tree? I didn't know it was implemented without using AST. It surprises me, as I've been always told that ASTs are necessary to implement a compiler. Maybe there seem to be some alternatives?
> Maybe there seem to be some alternatives? This is not meant to be an endorsement of this method, but PHP Like a lot of extant PHP, there's no real reason it was done this way: it's just the method Rasmus et al happened to program the original engine, and it's grown organically since then. With the AST, phpng, and the uniform variable syntax, I'd argue PHP7's main feature is finally getting around to correcting the…
A lot? Please stop spreading wrong info. In the words of an internal developer,
> It does fix a few minor points with regard to variables vs. expressions, but those aren't particularly important.
>"So, really, the whole thing has no direct effect on userland devs. It's an internal rewrite."
https://www.reddit.com/r/PHP/comments/2cc9xp/rfc_abstract_sy...
Re: Things you should know about PHP 7
#118Earlier quoted context omitted.
Email Zend.
I looked around and couldn't find an appropriate e-mail address anywhere. If you have one, feel free to let them know.
Re: Things you should know about PHP 7
#119Seeing this: > function add( ... ): float {} I think a much better choice would have been: > float function add( ... ) {} Or just: > float add( ... ) {} Since that's how it's done in other languages and people would feel at home with it.
Which if you read it out, it sounds entirely natural "This is a function called foo, which takes some params, and returns a float". Most of the other variants don't read as naturally.
> Since that's how it's done in other languages and people would feel at home with it.
PHP doesn't need to copy the mistakes of other languages. It's got plenty of its own mistakes.