Renaming Flow core classes Resource and Object

Continuing the discussion from Master discussion fixing (package) names:

So, here’s my take:

1. Renaming Resource

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.


Great, sounds fine to me.

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.” :smiley:

Robert Power :wink: fine for me too, make sense



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…

Good point!

So, I have the following “plan” currently:

  • rename Object to StorageObect as already agreed
  • 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.

1 Like


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?

So, I gave that some more thought and I think we should a) do this for master only and b) drop that compat package idea.

So, I renamed all that stuff in the Flow development collection:

  • TYPO3\Flow\Object -> TYPO3\Flow\ObjectManagement
  • TYPO3\Flow\Resource -> TYPO3\Flow\ResourceManagement
  • Resource -> PersistentResource
  • Storage\Object -> Storage\StorageObject
  • Interceptor\Resource -> Interceptor\ResourceInterceptor

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:

And these are the PRs actually caring for the renaming and needed adjustments:

To test, please install using the composer manifest at:

1 Like

Ok, I updated the PRs after the Fluid and Cache merges today.

Please review and ideally test… :wink:

Thanks a lot, will check it out! <3

Yeah, I’ll post a composer.json for testing here in a few minutes. And hopefully the tests run after all the master merges… :wink:

So, here is the composer manifest:

… and for me the unit and functional tests now pass. :tada:

Good night… :zzz:

Tests pass, demo site works, also tried from scratch. I am pretty happy with it.

Solved conflict in one of the PRs, ran tests again, checked website rendering and setup tool.

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.

1 Like

Now we have an issue:

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?

1 Like

So, that is all merged now… :bomb: