Re: [PHP-DEV] DateTime improvement
Stas Malyshev smalys...@sugarcrm.com wrote: Sebastian had responded off-list that he'd rather have DateTime inherit from DateTimeImmutable, instead of the current variant where DateTimeImmutable inherits DateTime. While this OO-design principle wise makes perfect sense, practically it is not as handy. I've played with a Actually, I would claim it doesn't make perfect sense, since it would mean DateTime would violate DateTimeImmutable's contract of being, well, immutable. Strictly speaking, they can not either extend from other one, since they have APIs which are not subset of each other. However, doing it strictly OO would mean getting into Java-esque web of interfaces, abstract classes and implementation classes, which would suck. As for established practice, everybody expects DateTime, so IMHO we should leave DateTime as base class even though it's not strictly OO-pure. Speaking of derived classes, though, I wonder how hard it would be to make DateTime factory methods - such as createFromFormat - to be able to produce instance of child class? Now if you want to extend DateTime and use those, you need to implement some weird things like: $dt = DateTime::createFromFormat($format, $time); $mydt = new MyDateTime(@.$dt-getTimestamp()); Maybe there's a better way but I'm not sure what it is. The above wouldn't quite work as you lose timezone information. I've thought about this before and we can only do this if we allow to specify the class name as extra argument. I'd like to add this, but it is a bit unrelated to this change. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime improvement
Hi! Sebastian had responded off-list that he'd rather have DateTime inherit from DateTimeImmutable, instead of the current variant where DateTimeImmutable inherits DateTime. While this OO-design principle wise makes perfect sense, practically it is not as handy. I've played with a Actually, I would claim it doesn't make perfect sense, since it would mean DateTime would violate DateTimeImmutable's contract of being, well, immutable. Strictly speaking, they can not either extend from other one, since they have APIs which are not subset of each other. However, doing it strictly OO would mean getting into Java-esque web of interfaces, abstract classes and implementation classes, which would suck. As for established practice, everybody expects DateTime, so IMHO we should leave DateTime as base class even though it's not strictly OO-pure. Speaking of derived classes, though, I wonder how hard it would be to make DateTime factory methods - such as createFromFormat - to be able to produce instance of child class? Now if you want to extend DateTime and use those, you need to implement some weird things like: $dt = DateTime::createFromFormat($format, $time); $mydt = new MyDateTime(@.$dt-getTimestamp()); Maybe there's a better way but I'm not sure what it is. -- 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
Re: [PHP-DEV] DateTime improvement
On Tue, 18 Dec 2012, Adam Harvey wrote: On 18 December 2012 04:52, Lars Strojny l...@strojny.net wrote: I would go with DateTimeValue or DateTimeImmutable as well. +1. I'd prefer DateTimeImmutable personally because it describes what it is better than the other options. That's what I have changed it to now[1]. I've also modified DatePeriod[2] to allow for immutable objects to be returned. Right now, it will return DateTimeImmutable objects if the start date object is also DateTimeImmutable. In case it is a DateTime object, or an ISO8601 date-string, the returned objects are of the DateTime class[3]. Sebastian had responded off-list that he'd rather have DateTime inherit from DateTimeImmutable, instead of the current variant where DateTimeImmutable inherits DateTime. While this OO-design principle wise makes perfect sense, practically it is not as handy. I've played with a patch to implement it and it works, but lots of messages are now blah blah wants a DateTimeImmutable class instead of blah blah wants a DateTime class. Although I think having a DateTimeImmutable is a good thing, I don't want to confuse too many people (novices!) with weird OO terms. And in most cases, people don't care whether DateTime is immutable or not. Besides that, it also made the change and the code more complex and duplicated. Because of this, I didn't pursue this patch any further. [1] http://git.php.net/?p=php-src.git;a=commit;h=6b48ae4580a0e97f7df4f1733eca345755110b96 [2] http://git.php.net/?p=php-src.git;a=commit;h=042ddf371e84fbb7ba1326e7bd45888e63fb30ef [3] http://git.php.net/?p=php-src.git;a=blob;f=ext/date/tests/date_period-immutable.phpt;h=0ec4b4a13025b9494833aa90fa64be7d95f8a261;hb=042ddf371e84fbb7ba1326e7bd45888e63fb30ef cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] DateTime improvement
What about putting the new DateTimeImmutable (or whatever it will be called) into a PHP namespace? Something like \PHP\Foobar\DateTimeImmutable Is it generally planned to use namespaces for PHP classes? In my opinion it would be nice if the SPL and other classes would be put into such a namespace, too. Are there any plans to do that? Christian Stoller -Original Message- From: Peter Cowburn [mailto:petercowb...@gmail.com] Sent: Friday, December 21, 2012 1:14 AM To: Lazare Inepologlou Cc: Larry Garfield; internals@lists.php.net Subject: Re: [PHP-DEV] DateTime improvement On 20 December 2012 20:06, Lazare Inepologlou linep...@gmail.com wrote: Of course, I have no idea if anyone in userspace is using DateTimeImmutable... Well, it seems unlikely, unless he is Yoda or French. I mean, in English, it is common to put the adjective in front of the noun, isn't it? Class names aren't particularly subject, too strictly, to English grammar rules. Besides, the coding standards [1] dictate the class name should be prefixed with the 'parent set' (e.g. extension name), which in this case is not Immutable. [1] https://github.com/php/php-src/blob/master/CODING_STANDARDS#L152 Lazare INEPOLOGLOU Ingénieur Logiciel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime improvement
On Thu, 20 Dec 2012, Larry Garfield wrote: I've seen DateTimeValue used elsewhere for userspace immutable date time objects. Whether that indicates we SHOULD or SHOULD NOT use that for an in-C version, I don't know. (I'm inclined to say should-but-namespace, but I don't know if we're doing that yet.) http://php.net/manual/en/userlandnaming.rules.php cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime improvement
I don't think it would be ok to move just DateTimeImmutable to the namespace. There were proposal to move all the php functions and classes in namespaces, so that for example str_replace() could be \Str\replace() and array_map() could be \Array\map() and so on. On Fri, 21 Dec 2012 12:33:04 +0400, Christian Stoller stol...@leonex.de wrote: What about putting the new DateTimeImmutable (or whatever it will be called) into a PHP namespace? Something like \PHP\Foobar\DateTimeImmutable Is it generally planned to use namespaces for PHP classes? In my opinion it would be nice if the SPL and other classes would be put into such a namespace, too. Are there any plans to do that? Christian Stoller -Original Message- From: Peter Cowburn [mailto:petercowb...@gmail.com] Sent: Friday, December 21, 2012 1:14 AM To: Lazare Inepologlou Cc: Larry Garfield; internals@lists.php.net Subject: Re: [PHP-DEV] DateTime improvement On 20 December 2012 20:06, Lazare Inepologlou linep...@gmail.com wrote: Of course, I have no idea if anyone in userspace is using DateTimeImmutable... Well, it seems unlikely, unless he is Yoda or French. I mean, in English, it is common to put the adjective in front of the noun, isn't it? Class names aren't particularly subject, too strictly, to English grammar rules. Besides, the coding standards [1] dictate the class name should be prefixed with the 'parent set' (e.g. extension name), which in this case is not Immutable. [1] https://github.com/php/php-src/blob/master/CODING_STANDARDS#L152 Lazare INEPOLOGLOU Ingénieur Logiciel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime improvement
I've seen DateTimeValue used elsewhere for userspace immutable date time objects. Whether that indicates we SHOULD or SHOULD NOT use that for an in-C version, I don't know. (I'm inclined to say should-but-namespace, but I don't know if we're doing that yet.) Of course, I have no idea if anyone in userspace is using DateTimeImmutable... --Larry Garfield On 12/17/12 2:52 PM, Lars Strojny wrote: Hi Derick, I would go with DateTimeValue or DateTimeImmutable as well. Am 17.12.2012 um 19:42 schrieb Benjamin Eberlei kont...@beberlei.de: On Mon, Dec 17, 2012 at 5:48 PM, Derick Rethans der...@php.net wrote: I went for DateTimePoint. Point as in Point in time. I am not too happy with the name, but I think it works better than DateTimeImmutable as that just sounds quircky. I'm still fixing up a few things and adding some test cases. I think I need to make it work with DatePeriod too - but I haven't looked at that yet. some suggestions: DateTimeValue DateTimeImmutable DateImmutable DateFixed DateStatic (and as a bonus: DateTime2) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime improvement
Of course, I have no idea if anyone in userspace is using DateTimeImmutable... Well, it seems unlikely, unless he is Yoda or French. I mean, in English, it is common to put the adjective in front of the noun, isn't it? Lazare INEPOLOGLOU Ingénieur Logiciel 2012/12/20 Larry Garfield la...@garfieldtech.com I've seen DateTimeValue used elsewhere for userspace immutable date time objects. Whether that indicates we SHOULD or SHOULD NOT use that for an in-C version, I don't know. (I'm inclined to say should-but-namespace, but I don't know if we're doing that yet.) Of course, I have no idea if anyone in userspace is using DateTimeImmutable... --Larry Garfield On 12/17/12 2:52 PM, Lars Strojny wrote: Hi Derick, I would go with DateTimeValue or DateTimeImmutable as well. Am 17.12.2012 um 19:42 schrieb Benjamin Eberlei kont...@beberlei.de: On Mon, Dec 17, 2012 at 5:48 PM, Derick Rethans der...@php.net wrote: I went for DateTimePoint. Point as in Point in time. I am not too happy with the name, but I think it works better than DateTimeImmutable as that just sounds quircky. I'm still fixing up a few things and adding some test cases. I think I need to make it work with DatePeriod too - but I haven't looked at that yet. some suggestions: DateTimeValue DateTimeImmutable DateImmutable DateFixed DateStatic (and as a bonus: DateTime2) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime improvement
On 20 December 2012 20:06, Lazare Inepologlou linep...@gmail.com wrote: Of course, I have no idea if anyone in userspace is using DateTimeImmutable... Well, it seems unlikely, unless he is Yoda or French. I mean, in English, it is common to put the adjective in front of the noun, isn't it? Class names aren't particularly subject, too strictly, to English grammar rules. Besides, the coding standards [1] dictate the class name should be prefixed with the 'parent set' (e.g. extension name), which in this case is not Immutable. [1] https://github.com/php/php-src/blob/master/CODING_STANDARDS#L152 Lazare INEPOLOGLOU Ingénieur Logiciel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime improvement
On Sun, 16 Dec 2012, Lars Strojny wrote: Am 16.12.2012 um 13:21 schrieb Derick Rethans der...@php.net: On Tue, 11 Dec 2012, Derick Rethans wrote: On Mon, 10 Dec 2012, Herman Radtke wrote: Another option is to make an ImmutableDateTime class. The DateTime class could actually be changed to inherit the ImmutableDateTime class. The only extensions on the DateTime class would be the mutable methods. I'm not really against that, but we do need to use the Date namespace - so DateTimeImmutable. It might be trickier to do than it sounds though... I've started hacking on this - with some luck I'm done before PHP 5.5 beta1. This is so cool, thanks Derick! If you need help with testing or anything else, let me know. I've just pushed it to the immutable-date branch: http://git.php.net/?p=php-src.git;a=shortlog;h=refs/heads/immutable-date I went for DateTimePoint. Point as in Point in time. I am not too happy with the name, but I think it works better than DateTimeImmutable as that just sounds quircky. I'm still fixing up a few things and adding some test cases. I think I need to make it work with DatePeriod too - but I haven't looked at that yet. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime improvement
On Mon, Dec 17, 2012 at 5:48 PM, Derick Rethans der...@php.net wrote: I went for DateTimePoint. Point as in Point in time. I am not too happy with the name, but I think it works better than DateTimeImmutable as that just sounds quircky. I'm still fixing up a few things and adding some test cases. I think I need to make it work with DatePeriod too - but I haven't looked at that yet. some suggestions: DateTimeValue DateTimeImmutable DateImmutable DateFixed DateStatic (and as a bonus: DateTime2)
Re: [PHP-DEV] DateTime improvement
Hi Derick, I would go with DateTimeValue or DateTimeImmutable as well. Am 17.12.2012 um 19:42 schrieb Benjamin Eberlei kont...@beberlei.de: On Mon, Dec 17, 2012 at 5:48 PM, Derick Rethans der...@php.net wrote: I went for DateTimePoint. Point as in Point in time. I am not too happy with the name, but I think it works better than DateTimeImmutable as that just sounds quircky. I'm still fixing up a few things and adding some test cases. I think I need to make it work with DatePeriod too - but I haven't looked at that yet. some suggestions: DateTimeValue DateTimeImmutable DateImmutable DateFixed DateStatic (and as a bonus: DateTime2) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime improvement
On 18 December 2012 04:52, Lars Strojny l...@strojny.net wrote: I would go with DateTimeValue or DateTimeImmutable as well. +1. I'd prefer DateTimeImmutable personally because it describes what it is better than the other options. Adam bikeshed Harvey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime improvement
On Tue, 11 Dec 2012, Derick Rethans wrote: On Mon, 10 Dec 2012, Herman Radtke wrote: Another option is to make an ImmutableDateTime class. The DateTime class could actually be changed to inherit the ImmutableDateTime class. The only extensions on the DateTime class would be the mutable methods. I'm not really against that, but we do need to use the Date namespace - so DateTimeImmutable. It might be trickier to do than it sounds though... I've started hacking on this - with some luck I'm done before PHP 5.5 beta1. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime improvement
This is so cool, thanks Derick! If you need help with testing or anything else, let me know. Am 16.12.2012 um 13:21 schrieb Derick Rethans der...@php.net: On Tue, 11 Dec 2012, Derick Rethans wrote: On Mon, 10 Dec 2012, Herman Radtke wrote: Another option is to make an ImmutableDateTime class. The DateTime class could actually be changed to inherit the ImmutableDateTime class. The only extensions on the DateTime class would be the mutable methods. I'm not really against that, but we do need to use the Date namespace - so DateTimeImmutable. It might be trickier to do than it sounds though... I've started hacking on this - with some luck I'm done before PHP 5.5 beta1. cheers, Derick -- 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
Re: [PHP-DEV] DateTime improvement
I'm not really against that, but we do need to use the Date namespace - so DateTimeImmutable. It might be trickier to do than it sounds though... I've started hacking on this - with some luck I'm done before PHP 5.5 beta1. Am I missing something here? Isn't this just making the object content read only? Haven't we been having a separate discussion on that? On the whole I'm only using DateTime objects when I need to display the content in a different timezone, so the timezone needs to be changeable, but the base date is read only. Alternatively I'm building a calendar so need 'all the days for month x' as an array, and then use those dates to generate the database query. If it's a 'local' calendar then there will be a time offset incorporated as well. In Firebird, the dates are stored as a numeric value, with the whole part the number of days, and the fraction the time of day. Two 32bit values. When doing comparisons there is no point converting to a DateTime object, one converts FROM the DateTime to parameter suitable for the database, and leave the database to do the filtering. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime improvement
I have actually started too, but I made it w/o inheritance from DateTime, and I made many of inline functions to avoid code repetition, so I don't know how good is it. The code on my work computer, so I can show it tomorrow. Derick Rethans der...@php.net писал(а) в своём письме Sun, 16 Dec 2012 16:21:47 +0400: On Tue, 11 Dec 2012, Derick Rethans wrote: On Mon, 10 Dec 2012, Herman Radtke wrote: Another option is to make an ImmutableDateTime class. The DateTime class could actually be changed to inherit the ImmutableDateTime class. The only extensions on the DateTime class would be the mutable methods. I'm not really against that, but we do need to use the Date namespace - so DateTimeImmutable. It might be trickier to do than it sounds though... I've started hacking on this - with some luck I'm done before PHP 5.5 beta1. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime improvement
On Sun, 16 Dec 2012, Lester Caine wrote: I'm not really against that, but we do need to use the Date namespace - so DateTimeImmutable. It might be trickier to do than it sounds though... I've started hacking on this - with some luck I'm done before PHP 5.5 beta1. Am I missing something here? Isn't this just making the object content read only? Sortof. But as that is how things work, making an immutable variant isn't that easy. Haven't we been having a separate discussion on that? On the whole I'm only using DateTime objects when I need to display the content in a different timezone, so the timezone needs to be changeable, but the base date is read only. Alternatively I'm building a calendar so need 'all the days for month x' as an array, and then use those dates to generate the database query. If it's a 'local' calendar then there will be a time offset incorporated as well. Al the methods will *still* return the modified DateTime object - it's just that the one that you *call* f.e. -modify() on won't change anymore. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime improvement
Hi! Al the methods will *still* return the modified DateTime object - it's just that the one that you *call* f.e. -modify() on won't change anymore. Doesn't it mean you can just call clone() on it in modifier methods before doing anything else? -- 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
Re: [PHP-DEV] DateTime improvement
On Sun, 16 Dec 2012, Stas Malyshev wrote: Al the methods will *still* return the modified DateTime object - it's just that the one that you *call* f.e. -modify() on won't change anymore. Doesn't it mean you can just call clone() on it in modifier methods before doing anything else? Yeah, I think so. I tried that but I got some errors. It's something for me to sort out. So far, I've just created all the helper methods etc. clone() however is not a method, but a language construct... so it's not that trivial. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime improvement
Hi! Date is immutable, but there's no reason why date object should be able to represent only one date. Reference to Java is not exactly applicable here, as many problems existing in Java (thread safety, long-living object references, etc.) do not exist in PHP. Say we have a blog post entity, it looks like this: Post Object ( [title] = Qwerty [body] = Lorem ipsum [craetedAt] = DateTime Object ( [date] = 2010-10-23 00:00:00 [timezone_type] = 3 [timezone] = Europe/Moscow ) ) Now we have some third-party service that we need to use to send our post somewhere, it has a method that accepts title, body and DateTime object when the post was created. So we pass our DateTime object to that method and it can do with that object whatever it wants. When our script ends, it tries to persist all changes to entities and this date will end up in the database. Or we can watch at that problem from ORM's side - when it fetches rows and maps them to objects, it should remember original state of that data, so it can distinguish what objects need to be UPDATE-d in database in the end. So there's to ways for ORM to think about dates - as strings/timestamps (it could be database's representation of date like 2010-10-23 or just integer with timestamp) or it could be objects of DateTime. More efficient and logical way would be objects, but that way you must aware users that they shouldn't modify values of DateTime objects, and instead they should create new instance when they want to change value of datetime type. And it's just bad that there could be situations when the entity will represent different data, after persisting, than database. It does not - if you don't need it mutable, don't use modify() or override modify() with method that would clone the object and return modified clone. This can easily be done in userspace if you require an immutable object, which most of the users actually do not. I was speaking not about modify() but about add() and sub(). Actually I don't like these two methods (plus and minus) that I proposed too, but how can we solve this problem differently? What about user-land implementation - there's one problem: I can't just extend DateTime object, because it has factory methods like createFromFormat, so I need to use decorator pattern and from that point hell begins. Timestamp doesn't need any timelib parsing AFAIK, but YMD certainly does - you need to calculate the actual timestamp according to current timezone, etc. I meant I must either call create new DateTime and pass to constructor timestamp string starting with @ (and there would be parsing involved) or call createFromFormat and pass U as second parameter and timestamp as first one. DateTime objects can be compared directly, why do you think you can compare only timestamps? My fault, didn't know about that. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime improvement
As Nikita says, from an ORM perspective, an object is always immutable (at least with current implementations I know of), and that's because they can simply use the object hashes to identify two different objects. While this may be a niche to many of you, I've encountered a quite big amount of people just modifying their DateTime objects with the existing API and then complaining about their date not being saved to DB. I don't believe (at all) in if you don't need it mutable, don't use modify() oroverride modify(). If the API is there, people will use it. We tried to implement an immutable DateTime in userland, but it doesn't work out well... Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
Re: [PHP-DEV] DateTime improvement
Hi! As Nikita says, from an ORM perspective, an object is always immutable (at least with current implementations I know of), and that's because they can simply use the object hashes to identify two different objects. Why for ORM Date is even an object? In most databases, date is a basic value type, and should be accepted by value, not as a complex object. So, it should also be identified as the value - for number 1, you do not need additional identity or hash except it being number 1, same should be for dates. I don't believe (at all) in if you don't need it mutable, don't use modify() oroverride modify(). If the API is there, people will use it. We tried to implement an immutable DateTime in userland, but it doesn't work out well... Why it doesn't work well and why PHP needs to be changed because of it? -- 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
Re: [PHP-DEV] DateTime improvement
People tend to desire API changes that go on the same directions they are going. That's nature... Daniel Ribeiro Gomes Pereira Twitter https://twitter.com/#!/drgomesp | Facebookhttps://www.facebook.com/profile.php?id=10407054469 | LinkedIn http://www.linkedin.com/pub/daniel-ribeiro-gomes/21/414/39 iPhone: +55 (48) 9111-0931 2012/12/11 Stas Malyshev smalys...@sugarcrm.com Hi! As Nikita says, from an ORM perspective, an object is always immutable (at least with current implementations I know of), and that's because they can simply use the object hashes to identify two different objects. Why for ORM Date is even an object? In most databases, date is a basic value type, and should be accepted by value, not as a complex object. So, it should also be identified as the value - for number 1, you do not need additional identity or hash except it being number 1, same should be for dates. I don't believe (at all) in if you don't need it mutable, don't use modify() oroverride modify(). If the API is there, people will use it. We tried to implement an immutable DateTime in userland, but it doesn't work out well... Why it doesn't work well and why PHP needs to be changed because of it? -- 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
Re: [PHP-DEV] DateTime improvement
Hi! strings/timestamps (it could be database's representation of date like 2010-10-23 or just integer with timestamp) or it could be objects of DateTime. More efficient and logical way would be objects, but that way you must aware users that they shouldn't modify values of DateTime objects, and instead they should create new instance when they want to change value of datetime type. And it's just bad that there could be situations when the entity will represent different data, after persisting, than database. You need not be aware of anything unless your database identifies dates by object identities, which is usually wrong since DateTime is a value type in most systems, and should be identified by value, as I already noted. If your data are mutable (which I assume they are, since otherwise the question of saving would not arise), you have to treat changes in title, body, etc. fields - treat the changes in createdAt field the same way. What about user-land implementation - there's one problem: I can't just extend DateTime object, because it has factory methods like createFromFormat, so I need to use decorator pattern and from that point hell begins. It is true that createFromFormat and other factory methods could use an extension that allows to instantiate child classes, however working around it is pretty trivial, not sure what hell begins there. I meant I must either call create new DateTime and pass to constructor timestamp string starting with @ (and there would be parsing involved) or call createFromFormat and pass U as second parameter and timestamp as first one. Yes, but what's wrong with that? It works just fine. -- 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
Re: [PHP-DEV] DateTime improvement
Hi! @Stas a DateTime object is the perfect representation of what in DB world has dozens of different representations. The reasoning behind it is exactly the same as having a DateTime object vs having a date+time string. You are confusing internal PHP representation with object identity vs. value treatment. There's no reason for dates to be treated as non-value types having complex structure, and if you do not, mutability is not a question. -- 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
Re: [PHP-DEV] DateTime improvement
Stas Malyshev smalys...@sugarcrm.com писал(а) в своём письме Tue, 11 Dec 2012 21:06:05 +0400: Hi! As Nikita says, from an ORM perspective, an object is always immutable (at least with current implementations I know of), and that's because they can simply use the object hashes to identify two different objects. Why for ORM Date is even an object? In most databases, date is a basic value type, and should be accepted by value, not as a complex object. So, it should also be identified as the value - for number 1, you do not need additional identity or hash except it being number 1, same should be for dates. Then why do we even need DateTime class? We could stay with functions. I think if we want to bring some OOP in php, then we need to do it right way. I don't believe (at all) in if you don't need it mutable, don't use modify() oroverride modify(). If the API is there, people will use it. We tried to implement an immutable DateTime in userland, but it doesn't work out well... Why it doesn't work well and why PHP needs to be changed because of it? Because of some DateTime's limitations - you will end up making brand new DateTime class, reimplementing *all* the features that were implemented in DateTime. At first - you can't just extend DateTime, because of factory-methods - so that way you will need to use decorator, but even with this approach (pretty shitty approach I must say) there would be problems with diff() method (if you want to use DateTime's diff, you will need to implement getDateTime method of your own DateTime class (because diff accepts DateTime), so you will end with mutable object again, because one can just execute $yourDate-getDateTime()-modify(*whatever you want*)). I think it should be changed (or implemented another one, like someone said, DateTimeImmutable) because date is atomic value. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] DateTime improvement
So there had been at least two or three messages (subjects) about DateTime object and everytime there was this problem - people tend to take DateTime object as mutable object and it really is. As long as we know, it's not so good - date is immutable by nature. I don't want to write here why it's so, I will just throw this link: http://www.ibm.com/developerworks/java/library/j-jtp02183/index.html I don't want to change any existing functionality, because some people already use it, but I just wanted to point out that current DateTime class is forcing people to think about it as mutable. My main concerns are DateTime#add() and DateTime#sub(). The problem is - they both change current object and return it. I think we could add methods to DateTime like add() and sub(), let's say plus() and minus(), but they would behave differently in the way that they would return new DateTime objects and won't change current object. Here's gist to make it clear: https://gist.github.com/4250785 Also, there's methods compareTo, createFromTimestamp and createFromDay, it could be another proposal. I think we are very often create DateTime objects just from timestamp or year-month-day. So we could introduce this methods that could not rely on timelib's parsing, and instead just take numbers directly. And I think DateTime lack comparing method. For now I can compare DateTime objects only by getting their timestamps, but I though that the idea of DateTime was to go away from using timestamps and instead use well thought out api. Anyway, I think this three methods should be considered as another proposal (because they are solve different problems). Even if this proposal doesn't go far, I think we should do something with DateTime. I think I'm going to create user-land library for dealing with some of this problems. But if it pass, I will make patch. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime improvement
On 10/12/12 16:18, Nikita Nefedov wrote: So there had been at least two or three messages (subjects) about DateTime object and everytime there was this problem - people tend to take DateTime object as mutable object and it really is. As long as we know, it's not so good - date is immutable by nature. I don't want to write here why it's so, I will just throw this link: http://www.ibm.com/developerworks/java/library/j-jtp02183/index.html I don't want to change any existing functionality, because some people already use it, but I just wanted to point out that current DateTime class is forcing people to think about it as mutable. My main concerns are DateTime#add() and DateTime#sub(). The problem is - they both change current object and return it. I think we could add methods to DateTime like add() and sub(), let's say plus() and minus(), but they would behave differently in the way that they would return new DateTime objects and won't change current object. That will make it even more inconsistent. You have add() and plus() but one changes the object and the other doesn't. If we were going to rewrite php or the DateTime class, it could be a good idea to make those methods (or its equivalents) not modify the object. But I don't think it'd be a win to do such thing now. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime improvement
On Mon, Dec 10, 2012 at 11:39 AM, Ángel González keis...@gmail.com wrote: On 10/12/12 16:18, Nikita Nefedov wrote: So there had been at least two or three messages (subjects) about DateTime object and everytime there was this problem - people tend to take DateTime object as mutable object and it really is. As long as we know, it's not so good - date is immutable by nature. I don't want to write here why it's so, I will just throw this link: http://www.ibm.com/developerworks/java/library/j-jtp02183/index.html I don't want to change any existing functionality, because some people already use it, but I just wanted to point out that current DateTime class is forcing people to think about it as mutable. My main concerns are DateTime#add() and DateTime#sub(). The problem is - they both change current object and return it. I think we could add methods to DateTime like add() and sub(), let's say plus() and minus(), but they would behave differently in the way that they would return new DateTime objects and won't change current object. That will make it even more inconsistent. You have add() and plus() but one changes the object and the other doesn't. If we were going to rewrite php or the DateTime class, it could be a good idea to make those methods (or its equivalents) not modify the object. But I don't think it'd be a win to do such thing now. Another option is to make an ImmutableDateTime class. The DateTime class could actually be changed to inherit the ImmutableDateTime class. The only extensions on the DateTime class would be the mutable methods. -- Herman Radtke hermanrad...@gmail.com | http://hermanradtke.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime improvement
On 11/12/12 06:59, Herman Radtke wrote: On Mon, Dec 10, 2012 at 11:39 AM, Ángel González keis...@gmail.com wrote: On 10/12/12 16:18, Nikita Nefedov wrote: So there had been at least two or three messages (subjects) about DateTime object and everytime there was this problem - people tend to take DateTime object as mutable object and it really is. As long as we know, it's not so good - date is immutable by nature. I don't want to write here why it's so, I will just throw this link: http://www.ibm.com/developerworks/java/library/j-jtp02183/index.html I don't want to change any existing functionality, because some people already use it, but I just wanted to point out that current DateTime class is forcing people to think about it as mutable. My main concerns are DateTime#add() and DateTime#sub(). The problem is - they both change current object and return it. I think we could add methods to DateTime like add() and sub(), let's say plus() and minus(), but they would behave differently in the way that they would return new DateTime objects and won't change current object. That will make it even more inconsistent. You have add() and plus() but one changes the object and the other doesn't. If we were going to rewrite php or the DateTime class, it could be a good idea to make those methods (or its equivalents) not modify the object. But I don't think it'd be a win to do such thing now. Another option is to make an ImmutableDateTime class. The DateTime class could actually be changed to inherit the ImmutableDateTime class. The only extensions on the DateTime class would be the mutable methods. Would love to see ImmutableDateTime! David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime improvement
Hi! As long as we know, it's not so good - date is immutable by nature. I don't want to write here why it's so, I will just throw this link: http://www.ibm.com/developerworks/java/library/j-jtp02183/index.html Date is immutable, but there's no reason why date object should be able to represent only one date. Reference to Java is not exactly applicable here, as many problems existing in Java (thread safety, long-living object references, etc.) do not exist in PHP. I don't want to change any existing functionality, because some people already use it, but I just wanted to point out that current DateTime class is forcing people to think about it as mutable. It does not - if you don't need it mutable, don't use modify() or override modify() with method that would clone the object and return modified clone. This can easily be done in userspace if you require an immutable object, which most of the users actually do not. Also, there's methods compareTo, createFromTimestamp and createFromDay, it could be another proposal. I think we are very often create DateTime objects just from timestamp or year-month-day. So we could introduce this methods that could not rely on timelib's parsing, and instead just take numbers directly. Timestamp doesn't need any timelib parsing AFAIK, but YMD certainly does - you need to calculate the actual timestamp according to current timezone, etc. And I think DateTime lack comparing method. For now I can compare DateTime objects only by getting their timestamps, but I though that the idea of DateTime objects can be compared directly, why do you think you can compare only timestamps? -- 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
Re: [PHP-DEV] DateTime improvement
On Mon, 10 Dec 2012, Herman Radtke wrote: On Mon, Dec 10, 2012 at 11:39 AM, Ángel González keis...@gmail.com wrote: On 10/12/12 16:18, Nikita Nefedov wrote: So there had been at least two or three messages (subjects) about DateTime object and everytime there was this problem - people tend to take DateTime object as mutable object and it really is. As long as we know, it's not so good - date is immutable by nature. I don't want to write here why it's so, I will just throw this link: http://www.ibm.com/developerworks/java/library/j-jtp02183/index.html I don't want to change any existing functionality, because some people already use it, but I just wanted to point out that current DateTime class is forcing people to think about it as mutable. My main concerns are DateTime#add() and DateTime#sub(). The problem is - they both change current object and return it. I think we could add methods to DateTime like add() and sub(), let's say plus() and minus(), but they would behave differently in the way that they would return new DateTime objects and won't change current object. That will make it even more inconsistent. Yes, that's horrible - and might not even work with the current design. You have add() and plus() but one changes the object and the other doesn't. If we were going to rewrite php or the DateTime class, it could be a good idea to make those methods (or its equivalents) not modify the object. But I don't think it'd be a win to do such thing now. Another option is to make an ImmutableDateTime class. The DateTime class could actually be changed to inherit the ImmutableDateTime class. The only extensions on the DateTime class would be the mutable methods. I'm not really against that, but we do need to use the Date namespace - so DateTimeImmutable. It might be trickier to do than it sounds though... cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
