Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.
  • Root
  • » PHP
  • » [PHP-DEV] Patch: Marking DateTime Instances Immutable [RSS Feed]

#1 Dec. 5, 2010 08:56:08

Larry G.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Patch: Marking DateTime Instances Immutable


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

Offline

#2 Dec. 5, 2010 09:43:58

Benjamin E.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Patch: Marking DateTime Instances Immutable


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***@*arfieldtech.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

Offline

#3 Dec. 5, 2010 16:19:33

Herman R.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Patch: Marking DateTime Instances Immutable


> 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
hermanrad***@*mail.com |http://hermanradtke.com--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#4 Dec. 5, 2010 17:44:53

Benjamin E.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Patch: Marking DateTime Instances Immutable


On Sun, 5 Dec 2010 08:18:46 -0800
Herman Radtke <hermanrad***@*mail.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
> hermanrad***@*mail.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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#5 Dec. 5, 2010 18:04:13

troels k.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Patch: Marking DateTime Instances Immutable


On Sun, Dec 5, 2010 at 6:44 PM, Benjamin Eberlei <kont***@*eberlei.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 class DateTimeValue" like syntax that
> creates an immutable class.
>
> Any ideas?

I'd prefer BC breakage. DateTimeValue just doesn't have a good ring to
it. Besides, having two both a mutable and an immutable version at the
same time is bound to cause confusion.

--
troels

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#6 Dec. 5, 2010 18:31:00

Stas M.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Patch: Marking DateTime Instances Immutable


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 thatassumes different semantics. Yes, I noticed the word optional, however,the code accepting DateTime assumes some semantics, and had no means toreject object with different semantics, and combining two semantics inone class is a bad idea.On the other hand, you can create DateTimeValue object, which can dowhat you want. I'd imagine it'd be quite easy to do in user space too.If enough people feel they need it then it can be brought into theextension too.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.I've talked to many people who agree it isn't ;)
--
Stanislav Malyshev, Software Architect
SugarCRM:http://www.sugarcrm.com/(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#7 Dec. 5, 2010 19:02:46

Pierre J.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Patch: Marking DateTime Instances Immutable


On Sun, Dec 5, 2010 at 7:02 PM, troels knak-nielsen <troel***@*mail.com> wrote:
> On Sun, Dec 5, 2010 at 6:44 PM, Benjamin Eberlei <kont***@*eberlei.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 class DateTimeValue" like syntax that
>> creates an immutable class.
>>
>> Any ideas?
>
> I'd prefer BC breakage. DateTimeValue just doesn't have a good ring to
> it. Besides, having two both a mutable and an immutable version at the
> same time is bound to cause confusion.

It is not only about date but about create value type. There are
plenty of good usages for such thing.

Cheers,
--
Pierre

@pierrejoye |http://blog.thepimp.net|http://www.libgd.org--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#8 Dec. 5, 2010 19:27:19

Jonathan B.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Patch: Marking DateTime Instances Immutable


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 ideas here:http://www.javalobby.org/articles/immutable/index.jspA pattern I've been using is ~

interface Immutable {}

class DateTime_Immutable extends DateTime implements Immutable {
// throw exceptions if attempt to modify...
}

// Get immutable objects...
Objects::getImmutable('Datetime', '2009-01-09'); // returns
(Immutable) new DateTime_Immutable('2009-01-09')
Objects::getImmutable('Datetime', $param1, $param2, ...); // returns
(Immutable) new DateTime_Immutable($param1, $param2, ...)



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#9 Dec. 5, 2010 19:37:43

Benjamin E.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Patch: Marking DateTime Instances Immutable


On Sun, 05 Dec 2010 10:29:29 -0800
Stas Malyshev <smalys***@*ugarcrm.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 that
> assumes different semantics. Yes, I noticed the word optional, however,
> the code accepting DateTime assumes some semantics, and had no means to
> reject object with different semantics, and combining two semantics in
> one class is a bad idea.
>
> On the other hand, you can create DateTimeValue object, which can do
> what you want. I'd imagine it'd be quite easy to do in user space too.
> If enough people feel they need it then it can be brought into the
> extension too.

Hey Stas,

i actually implemented this in userland, but its rather ugly:http://whitewashing.de/blog/124I'd like to see it in the extension, the patch was just the only thing i could
do with my limited C skills ;-) It is better to start the discussion with
something visible rather than just speaking about hypothetical changes :-)

>
> > 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.
>
> I've talked to many people who agree it isn't ;)
> --
> Stanislav Malyshev, Software Architect
> SugarCRM:http://www.sugarcrm.com/> (408)454-6900 ext. 227
>
> --
> 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

Offline

#10 Dec. 5, 2010 20:21:58

Stas M.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Patch: Marking DateTime Instances Immutable


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 amistake. If you remove this ambiguity it actually would be quite small.--
Stanislav Malyshev, Software Architect
SugarCRM:http://www.sugarcrm.com/(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

  • Root
  • » PHP
  • » [PHP-DEV] Patch: Marking DateTime Instances Immutable [RSS Feed]

Board footer

Moderator control

Enjoy the 24th of October
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support