On Tue, Mar 25, 2025, at 19:51, Larry Garfield wrote:
> On Tue, Mar 25, 2025, at 6:59 AM, Rob Landers wrote:
>
> >> When I say module scope, I'm referring to something along the lines that Arnaud
> >> and I were exploring a while back. tldr, "cluster of files with a common namespace root, which
> >> can get loaded together." It was mostly about performance, but did offer module-private as
> >> well, with some nice potential. At the moment it's stalled out on "there's nasty
> >> hard edge cases and we're not sure if it's worth it" concerns.
> >>
> >> Concept brain dump here: https://github.com/Crell/php-rfcs/blob/master/modules/spec-brainstorm.md
> >> Code exploration from Arnaud here: https://github.com/arnaud-lb/php-src/pull/10
> >>
> >> Still well short of RFC state, of course, but provided for context.
> >
> > My email has been broken for a few days, so sorry for the late response...
>
> No worries, I'm about to leave town myself. :-)
>
> >> In this case, I am not seeing what the nesting gets you. Making Destination a normal
> >> class doesn't hurt anything here, does it?
> >
> > I wasn't intending to write a definitive example, just to illustrate
> > it. A better example might be a lazy cache, using hooks to notify the
> > outer class it has possibly been updated:
> >
> > (note this is using the new syntax, but this syntax is NOT currently
> > reflected in the RFC text, yet)
> >
> > namespace Caching;
> >
> > class Cache {
> > private array $items = [];
> > private array $dirty = [];
> >
> > public function getItem(string $key): CacheItem {
> > return $this->items[$key] ?? ($this->items[$key] = new
> > CacheItem($this, $key, null));
> > }
> >
> > public function saveChanges(): void {
> > foreach ($this->dirty as $key => $value) {
> > echo "Saving $key to persistent storage\n";
> > }
> > $this->dirty = [];
> > }
> >
> > private function markDirty(string $key): void {
> > $this->dirty[$key] = $this->items[$key];
> > }
> >
> > public class CacheItem {
> > public string|null $value {
> > get {
> > return $this->_value;
> > }
> > set {
> > $this->_value = $value;
> > $this->cache->markDirty($this->key);
> > }
> > }
> >
> > public function __construct(
> > private readonly Cache $cache,
> > public private(set) string $key,
> > private string|null $_value,
> > ) {}
> > }
> > }
> >
> > $cache = new Cache();
> > $item1 = $cache->getItem('foo');
> > $item1->value = 'bar';
> >
> > $cache->saveChanges();
> >
> > This outputs:
> >
> > Saving foo to persistent storage
> >
> > This provides for a simple API for outside the Cache class: getItem()
> > and saveChanges(); that's it. For CacheItem's, you only have the props
> > for the key or value, and updating the value marks the item as "dirty".
> >
> > Currently, if you want this same API, the only way to do this is by:
> >
> > 1. using reflection,
> > 2. using a closure and binding it to the other class's scope,
> > 3. providing a listener + observer (more formal version of [2]), or
> > 3. iterating over items while saving to find dirty items.
> >
> > Those choices are not ideal (IMHO).
> >
> > Reflection feels "hacky" as does using a bound closure. The
> > listener/observer pattern is probably overkill here, unless you already
> > have one lying around (i.e., using symfony/laravel or a related
> > framework), but still might require making some of the "internal" api
> > public. Finally, iterating over all the items to find dirty ones is
> > naive and inefficient.
> >
> > Hopefully this is a better illustration of what nesting provides?
> >
> > -- Rob
>
> I have a similar if less involved use case in my ordering library, though it doesn't need
> the look-back functionality.
>
> So the use case that nested classes would enable that isn't currently covered by
> "just use separate files and @internal, deal" is around the lesser class having private
> access to the greater class. Which... I believe fileprivate and modules would also address, albeit
> in a different way, yes? (Presuming fileprivate is available on properties, not just the class
> itself.)
>
> --Larry Garfield
Well ... to use the best engineering response: "it depends..."
File-private, in my mind, is different; such as when the classes are distinctly unrelated with
respect to each other, but nobody else should be able to instantiate or use the private class. It is
like it doesn't exist outside that file. For example, something like a log formatter or a
default strategy implementation. Personally, I'd feel that file-private should be kept as
simple as possible and limit it to "top-level" things, but that doesn't necessarily
have to be the case. If we did allow it on methods/properties, when mixing it with regular
visibility, what happens? fileprivate public private(set) ... means what exactly? I
assume we probably wouldn't allow that particular scenario, and maybe fileprivate
on a property means public in the file, but private outside the file. But
then how would that intersect with inheritance? My point is that I don't think there is an
intuitive answer to these behaviors, but at least nested/inner classes, while not 100% intuitive
either, at least are available in other languages, so its behavior will be familiar.
If we were to target php 9, then we could simply redefine what private even means, similar to
Rowan's findings up thread (emphasis mine), and not even have a special keyword:
On Mon, Mar 24, 2025, at 20:22, Rowan Tommins [IMSoP] wrote:
> If you'll excuse a brief philosophical detour, I noticed something interesting in the
> Swift documentation: the description of nested classes doesn't describe any special scope
> access. Instead, the description of "access levels" defines "private" in a way
> that naturally includes them:
>
>> Private access restricts the use of an entity to the enclosing declaration, and to
>> extensions of that declaration that *are in the same file*.
>
> It's a subtly different framing - nested types aren't breaking into the private
> entity, the "private" keyword is explicitly letting nested types in.
Module-private, on the other hand, would be a huge boon to php; for a number of reasons. After
reading your brain-dump, it would be really interesting if we could package a binary representation
of the module alongside the module itself -- maybe not in an initial version, but later -- so that
it could basically be "pre-loaded" right into OPcache... But I digress. Your module idea
looks far simpler to implement than this one :D
I'd be happy to give it a go, if you're up for it and no one else is working on it. It may
be a few months, though; if this one passes, I want to go for short-classes next, plus I assume
there is an expectation that I would fix bugs.
— Rob