Drop vfsStream prefix from most classes?
mikey179 opened this issue · comments
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?
That'd be a nice improvement 👍
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
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
orDirectory
.
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.