On Thu, 04 Apr 2013 19:13:54 +0400, 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
Hi,
this is great idea, I thought about it lately.
Though I think it should be called struct like in other other languages.
And it would be very useful if we could declare structs in-place (it's
useful when dealing with some data-proccessing and all you want is just
strong-typing but without the need for declaring a whole new class in a
new file, etc).
But this is a very big feature and I doubt it will get any support :(
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
