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/
(40
On Sun, 05 Dec 2010 10:29:29 -0800
Stas Malyshev 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 that
> assumes d
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
On Sun, Dec 5, 2010 at 7:02 PM, troels knak-nielsen wrote:
> On Sun, Dec 5, 2010 at 6:44 PM, Benjamin Eberlei 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
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 6:44 PM, Benjamin Eberlei 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 class DateTimeVa
On Sun, 5 Dec 2010 08:18:46 -0800
Herman Radtke 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
> 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 st
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
stil
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
10 matches
Mail list logo
