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

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/

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

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


Volker Dusch's Blog:
An introduction to PHPUnits @covers annotation
November 04, 2011 @ 09:55:32

PHPUnit is one of the most widely used unit testing tools for PHP applications. It comes packed with features, some that are commonly used and some not so much. In a new post to his blog today Volker Dusch looks at one specific feature - the "@covers" annotation you can use in your tests' comments to specify which functionality you're actually testing.

One of the goals of your test suite and the coverage report is to make you trust in your code base and to remove the fear of changing something that needs to be changed. [...] You shouldn't think "Well yes that a 100% but a lot of that just comes from that big integration test and I don't know if the class is really tested!". [...] Thankfully PHPUnit offers a way to drastically increase your confidence in what you actually have tested.

Using the "@covers" annotation on your test method docblocks gives you one more level of confidence in what's being tested and can help make for clearer updating down the road. He also mentions using them to provide extra insight into protected methods in your code and where the test coverage for them really lies.

0 comments voice your opinion now!
phpunit covers annotation protected methods codecoverge


Till Klampaeckel's Blog:
RFC Mocking protected methods
June 16, 2011 @ 13:48:33

Till Klampaeckel has a new post to his blog today looking at the method he's found (through some help from others) to be able to mock out protected methods in his unit tests.

I wrote a couple tests for a small CouchDB access wrapper today. But when I wrote the implementation itself, I realized that my class setup depends on an actual CouchDB server being available and here my journey began.

It was his first experience trying to mock out parts of a class, and he found it a bit difficult to use even after reading this article from Sebastian Bergmann. He ended up, as a first solution, making a "fake" (a term from Ruby testing) that just returned the basic JSON string of an error. Thanks to comments on the post, though, he was able to come up with a more correct solution using getMock() to create a stub and apply an expects() to his "makeRequest" method.

0 comments voice your opinion now!
mock protected method unittest phpunit tutorial


RubySource.com:
Confessions of a Converted PHP Developer On Visibility and Privates
May 12, 2011 @ 10:49:52

From RubySource.com there's a new post from a confessed developer who moved from PHP to Ruby about PHP's private visibility rules and how they compare to Ruby's.

Alright class - today I'm here to talk about the differences and similarities that PHP and Ruby have when it comes to object properties, methods, and their visibility - how you create variables inside classes, and how you can interact with them.

He compares the private properties in PHP classes to the corresponding handling in Ruby, including the getters and setters to go with them. There's also a look at class visibility settings in Ruby.

1 comment voice your opinion now!
visibility private protected public visibility ruby rubysource


Lorna Mitchell's Blog:
Invalid Protected Resource URL in pecl_oauth
April 12, 2011 @ 10:16:03

In a quick post to her blog today, Lorna Mitchell talks about an issue with pecl_outh tat came up during her development of a new API. A strange fatal error message was breaking her connection.

I'd gone through all the handshaking steps, got the acces token and was ready to start talking to the service itself. However when I tried to call OAuth::fetch, I got an error message: Fatal error: Uncaught exception 'OAuthException' with message 'Invalid protected resource url, unable to generate signature base string'

As it turns out, the issue was obscure - the address she was connecting to was missing a training slash (http://api.localhost versus http://api.localhost/) and it was causing the OAuth fetch to fail (apparently undocumented). If you're interested in some of the other things that have come up in her work with OAuth on the project, see here.

0 comments voice your opinion now!
pecloauth oauth api protected resource url fatal error


Vance Lucas' Blog:
Protected vs Private Scope Arrogance, Fear and Handcuffs
April 05, 2011 @ 10:45:53

Vance Lucas has tossed his hat into the ring in the debate about private versus protected scope in PHP projects with this new post to his blog.

The age old private vs protected debate has been re-ignited in the PHP community recently following the decision of Doctrine2 and Symfony2 to make all class methods private until there is a very clear and proven reason to change them to protected or public. The intention is a good one - to ensure they are providing a clear and stable API through intentional and known extension points that they can better test and support. [...] The problem is that this kind of thinking is a slippery slope that kills the spirit of programming.

He suggests that, by limiting the scoping down to private, you're taking away the very thing that gets most people excited about third-party tools - the extensibility. In his opinion, it sends a strong message to other developers that they're "not welcome" to make suggestions or updates to the application/tool.

0 comments voice your opinion now!
opinion private protected scope application thirdparty


Stefan Koopmanschap's Blog:
My privates are not public, they are protected
July 19, 2010 @ 13:58:12

Stefan Koopmanschap has spoken up in response to some of the comments about OOP design, specifically in using the private scope in your applications. Overall, Stefan agrees and thinks that this access prevents possible extension which goes against the whole point of writing open source software.

I agree with pro-private people that it is important to have a good API design and to use that to protect less experienced developers from making mistakes, however one should never assume that the developers using your libraries, especially Open Source libraries, are less than yourself. [...] I definitely am not in favor of simply opening up the complete library to every developer though. By making a clear decision on which methods are public and which methods are protected you will ensure that people simply implementing your library will use the API that you have taken the time designing.

His does note, however, that there are cases when a private scope is valid - usually when it involves a planned, architected product where it is someone's responsibility to have that access controlled.

0 comments voice your opinion now!
private protected scope access modifier opinion


Ivo Jansch's Blog:
Good use of public, private and protected in OO class design
July 19, 2010 @ 10:57:14

In a new post to his blog Ivo Jansch responds to some of the recent comments about scoping in PHP applications with some thoughts of his own (someone spurred on by the Symfony project saying that "private is evil").

I don't care much about Symfony as I'm not a user, but it turned to a discussion on OO theory when Stefan defended the position by claiming that you 'should have the right to extend a class's methods if it doesn't support the use case you have'.

He also mentions the agreeing opinions of Marco Tabini and Travis Swicegood. Ivo gives an example of a piece of code that uses all three states - public, protected and private - as a use case for his later statements. In his opinion, removing the private/protected scoping from the picture only helps those looking to make it easier to derive information from the class rather than fine-tuning what can be called.

Be sure to read the comments on this one - there's lots of great thoughts from community members in there.

0 comments voice your opinion now!
public private protected scope opinion use unittest



Community Events





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


series symfony framework community composer security artisanfiles laravel language voicesoftheelephpant interview podcast version release opinion list introduction conference library tool

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