News Feed
Jobs Feed
Sections




News Archive
feed this:

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

VG Tech:
Comparing Your Privates in PHP
March 19, 2014 @ 09:56:33

In a new post to their blog, the VG Tech folks talk about "comparing your privates" with a "hidden" feature of PHP. Don't worry, they're referring to private class properties on object instances here...

I was going to compare several private properties between to objects and started making a piece of code to perform the actual comparison using getters for the properties. I felt the approach sucked, and started looking into alternatives way to do this.

He shares what the current PHP documentation shares about comparing objects, but neither of them take private properties into account. He remembers, however, that object visibility is at the class level not instance level, allowing two object instances of the same class to have access to all properties of the other, regardless of exposure level. He includes a code snippet showing how to use this to compare those private properties.

0 comments voice your opinion now!
private comparison object instance class

Link: http://tech.vg.no/2014/03/14/comparing-your-privates-in-php/

Nikita Popov:
Methods on primitive types in PHP
March 17, 2014 @ 12:11:22

In his latest post Nikita Popov highlights one of the topics from this post, primitive types as objects, and some alternative options.

A few days ago Anthony Ferrara wrote down some thoughts on the future of PHP. I concur with most of his opinions, but not all of them. In this post I'll focus on one particular aspect: Turning primitive types like strings or arrays into "pseudo-objects" by allowing to perform method calls on them. [...] Note that this isn't far off dreaming, but something that already exists right now. The scalar objects PHP extension allows you to define methods for the primitive PHP types. The introduction of method-call support for primitive types comes with a number of advantages.

Among the advantages he lists:

  • The opportunity for a cleaner API (instead of the current, sometimes oddly named functions)
  • Improved readability
  • Polymorphism through a "cleaning up" of shared methods
  • Loose Typing

He also looks at possible ways that other primitive types could be handled (like "null" or "float") and some of the problems that could come up when passing objects around. Since the values could be an object or scalar, how would you know the difference. He finishes off the post with a look at the current state of things, including that there's not much resistance just that there hasn't been a good API defined to make it work.

0 comments voice your opinion now!
method primitive type object example problems

Link: http://nikic.github.io/2014/03/14/Methods-on-primitive-types-in-PHP.html

Ross Tuck:
Persisting Value Objects in Doctrine
March 03, 2014 @ 10:11:29

Ross Tuck has submitted a new article he's posted about persisting value objects in the popular PHP database storage and object mapping library, Doctrine. Value objects are immutable objects that " follow value semantics rather than reference semantics".

I've been using more and more Value Objects in my applications over the last year, primarily with Doctrine ORM. Value Objects are an extremely powerful technique and I've been impressed with how much they can clean up a codebase. One of the main questions I've had when starting with Value Objects is how to persist them with Doctrine. This post attempts to create a reference for all the different persistence techniques I've seen so far.

You'll need to be familiar with Value Objects and Doctrine before starting (it's not an "intro to Doctrine" article). His example sets up an "IPRange" and an "IPAddress" that are stored in a "Server" instance. He talks about mapping the value object to the database and the getter/setter to do the work. He also touches on DBAL types, working with multiple columns in the entity and the "promised land" of embeddables. He finishes off the post looking at collections of entities and some of the other options to what he's shown (including serialization).

0 comments voice your opinion now!
doctrine valueobject value object database entity dbal embeddables

Link: http://rosstuck.com/persisting-value-objects-in-doctrine/

Derick Rethans:
DateTimeImmutable
February 26, 2014 @ 10:26:45

In his latest post Derick Rethans (knower of all things date and time) talks about the DateTimeImmutable functionality. It has been added into the PHP 5.5 releases and provides the same DateTime functionality but removes the ability for modification (mutability).

The first time that my improved DateTime support made its way into PHP was officially in PHP 5.1, although the more advanced features such as the DateTime class only made it appearance in PHP 5.2. Since its introduction the DateTime class implementation suffered from one design mistake - arguably not something that even an RFC would have highlighted. [...] This mutability property that all modifying methods of the DateTime class have is highly annoying, and something that I would now rather remove. But of course we cannot as that would break backwards compatibility. So in PHP 5.5, after a few stumbles, I finally managed to rectify this.

He includes some code examples showing the current DateTime object's mutability (via the "modify" function) and the new immutable handling. This new handling doesn't update the current object but instead returns the modified object, leaving the initial one intact. You can find out more about this new object in the PHP manual.

0 comments voice your opinion now!
datetime datetimeimmutable mutability return object php55

Link: http://derickrethans.nl/immutable-datetime.html

QaFoo:
Learn OOD - to unlearn it again
February 11, 2014 @ 12:52:10

In this latest post to the QaFoo blog Tobias Schlitt recommends learning proper object-oriented design first before trying to worry about the interactions between the objects.

One topic we regularly teach in workshops for our customers is object oriented design (ODD), i.e. the art of crafting classes/interfaces in a way that the result is an easy-to-understand, maintainable and flexible code base. With the agile focus on shipping working software, some might consider the skill of OOD less important. One popular argument is that quick reaction to change is more important than designing objects and their interaction carefully. I personally look at it the exact other way around. This blog post summarizes why you need to learn OOD first, in order to avoid it to some degree again.

He's broken up the rest of the post into a few different topics reinforcing this idea:

  • Learning OOD the classical way
  • OOD in fast pace and agile
  • Refactoring is the key
  • Learning OOD to unlearn it

Finally, he makes the recommendation that all developers should learn about effective refactoring and automated testing to help create well-structured OOP applications.

0 comments voice your opinion now!
learn ood oop objectorienteddesign design object learn

Link: http://qafoo.com/blog/064_learn_ood_to_unlearn_it.html

Evert Pot:
jCard is now a thing
January 21, 2014 @ 11:04:18

In his most recent post Evert Pot talks about jCard, a JSON-based format that was recently approved to serve up VCard personal information data in an easier-to-parse format.

I'm a big fan of this format. vCards have been around since 1995, and even though we've had a pretty significant update in 2011 in the form of vCard 4.0, the format is still complicated to parse, has a number of problems that go all the way back to the early days. [...] The biggest problem with vCards, is that upon a first glance, the format seems extremely easy to parse and generate with just a couple of string manipulation functions. When you dig deeper into the specifications though, you'll notice that it's actually really complex and hosts a ton of edge cases.

He includes an example of how to generate the jCard format using the Sabre/Object and the resulting output, both in the traditional vCard format and the new jCard structure.

0 comments voice your opinion now!
vcard jcard json format sabre object parse output

Link: http://evertpot.com/jcard-completed

Mathias Verraes:
Value Objects and User Interfaces
November 18, 2013 @ 11:35:07

Mathias Verraes has a new post today with a response to an email he received about some comments on a recent Elephant in the Room podcast about Value Object usage. The question asks about usage of Value Objects, specifically when it comes to things like country information.

There's nothing intrinsically wrong with modeling countries as entities and storing them in the database. But in most cases, that overcomplicating things. Countries don't change often. When a country's name changes, it is in fact, for all practical purposes, a new country. If a country one day does not exist anymore, you can't simply change all addresses, because possibly the country was split into two countries. Whenever you have this kind of friction, there's usually some missing concept screaming to be discovered.

He talks some about the concepts around the "country" data and some of the functional concerns around it (duplicate checking, validation of existence, etc). He takes the concept and breaks it out into two different concepts - the actual Value Object of a single country and an "AvailableCountries" set (and "AvailableCountryRepository").

0 comments voice your opinion now!
value object country example registry set

Link: http://verraes.net/2013/11/value-objects-and-user-interfaces/

David Adams:
Is ORM abstraction a pipe dream?
October 23, 2013 @ 09:59:21

David Adams has published a recent post that wonders if ORM abstraction is a "pipe dream" when it comes to abstraction. ORM stands for "object relational mapper" and is commonly used as a layer between the application and a dta source to work with the data as objects, not directly with it. He instead investigates replacing the ORM layer with multiple instances of repository pattern-structured code to abstract thing even more.

I was recently introduced to the repository pattern, a type of abstraction and organizational technique. The idea being, create a repository for each of your models to retrieve and persist to and from. A supposed benefit of the repository pattern is the ability to abstract your ORM and create different implementations for Eloquent, Doctrine, Propel, etc. This abstraction intrigued me. I set off to put this idea into practice and see what it took. Here are my findings.

He looks into how Doctrine handles its entities and tries to mimic some of the logic, including the calls to "save" and "flush". He also looks at how to handle a few other common ORM-ish topics like relationships, validation and observers. Unfortunately, he hit a wall with his solution and wasn't able to figure out a good Repository-based solution.

0 comments voice your opinion now!
repository designpattern proofofconcept orm object mapper doctrine entity

Link: http://programmingarehard.com/2013/10/21/is-orm-abstraction-a-pipe-dream.html

Brandon Savage:
The Cardinal Sin Of Object Inheritance
September 09, 2013 @ 12:38:04

Brandon Savage talks about the "cardinal sin" of working with object inheritance in PHP applications - adding public methods to a class that extends/implements another.

I know I've committed this sin, and you probably have too. The sin of which I speak is a grave one, and it violates several well known and established principles of object oriented application development. What is this sin of which I speak? It is none other than the addition of new public methods to an object that extends or implements abstract class or application interface, in violation of both the Liskov Substitution Principle and the Dependency Inversion Principle.

He talks some about the Liskov Substitution Principle first, pointing out that adding those new methods makes the new object non-replaceable as the Liskov principle requires. As far as the Dependency Inversion Principle, the practice breaks it because you'd be depending on those new methods as concrete, not abstracted from the parent. He makes a few recommendations as far as ways to prevent violating these principles including using multiple interfaces or creating multiple abstract classes for different public APIs.

0 comments voice your opinion now!
object inheritance sin solid principle public method violation

Link: http://www.brandonsavage.net/the-cardinal-sin-of-object-inheritance/

James Morris:
PHPUnit Mocking and Method Chaining
July 17, 2013 @ 12:13:02

James Morris has an interesting new post about mocking and method chaining and a discovery he made about the proper use of the "at" method in what his mock objects were expecting.

I've been given the task of unit testing Symfony2's security layer, which at first seems daunting, but in reality with a clever bit of PHPUnit mocking, it's actually quite simple. Symfony2 makes heavy use of method chaining.

He illustrates one way to create the mocks for this chain (one mock returning another) but suggests an alternative - returning an instance of "self" to keep the chain alive. He also includes a bit about the "at" matcher and how, despite what the PHPUnit documentation says, it should be correctly used to handle the response of certain methods in the chained call.

0 comments voice your opinion now!
phpunit mock method chain object tutorial matcher

Link: http://blog.jmoz.co.uk/phpunit-mocking-and-method-chaining


Community Events











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


component podcast application facebook framework symfony2 performance database release project introduction package hhvm composer unittest language example security hack install

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