On 06/05/2016 15:20, Alex Peshkoff wrote: > On 05/06/2016 08:41 PM, Adriano dos Santos Fernandes wrote: >> On 06/05/2016 14:16, Dimitry Sibiryakov wrote: >>> 06.05.2016 19:03, Adriano dos Santos Fernandes wrote: >>>> Yes, PathName may represent a relative path, but generally (always?) you >>>> know that a path read from somewhere will or not going to be appended >>>> with a parent path. >>> No, on contrary in current code they are always split or combined with >>> something else. >>> >>>> So these names is better represented as strings, they are not about real >>>> files. >>> And this is exactly why we have current problem with platform-dependent >>> case-sensitivity and encoding. "Just a string" just doesn't work. >>> >> We should think on separation of concerns in utility classes. >> >> A PathName should not know anything about Firebird. It should be a >> PathName for Firebird, project X, Y, etc. >> >> So it could allow to concat another PathName, but with an explicit >> method (not with operators or constructors) as this is not common operation. >> >> If you have a comparation problems of strings that are file paths, you >> have a problem in another layer. It's not a PathName problem. You could >> use PathName in this layer to solve. >> >> PathName problem is to compare two PathNames. > Agreed with everything till here. > >> And common operation is to >> append a file name (generally represented in a string) to it. > Not agreed. > Why file name should be represented as a string, not PathName? It does > not follow from what you say before. Moreover, if we need to correctly > compare that file name with another one we must "use PathName ... to > solve". I.e. to correctly work with file name it should be represented > as PathName, not generic string. > > As I said, you want to represent this "file name you know does not exist because it's going to be appended to something else" in an PathName, go for it.
It's perfectly valid to represent it as a string too. It's not bad code. So you don't want to convert it to string to pass to PathName concat? Ok too. Then call its method PathName::concatRelativePath(const PathName& subPath) (documented as throwing error if subPath is absolute). But we cannot go further with the discussion before clarify a point. Will PathName continue to be inherited by BaseString? I think it's wrong. It should be an standalone class, or if you want (I prefer you don't) a private/protected inheritance. I think PathName should have conversion method to string but not be a string. Adriano ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
