Important KDatabaseQuery naming conflict fatal error

Hi guys,

In a recent Kunena 1.6 update you added a class you call KDatabaseQuery, a backport of the query class in 1.6.

Now the problem is that a class with the same name have existed in Nooku Framework for quite some time.

So I kindly suggest you rename yours to KunenaDatabaseQuery. That would make it follow your own naming conventions, not just avoid a naming conflict with Nooku Framework.

Thanks

Stian,

Thanks for bringing this up!

Kunena uses the K prefix for a while now - both for css as well as php classes. The KDatabaseQuery class was in fact committed to our SVN in early 2009 when we started working on Kunena 2.0. Louis was so kind to provide a version of it before it made it fully into Joomla 1.6. To better support Joomla 1.6 this was recently back ported to Kunena 1.6.

At this time we do not support the Nooku framework due to the extra overhead it creates on a Joomla install.

Given how far advanced Kunena 2.0 is at this point in time, and the work we have spent with various partners like CB and JS, it is highly unlikely that we would go through a major naming convention change at this point in time.

We might also consider adoption and naming of the various libraries around the world. With hundreds of thousands of Kunena installs it is clearly one of the leading installed Joomla components/addons.

Last time I checked I believe less than 1% of all Joomla addons support Nooku at this point in time. Would need to do a new search to confirm that.

Maybe it would be wise to consider using a Nooku related prefix (e.g. 'N') for all of its classes, rather than a prefix that is used so widely already.

Hope this helps!

Oliver

Stian, as you wanted my comment on this:

I remember Louis committing database query class during our meeting back in 2009. For long time the class was not used in stable versions but JxTended / ArtOf User support forced us to backport/update it for Kunena 1.6.

I believe that fxstein was referring to Kunena 1.6 and not to Kunena 2.0. All classes in Kunena 2.0 were renamed to use Kunena prefix for over than 4 months ago. The decision was easy to make as K2.0 will not have backwards compatible API with older versions and we didn't want to keep using prefix that will most likely cause issues now and forever in the future.

That said, I do agree that using one letter (K) prefix in class names was a great mistake from us, even if there haven't been too many naming conflicts this far. Unfortunately we cannot do the same change in Kunena 1.6 as the classes are part of our official API and are already being used in few 3rd party modules, plugins and integrations.

I'm also really sorry to hear that Nooku Framework has made the same mistake we did -- I never expected that it was using K-prefixed classes, so I didn't make a conflicts check against it. You should know that we are not the only extension which is using the same prefix and that will keep causing Nooku more and more issues in the future.

I disagree with fxstein on your prefix -- you should use Nooku and Koowa instead of one letter:
docs.joomla.org/Coding_style_and_standards#Classes

Third-party developers are advised to namespace their functions with a unique prefix.

Hi guys,

Thanks a lot for your response!

@Matias so far the only conflict I'm aware of is KDatabaseQuery, the rest is not conflicting.

I understand you didn't expect K prefixes, after all it's called Nooku Framework. However before it got named Nooku Framework the codename were Koowa (swahili for "growth") which is why it's K prefixed.

Since it's a framework, it have a one letter prefix, just like Joomla.
Everything else follow strict naming conventions, that includes prefixing.
For instance, the com_default component, a framework component other Nooku components extend, have all its classes prefixed with ComDefault. So the default model is called ComDefaultModelDefault.

Nooku Framework is already in use on a lot of sites, not so much in extensions on the JED, but a healthy share of custom sites and by site integrators.

So changing the prefix for the 0.7 version of Nooku, which got tagged as Alpha 1 just a few days ago on the SVN unfortunately can't be done without major consequences for existing extensions using it.
If it were an option, we would've done it in a heartbeat.


So I really hope it's possible for you guys to just rename this one class, as it's the only one causing a conflict that may lock users out of the administrator. If it's the same exact class as the one in Joomla, it might not be a bad idea to call it JDatabaseQuery so that you only have to load that class on 1.5, and make your own codebase a little bit easier to work with for outside developers

That said I can't wait for PHP 5.3 to become widely enough adopted to rely on it, as the namespacing functionality there will put an end to problems like this once and for all.

Cheers!

Hi guys,

Thanks for the feedback. Let's not make this into a who was first or who's codebase is more widely used. No need for ego driven arguments. Let's just stick to the code.

With that said. Class naming collisions will still be a little bit a problem for the foreseeable future until we can move our code to PHP5.3 and introduce namespaces. It's great to hear that you renamed your classes to use the Kunena prefix for 2.0. This will definitely prevent more naming conflict issues down the road. In the mean time it looks like we will need to settle with the fact that Kunena 1.6 and Nooku are not compatible.

Just a final note about the naming conventions for Joomla extensions. When we developed Joomla 1.5 and modularized the API we setup the following convention :

1. Library classes : Classes that reside in the /libraries folder need to start with a unique prefix, this could be a full name or a one letter prefix. In Joomla's case this is the one letter prefix 'J'. The prefix 'J' is the only reserved prefix.

2. Other classes : Classes that are part of plugins, modules or components should use a unique prefix, preferably the name of the extension.

In Nooku we have further improved on this convention. The Nooku codebase is divided into different parts, we have libraries, plugins, components etc. See : nooku.assembla.com/code/nooku-framework/...ion/nodes/trunk/code

For actual framework libraries we use the 'K' prefix. The code name for the framework is Koowa hence the 'K' prefix. All other classes in Nooku use a fullname prefix based on the name of the extension. We also prefix all extension classes with an additional 'Com', 'Mod', 'Plg', prefixes to namespaces the different types of extensions. This makes it possible for our auto-loader to easily load classes.

I hope this helps how we prefix our classes and what conventions we use.

Keep up the good work on Kunena !

Cheers,

Johan

Unfortunately we cannot call the class JDatabaseQuery because of it breaks all the other extensions which are doing the same. Class gets loaded two times from different locations as JLoader is broken on extensions (loading the file right away by using include). Also changing the class name means that we need to go through all the extensions one by one and make sure that they are not using the new class, potentially breaking a lot of sites on upgrade.

In general, I'm still arguing against using one letter prefix as K2 and some other components are also using the same prefix. So even if there are no other known conflicts right now, it's very likely that there will be conflicts in the future.

Being a framework doesn't mean that you should use one letter prefixes. I would even prefer Joomla instead of J, but as everyone knows their prefix, it should be OK -- as long as you aren't using external libraries. At some day namespaces will fix this, but it takes years before all servers have upgraded to use PHP 5.3.

If I were you, I would gradually (before 1.0) deprecate old names and start using prefix that's easy to associate with Nooku -- just what we did with Kunena 2.0. I understand that it's not something that can be done in a day, but with legacy classes it should be possible to get rid of the old prefix fairly easily.