News Feed
Sections




News Archive
feed this:

Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Anthony Ferrara:
Scalar Types and PHP
February 12, 2015 @ 11:25:47

Anthony Ferrara has tossed his own hat into the ring around the debate that's been going about the RFC for scalar type hints in PHP. In his post he agrees with (most of) the suggestions made in the proposal around strict, weak and the "compromise" of mixed typing.

There's currently a proposal that's under vote to add Pascal Martin's excellent post about it. What I want to talk about is more of an opinion. Why I believe this is the correct approach to the problem.

He starts off talking about the "all strict" angle that some suggested as the proper approach then moves into the "weak argument" explaining the difference between the two. He shares a bit of history around the problems detecting subtle bugs caused by typing issues and how it is definitely a problem that needs solving. Finally, he talks about the mixed-typing compromise and provides some code samples showing a common bug that can happen with weak typing.

0 comments voice your opinion now!
scalar type hint rfc opinion example weak compromise mixedtype

Link: http://blog.ircmaxell.com/2015/02/scalar-types-and-php.html

Pascal Martin:
In favor of RFC "Scalar Type Hints"
February 09, 2015 @ 09:40:18

Pascal Martin has a new post today sharing some of his thoughts around one of the currently proposed PHP RFCs for < href="http://blog.pascal-martin.fr/post/in-favor-of-rfc-scalar-type-hints.html">scalar type hinting. PHP has had type hints for custom objects and some things like arrays but this proposal would add in additional ones for things like "string", "int" and "float".

The Scalar Type Hints RFC for PHP 7 has first been initialized in December 2014. It went on with version 0.2 at the middle of January 2015, after changing several major ideas, and is now in version 0.3, integrating return types, as RFC Return Type Declarations has been accepted a few days ago. [...] I've been following this RFC (and the previous ones) with some interest, and, as I've taken some time to play with it a bit last week, building PHP from the sources of the corresponding Git branch, I'll try summarizing here why I think it is interesting. Please note this is my personal opinion.

He starts with a look at what the proposal entails around these new scalar type hints and why he thinks they're a good idea. He looks at some of the things that PHP's current weak typing allows and how it has made the language very flexible as a result. He also shows how the proposal suggests the use of the "declare" function to define a strict typing constant to essentially turn on the checking only where needed. He provides a few code snippet example including object/method handling, setting a custom error handler and which of the calls work in which typing method. He finishes the post looking at the "per-file" idea of enabling the strict typing checks and some of his confusion around the point. He also talks about return types, the directives that are proposed to enable the feature and the current status of the RFC.

0 comments voice your opinion now!
scalar type hint rfc summary proposal php7 opinion overview

Link: http://blog.pascal-martin.fr/post/in-favor-of-rfc-scalar-type-hints.html

Stanislav Malyshev:
Objects as keys
December 15, 2014 @ 09:18:50

In his latest post Stanislav Malyshev looks at a RFC he's proposed to allow array keys to be objects including some of his thoughts behind the proposal and how he sees it being helpful to the language.

I'm going to put to vote soon another of my RFCs, namely one about "objects as keys". So, I want to outline the case for it here and address some criticisms and questions raised while discussing it.

He starts off by answering the "why" question, mentioning specially the introduction of things like GMP numbers and how, despite them seeming to work like numbers, other things can be done with them. He talks about how you'd use this functionality "the right way" and how that'd relate back to value objects. He answers a few other questions about the proposal including why it's better than just using __toString or spl_object_hash instead. He spends the rest of the post looking at some of the implementation problems, disadvantages and some of the possible names (function names) for the handling.

0 comments voice your opinion now!
object array key rfc proposal gmp number

Link: http://php100.wordpress.com/2014/12/14/objects-as-keys/

Pascal Martin:
October 2014 on internals@php
December 01, 2014 @ 11:03:32

Pascal Martin has posted his latest summary of the discussions happening on the php.internals mailing list for the month of October 2014.

809 messages have been exchanged in October 2014 on PHP's internals@ mailing-list - a bit more than in September. [...] First of all, PHP 5.6 has entered its normal cycle of releases, with a first maintenance version at the beginning of the month.

He includes a graph of the (monthly) number of emails over the last year and how October fits in. Topics mentioned include:

If you'd like to follow along with the discussions or are interested in getting an "inside look" at what's going on with the language, you can use either the web-based reader or subscribe to the mailing list.

0 comments voice your opinion now!
phpinternals mailinglist summary oct2014 rfc discussion

Link: http://blog.pascal-martin.fr/post/php-mailing-list-internals-october-2014-en

Stanislav Malyshev:
unserialize() and being practical
November 04, 2014 @ 10:49:40

Stanislav Malyshev has a new post to his site talking about his proposal for a filtered unserialize change and why he sees it as a practical next step.

I have recently revived my "filtered unserialize()" RFC and I plan to put it to vote today. Before I do that, I'd like to outline the arguments on why I think it is a good thing and put it in a somewhat larger context. It is known that using unserialize() on outside data can lead to trouble unless you are very careful. Which in projects large enough usually means "always", since practically you rarely can predict all interactions amongst a million lines of code. So, what can we do?

He touches on three points that would make it difficult to just not use it this way (on external data) including the fact that there's not really any other way to work with serialized data in PHP. He suggests that by adding filtering to the unserialize handling of the language it can protect from issues around working with serialized external data.

Is this a security measure? [...] Yes, it does not provide perfect security, and yes, you should not rely only on that for security. Security, much like ogres and onions, has layers. So this is trying to provide one more layer - in case that is what you need.
0 comments voice your opinion now!
unserialize rfc filter practical security reasons

Link: https://php100.wordpress.com/2014/11/03/unserialize-and-being-practical/

Anthony Ferrara:
What's In A Type
October 24, 2014 @ 13:55:39

In a new post to his site Anthony Ferrara takes on the topic of typing in PHP, discussing some of the main ideas around the current typing scheme and the discussions being have about potential changes.

There has been a lot of talk about typing in PHP lately. There are a couple of popular proposals for how to clean up PHP's APIs to be simpler. Most of them involve changing PHP's type system at a very fundamental level. So I thought it would be a good idea to talk about that. What goes into a type?

He starts at the highest level, covering what "typing" is in general and some of the tradeoffs that come with being a strongly typed versus weakly typed language. He then gets into PHP's two "semi-independent type systems" - one for objects and one for everything else. He includes some code examples to illustrate and how, for the non-object handling, context means everything for how the types are switched. He also talks about polymorphism, the chaos that could come from scalars becoming objects and a current RFC suggesting the addition of "safe casting" functions to PHP to provide less "magic" when shifting values from one type to another.

0 comments voice your opinion now!
type switching casting rfc proposal function weak strong

Link: http://blog.ircmaxell.com/2014/10/whats-in-type.html

Pascal Martin:
September 2014 on internals@php
October 07, 2014 @ 09:35:15

Pascal Martin has posted his latest edition of the happenings on the PHP internals mailing list for the month of September. In this latest edition he covers some of the major topics discussed this past month including:

  • the "Implicit isset() in Shorthand Ternary Operator" RFC (or, as it came to be known, the "Null Coalesce Operator" RFC)
  • An RFC for a "loop + or control structure"
  • an opinion to make PHP 7 transtyping operations more strict
  • the RFC to "Remove alternative PHP tags"
  • another RFC proposed to "Fix list() behavior inconsistency"

There's links to lots of other topics and various messages on the list including lots of other RFCs and plenty of discussion around them. Check out the full post for more great information and links around last month's php.internals happenings.

0 comments voice your opinion now!
internals september mailinglist sept2014 summary rfc discussion

Link: http://blog.pascal-martin.fr/post/php-mailing-list-internals-september-2014-en

Phil Sturgeon:
The Neverending Muppet Debate of PHP 6 v PHP 7
July 24, 2014 @ 10:18:14

Phil Sturgeon has posted about something he calls the "neverending muppet debate of PHP 6 versus PHP 7. As the PHP language moves forward, the PHP 5.x series is coming to a close. The discussion as started up whether to name it "PHP 6" or "PHP 7" and both sides have their proponents.

There are a few major, important conversations happening in the PHP internals mailing list as we speak: The Facebook lot heading up a specification based off of PHP 5.6 Should phpng be moved into master to be the base of the next major PHP version How can we best go about scalar typehinting? There is also another conversation: Should it be PHP 6 or PHP 7 Wait... what?

He goes on to provide a little context, pointing out that back in 2010 PHP 6 was being slated for release as the next major version of the language (this was around the PHP 5.2 days). Unfortunately, it stalled out and some of what was planned went into PHP 5.3. This didn't stop publishers from releasing books and articles about "PHP 6" though. It's already being put up for a vote with "PHP 7" pulling ahead. Phil also includes more context around the discussions, sharing the main points of each side and snippets from the RFC and mailing list thread currently ongoing.

0 comments voice your opinion now!
debate php6 php7 naming internals rfc version

Link: http://philsturgeon.uk/blog/2014/07/neverending-muppet-debate-of-php-6-v-php-7

Daniel Cousineau:
PHPRFC Internals Logo
July 23, 2014 @ 09:32:56

As anyone who subscribes to the php.internals mailing list knows, there can be a lot of drama around some of the discussions for the future of the language, both in its features and surrounding technical concerns. Daniel Cousineau has posted a lighter take on some of this drama and is issuing his own "RFC" for a proposed mascot for internals - the DramaLlama.

Branding and PR is an increasingly important factor in programming language viability and adoption. Visible instability in the core team is off-putting to large organizations who depend on long term reliability and support and only encourages them to look to languages and tools with more stable and professional core teams. This RFC proposes that the PHP core team get ahead of the issue and introduce a logo, separate from the public facing project, to provide a sense of professionalism that is lacking. I humbly submit the DramaLlama as the superior candidate.

His proposed mascot, shown here, bears the PHP logo on the side of a cartoon purple llama. As Daniel puts it, the llama is a "proud, capable animal" that can deal with a lot and still stand up under a heavy burden.

By not adopting a logo, the PHP core team risks losing the respect and trust of the end user community. However it could be argued that the core team has survived without this and could do so indefinitely.

The post is practically dripping with sarcasm, but it's a good mood-lightener around some of the drama that can come from the clash of multiple personalities in the PHP internals community.

0 comments voice your opinion now!
rfc internals logo funny llama dramallama mailing list

Link: http://dcousineau.com/blog/2014/07/22/phprfc-internals-logo/

Derick Rethans:
No to a Uniform Variable Syntax
July 17, 2014 @ 09:32:15

There's been an RFC that's recently made it through the voting process and was approved for inclusion in PHP6, the uniform variable syntax handling. When these changes are put into effect, some of the odd syntax you had to use for things like variable variables will be cleared up and standardized. However, Derick Rethans stood out as the only "no" vote, here's why...

As you might have heard, PHP developers voted on an RFC called "Uniform Variable Syntax". This RFC "proposes the introduction of an internally consistent and complete variable syntax". In general, this RFC argues for making PHP's parser more complete for all sorts of variable dereferences. [...] Thirty people voted for, and one against: Me. Does that mean that I am against a unified variable syntax? No, I am not. I am actually quite a fan of having a consistent language, but we need to be careful when this hits existing users.

He points out that there's known backwards compatibility breaks in the changes and this breaks the semantics of the language. While the BC breaks are understood, Derick suggests that this is one of the worst changes a language can make: "...and this is exactly why people whine that PHP breaks BC and does not care about its users".

0 comments voice your opinion now!
rfc uniform variable syntax against vote semantics language

Link: http://derickrethans.nl/uniform-variable-syntax.html


Community Events

Don't see your event here?
Let us know!


wordpress series unittest community conference opinion introduction extension development middleware interview laravel5 api framework podcast release voicesoftheelephpant laravel library language

All content copyright, 2015 PHPDeveloper.org :: info@phpdeveloper.org - Powered by the Solar PHP Framework