The PHPBenelux Conference has officially announced their Call for Proposals for their 2014 event:

It’s that time of the year again! The call for proposals is here, this is your chance to grab the microphone on stage, hook up your laptop and teach the world how to make better PHP sites and applications! Did anything new lately which gave you a lot of cool insights? Do you feel like an expert on a certain topic? Why not share it with other developers? We now have opened up our Call for Proposals (CfP) for you to start submitting your talks.

They include some suggestions of topics to help get your mind working including things like refactoring, devops, data management, best practices and soft skills. The Call for Proposals is only open until October 6th, so if you're considering submitting you'd better get them in quickly!

If you've considered submitting to a technology conference as a speaker but didn't really know where to start, you might check out this advice from Neal Anders based on his experiences in the PHP community.

Recently in a conversation on Twitter the topic of what a successful conference proposal – one that gets accepted – looks like, came up. I thought I would expand upon the conversation and the “3 key takeaways” advice I gave, by providing the raw submissions I entered, in this case, to PHP Tek 12, as well as some lessons learned and additional commentary.

He shares his thoughts on what kinds of things it takes to get accepted (note: one is "luck"), what some of his example proposals look like, how to deal with some of the pre-conference jitters and a few final tips on getting that "accepted" email.

Anna Filina has posted a reminder for all of those that wanted to put their hat into the ring for this year's ConFoo conference - the Call for Papers is now open!

The ConFoo team just opened its call for papers. Candidates can submit proposals until September 23. Consult the call for papers page for details and to start submitting. That page also explains what expenses ConFoo can cover for speakers. You can even get advice on how to write proposals. The call for papers is public, meaning that all proposals get published on the website for others to vote and comment on.

This year's event is happening from February 25th through March 1st in Montreal, Canada with tracks covering things like .NET development, Project Management, Web Standards, DevOps and, of course, PHP. The Call for Papers closes on September 23rd so you have less than a month to get your proposals in!

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.

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.