# a couple of thoughts on the DateTime type debate

- Thread: https://externals.io/message/66946
- Original archive: https://news-web.php.net/php.internals/66946
- Started by Rasmus Schultz on 2013-04-04T15:13:54+00:00
- Messages: 16
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #66946 — Rasmus Schultz — 2013-04-04T15:13:54+00:00

URL: https://externals.io/message/66946#66946

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

---

## #66948 — Nikita Nefedov — 2013-04-04T15:44:47+00:00

URL: https://externals.io/message/66946#66948 · In reply to: #66946

On Thu, 04 Apr 2013 19:13:54 +0400, Rasmus Schultz <rasmus@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 :(

---

## #66951 — Rasmus Schultz — 2013-04-04T16:46:22+00:00

URL: https://externals.io/message/66946#66951 · In reply to: #66948

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

---

## #66953 — Madara Uchiha — 2013-04-04T17:03:24+00:00

URL: https://externals.io/message/66946#66953 · In reply to: #66951

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

---

## #66957 — Lazare Inepologlou — 2013-04-04T17:58:52+00:00

URL: https://externals.io/message/66946#66957 · In reply to: #66953

2013/4/4 Madara Uchiha <dor.tchizik@gmail.com>

> OOP is not a beginner's concept. I don't want to sacrifice good coding
> practices for a better learning curve.
>
>
This is interesting. Best practices from other languages, including C#,
Scala etc, have shown that some things are better represented by value
types. Even in PHP, strings are value types, because it is better this
way...

Besides, having to think whether to use a value type or a reference type
does not make anything easier to learn! Value types is an advanced,
post-OOP concept, not targeted to beginners anyway.




> 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?)
> 
>
> > […]
> any
> > […]
> fact
> > […]
> and
> > […]
> DateTime
> > […]
> what
> > […]
> methods
> > […]
> you
> > […]
> implement
> > […]
>

Lazare INEPOLOGLOU
Ingénieur Logiciel

---

## #66964 — Rasmus Schultz — 2013-04-04T22:59:28+00:00

URL: https://externals.io/message/66946#66964

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

value Color
{
    public $r = 1.0;
    public $g = 1.0;
    public $b = 1.0;

    public function __construct($r, $g, $b)
    {
        $this->r = $r;
        $this->g = $g;
        $this->b = $b;
    }

    public function mix(Color $other, $amount)
    {
        $this->r = $other->r * $amount + $this->r * (1 - $amount);
        $this->g = $other->g * $amount + $this->g * (1 - $amount);
        $this->b = $other->b * $amount + $this->b * (1 - $amount);

        return $this;
    }
}

$red = new Color(1, 0, 0);
$blue = new Color(0, 0, 1);
$mix = $red->mix($blue);

Okay, this would probably work - since $this actually refers to an array
inside the `mix()` method scope, the array would be copied as soon as the
first assignment is made... but I can see how this is starting to look
rather confusing, given that it clashes with existing syntax and how actual
objects currently work...

Probably not a good idea after all...

Though I still wish there was some better way to handle value-types...


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.

---

## #66966 — Richard Bradley — 2013-04-05T08:01:45+00:00

URL: https://externals.io/message/66946#66966 · In reply to: #66964

> On Thu, Apr 4, 2013 at 12:57 PM, Benjamin Eberlei <kontakt@beberlei.de>wrote:
>
> > […]
>
> 
>
> 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

---

## #66967 — Madara Uchiha — 2013-04-05T08:31:06+00:00

URL: https://externals.io/message/66946#66967 · In reply to: #66966

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:
> > […]
>
> 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

---

## #66968 — Joe Watkins — 2013-04-05T08:58:46+00:00

URL: https://externals.io/message/66946#66968 · In reply to: #66967

> 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:
> > […]

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

---

## #66981 — Rasmus Schultz — 2013-04-05T12:50:20+00:00

URL: https://externals.io/message/66946#66981 · In reply to: #66966

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

> > […]
> that is immutable.
> > […]
> 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

---

## #66982 — Rasmus Schultz — 2013-04-05T13:02:18+00:00

URL: https://externals.io/message/66946#66982 · In reply to: #66981

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?





> > […]
> - 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:
>
> > […]

---

## #66984 — Richard Bradley — 2013-04-05T13:29:54+00:00

URL: https://externals.io/message/66946#66984 · In reply to: #66982

> 
> > […]
>
> Looking at that code sample, yes - that is more or less exactly what I had in mind.
>
> 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?

Are you asking me, or the list?

If me: I don't know. I suspect it would be, but I think Joe Watkins nailed it in his
recent email on this thread:
  "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."

I'm not going to implement it. Will you be implementing it? I suspect not, as you said "I don't know C very well".

I think it does look like a nice syntax extension, but I don't think it'll end up in PHP.

I only waded in to correct someone who said that structs in C# don't have methods :-)



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

---

## #66985 — ALeX — 2013-04-05T14:00:55+00:00

URL: https://externals.io/message/66946#66985 · In reply to: #66982

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

One thing I do not like about the "struct as array" is that you can
create "invalid" structs, in classes you could have all variables
private and check during set, but not here: "$array = ['r'=>1,
'b'=>'yes', '__struct'=>'Color'];".

Hmm... just an thought: why not make struct almost like a class except
that $this is a copy (on write) - modifying and returning $this would
be a new instance of that struct/class. That would give you
public/private/static/variables/methods/interfaces/..., but it would
lead to another type.
Or use a keyword to the class, e.g. "autoclone class Color {...", and
not the new name struct -> it would be clear that struct/classes use
the same namespace.
You maybe even could do "autoclone class DateTimeImmutable extends
DateTime {}" to create the immutable version. (I see no reason why an
"normal" class could not be extended into autoclone, but useless in
most cases though)

On the other hand, I would just use an array. (without any "magic"
like methods on structs, yes you would have to write plain functions
and not use OOP like methods).

---

## #66988 — Rasmus Schultz — 2013-04-05T14:35:03+00:00

URL: https://externals.io/message/66946#66988 · In reply to: #66985

> On the other hand, I would just use an array. (without any "magic"
> like methods on structs, yes you would have to write plain functions
> and not use OOP like methods).

Yeah, that's what people are doing right now - the problem with that, is
you have the class-name referenced on every call, e.g.:

abstract class Color
{
    public static function create($r, $g, $b)
    {
        return array('r'=>$r, 'g'=>$g, 'b'=>$b);
    }

    public static function mix(array $base, array $mix, $amount)
    {
        return array(
            'r' => $base['r'] * $amount + $mix['r'] * (1 - $amount),
            'g' => $base['g'] * $amount + $mix['g'] * (1 - $amount),
            'b' => $base['b'] * $amount + $mix['b'] * (1 - $amount),
        );
    }
}

$red = Color::create(1, 0, 0);

$green = Color::create(0, 1, 0);

$mix = Color::mix($red, $green, 0.5);

The problem with this approach, is you have a static reference to the
Color-class for every method-call.

With structs you can accomplish the same thing without littering your code
with static class-references.

With pseudo-types implemented as arrays in this way, you also can't hope to
have IDE support or static analysis, e.g. for properties...





> > […]
> checking
> > […]
> on
> > […]
> array
> > […]
>
> One thing I do not like about the "struct as array" is that you can
> create "invalid" structs, in classes you could have all variables
> private and check during set, but not here: "$array = ['r'=>1,
> 'b'=>'yes', '__struct'=>'Color'];".
>
> Hmm... just an thought: why not make struct almost like a class except
> that $this is a copy (on write) - modifying and returning $this would
> be a new instance of that struct/class. That would give you
> public/private/static/variables/methods/interfaces/..., but it would
> lead to another type.
> Or use a keyword to the class, e.g. "autoclone class Color {...", and
> not the new name struct -> it would be clear that struct/classes use
> the same namespace.
> You maybe even could do "autoclone class DateTimeImmutable extends
> DateTime {}" to create the immutable version. (I see no reason why an
> "normal" class could not be extended into autoclone, but useless in
> most cases though)
>
> On the other hand, I would just use an array. (without any "magic"
> like methods on structs, yes you would have to write plain functions
> and not use OOP like methods).

---

## #66989 — Rasmus Schultz — 2013-04-05T14:40:32+00:00

URL: https://externals.io/message/66946#66989 · In reply to: #66985

> why not make struct almost like a class except
> that $this is a copy (on write) - modifying and returning $this would
> be a new instance of that struct/class. That would give you
> public/private/static/variables/methods/interfaces/..., but it would
> lead to another type.

As said, I don't know the innards of the codebase, but that sounds more
"hacky" to me somehow? - other value-types in PHP such as array already
have the semantics we're looking for in value-types, whereas
classes/objects do not. I don't know how it's implemented though.

> Or use a keyword to the class, e.g. "autoclone class Color {...", and
> not the new name struct -> it would be clear that struct/classes use
> the same namespace.

Other languages use the term "struct" - I don't think there's any reason to
invent new terminology for something that is already well-known and has
established terminology?





> > […]
> checking
> > […]
> on
> > […]
> array
> > […]
>
> One thing I do not like about the "struct as array" is that you can
> create "invalid" structs, in classes you could have all variables
> private and check during set, but not here: "$array = ['r'=>1,
> 'b'=>'yes', '__struct'=>'Color'];".
>
> Hmm... just an thought: why not make struct almost like a class except
> that $this is a copy (on write) - modifying and returning $this would
> be a new instance of that struct/class. That would give you
> public/private/static/variables/methods/interfaces/..., but it would
> lead to another type.
> Or use a keyword to the class, e.g. "autoclone class Color {...", and
> not the new name struct -> it would be clear that struct/classes use
> the same namespace.
> You maybe even could do "autoclone class DateTimeImmutable extends
> DateTime {}" to create the immutable version. (I see no reason why an
> "normal" class could not be extended into autoclone, but useless in
> most cases though)
>
> On the other hand, I would just use an array. (without any "magic"
> like methods on structs, yes you would have to write plain functions
> and not use OOP like methods).

---

## #66993 — David Muir — 2013-04-06T03:15:36+00:00

URL: https://externals.io/message/66946#66993 · In reply to: #66989

> > […]
> 
> As said, I don't know the innards of the codebase, but that sounds more
> "hacky" to me somehow? - other value-types in PHP such as array already
> have the semantics we're looking for in value-types, whereas
> classes/objects do not. I don't know how it's implemented though.
> 
> > […]
> 
> Other languages use the term "struct" - I don't think there's any reason to
> invent new terminology for something that is already well-known and has
> established terminology?
> 
> 
> 
> 
> 
> > […]

Isn't this basically the way classes were originally implemented in php4?

Cheers,
David