Hi, this would be basic implementation of 'modify' function which would
operate on cloned object
PHP_FUNCTION(modify)
{
zval *obj,
*properties,
*entry;
zend_long h;
zend_string *key;
if (zend_parse_parameters(ZEND_NUM_ARGS(), "oa", &obj, &properties)
== FAILURE) {
return;
}
ZEND_HASH_FOREACH_KEY_VAL_IND(Z_ARRVAL_P(properties), h, key, entry) {
zval member;
ZVAL_STR(&member, key);
zend_std_write_property(obj, &member, entry, NULL);
zval_ptr_dtor(&member);
} ZEND_HASH_FOREACH_END();
RETVAL_OBJ(Z_OBJ_P(obj));
}
immutable class User{
public $firstname;
public $lastname;
public function __construct($firstname, $lastname){}
public function withFirstName($firstname){
return modify($this, ['firstname' => $firstname]);
}
}
$user = new User('John', 'Doe');
$new = $user->withFirstName('Foo');
Any feedback?
2016-12-12 15:43 GMT+01:00 Silvio Marijić <marijic.sil...@gmail.com>:
>
>
> 2016-12-12 15:14 GMT+01:00 Rowan Collins <rowan.coll...@gmail.com>:
>
>> On 12 December 2016 09:11:17 GMT+00:00, "Silvio Marijić" <
>> marijic.sil...@gmail.com> wrote:
>> >Regarding my proposal above, since copy() would essentially operate
>> >only on
>> >immutable objects, why not put it only there. So you would be able to
>> >make
>> >a call like this one $immutable->copy(array $args); or
>> >$this->copy(array
>> >$args); depending on whether you are inside let's say with* method or
>> >outside of the object.
>>
>> If users of the object can set arbitrary (public) properties this way,
>> then you've thrown away a bunch of the free encapsulation the immutable
>> keyword gave you in the first place. What you get is an enforced
>> copy-on-write, where you can set the properties to whatever state you like,
>> just not using normal object passing semantics. That's very different from
>> what the RFC shows, which are properties which are publicly readable, but
>> whose state is exclusively controlled by the class (and its descendants).
>>
>>
>> PS The rule on this mailing list is too always reply *below* the text
>> you're replying to.
>
>
>
>> I understand that, but I think we'll have to meet in the middle. How
>> would you handle situation where for one little change you have to manually
>> recreate not so trivial object with a lot of arguments ? I don't think that
>> should be a deal breaker for this RFC but I do agree that we should try to
>> find solution to bridge that gap and put that aside in a other rfc.
>>
> --
>> Rowan Collins
>> [IMSoP]
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
> --
> Silvio Marijić
> Software Engineer
> 2e Systems
>
--
Silvio Marijić
Software Engineer
2e Systems
