Is it a really big feature if it's just syntactic sugar and internally
stored as an array? say:
struct Color
{
public $r = 1.0;
public $g = 1.0;
public $b = 1.0;
}
Stored internally this might be something like:
array('__type'=>'Color', 'r'=>1.0, 'g'=>1.0, 'b'=>1.0)
Have you worked extensively with DateTime or other value-as-object types?
$today = new DateTime();
$yesterday = $today->modify('-1 day');
echo "today: " . $today->format('Y-m-d') . "\n";
echo "yesterday: " . $yesterday->format('Y-m-d');
Code like this is a major mind-boggle to most programmers - it's not by any
means obvious from reading this code that $yesterday and $today are in fact
references to the same object, and the output of this script is the same
date, twice.
Most programmers automatically think of "atomic" things like date/time and
color as being values, and it's easy (even for experienced developers) to
make mistakes. In my own code, for example, constructors that take DateTime
instances as arguments usually have to safeguard by doing something like
this:
public function __construct(DateTime $begin, DateTime $end)
{
$this->begin = clone $begin;
$this->end = clone $end;
}
This makes redundant copies of objects in every instance, which isn't
optimal - but enables code like this to actually do what you expect:
$date = new DateTime();
$week = array();
for ($i=0; $i<7; $i++) {
$week[] = new Day($date);
$date->add('P1D');
}
if the Day constructor doesn't clone $date, you have problems - that's what
started the debate about a new DateTime type in the first place, I think?
existing DateTime is fine, if what you want is a timestamp you can
manipulate for reasons *other* than using the resulting value, e.g. for
printing out successive dates - as soon as you want to do something other
than using the immediate value contained in the object, trouble's a-brewin'.
a new DateTime-type would solve that by having the add() and sub() methods
clone internally - but I can already do that by extending DateTime myself
(as countless frameworks and libraries have done) with all the same
problems in terms of API issues and expected behavior. (in cases where you
do expect the internal value to change.)
as said, it only addresses the problem for DateTime, which is just one
isolated example of natural value-types represented as dysfunctional
objects.
why not address the real issue, which is the lack of value-types?
other languages have them for the same reasons.
had we had value-types at the time, no one would have thought to implement
DateTime as an object...
