Last modified: 2011-03-13 18:05:55 UTC
Greetings, I'm sending this message to request some kind of feedback about an eventual renaming of the class User to another name, like MWUser, for instance. The reason is that it could allow/ease integration with other applications. In fact, I'm having a class naming colision between mediawiki and another application, which has a very complex authentication backend, which is also not so flexible as mediawiki's. By renaming it, I could integrate both apps without having to provide a patch for each mediawiki that comes out. I see no impact at renaming it, besides massive search&replace, so I'm asking you if there is any reason so that an eventual User->MWUser patch would not get into mainline. I really look forward to hear from you, -NT
Why not rename the other application's classes? There are many possible collisions that will probably not effect anyone, we could end up with a lot of renaming. If some third party application has issues, then that application needs tweaking, possible with a live patch on the sites that use it (if the makers of that app don't want to rename). Renaming would also break all kinds of MW extensions.
Namespace support in PHP 5.3 & 6.0, in theory, could make such conflicts irrelevant in future. Assuming it actually works sanely. :)
Created attachment 4265 [details] class User renamed to MWUser to avoid name collision Brion: exactly. It's one of the things I miss from Java and .NET VoiceOfAll: I disagree with «If some third party application has issues, then that application needs tweaking», specially in this case, where the application has thousands more lines that mediawiki, and bigger complexity. About the patch, that was what I was thinking: avoiding it would be the best solution and, come on, class User is pretty asking for a name colision :) If not with this particular app, it can happen with anyother which someone tries to integrate with. I didn't remember of extensions, and you are right. But, please, consider that they are usually small pieces of code (even mediawiki, I renamed the class in a few minutes) and either are still being actively developed, or are so old that they might not even run at 1.11 . In any case, I'm posting this patch against 1.10.1 for anyone that needs it. It was human-made, so I preserved comments, except for references to "@return User object" (which turned to be "@return MWUser object"). I've tested it a bit, and it seems OK. If you later merge it, I can port it to 1.11, which shouldn't be difficult, I hope. Enjoy, and thanks for the effort put up to mediawiki.
That still totally breaks extension and is thus totally unacceptable. I'd wait for namespace support and do it right.
Agree with VoA. While this is an issue for integration with other apps, fixing it will cause more issues overall than it will solve, given that most MW users don't particularly need to integrate with other apps. It might still be worthy of consideration for long-term benefit if namespaces weren't on the table, but PHP devs are apparently interested in adding those at some point, so it seems best to wait until then rather than doing a massive breaking change that will be superseded sooner or later anyway. The short-term turmoil won't be outweighed by the long-term benefit, because there will *be* no long-term benefit.
