---------- Forwarded message ---------- From: dor.tchi...@gmail.com Date: Apr 4, 2013 6:19 PM Subject: Re: [PHP-DEV] a couple of thoughts on the DateTime type debate To: Rasmus Schultz <ras...@mindplay.dk> Cc:
I really don't understand the problem. You have a DateTime instance, you manipulate it as you see fit, and output using the format method. Same goes for colors, URLs, and email addresses. You manipulate the instance, and format when you need it displayed. I see no need for more value types, while the current, oop solution works perfectly fine. On Apr 4, 2013 6:14 PM, "Rasmus Schultz" <ras...@mindplay.dk> wrote: I've been pondering this issue for a while now, and I keep reaching the same conclusion, so I'm going to just briefly share what I think. In my opinion, the real issue is not poor design of the DateTime class - it works as you would expect classes and objects to work, in the sense that when you make changes (adding, subtracting, changing the timezone) you're making changes to the instance. I can't help but think that the real underlying issue, is the fact that you really want value-types and not objects/classes for something like this - and we only have a few value-types in php, namely the scalar types (int, string, float, bool) and arrays. If you've ever attempted to build an object-abstraction for other value-types, such as colors, URLs (or routes), e-mail addresses, etc. - you've faced the same issues: when somebody increases the saturation of an RGB color object, do you change the RGB values, or return a new color instance? Questions like this stem from the fact that what you really wanted for something as self-contained as a color or URL, is not an object, but a value-type. I don't tend to like solutions that solve one isolated problem, when the whole class of problems could potentially be address - hearing about another DateTime type makes my skin crawl, in particular because it introduces all manner of issues with current APIs that most likely already depend on the existing DateTime type. Even coming up with a reasonably descriptive (yet practical) name for this class, is difficult - which to me indicates a contrived attempt to extend something that only needs to be extended for technical (as opposed to functional) reasons. Please consider addressing the real underlying issue: the need for value-types. Off the top of my head, I'm thinking this could be addressed by introducing a new keyword for value-types, interchangeable with "class", for example "value". Value-types would work syntactically like classes and objects. But internally they would work like arrays, meaning they are always passed by value. If this could be implemented in such a way that value objects were actually internally implemented as arrays, we would get all the benefits of arrays - mainly that they would be passed by value, but would not physically be copied until modified. It seems to me, that really is precisely the behavior you want for something like a date/time, color, URL, e-mail, etc. - in many frameworks and libraries, this behavior is actually emulated, by using arrays to represent colors, routes, etc., in order to be able to treat them like value-types, but with the enormous downside of having to know which value-type is represented by an array, typically relying on static helper-methods to modify their properties, and with no chance of any IDE support. Just putting that on the table... - Rasmus Schultz
