Newsgroups: php.internals,php.internals
Path: news.php.net
Xref: news.php.net php.internals:104764 php.internals:104765
To: internals@lists.php.net,internals@lists.php.net
References: <php.internals-104730@news.php.net>
Message-ID: <d691cba8-c1da-cfdf-7f55-70c7335abad3@gmail.com>
Date: Fri, 15 Mar 2019 21:56:48 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Firefox/52.0 SeaMonkey/2.49.4
MIME-Version: 1.0
In-Reply-To: <php.internals-104730@news.php.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Proposal] Struct Data Types
From: xellisx@gmail.com (Kenneth Ellis McCall)

Kenneth Ellis McCall wrote:
> Hey all,
> 
> I'm looking to get feedback on a RFC I want to propose.
> 
> PHP RFC: Addition of the 'struct' data type.
> 

Hey all,

Hopefully this addresses the questions you had in someway, even if it's 
not a direct answer and might propose other things. Also sorry for the 
brevity.

Immutability:
My initial thought was to have the property list be immutable, such as 
you can't add or remove properties, but could change the value.
Maybe it would be possible to do something like this:

const Acme\MyStruct $myStruct = {
...
};

To make just the instance of the struct be fully immutable.

Other options could be another type, say constStruct (say that ten times 
fast), or maybe add a const hint type (or readonly) to the properties, like:

struct Acme\MyStruct {
    const int id;
}



Access:
I think I'm leaning towards the arrow accessors.


Making it more of class type:
Initial thinking, and why I thought we would need this, is that I would 
like a way to not use class objects for data bags (like that you see 
with entities), since you can abuse classes (and arrays) like this:

class xyz {

};

$a = new xyz();
$a->def = 123;

// Returns 123.
echo $a->def;

While people shouldn't do it, but because they can, they will.

Types hints:
I think having them on the left side would be the best, since it kind of 
matches what we already do.
As for the loosely type properties, I'm kind of on the border on that. I 
really want to have strongly / statically typed hints, so it could 
enforce some better habits. On the other side, for historical 
purposes... Would definitely want to take a consensus on this.


Validation:
I have another item I want to bring up, but don't think it would go over 
well: https://github.com/ellisgl/PHP-RFC-Advanced-Type-Hint-Validors


Array / Class features:
When I wrote, 'resembles a mix of a class and an array' I was thinking 
loosely around the styling, accessing properties and errors.


Copy on Write or pass by reference/value:
I think I'm more with Levi with the "pass by-value with copy-on-write 
semantics", of course, since this is still draft mode, it could go 
another way after further investigation and testing during implementation.