Drop vfsStream prefix from most classes?

[mikey179]

PR #212 got me thinking about whether we want to keep the vfsStream prefix for class names? This stems from a time when there weren't namespaces in PHP. As we just changed the namespace anyway and are on the road for a new major release it might be an idea to drop this prefix from all classes except the vfsStream class itself. Some of the classes introduced after having a namespace were already named without that prefix. It would also allow to improve some of the class names. Here's a list of the class names that might change, I marked the ones which are currently declared as being part of the public API:

• [ ] vfsStreamContent => Content
• [ ] vfsStreamAbstractContent => AbstractContent
• [ ] vfsStreamContainer => Container
• [ ] vfsStreamContainerIterator => ContainerIterator
• [ ] API vfsStreamBlock => vfsBlock
• [ ] API vfsStreamDirectory => vfsDirectory
• [ ] API vfsStreamFile => vfsFile
• [ ] vfsStreamWrapper => StreamWrapper
• [ ] vfsStreamAbstractVisitor => AbstractVisitor
• [ ] API (not marked on the class but on constructor) vfsStreamPrintVisitor => Printer
• [ ] API (not marked on the class but on constructor) vfsStreamStructureVisitor => StructureInspector
• [ ] API (not marked on the interface but used in methods declared as part of the public API) vfsStreamVisitor => vfsStreamVisitor

I wouldn't change the vfsStream class itself. What do yo think?

[bizurkur]

That'd be a nice improvement 👍

[allejo]

I'm mostly in favor of this. For anything that's a public API, I'd lean towards leaving some type of prefix in the class name. Introducing a class with such a generic name like Directory or File would cause users to have to set aliases in their use statements if they're using real filesystem classes with names like File or Directory. So for public API classes, what about leaving a prefix like vfs? e.g.

• vfsDirectory
• vfsFile

[mikey179]

Introducing a class with such a generic name like Directory or File would cause users to have to set aliases in their use statements if they're using real filesystem classes with names like File or Directory.

You are right, that's an important point. I updated the list to reflect this. For the concrete Visitor implementations however I don't think it's a big issue, so I'd keep my suggestion.