On 09-01-2020 17:52, Andreas Hennings wrote: > On Thu, 9 Jan 2020 at 16:31, Nikita Popov <nikita....@gmail.com> wrote: > >> On Thu, Jan 9, 2020 at 4:06 PM Rowan Tommins <rowan.coll...@gmail.com> >> wrote: >> >> An argument could be made that $this does also specify a certain contract >> to the caller: That the API may be used fluently or not without change in >> functionality. That is >> >> $foo->setBar(); >> $foo->setBaz(); >> >> must be strictly equivalent to >> >> $foo >> ->setBar() >> ->setBaz() >> ; >> >> The same is not the case for a plain "static" type. In fact, I think that >> for all other uses of "static" outside of fluent interfaces, not using the >> return value would be a programming error. >> >> But still, this kind of contract is not a type-system contract, and I'm not >> sure it's a good idea to mix other types of API contracts into the type >> system in this fashion. >> > > We currently don't have another "system" where this kind of info could be > specified.
How about: public fluent function doWhatever(): static Perhaps this could be introduced at some point in the future to enforce returning $this. > And in this case, $this also implies static, so if we would use whichever > other system to specify $this, the type hint "static" would become > redundant. > > "@return $this" is common in phpdoc (*) since a while, and so far I have > not seen any problems with it. > > If we ask "where does this lead?", one natural next step might be to > specifically say that the return type is the same type, but NOT $this. > So, a promise that we really get a new object which we can modify without > changing the original object. > > I don't know how we would express this. Perhaps ": clone", but this would > be too specific imo, because whether it is a clone is an implementation > detail. Maybe ": new" ? Regards, Dik Takken -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
