These forums are read-only and for archival purposes only!
Please join our new forums at discourse.kohanaframework.org
Class name conflict in Kohana v3.2
  • I'm trying to upgrade from v3.0.8 to 3.2.0. I read the docs on what changed in 3.1 and 3.2 and made as many changes that affect me. Most of my existing codes seem to be working. However, it appears class name resolution is handled differently in 3.2. I was using external libraries like the PEAR HTTP_Request class and jpgraph library (which includes a Text class). Since Kohana has its own HTTP_Request and Text class, my controller now is throwing error because it is using the wrong class.

    For example, if the jpgraph Text class was loaded first, invoking the Kohana Text class will throw an error.

    ErrorException [ Fatal Error ]: Call to undefined method Text::ucfirst() SYSPATH/classes/kohana/http/header.php [ 865 ]

    Is there anything obvious that I missed when upgrading? Any suggestion would be really appreciated.

  • I'm not sure there's an easy way to fix this to be honest. This sort of thing is one of the reasons languages add namespaces.

    You'll probably end up having to modify some class names.

  • I'm surprised how this never comes up in v3.0.8. There must be a change in the logic for class loading in Kohana v3.2? Does anyone know what caused the difference in behavior or where in the system codes I can check? Thanks!

  • Assuming the Kohana Textclass always existed, this problem has always been there.

    There's a chance that the two different classes may have originally had a compatible API and so you never noticed the problem.

    To check, clone the git repository and compare the difference in that class file between two tagged releases :)

  • You are right. There are some differences in the 2 Text classes (v3.0.8 vs v3.2.0). So it looks like I was just lucky not to run into the problem previously. Thanks a lot!

    Time to investigate namespace or maybe just renaming class names.

  • Yes, kohana is based on the autoloader so if the class is already loaded beforehand and you/kohana don't use any functions that don't exist in both (or behave differently) then you'll get the impression stuff works.

    The problem with namespaces is that they work really well with things that are namespaced themselves (the "use" keyword can be very handy for example) but are major pain otherwise. If the Pear class had been namespaced you could just have extended something like Pear\Text but since it isn't you're pretty much stuck since there is no way to namespace it with out loading it into the global scope first, which in turn throws a wrench in Kohana's cogs.

    If you find a solution for this please let us know, I'm interested in the problem too. :)

  • As a side note, there has been some discussion regarding implementing PHP Namespaces in KO 3.3. It is probably the time to start looking at this seriously.

  • Where is this discussion?

  • Offline.

  • Ok. So what are the current issues with it?

    I suppose defining them isn't a problem since you can just do something like read the namespace name from init.php or alternatively define them manually by creating a path => namespace association in Kohana::modules.

    Transitioning to namespace should be a piece of cake too:

    • find/replace "Kohana_" => "\org\kohana\"
    • find/replace "<?php defined('SYSPATH') or die('No direct script access.');" => "<?php namespace org\kohana; defined('SYSPATH') or die('No direct script access.');" (and so on for each module)

    The only real issue is how do you dynamically set namespaces so you don't have to type org\kohana\HTML and so on all the time in non-namespaced files like views (this gets a little more complicated with namespaced files such as models, controllers, helpers etc). Given how the functionality that allows you to alias namespaces happens at compile-time we might have to do some real magic to get it to work; or it may just well be near well impossible and require you hardcode it every time (haha, like anyone is going to use something so dumb!).

    Considering how niche the cases where you need namespaces are, I still stand by the my opinion in the other thread where this popped up that kohana doesn't need namespaces. However, a really dumbed down implementation where every file you create in kohana is namespaced to one single kohana namespace to allow for interoperability with other libraries could work (though I don't know if even then it's really worth the hassle). It would certainly be simpler since you would only need to add the line namespace kohana; (and it would also work for this thread since you can then just call \Text for the PEAR version) however it would mean internally kohana makes absolutely no use of namespaces.

    Oh and I don't think namespaces will ever work for modules. It might sound like they make transparent extension a lot more accessible but in truth they kill it! For example, kohana classes when calling something like HTML will now always call their HTML, which pretty much destroys the current way of things. The cases where they call themselves this can be mitigated by having instead of say HTML::attributes call static::attributes.

    ps. what are some other offline discussions?

  • @Akki, this is not a good place for this discussion. You should either start a new thread, or better yet open a feature request on our issue tracker so your ideas/suggestions don't get lost.

  • @moonRabbit if you don't want to modify the Kohana source, then an other - well, crazy - option might be to play with the Runkit extension. If you want to work with jpgraph or PEAR HTTP_Request, then create a Runkit Sandbox and do your stuff there ( http://www.php.net/manual/en/runkit.sandbox.php ). I would only recommend this if you hardly don't want to modify the Kohana sources.

  • Also, consider using the Kohana request class in place of the PEAR one. I'm aware that the PEAR class provides additional features, but if it is not a requirement of vendor code and you're just using it to request external resources, the Kohana class provides a good base. HTTP basic/proxy authorisation can easily be added to the class if you require it.

  • @Crystal Yes I am trying to avoid modifying the Kohana source codes, which will be messy and painful when upgrade time comes. I will take a look at Runkit. Thanks! Fortunately this time I could modify the jpgraph source codes (added namespace) and use another PEAR class to resolve the conflicts.

    @Samsoir, thanks for you suggestion. For now, I'll stick with the Pear HTTP_Request2 class. It will be a thing to look into though.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion