a couple of thoughts on the DateTime type debate

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?)

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...

After discussing things over the PHP chat on Stack Overflow, I
realized I misread and missed the point.

Good suggestion, you have my +1.

On Fri, Apr 5, 2013 at 11:01 AM, Richard Bradley
Richard.Bradley@softwire.com wrote:

On Thu, Apr 4, 2013 at 12:57 PM, Benjamin Eberlei kontakt@beberlei.dewrote:

structs as in c# don't have methods, however DateTime has them. so
this doesn't work. What you can do is just pass all the data in the
constructor and then don't change it, and you have your value type that is immutable.
It just requires a bit self control.

You're right, struct isn't the right word - "value" is probably more accurate.

Actually "structs" in C# can have methods. They are exactly classes with value type semantics (i.e. pass-by-value, like arrays in PHP).

I think "struct" would be an ideal name for this feature, as this proposal matches the C# implementation very closely, and many people will be familiar with that.

See the "Structs Tutorial" at msdn for a brief summary of structs in C# - http://msdn.microsoft.com/en-us/library/aa288471(v=vs.71).aspx

Richard Bradley
Tel : 020 7485 7500 ext 3230 | Fax : 020 7485 7575

softwire
Sunday Times Best Small Companies 2012 - 6th in the UK
Web : www.softwire.com | Addr : 325 Highgate Studios, 53-79 Highgate Road, London NW5 1TL
Softwire Technology Limited. Registered in England no. 3824658. Registered Office : 13 Station Road, London N3 2SB

--

You are shooting at ants with bazookas ... I don't see a clear path from
an immutable DateTime to C# structs in PHP ...

This seems like a crazy conversation to me, not only is it crazy, it's a
waste of time; I don't see any of the people able to implement it
actually implementing it, and I don't see a vote going in favour of the
idea if there were an implementation.

/me attempts to push the conversation back on track ...

If structs were even somehow interchangeable with "real" arrays, that might
be a really useful side gain:

$white = new Color(1, 1, 1);

$red = $white->r; // it's a struct

$green = $white['r']; // it's an array

$type = $white['__struct']; // => 'Color'

$array = ['r'=>1, 'g'=>1, 'b'=>1, '__struct'=>'Color'];

$blue = $array->b; // it's an array, but it still works like a struct

You see where I'm going with this?

I imagine the implementation could be something along the lines of checking
for the '__struct' key when somebody attempts to use method-call syntax on
an array, invoking the appropriate method with $this referencing the array
you were using.

The rest of the time, a struct, for all intents and purposes, is just an
array.

I'm sure it's a lot more complex than it sounds, but probably simpler than
attempting to "extend" arrays into structs or trying to "hide" the struct
type-name in an internal array property somehow. Being able to juggle the
types by accessing a reserved key might actually be a benefit?

See the "Structs Tutorial" at msdn for a brief summary of structs in C#

• http://msdn.microsoft.com/en-us/library/aa288471(v=vs.71).aspx

Looking at that code sample, yes - that is more or less exactly what I had
in mind.

I take back my last remark - I don't think the similarity in syntax is
confusing; what is confusing, is the way it works now... because there are
certain types that we just naturally think of as being values, not objects,
even if they have object syntax.

I don't know C very well, and I certainly don't know the PHP codebase very
well, but do you think it's feasible to internally piggyback structs on
arrays?

If structs were even somehow interchangeable with "real" arrays, that
might be a really useful side gain:

On Fri, Apr 5, 2013 at 4:01 AM, Richard Bradley <
Richard.Bradley@softwire.com> wrote:

On Thu, Apr 4, 2013 at 12:57 PM, Benjamin Eberlei <kontakt@beberlei.de
wrote:

structs as in c# don't have methods, however DateTime has them. so
this doesn't work. What you can do is just pass all the data in the
constructor and then don't change it, and you have your value type
that is immutable.
It just requires a bit self control.

You're right, struct isn't the right word - "value" is probably more
accurate.

Actually "structs" in C# can have methods. They are exactly classes with
value type semantics (i.e. pass-by-value, like arrays in PHP).

I think "struct" would be an ideal name for this feature, as this
proposal matches the C# implementation very closely, and many people will
be familiar with that.

See the "Structs Tutorial" at msdn for a brief summary of structs in C# -
http://msdn.microsoft.com/en-us/library/aa288471(v=vs.71).aspx

Richard Bradley
Tel : 020 7485 7500 ext 3230 | Fax : 020 7485 7575

softwire
Sunday Times Best Small Companies 2012 - 6th in the UK
Web : www.softwire.com | Addr : 325 Highgate Studios, 53-79 Highgate
Road, London NW5 1TL
Softwire Technology Limited. Registered in England no. 3824658.
Registered Office : 13 Station Road, London N3 2SB