Hi Yasuo,
Yes, that looks like interesting idea. I can open another RFC and start
working on that one, if there is a interest for that. Why can't we fit that
into 7.2 ?
Cheers,
2017-01-17 10:12 GMT+01:00 Yasuo Ohgaki :
> Hi Silvio,
>
> On Tue, Dec 13, 2016 at 6:17 PM, Silvio Marijić
> wrote:
Hi Silvio,
On Tue, Dec 13, 2016 at 6:17 PM, Silvio Marijić
wrote:
> After much thinking regarding array in immutable objects I'm thinking of
> revoking this RFC. If someone has some suggestion on that matter now is the
> time, but otherwise my work is done on this one.
>
It may be good to start
Hi!
> Discussion is open for following rfc https://wiki.php.net/rfc/immutability
The RFC says:
> Safe for concurrency.
I'm not sure - what concurrency are you talking about?
> Value objects, DTO's etc. can be easily created.
Value objects can be easily created right now if you follow generic
Hi,
Paul Jones wrote:
On Dec 12, 2016, at 13:36, Andrea Faulds wrote:
Consider that some popular applications of immutability ultimately contain a
reference to something mutable: PSR-7's immutable HTTP message objects point to
mutable streams
Which subverts its overall promise of immutab
Hello,
On 13.12.16 10:17, Silvio Marijić wrote:
> After much thinking regarding array in immutable objects I'm thinking of
> revoking this RFC. If someone has some suggestion on that matter now is the
> time, but otherwise my work is done on this one.
It would be nice if you could summarize the f
After much thinking regarding array in immutable objects I'm thinking of
revoking this RFC. If someone has some suggestion on that matter now is the
time, but otherwise my work is done on this one.
Cheers,
2016-12-12 20:56 GMT+01:00 Paul Jones :
>
> > On Dec 12, 2016, at 13:36, Andrea Faulds wr
> On Dec 12, 2016, at 13:36, Andrea Faulds wrote:
>
> Consider that some popular applications of immutability ultimately contain a
> reference to something mutable: PSR-7's immutable HTTP message objects point
> to mutable streams
Which subverts its overall promise of immutability (and the st
Hi Silvio,
Silvio Marijić wrote:
Discussion is open for following rfc https://wiki.php.net/rfc/immutability
The restriction that immutable properties may only hold immutable values
seems potentially overzealous. Consider that not all immutable classes
will actually be marked as such. Any cod
On 12 December 2016 14:42:11 GMT+00:00, "Silvio Marijić"
wrote:
>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
On 12/12/2016 8:19 PM, Silvio Marijić wrote:
> @Fleshgrinder
>
> My opinion on that subject is still that features are mostly complete but
> I'am willing to find also solution to ease modifying.
> Modify function does not modify object in any way, it will operate on the
> clone of the object and t
@Fleshgrinder
My opinion on that subject is still that features are mostly complete but
I'am willing to find also solution to ease modifying.
Modify function does not modify object in any way, it will operate on the
clone of the object and this was just prototype. Moreover it should be
restricted
On 12/11/2016 5:57 PM, Silvio Marijić wrote:
> Hi,
>
> Discussion is open for following rfc https://wiki.php.net/rfc/immutability
>
> Cheers
>
-1 from my side for all the things previously mentioned. The
copy-on-write topic must be solved along with the introduction of
immutable classes or we e
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_FOR
2016-12-12 15:14 GMT+01:00 Rowan Collins :
> 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
> >m
2016-12-12 15:14 GMT+01:00 Rowan Collins :
> 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
> >m
On 12 December 2016 09:11:17 GMT+00:00, "Silvio Marijić"
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
>$a
@Davey,
There was similar suggestion that $this represents clone of the object. I
think that is a bit vague, and I'am not sure about the 'scope' you refer to
because 'double scoping' could be also a reason to downvote this rfc and it
can lead to confusion in my opinion. I will check HHVM also.
Re
On Sun, Dec 11, 2016 at 7:40 PM, Mathieu Rochette
wrote:
>
>
> On 12/12/2016 01:16 AM, Silvio Marijić wrote:
> > This have occurred to me also, I wanted to separate that into two RFC's,
> > but then how we deal with RFC's that depend on each other?
> well that's just my opinion but I don't think
On 12/12/2016 01:16 AM, Silvio Marijić wrote:
> This have occurred to me also, I wanted to separate that into two RFC's,
> but then how we deal with RFC's that depend on each other?
well that's just my opinion but I don't think they depend on each other,
this rfc seems useful on its own. The "clo
This have occurred to me also, I wanted to separate that into two RFC's,
but then how we deal with RFC's that depend on each other?
2016-12-12 1:03 GMT+01:00 Larry Garfield :
> Assuming this was intended for the list...
>
> On 12/11/2016 05:55 PM, Mathieu Rochette wrote:
>
>> Currently the only "
Assuming this was intended for the list...
On 12/11/2016 05:55 PM, Mathieu Rochette wrote:
Currently the only "unlocked context" for an object is its
constructor. As discussed previously, that is insufficient. For any
non-trivial object (more than 1-3 internal properties) creating a new
one vi
@Larry, first of all thanks for pointing out grammar issues, I will correct
them. Now, regarding cloning of the immutable object, I'm aware of that
issue and I'm not sure if we could even use clone operation for this
purpose, I do have one proposal for that matter, consider example:
immutable clas
2016-12-11 12:57 GMT-04:00 Silvio Marijić :
> Hi,
>
> Discussion is open for following rfc https://wiki.php.net/rfc/immutability
>
> Cheers
>
Hi,
Can you make a pull request? I'd like to comment the patch but it's not
possible to make inline reviews only with a diff uri on github.
On 12/11/2016 10:57 AM, Silvio Marijić wrote:
Hi,
Discussion is open for following rfc https://wiki.php.net/rfc/immutability
Cheers
Some grammar issues:
"After object is constructor" => should be "After the object's
constructor has run".
" If immutable property contains object, to preser
Hi,
Discussion is open for following rfc https://wiki.php.net/rfc/immutability
Cheers
25 matches
Mail list logo
