Hey Larry,
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.
What would be possible though to detect if the return value of all the modify
methods is used. If it is not and the DateTime is immutable we could trigger a
notice or throw an exception.
greetings,
Benjamin
On Sun, 5 Dec 2010 02:55:53 -0600
Larry Garfield <la...@garfieldtech.com> wrote:
> 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
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
