Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50856
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain beberlei.de from 178.77.98.152 cause and error)
Date: Sun, 5 Dec 2010 18:44:09 +0100
To: Herman Radtke <hermanradtke@gmail.com>
Cc: Larry Garfield <larry@garfieldtech.com>, internals@lists.php.net
Message-ID: <20101205184409.3bcf5433@benny-pc>
In-Reply-To: <AANLkTi=_PyesTufmF=bJr5ZVEqHzTwjbQv3w+kn7j0Yj@mail.gmail.com>
References: <f9e85836d9f401e78d6a045116c6f5e0@beberlei.de>
	<201012050255.54059.larry@garfieldtech.com>
	<20101205104251.3e0310d5@benny-pc>
	<AANLkTi=_PyesTufmF=bJr5ZVEqHzTwjbQv3w+kn7j0Yj@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Patch: Marking DateTime Instances Immutable
From: kontakt@beberlei.de (Benjamin Eberlei)


On Sun, 5 Dec 2010 08:18:46 -0800
Herman Radtke <hermanradtke@gmail.com> wrote:

> > You don't need to know if the instance is immutable or not, since the current DateTime instances also return themselves for method chaining. So any code that looks like:
> >
> > $d = $d->modify("+1 hour");
> >
> > would work no matter mutable/immutable. This is still a bit strange though. But still any DateTimeValue would extend DateTime. So when you typehint
> > for a "DateTime", you still don't know if you get the one or the other and you would have to resort to the previous code example anyways.
> 
> I do need to know if the instance is immutable.  I have plenty of
> class methods that modify the DateTime instance and some don't return
> the DateTime instance back.  If you want to make sure the object is
> immutable, you typehint for a DateTimeValue object.  From an OO
> perspective, it makes much more sense to extend the class and add this
> functionality than to change the inner workings of the existing class.
> 
> -- 
> Herman Radtke
> hermanradtke@gmail.com | http://hermanradtke.com
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

Hmm yeah you and Larry maybe right on this.

I want to take some discussion over from #pecl-dev also i had with Pierre and others. I am not certain if i carry their argument over correctly, but Immutable Objects are a pain for the garbage collector (many instances) and it would be much more efficient if PHP had a concept of static or read-only classes that don't change after the constructor has been called. This way they could be handled much better by PHPs internal garbage collection mechanisms.

So currently preferred over my patch are two solutions:

1. Just create a DateTimeValue object that is immutable, not optimizing PHP to handle it with efficient garbage collection.
2. One step further, add a "static class DateTimeValue" like syntax that creates an immutable class.

Any ideas?

Benjamin