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

Stanislav Malyshev:
Objects as keys
December 15, 2014 @ 09:18:50

In his latest post Stanislav Malyshev looks at a RFC he's proposed to allow array keys to be objects including some of his thoughts behind the proposal and how he sees it being helpful to the language.

I'm going to put to vote soon another of my RFCs, namely one about "objects as keys". So, I want to outline the case for it here and address some criticisms and questions raised while discussing it.

He starts off by answering the "why" question, mentioning specially the introduction of things like GMP numbers and how, despite them seeming to work like numbers, other things can be done with them. He talks about how you'd use this functionality "the right way" and how that'd relate back to value objects. He answers a few other questions about the proposal including why it's better than just using __toString or spl_object_hash instead. He spends the rest of the post looking at some of the implementation problems, disadvantages and some of the possible names (function names) for the handling.

0 comments voice your opinion now!
object array key rfc proposal gmp number

Link: http://php100.wordpress.com/2014/12/14/objects-as-keys/

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/

Matthias Noback:
Decoupling your (event) system
August 26, 2014 @ 11:15:17

Matthias Noback has continued his look at event handling in PHP applications (well, Symfony-related ones at least) in his latest post. In this latest post he focuses more on abstracting out the event handling process and decoupling it from your application as much as possible.

You are creating a nice reusable package. Inside the package you want to use events to allow others to hook into your own code. You look at several event managers that are available. [...] Introducing this dependency is not without any problem: everybody who uses my/package in their project will also pull in the [event dispatcher] package, meaning they will now have yet another event dispatcher available in their project (a Laravel one, a Doctrine one, a Symfony one, etc.). This doesn't make sense, especially because event dispatchers all do (or can do) more or less the same thing.

As mentioned, he focuses in on the Symfony ecosystem and the event handlers commonly used there. He talks about some of the disadvantages of the Symfony EventDispatcher and how its interface can lead to code bloat due to it's verbosity (flexibility?). He talks about its violations of the Interface Segregation Principle and how he would structure the listener setup and handling if he was starting from scratch. To this end, he's created an adapter that wraps around an EventDispatcher interface and works with objects for the different kinds of events rather than the string names.

0 comments voice your opinion now!
decouple event manager dispatch handling symfony adapter object

Link: http://php-and-symfony.matthiasnoback.nl/2014/08/symfony2-decoupling-your-event-system/

Mathias Verraes:
Resolving Feature Envy in the Domain
August 12, 2014 @ 11:55:24

Mathias Verraes has a new post today about something he calls "feature envy" in the domain, related to this code smell (based on a definition from Martin Fowler).

Benjamin Eberlei did a really nice job of explaining refactoring the Feature Envy code smell on his blog. I wrote a comment because I felt the example could be taken one step further. You should read the original post. Below are Benjamin's code examples (for reference), followed by a repost of my comment.

The "smell" is defined as "a method that seems more interested in a class other than the one it's in". Mathias includes the code examples from the other post showing a datetime calculation and how it could be abstracted out to another class and method. He talks about the migration and how it relates to the "Whole Value" pattern and integrating some of the logic into a factory, generating a "reporting period" instance. He finishes the post with a brief look at an application of domain-driven design concepts to the problem, suggesting that the reporting be even more abstracted from the datetime data and using the "reporting period" object instead.

0 comments voice your opinion now!
feature envy whole value designpattern class object abstraction domaindriven

Link: http://verraes.net/2014/08/resolving-feature-envy-in-the-domain/

Mathias Verraes:
When to Use Static Methods
June 16, 2014 @ 10:20:52

Mathias Verraes has followed up his previous post about named constructors in PHP with a bit more clarification about when to use static methods (as he did in his "multiple constructor" examples previously).

Some of the reactions to my last blog post on Named Constructors in PHP, originate from the notion that static methods are inherently bad and should never be used. This is rather overgeneralized. Static methods are nothing more than namespaced global functions. Namespacing, I think we can all agree on, is great. As for global functions: We use those all the time. The native functions in PHP form our basic building blocks.

He talks about the main problem with their use, the shared global state, and compares it to a more stateful service. His solution is to either move to a normal object state (that allows for internal tracking) or think more about abstractions and how they relate.

0 comments voice your opinion now!
static methods opinion object stateless abstraction

Link: http://verraes.net/2014/06/when-to-use-static-methods-in-php/

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/

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


Community Events





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


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

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