OOP is not a beginner's concept. I don't want to sacrifice good coding
practices for a better learning curve.
Also, a glance on the manual would reveal that the method returns the same
instance for chaining (which is also debatable, why do we even do that?)
On Apr 4, 2013 7:46 PM, "Rasmus Schultz" <ras...@mindplay.dk> wrote:
> 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...
>
