---------- Forwarded message ----------
From: dor.tchizik@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 rasmus@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.
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