sysrpl wrote:I can only guarantee that my component class names won't clash with the LCL component class name, but this shouldn't be a problem, as the majority my classes are non visual, which will be unaffected by by this type of problem.
Yes, for non visual components this problem is minimized.
If the case arises that some new LCL bundled component classes with the name of something I've already created, then at that point I will rename the class.
...and all user code will need to be updated too. If this component is visual, *.lfm is other problem.
I understand the notion of class prefixes, but will never use them as I prefer cleanly named code
TUrl or TcbUrl
TFtpClient or TcbFtpClient
TDetailList or TcbDetailList
I'll take the former naming convention everytime.
I agree a cleanly named code is better, visually, but all frameworks are used in user-code and, many times, together with others frameworks. So, if my unit has two 'uses' for others units that have TUrl class... colision name.
Ok, that is not a big problem because methods could be little different and the programmer will see... but you use simple names even to functions. In Bare.Game you have a bare.system unit that have many functions. Many of them have the same names as the FCL. In these cases the compiler will compiles with no error, but which function should be used in user code, FCL or Bare.Game? See my point?
Do you have -- still in Bare.Game -- TStream class, TFileStream class, so on.
I'm not criticizing you. I just want understand how I can codify using simple names, like you, but not thinking in these language problems.PS: I've checked "Notify my when a replay..." but I didn't received any mail.