Anthony Ferrara has a new article posted to his site today about parameter typecasting and the discussions that have been happening about it on the PHP "internals" mailing list.

As any of you who follow the PHP internals list know, scalar type hinting has been a hot topic as of late. You'll also know that I've submitted two new RFC (Request For Comment) proposals for inclusion of two new major features in the PHP language. I figured it was worth going into both RFCs and patches a little deeper, explain my rationale and (hopefully) garner some more visibility of the proposals.

He shares the details of the two main RFCs that are proposed right now - parameter type casting hints and object scalar casting magic methods (both with code examples). Right now, they're only in the patch stage and there's talk of improving the current casting functionality of PHP before something like one of these goes into place.

Freek Lijten has posted another "Currently on PHP's internals..." post to his blog today (here's the previous one) with a look at the discussions around the idea of having "property accessors" in PHP - a standardized way of defining getters/setters in objects.

Today I will be discussing a feature that at this moment is called "Property Accessor". It is a method of defining getters and setters. Originally an RFC was defined as early as september 2009, but recently new discussion took place and an actual patch was created. There is no certainty this feature will ever make a PHP version but discussion seems to target implementation details and not the feature itself, so things are looking bright for this feature.

There's two RFCs posted about the topic - the original proposal (from Dennis Robinson) and a patch for implementing them (from Clint Priest). The proposal replaces the common magic getters/setters (__get & __set) with the optional "get" and "set" keywords inside of custom-defined properties.

Along with a few personal comments, Lukas Smith has posted some thoughts about the state of everything PEAR following his stepping down from working as an active developer on the project.

I guess with me and Pierre leaving it did spawn a lot of energy about how to organize PEAR in the future. I am still participating in this discussion to some extent, mainly functioning as the historian who can explain why things are the way they are etc in order to prevent people from making rash decisions or even worse repeating old mistakes.

He also comments on the state of package submissions to PEAR, noting that some of them are just unrealistic and that it might be better to start a "PEAR2" side to allow for some of these more expanded ideas to flourish.

Instead I think each of the categories should manage itself more. So packages approval would be handled within the category. The same for QA'ing etc. This way new developers would not be facing this gigantic community. I think this is simply overwhelming. Even for old developers it becomes impossible to feel "at home" in a project of the size of PEAR.