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

Mathias Verraes:
Objects as Contracts for Behaviour
September 29, 2014 @ 11:10:33

Mathias Verraes has a new post to his site today with an interesting idea when it comes to handling the architecture of an application: using objects as the contracts for behavior. He suggests that the objects themselves define how other pieces of code should interact with them, not necessarily external services. He illustrates with an invoice and appointment example.

Of course invoices do not pay themselves, but that's not what an object model is trying to do. An invoice exposes the behaviour of being able to be paid. That ability is in fact essential to what it means to be an invoice. The behaviour is an inherent property of an invoice. If an invoice doesn't have the ability of being paid, there's no point in issuing invoices at all. In other words, the contract of an invoice object declares that its interface includes payment as a feature. Its promise to the outside world is that it allows an outsider to pay for it. Encapsulation of state and behaviour is the core idea behind objects.

He wonders why, if this is more true to the "object-oriented programming" ideals, the idea of encapsulating procedural code as objects is so widespread. He suggests a lack of education on the subject or maybe even confusion from spoken languages themselves.

0 comments voice your opinion now!
objectoriented programming oop contract expose behavior property

Link: http://verraes.net/2014/09/objects-as-contracts-for-behaviour/

Evert Pot:
Accessing protected properties from objects that share the same ancestry.
September 16, 2014 @ 11:19:23

In his latest post Evert Pot shows an interesting side effect of working with two objects from the same class: accessing protected properties from one instance to the other.

I realized something odd about accessing protected properties the other day. It's possible in PHP to access protected properties from other objects, as long as they are from the same class. [...] I always thought that protected strictly allows objects to access things from the current inheritence tree, but didn't realize that this also extends to other instances of the same object.

He includes a bit of sample code showing two object instances each being able to access the protected "val" property from the other. He also shows an example of how it works in two different objects, both that derive from a common ancestor. He shares a few other code examples showing this relationship and points out a few places where it could come in handy.

0 comments voice your opinion now!
protected property object ancestor access

Link: http://evertpot.com/properted-properties-from-shared-ancestry/

Wojciech Sznapka:
Immutable value objects in PHP
May 16, 2014 @ 09:04:27

Wojciech Sznapka has a quick post to his site today looking at a possible implementation of Value Objects (immutable objects) in PHP applications.

Value objects are one of building blocks in Domain Driven Design. They represents a value and does not have an identity. That said, two value objects are equal if their values are equal. Other important feature is that Value Objects are immutable, i.e. they can not be modified after creation. [...] This post isn't about obvious advantages of representing domain logic with support of Value Object. As well, we wouldn't elaborate here about pros and cons of immutable objects. I'd rather would like to show an attempt to change Value Object.

His change method isn't so much a "change" as a "duplicate with new values" process. In his example he creates a EmailValueObject with "host" and "mailbox" properties. This object has a "changemailbox" method that seems to update the "mailbox" property, but in actuality clones the current object with a new "mailbox" value in the constructor.

0 comments voice your opinion now!
value object immutable clone change property

Link: http://blog.sznapka.pl/immutable-value-objects-in-php/

Christian Weiske:
PHP Cannot access property started with '\o'
November 08, 2013 @ 09:59:13

Christian Weiske had an interesting situation pop up in one of his applications around a call to a variable with an interesting name.

Some days ago I saw the following fatal error for the first time in my life:

Fatal error: Cannot access property started with 'o' in file.php

After some debugging, I found out that the source of the error was not some strange BOM or UTF-8 characters in PHP source code files. No, it was a combination of protected class properties, object-to-array casting and automatic template property mappings.

As it turns out, there was a change in how object-to-array casting was done in PHP 5.3 that made this break (related to things appended to private and protected variable names). He includes a bit of sample code to illustrate the problem - a simple class converted from object to array with direct casting. He does point out that it doesn't happen with get_object_vars, though, as that doesn't do the casting, just extraction.

0 comments voice your opinion now!
class property special character private protected casting

Link: http://cweiske.de/tagebuch/php-property-started-nul.htm

7PHP.com:
Auto Generate Properties Dynamically For Your Classes Using Magic Methods & Reflection
October 28, 2013 @ 12:57:14

Accessing private class properties via getters and setters is a pretty standard way to write your applications. Unfortunately it can be time consuming to write them for every property your class may have. On 7PHP.com Khayrattee Wasseem has a few ideas (including using PHP's own Reflection functionality) to dynamically create them.

When coding a project, at times (or most of it?) some classes might have more than 3 fields (for whatever reason it suits you). So instead of each time writing and repeating setters and getters (accessor methods), I would like to have a piece of reusable code for all my classes without me ever writing a single line of code for accessors. ('ever' as in 'very very rarely'). Now, we also have to take into consideration that some fields might be only get-able or only set-able - (our re-usable piece of code should cater for this)

He shows two different methods to accomplish this kind of dynamic access, one using traits and the other using normal class inheritance. HE includes the code illustration each solution and talks a bit at the end of each section of why that method might be better than the other.

0 comments voice your opinion now!
reflection getter setter private property tutorial trait inheritance

Link: http://7php.com/magic-dynamic-properties/

Russell Walker:
Public properties, getters and setters, or magic?
September 26, 2013 @ 09:58:36

Russell Walker has a recent post to his site looking at different ways to work with class properties including using them as public properties or using getters and setters.

Opinion seems to be divided on whether it is good practice to use public properties in PHP classes, or whether to use getter and setter methods instead (and keep the properties private or protected). A sort of hybrid third option is to use the magic methods __get() and __set(). As always, there are advantages and disadvantages to each approach, so let's take a look at them.

He breaks the rest of the post up into three sections, each with a bit of a code example and the common advantages/disadvantages. It's a good overview of the three types and, in the end, it's mostly about what works for your applications. What's his favorite?

My choice then is to use public properties most of the time, but getters and setters for critical settings that I feel need stricter control, would benefit from lazy loading, or that I want to expose in an interface.
0 comments voice your opinion now!
class property getter setter magic public opinion

Link: http://russellscottwalker.blogspot.co.uk/2013/09/public-properties-getters-and-setters.html

Phil Sturgeon:
PHP 6 Pissing in the Wind
January 28, 2013 @ 10:42:16

With some of the recent talk about the consistency of naming methods in PHP (or lack thereof) Phil Sturgeon has put together some ideas about why this (and unicode) changes aren't happing in the language.

PHP is well known for having an inconsistent API when it comes to PHP functions. Anyone with an anti-PHP point of view will use this as one of their top 3 arguments for why PHP sucks, while most PHP developers will point out that they don't really care. [...] Another big thing that anti-PHP folks laugh about is the lack of scalar objects, so instead of $string->length() you have to do strlen($string). ANOTHER thing that people often joke about is how PHP 6.0 just never happened, because the team were trying to bake in Unicode support but just came across so many issues that it never happened.

He shares an "obvious answer" to the problems and shares a theory as to why it's not happening - that no one is really working on out (outisde of this POC) and some of the handling with the recent property accessors RFC. He finishes off the post with three more points, all related to the results of the voting - little points seem to get voted in easier, the representation of developers in the process and that at least one of the "no" votes had to do with not wanting to maintain the results.

Making changes to this language should not be blocked just because a quiet minority of the core team don't like the idea of being asked to do stuff.

Be sure to check out the comments on the post - there's lots of them, so be sure you have some good time to read.

0 comments voice your opinion now!
opinion php6 unicode property accessors rfc voting


PHPClasses.org:
The Secret PHP Optimization of version 5.4
June 14, 2012 @ 12:12:42

In this new post from Manuel Lemos on the PHPClasses.org blog about some of the performance enhancements that were introduced in the latest PHP releases (the 5.4.x series) including variable access optimization.

PHP 5.4 introduced several performance optimizations. One of them was not discussed much in the PHP community but it may affect the performance of your code depending on the way you write it.

He gets into some of the details surrounding the variable access optimization, pointing out how to get the most out of this improvement. He also does a bit of speculation about future versions of the language, including the possible introduction of "Just In Time" compilers.

0 comments voice your opinion now!
optimization version variable access object property


Chris Hartjes' Blog:
Metatesting Extending Your Testing Tools
April 23, 2012 @ 11:27:02

Chris Hartjes has had a few posts about "metatesting" already and in this latest article he takes the series one more step. He looks at moving outside of the current toolset and expanding on them to meet your testing needs.

While PHPUnit is awesome out of the box, it still lacks some tools that are required to do things like test protected class methods or assign values to protected class attributes. Lucky for me we have an awesome testing engineer at Kaplan named Will Parker who has shown me some ways that they have extended PHPUnit itself to make testing certain things easier.

Chris talks about things like testing protected methods (easy thanks to a helper) and checking the value of a class property. The key to both of them lies in using PHP's own Reflection functionality to alter properties on the class objects themselves.

0 comments voice your opinion now!
metatesting extend tool phpunit reflection protected property


Josh Adell's Blog:
GetSet Methods vs. Public Properties
March 05, 2012 @ 09:50:21

Josh Adell has a new post to his blog talking about a debate between developers over which is the better method - using public properties or getters and setters to work with values on your objects.

I was recently having a debate with a coworker over the utility of writing getter and setter methods for protected properties of classes. On the one hand, having getters and setters seems like additional boilerplate and programming overhead for very little gain. On the other hand, exposing the value properties of a class seems like bad encapsulation and will overall lead to code that is more difficult to maintain. I come down firmly on the get/set method side of the fence.

In his opinion, the getter/setter method provides an explicit interface to the class that describes what it can do and how you can work with it. He gives code examples, comparing the two methods - simple setting of properties on one object and using get*/set* methods on the other. He brings up the point that, if ever in the future you wanted to handle the data for a property differently, say always make it an array or object. He also points out that this still doesn't prevent the setting of new properties directly, so he uses the magic __get and __set to deal with that.

0 comments voice your opinion now!
getter setter public property debate example



Community Events





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


voicesoftheelephpant community introduction framework tips zendserver list language developer conference library laravel series symfony podcast bugfix deployment release interview api

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