Master discussion fixing (package) names

Creating Neos & Flow Code
1

As the next major is coming soon ™ we need to tackle this topic IMHO as waiting another 1.5 years is not helpful.

So I want to collect and discuss what is needed and how we tackle it.

  • TYPO3\Flow\Resource\Resource needs to be renamed for future PHP compatibility
  • All TYPO3 package names and namespace need to be renamed to Neos
  • Package names TypoScript, TYPO3CR, Media, Form probably need a rename with our naming policy

For Resource a discussion was started in slack with a few ideas already:

  • FileResource
  • FlowResource
  • ResourceObject
  • FileObject
  • File

Also relevant:

Lets start discussion and work on solutions ASAP, time is short and we need to do this.

1 Like
2

Hi Christian,

thanks for moving the discussion here!

Just to get everyone on track: A Flow Resource currently represents a pointer to a persisted binary blob aka file.
It is an entity, thus a representation will live in the database even if the actual file contents are somewhere in the cloud.

Resource was fitting name obviously, but it didn’t explicitly imply the persisted nature.
Even less specific is anything that ends in *Object because every class represents an object.
I like File because it we already use that term for exactly what a resource is (even though a file can also mean a lot more as does “resource” and especially “object”).

Follow-up question: What about related classes like ResourceManager?

Did we write down that policy somewhere?

3

Good to have this here in a centralised spot, thanks Christian!

I’m not 100% convinced by the File name, but I’m starting to buy into it. Out of the current alternatives it’s probably the most fitting.

Follow-up question: What about related classes like ResourceManager?

This however brings up a new issue, because "FileManager" would be a bit misleading, no?
I at least would expect a FileManager to deal with basic file operations, like moving/copying, renaming and deleting, ie. structuring your file system/collection.

4

Actually we have two classes that are somewhat related:

\TYPO3\Flow\Resource\Storage\Object and
TYPO3\Flow\Resource\Resource

The whole subpackage is called Resource and I think that is just fine, so keeping the ResourceManager would be fine for me. I don’t see the need to have it named like the class that represents a file as it has responsibility beyond that.

5

PHP: List of other reserved words - Manual under soft reserved words we have “Resource” and “Object”

6

Right, that means we need to actually change both!

7

I think we need to split this discussion to distinct topics:

TLDR

This answer is sort of a brain dump :wink:

1. Renaming of Resource and Object entities

  • Resource is a persisted entity
  • Object is a DTO, used internally in the “Resource bounded context”, it’s not part of the public API and should be easy to rename.

Object Storage is a really common naming in the cloud industry, so I can understand why we have the current name. Not sure if File === Resource is exact in this context. By ex. in our case a Video === File !== Resource, because a Video is compose by multiple Resource. A big file can also be splited in multiple Resources.

Who say naming is hard :frowning:

2. Package naming (understand product name)

I see this one as the most complex, and need discussion, because we will communicate on the product (Fluid, TypoScript, CR, Form, …) and this is the visible part of our Iceberg for the outside world :wink:

But in this discussion we have so hidden gems, like did we rename Fluid to something else and split more with the T3 universe ?

Basically we have two option use simple work (Template, Media, Content Repository, Form, …) all under the Neos umbrella / namespace. Or invent fancy name for all our technologies. I’m in favor of simplicity here, and found the simple “word” the most effective.

3. Namepace

If I remember correctly the state of the last discussion, we agree on Neos is the Vendor, so all namespace should start with \Neos\...

Personally I will try to avoid \Neos\Neos in favor of \Neos\Core for the core CMS feature. Fine to have \Neos\Flow\. For the media package,\Neos\Media\, \Neos\Media\MediaBrowser in two distinct package.

What about create one thread per discussion before this one start to be out of control ?

8

That’s fine but lets relink any sub discussion here to keep the big picture.

9

For the Namespace renaming I made a little tool to help us:

10

Bump.

I think if we want to proceed with this (and I really think we must) we should introduce new namespace classes side by side with deprecated old classes in the 2.3 LTS (next version) so a bit of hurry is in order…

2 Likes
11

I opened a side-thread for renaming the resource-related classes: Renaming Flow core classes Resource and Object

12

It’s hard for me to follow this discussion in its entirety, but we urgently need to move our UI package under Neos umbrella. Under what namespace should we move it? Neos.Neos.UI?

13

So,

seems that the Resource topic is pretty much settled:

PersistentResource
StorageObject

Woudl be the two new names for the objects, as much as possible of the rest is being kept for b/c.

This change will still be breaking and therefor needs to be done after 2.3 is out. We could deprecate them in 2.3 though to raise awareness for the issue and pending rename.

2 Likes
14

Yes, I think something like

/**
 * @deprecated since 2.3. Use PersistentResource insted
 */
class Resource extends PersistentResource {
// ...
}

could work!?

15

Unfortunately only the other way around, otherwise PrsistentResource objects are not compatible with Resource anymore which would be breaking for any argument declaration.
But the other way around is what I have in mind for 2.3.

1 Like
16

I just started a discussion on Renaming TYPO3CR. If we rename TypoScript to Neos.Fire then we should rename TYPO3CR to Neos.SolidCR.

17

Just FYI I discussed the namespace topic with Karsten again for the upcoming LTS and we figured it doesn’t bring that much benefit to introduce class aliases. That said we will probably not include them in the LTS.