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
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
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
On Sun, 5 Dec 2010 08:18:46 -0800
Herman Radtke hermanrad...@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
On Sun, Dec 5, 2010 at 6:44 PM, Benjamin Eberlei kont...@beberlei.de wrote:
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
Hi!
I propose to allow to work with DateTime objects that are marked as
immutable optionally. This means that all methods add, sub, modify,
I think it's a bad idea, which would instantly break all the code that
assumes different semantics. Yes, I noticed the word optional, however,
the code
On Sun, Dec 5, 2010 at 7:02 PM, troels knak-nielsen troel...@gmail.com wrote:
On Sun, Dec 5, 2010 at 6:44 PM, Benjamin Eberlei kont...@beberlei.de wrote:
So currently preferred over my patch are two solutions:
1. Just create a DateTimeValue object that is immutable, not optimizing PHP
to
On Sun Dec 5 12:44 PM, Benjamin Eberlei wrote:
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?
Some
On Sun, 05 Dec 2010 10:29:29 -0800
Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
I propose to allow to work with DateTime objects that are marked as
immutable optionally. This means that all methods add, sub, modify,
I think it's a bad idea, which would instantly break all the code
Hi!
i actually implemented this in userland, but its rather ugly:
It is ugly because you try to have one class with two semantics. It is a
mistake. If you remove this ambiguity it actually would be quite small.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
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
11 matches
Mail list logo
