In general, we should break only as few as possible, so I think that renaming everything resource-related to something else (including ResourceManager etc.) is out of question.
As you know, we have two kinds of resources: Static Resources and Persistent Resources. While the former are unmanaged, the latter need some kind of registry, which is the ResourceRepository. Therefore, why not just call the class PersistentResource?
2. Renaming Object
I think that’s rather easy: we currently use Object only as a representation of data in storages. The term “object” is quite common in cloud storages, so let’s try to stick with it.
My suggestion for a new class name would be StorageObject.
Both sound good to me. The names Resource and Object were already generally quite fitting, but missed specific aspects of them inside the Flow context. So simply enriching the names with those aspects makes total sense. Amazing that no one else came up with those names before, even though Bastian already directly pointed towards it: “Resource was fitting name obviously, but it didn’t explicitly imply the persisted nature.”
Ok, still trying to get some harder confirmation, but it seems this reserving will not happen in 7.1.0 as it seems. That means for me we can do this in one go for the next major. So next major will simply have a breaking change to rename this.
Btw. when it happens in PHP that will also apply to namespace parts, so we need to rename the full TYPO3\Flow\Resource namespace… Which means big breaking change, but then again we have to rename stuff anyway…
rename Resource to PersistentResource as already agreed
do all that for the oldes maintained release
create a new package that contains the old classes and declares itself compatible with PHP < 7.1 only and which we require (for PHP >= 7.1 that package would be empty or whatever works…)
That would allow people to adjust their code even when using older versions of Flow and at the same time keep it working for un-adjusted code.
Now, that sounded clever, until I came here to post this, and realized we indeed need to rename TYPO3\Flow\Resource and TYPO3\Flow\Object namespaces anyway (do we really have to? sources welcome, @christianm).
Bummer. So, would this just mean a ton of classes or aliases more in that compatibility package? Or…? Gnah.
And yes namespace as well, but what does that matter for the compat package?
I am not entirely sure about the compat package idea. I think I thought this through and found some issue with it.
Let me think:
You would basically extend from new namespace/name class with an empty old namespace class. That could be a problem for singletons if we use new namespace/name in our code and someone uses the old one, because both would be separate instances, right?
There is a Doctrine migration to rename the table used to store PersistentResource objects.
And there are two core migrations to help do the needed code changes, those were used to adjust the remaining packages used in Neos. Those migrations may leave things untouched that need to be adjusted, since replacing “standalone” Resource is rather dangerous. So when that class has been imported using use TYPO3\Flow\Resource\Resource things get hairy… The migration emits a warning about that.
On the way to all this, I created a bunch of PRs that are not directly related, but I’d still love to have them merged before the renaming, if possible:
Just for the record, because we just talked about it: I think that most of this information here should have gone into an issue on Github, so all that information is available in all related pull requests.
Right, GH should be the place. I stopped looking for the correct place to describe this, once I had arrived here, TBH. So we need to find the sweet spot between Discourse and GH for such discussions… Something for the playbook?
fine for me too, make sense
