I'd love to have a Value Object version of DateTime, as its current behavior is quite annoying.
However, making it a toggle on the existing class does not make sense to me. A function or method that gets called with a DateTime object then doesn't know if it is safe to modify or not, and if the return value from a method will be a new object or not. That means I need to also pass around a flag saying which it is, or else have a method to ask DateTime which mode it's in and then fork my own code to account for both cases. That's ugly. :-) I think it would be better to have a new DateTimeValue class that subclasses off DateTime (or even better, introduce a new interface that they both implement) that is essentially identical but is immutable. That would make it much easier to code against. --Larry Garfield On Saturday, December 04, 2010 6:11:37 pm Benjamin Eberlei wrote: > In the current implementation DateTime is not a value object, but its > internal state can be modified at any given time. This can lead to very > obscure bugs when references to DateTime objects are shared or objects are > passed through a chain of methods/functions that modify it. Using DateTime > is not side-effect free. > > I propose to allow to work with DateTime objects that are marked as > immutable optionally. This means that all methods add, sub, modify, > setDate, setTime, setISODate, setTimestamp and setTimezone will return a > NEW instance of Datetime instead of reusing the old one. > > I also talked to Derick about this and he agrees that immutable DateTime > objects would be desirable. I have talked to many other people who agreed > that the current behavior is weird. > > My proposed syntax would be: > > $immutableDateTime = date_create("2010-12-05", null, true); > $immutableDateTime = new DateTime("2010-12-05", null, true); > $immutableDateTime = DateTime::createFromFormat("%Y-%m-%d", "2010-12-05", > null, true); > > Where the third and fourth variable respectivly are boolean flags > $immutable yes or no. Also the DatePeriod iterator would be modified. If an > immutable start date is passed the date iterator would also create > immutable dates. > > I have attached a patch that implements this functionality and a little > test-script that shows how it would work. This is the first complex bit of > C-code that I did so please bear with any mistakes I made ;-) Also i havent > followed the coding standards. > > Any feedback is greatly appreciated. My C-Skills arent that good so i am > not finished with an additional solution allowing to call a method > "setImmutable()" on any datetime instance, marking it as immutable. > Obviously this would only mark the instance as immutable, allowing to > accept a flag to reset it to be mutable would be counter-productive. > > The only drawback I see to this patch is the additional int variable on > the _php_date_obj and _php_date_period structs. I am not sure if they > affect memory in such a way that this solution isn't viable. > > If this topic needs more discussion or pro/cons I am willing to open up an > RFC for a more detailed discussion. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php