2020-07-11 23:24 GMT, Rowan Tommins <rowan.coll...@gmail.com>: > On 11 July 2020 22:47:21 BST, "Olle Härstedt" <olleharst...@gmail.com> > wrote: >>You're misunderstanding. :) Yes, it should be shared, but not with the >>same access level as the owner. If a dependent class closes the >>connection it will cause spooky-action-at-a-distance somewhere else in >>the program. > > > I think that particular example is solved adequately by destructors: if you > know you hold the last reference to an object, you can unset() that > reference and the destructor will fire. > > You'd only need the ability to "unfreeze" an object if you were going to > mutate it and then carry on using it. > > >> Sorry, it's related to refcount as ownership checking > > > I still don't think those concepts map well. If you store two references to > an object in an array, and then unset one of them at random, does it make > sense to say the remaining reference "owns" that value, because the object > now has a refcount of one?
Well, yes, to do it properly you'd have to make sure the owner remains in scope longer than the borrower. Otherwise you're "leaking" ownership. :) > As I understand it, ownership in Rust implies not just the *right* to free > something, but the *obligation* to do so. That only works if ownership is > explicitly assigned, rather than being a side effect of other references > being released. That's due to move semantics. You can have benefit of ownership and uniqueness without having move. > Thinking about destructors, a better description of how PHP currently works > might be that the owner of an object is the object itself, and the refcount > is a count of how many times it has been borrowed. So once the constructor > completes, all we can say is that there is at least one "borrowed" reference > somewhere in the code; once that stops being true, the "owner" is notified, > and runs the code in the destructor. > > > You could create a wrapper object and have a way to check that its > destructor had been called - anything from setting a global variable to > holding a WeakRef and calling its valid() method - but if something *does* > hold onto a reference, there's not much you can do about it. > > I can't think of a scenario where the code that wants to "own" the object > wouldn't end up equivalent to either full immutability (don't mutate it > after initialisation because you can't guarantee yours is the only > reference) or an optimised copy-on-write (mutate if you happen to have the > last reference, otherwise clone). It would be better for the language to > implement those in a user-friendly way than exposing the implementation > details of refcounting. Yeah, I guess. :( In the end I need uniqueness (non-aliasing) to finish my series of patches about typestate and type-safe builders to Psalm, but I guess I can live without any runtime representation of this, or just suffer the hack I already did with zval dump. Thanks for the feedback! > Regards, > > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
