with upstream
master couple days ago, might be a reason.
I would appreciate if anyone could give me hand on this ?
On Feb 26, 2018 1:48 PM, "Silvio Marijić" wrote:
> Currently the build is failing in some parts of the codebase that are
> obviously affected in some way.
>
quot;value" is going
> to bring more BC breaks then "immutable".
>
> On Sun, Feb 25, 2018 at 8:02 PM Paul Jones wrote:
>
>>
>>
>> > On Feb 25, 2018, at 12:59, Silvio Marijić
>> wrote:
>> >
>> > Here is link to tweet https://t
Here is link to tweet
https://twitter.com/SilvioMarijic/status/965564630071300096
2018-02-25 19:53 GMT+01:00 Paul Jones :
>
>
> > On Feb 25, 2018, at 11:29, Silvio Marijić
> wrote:
> >
> > I had discussion on Twitter regarding semantics of keyword 'immutable'
I had discussion on Twitter regarding semantics of keyword 'immutable'.
I am considering now to replace keyword 'immutable' with 'value'.
How would you compare those two, which one is more suitable here?
On Feb 25, 2018 6:24 PM, "Silvio Marijić" wrote:
8 at 13:47, Silvio Marijić
wrote:
> In addition to your question about impact on the performance, there is
> none.
Have you actually measured that there is no performance impact, or is
that an assumption from what affect the code should have?
cheers
Dan
cally.
>
> > I agree that it would be better to pass by value but I am not sure how
> would
> > that impact the way we currently manage objects in object store.
>
> If we both agree it would be the better way, why not draft an RFC for
> it and find someone who knows how to implement it?
>
> Regards, Niklas
>
--
Silvio Marijić
Software Engineer
SMSGlobal
n't be immutable.
>
> I like the RFC, but generally I think value objects that are passed
> by-value instead of by-reference are the better way to solve the
> problem.
>
> Regards, Niklas
>
--
Silvio Marijić
Software Engineer
SMSGlobal
object.
>
> - Disable the constructor after it has been called, so the object cannot
> be "re-constructed" in place.
>
> * * *
>
> That's all I can think of for now. Thanks for putting this together.
>
>
> --
> Paul M. Jones
> pmjo...@pmjones.io
In addition to your question about impact on the performance, there is
none. As there is no special tracking of those references just control
check when you try to write by reference.
2018-02-23 14:40 GMT+01:00 Silvio Marijić :
> Hi Rowan,
>
> I agree that RFC needs a bit refinement whi
eally appreciate it.
Regards,
2018-02-22 10:57 GMT+01:00 Rowan Collins :
> On 20 February 2018 at 11:25, Nikita Popov wrote:
>
> > On Tue, Feb 20, 2018 at 12:20 PM, Silvio Marijić <
> marijic.sil...@gmail.com
> > >
> > wrote:
> >
> > > Hi,
> > &g
). I'll be more then happy to answer all questions.
--
Silvio Marijić
Software Engineer
SMSGlobal
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 Ma
https://leanpub.com/sn1php
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Silvio Marijić
Software Engineer
2e Systems
ould be) at the first place. Value can imply or create confusion with
Value Objects, on the other hand immutable clearly states what it is.
Cheers,
2016-12-12 19:44 GMT+01:00 Fleshgrinder :
> On 12/11/2016 5:57 PM, Silvio Marijić wrote:
> > Hi,
> >
> > Discussion is open for fo
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->wit
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 pu
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 pu
t's say with* method or
outside of the object.
2016-12-12 6:58 GMT+01:00 Davey Shafik :
> 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
and
> leaves major gaps in place is a poor RFC, and I would expect to be
> justifiably voted down.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Silvio Marijić
Software Engineer
2e Systems
ll submit PR, have you found bug or?
Cheers
2016-12-11 23:35 GMT+01:00 Marcio Almada :
>
> 2016-12-11 12:57 GMT-04:00 Silvio Marijić :
>
>> Hi,
>>
>> Discussion is open for following rfc https://wiki.php.net/rfc/immut
>> ability
>>
>> Cheers
>>
>
Hi,
Discussion is open for following rfc https://wiki.php.net/rfc/immutability
Cheers
Hi Dan,
Thanks for feedback. I'm not sure about RFC either, but it is a new feature
sort of.
Cheers,
Silvio.
On Dec 6, 2016 6:48 PM, "Dan Ackroyd" wrote:
> On 6 December 2016 at 14:59, Silvio Marijić
> wrote:
>
> > https://wiki.php.net/rfc/soap_get_location
>
Here is RFC open for discussion.
https://wiki.php.net/rfc/soap_get_location
2016-12-06 14:48 GMT+01:00 Silvio Marijić :
> Hi,
>
> I've submited pull request to add a __getLocation to SoapClient.
> Motivation for that was to add a practical way of getting current location
2016-12-06 15:47 GMT+01:00 Silvio Marijić :
> Here is RFC open for discussion.
>
> https://wiki.php.net/rfc/soap_get_location
>
> 2016-12-06 14:48 GMT+01:00 Silvio Marijić :
>
>> Hi,
>>
>> I've submited pull request to add a __getLocation to SoapCl
Hi,
I've submited pull request to add a __getLocation to SoapClient. Motivation
for that was to add a practical way of getting current location from
SoapClient.
https://github.com/php/php-src/pull/2232
Any feedback?
Cheers.
--
Silvio Marijić
Software Engineer
2e Systems
rty type-hints, as these are all essentially about defining and
>> enforcing constraints and making assertions about the state of a model.
>>
>> I feel that this feature is a poor substitute for accessors, for example,
>> because this feature really applies only to immutab
table, persist that to
> storage, and then on load of historical data you want a read-only object to
> expose to application code. That object will still have an identity,
> however.
>
> I'm actually working on such a library on the side right now.
>
> --Larry Gar
@Paul,
I understand that immutable doesn't automatically apply value object. Can
you give us some examples where immutable object should have identity?
Cheers
On Nov 16, 2016 4:48 PM, "Paul Jones" wrote:
>
> > On Nov 16, 2016, at 07:57, Silvio Marijić
> wrote:
> &
> Cheers,
>
> Stephen
>
> > On 16 Nov 2016, at 20:57, Silvio Marijić
> wrote:
> >
> > Hi,
> >
> > To anyone who is interested in this RFC. What do you think what behavour
> we
> > should have when you try to compare two immutable object
@Ryan which is existing behaviour in language. Because object is immutable
I don't think we should care anymore about 'references' instead maybe we
could focus on value that object represents.
2016-11-16 15:29 GMT+01:00 Ryan Pallas :
>
>
> On Wed, Nov 16, 2016 at 6:57 AM,
$a1 === $a2
If we treat those objects as values then this should return true. But then
again there might be some confusion because then two operators are doing
the same thing. Maybe throw an error ? Suggestions ?
Cheers.
--
Silvio Marijić
Software Engineer
2e Systems
>
> cheers,
> Derick
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Silvio Marijić
Software Engineer
2e Systems
nt proposal, or has
> the RFC page been updated with the latest CoW-based recommendation?
>
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Silvio Marijić
Software Engineer
2e Systems
I agree. Will add this feature to RFC also
Cheers
On Sep 10, 2016 8:02 PM, "Marco Pivetta" wrote:
> On Sat, Sep 10, 2016 at 7:49 PM, Niklas Keller wrote:
>
>> 2016-09-10 19:41 GMT+02:00 Silvio Marijić :
>>
>> > @Fleshgrinder,
>> >
>> >
@Fleshgrinder,
While I'm not sure at the moment about CoW, I can agree that we should add
immutable keyword as a interface modifier to make sure all classes
implementing must be immutable.
On Sep 10, 2016 12:55 PM, "Fleshgrinder" wrote:
> So? Where are we now? CoW is definitely doable and I pers
@Fleshgrinder,
Well since implementation is still underway I think the best ways would be
to wait untill we finish implementation, and then we all can do the review
to make sure everything is in place.
2016-09-09 23:16 GMT+02:00 Fleshgrinder :
> On 9/9/2016 10:02 PM, Silvio Marijić wr
It will be patched before this RFC goes into official discussion.
2016-09-09 22:01 GMT+02:00 Silvio Marijić :
> @Fred
>
> Thanks for taking interest. I still need to fully patch reflection
> extension for this. We had more important discussions in the past two weeks.
>
>
y become unwieldy for classes with a large number
> of properties.
>
> Regards,
> - Fred
>
>
> On Aug 8, 2016, at 3:31 AM, Silvio Marijić
> wrote:
>
>
> Hi,
>
> I would need your help with one idea. I'm working on one RFC that I'm would
> like to
ecifically say that the entry *isnt* in $_SERVER, and
> must be fetched via apache_request_headers()?
>
>
>
> Sent from my iPhone
>
> > On 10 Sep 2016, at 00:15, Silvio Marijić
> wrote:
> >
> > @Stephen
> >
> > Yes, this change does not remove
16, at 21:30, Silvio Marijić
> wrote:
> >
> > @Niklas
> > We are already supporting Basic and Digest and Bearer and MAC are used
> > widely as a form of token authorization.
> >
> > 2016-09-09 14:37 GMT+02:00 Niklas Keller :
> >
> >> 2016-09-0
@Niklas
We are already supporting Basic and Digest and Bearer and MAC are used
widely as a form of token authorization.
2016-09-09 14:37 GMT+02:00 Niklas Keller :
> 2016-09-09 14:17 GMT+02:00 Silvio Marijić :
>
>> Came across this issue https://bugs.php.net/bug.php?id=72915 and go
e the changes I made:
https://github.com/php/php-src/compare/master...smarijic:php_auth_bearer
Cheers,
Silvio.
--
Silvio Marijić
Software Engineer
2e Systems
@Christoph
I get the nostalgia :)
I think that *zend_compare_symbol_tables* compares only hash tables whether
they contain same properties regardless of the values.
2016-09-07 20:44 GMT+02:00 Silvio Marijić :
> @Fleshgrinder
>
> I will make changes that if immutable objects are being
@Fleshgrinder
I will make changes that if immutable objects are being compared that they
will be compared by value rather then hash
On Sep 7, 2016 8:27 PM, "Christoph M. Becker" wrote:
> On 07.09.2016 at 20:11, Fleshgrinder wrote:
>
> > On 9/7/2016 8:57 AM, Michał Brzuchalski wrote:
> >
> >> AFA
t;>
>>>>> How does one know which property is to be mutated in the __with
>>>> method?
>>>> You should also not underestimate the performance hit and the
>>>> branching
>>>> since you only want to change the properties that changed based on
>>>> the
>>>> data from the passed array.
>>>>
>>>> I have a third proposal after giving this some more thought.
>>>> Inspired by
>>>> Rust's approach to mark mutation explicitly.
>>>>
>>>>final immutable class ValueObject {
>>>>
>>>> public $value;
>>>>
>>>> public mutator [function] withValue($clone, $value): static {
>>>>$clone->value = $value;
>>>> }
>>>>
>>>>}
>>>>
>>>>
>>>> Providing `mutator` | `mut` keyword as method modifier sounds liek
>>> a good
>>> idea,
>>> althought passing `$clone` parameter as first additional param could
>>> break
>>> method declaration and would be misleading.
>>>
>>> Assuming mutator method is designed to return mutated clone of
>>> immutable
>>> object
>>> having `$clone` variable could be handled internally without breaking
>>> method declaration.
>>>
>>> Such variable could be unlocked while in mutator method and locked on
>>> return.
>>> I was thinking about additional check if such mutator returns
>>> `$clone` but
>>> not `$this`
>>> but I don't see the need of it - assuming there is no what to change
>>> in some
>>> circumstances ther would be also possible to return `$this`.
>>>
>>> The return type declaration `self` could increase readability, but
>>> should
>>> not be required,
>>> as some developers doesn't already use return types.
>>>
>>>
>>> A mutator function always receives the mutable clone as first
>>>> argument
>>>> and always returns that one. Users can have a return but they must
>>>> return the clone (hence the static return type declaration).
>>>>
>>>>$vo1 = new ValueObject(1);
>>>>$vo2 = $vo1->withValue(2);
>>>>
>>>> Calls are of course without the clone as it is handled by the
>>>> engine.
>>>> There is no special branching necessary and no performance hit at
>>>> all
>>>> while the logic is kept in the place where it is required.
>>>>
>>>> --
>>>> Richard "Fleshgrinder" Fussenegger
>>>>
>>>>
>>>>
>>
>>
>>
>> --
>> regards / pozdrawiam,
>> --
>> Michał Brzuchalski
>> brzuchalski.com <https://brzuchalski.com/>
>>
>
>
--
Silvio Marijić
Software Engineer
2e Systems
Ok, I have some time also so we can together try to write some initial
implementation of that.
2016-09-07 14:10 GMT+02:00 Michał Brzuchalski :
> Silvio,
>
> I can try with it tommorow, we'll see about that.
>
>
> 2016-09-07 14:05 GMT+02:00 Silvio Marijić :
>
>&
cator for changing object in context of newly
> created clone is the best solution. The keyword for it isn't chosen yet, we
> may discuss it or even vote for it. For now we can call it anyway while
> keeping in mind it may change during voting.
>
>
>
> 2016-09-07
d this then mean that
> such a method could modify the object itself, rather than the clone?
>
> Cheers
>
> Stephen
>
> > On 7 Sep 2016, at 17:09, Mathieu Rochette wrote:
> >
> >
> >
> > On 07/09/2016 11:28, Silvio Marijić wrote:
> >> Hi Stephen,
@Mathieu,
Object can not be modified neither internally or externally, question is if
you clone object where should we allow modification of cloned object
On Sep 7, 2016 12:13 PM, "Mathieu Rochette" wrote:
>
>
> On 07/09/2016 11:05, Stephen Reay wrote:
>
>> (Sorry for any dupes, sent from wrong
And also Fleshgrinder made a good point about comparing two immutable
objects. They should be compared based on value, not on identity.
2016-09-07 11:28 GMT+02:00 Silvio Marijić :
> Hi Stephen,
>
> Cloning is disabled at the moment in implementation because you would end
> up with a
gt;> >>
> >> final immutable class ValueObject {
> >>
> >> public $value;
> >>
> >> public function __construct($value) {
> >> $this->value = $value;
> >> }
> >>
> >> public function withValue($value) {
> >> $this->value = $value;
> >> }
> >>
> >> }
> >>
> >> class A {
> >>
> >> public $vo;
> >>
> >> public function __construct(ValueObject $vo) {
> >> $this->vo = $vo;
> >> }
> >>
> >> }
> >>
> >> class B {
> >>
> >> public $vo;
> >>
> >> public function __construct(ValueObject $vo) {
> >> $this->vo = $vo;
> >> }
> >>
> >> }
> >>
> >> $vo = new ValueObject(1);
> >>
> >> $a = new A($vo);
> >> $b = new B($vo);
> >>
> >> var_dump($a->vo === $b->vo); // bool(true)
> >>
> >> $a->vo->withValue(2);
> >>
> >> var_dump($a->vo === $b->vo); // bool(false)
> >>
> >> $a->vo->withValue(1);
> >>
> >> var_dump($a->vo === $b->vo); // bool(true)
> >>
> >> // :)
> >>
> >> ?>
> >>
> >> --
> >> Richard "Fleshgrinder" Fussenegger
> >>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Silvio Marijić
Software Engineer
2e Systems
nce there's no extra keywords. Is that
> sufficiently obvious for developers? I fear not.
>
> Also, would the above still allow for custom clone() implementations on an
> immutable object or no? I' not sure off hand which I'd prefer, honestly...
>
> Another note: This would preclude "externally immutable" objects, eg, ones
> that can compute and internally cache a value but are still effectively
> immutable as the outside world sees them. That's probably acceptable since
> the manual way is still available, but I thought it worth calling out.
>
> I definitely like any of these options better than an explicit user-facing
> lock/unlock mechanism, as that's begging for abuse, confusion, and
> inconsistency.
>
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Silvio Marijić
Software Engineer
2e Systems
Michal I'm talking about __clone() callback after clone operation. But I
agree with you about syntax part.
2016-09-02 16:46 GMT+02:00 Michał Brzuchalski
:
> 02.09.2016 16:29 "Larry Garfield" napisał(a):
> >
> > On 09/02/2016 09:06 AM, Silvio Marijić wrote
Basically I'm concerned about __clone() since you can not pass parameters
2016-09-02 16:44 GMT+02:00 Silvio Marijić :
> Hi Larry,
> I'm aware of that but we do have make some strong constraints there
> otherwise we are undermining the strong guarantee of immutability. I wou
that look like.
If you guys have some suggestions, that would be great.
2016-09-02 16:27 GMT+02:00 Larry Garfield :
> On 09/02/2016 09:06 AM, Silvio Marijić wrote:
>
>> Well at the moment expection is thrown in case when you try to clone
>> immutable object. But you do se
allow cloning, throw in __clone.
>
> Best,
> André
>
>
> >
> > Best,
> > Silvio.
> >
> > 2016-09-02 4:23 GMT+02:00 Michał Brzuchalski :
> >
> >> Firstly, thanks for your interest.
> >> My answers are inline.
> >>
> >>
2/2016 04:23 AM, Michał Brzuchalski wrote:
> > Firstly, thanks for your interest.
> > My answers are inline.
> >
> > 2016-09-01 23:48 GMT+02:00 Mathieu Rochette :
> >
> >>
> >> On 09/01/2016 09:12 PM, Fleshgrinder wrote:
> >>> On 9/1/2016 3:49
:
> Firstly, thanks for your interest.
> My answers are inline.
>
> 2016-09-01 23:48 GMT+02:00 Mathieu Rochette :
>
> >
> >
> > On 09/01/2016 09:12 PM, Fleshgrinder wrote:
> > > On 9/1/2016 3:49 PM, Silvio Marijić wrote:
> > >> Hi Andre,
> &g
n writing RFC if you have
> karma
> > could help us very much.
>
>
> I would also like to contribute to help make this RFC happen, anything
> that needs help on in terms of doc or rfc wiki?
>
>
> Best,
> André (andrerom)
--
Silvio Marijić
Software Engineer
2e Systems
Hi Internals,
I would like to create RFC for immutability in PHP which has gone trough
couple of discussions, so I need RFC Karma for that. Michal Brzuchalski and
I will be authors and we will implement it.
Best regards,
Silvio Marijic
--
Silvio Marijić
Software Engineer
2e Systems
@Fleshgrinder, Thanks, every help is welcome.
2016-08-08 18:44 GMT+02:00 Fleshgrinder :
> On 8/8/2016 5:00 PM, Silvio Marijić wrote:
> > It's great that you are up of this.
> > I think it will be great to see this one in action.
> >
> > I agree that we should s
arting from
> Immutable because it's base point to toher two keywords.
> Whole idea needs refreshing discussion to clarify idea so it can success.
>
> 2016-08-08 15:23 GMT+02:00 Silvio Marijić :
>
>> @Michal Would you consider cooperating on implementing immutable and
>
e
> to implement immutable and sealed, AFAIK I had problems with OPcache
> enabled, you need to remember to run every test after compile with opcache
> enabled in CLI.
>
> 2016-08-08 15:00 GMT+02:00 Silvio Marijić :
>
>> @Michal, well no I did read it. I see that there is not muc
= new Email;
>>
>> it will be a super global immutable instance of Email.
>>
>
> I think you've missunderstood concept of immutable classes.
>
>
> --
> pozdrawiam
> --
> Michał Brzuchalski
>
--
Silvio Marijić
Software Engineer
2e Systems
Btw, I was not aware that there was already conversation on immutable
classes.
2016-08-08 14:31 GMT+02:00 Silvio Marijić :
> I see your standpoint, but I think it could cause confusion because of
> final classes. I think "immutable" is more suited here.
> What I try to a
class midifier rather than proprty modifier
> keyword.
>
> regards,
> --
> Michał Brzuchalski
>
> 2016-08-08 12:31 GMT+02:00 Silvio Marijić :
>
>> Hi,
>>
>> I would need your help with one idea. I'm working on one RFC that I'm
>> would
>
s are needed:
1. Child class that extends immutable class must be defined as immutable
also.
2. If property on immutable class contains object, it must be instance
of immutable class.
3. You can not have immutability per property, it either whole class or
none.
Thank you all in advance.
--
Silvio Marijić
Software Engineer
2e Systems
67 matches
Mail list logo
