Re: RFC - Immutable classes

On 9/4/2016 2:29 PM, Michał Brzuchalski wrote: >> 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. >> > > It could look like in this gist > > https://gist.github.com/brzuchal/e7b721e22a19cca42ec0d1f597a23baf > This is exactly how I meant it, yes. I actually prefer it if the variable just exist in the context instead of passing it as first argument. It's less obvious that it exists but the same could be said about $this. Would it be possible to have this thing just in time instead of automatically created in every mutator function? public mutator function f() { if (condition) { $clone is created; return $clone; } return $this; } PS: I started overhauling the test cases and error messages and will create a PR against your branch soon. I will start with the RFC afterwards. Should I simply edit the RFC in the Wiki or should we manage this somewhere else? -- Richard "Fleshgrinder" Fussenegger

Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc