0

I'll try to describe the situation I'm having problems with:

I have one main folder. I keep all files in there (empty classes for a reason), and one sub-folder, containing the same files, with all implementations here (empty classes extend them).

the main folder's namespace is declared as Project/Folder, and the sub-folder as Project/Folder/Subfolder. These are class's declarations:

namespace Project\Folder;
class Foo extends Subfolder\Foo {  }

namespace Project\Folder\Subfolder;
class Foo {  }

What I want to achieve is to be able to call other classes from inside of the Project\Folder\Subfolder\Foo through these empty classes on the lower level, with only its name, e.g.:

namespace Project\Folder\Subfolder;
class Foo {
     function bar() {
        Another_Class::do_something();
     }
}

By default, there will be called Another_Class from the Project\Folder\Subfolder namespace. I want this to refer to Another_Class from the Project\Folder namespace with the same syntax - is that possible?

I hope I explained this clear enough, if not, write a commend, and I'll try to make it clearer.

tereško
  • 58,060
  • 25
  • 98
  • 150
user1615069
  • 631
  • 4
  • 16
  • 26
  • I'm really curious what that reason is you need to put everything in 1 directory. I'm even more curious why you need those bodyless classes. Sounds more like a serious design issues rather than a legitimate use case to me tbh. – PeeHaa Nov 17 '12 at 21:47
  • Empty classes...I was thinking of deleting them lately. Their purpose was to allow the users of my code to extend the functionality of original classes if they would want to, without messing the original code. – user1615069 Nov 17 '12 at 22:04
  • 1
    If users want to extend your classes they can just, well... `extend` them. – PeeHaa Nov 17 '12 at 22:05
  • And, well...maybe not all classes...But in fact, ALMOST all of them. It's a framework, I've put there all basic classes for handling things like HTML, FORMS, but also classes which handle request flow, routing, etc. Didn't find any better solution here. – user1615069 Nov 17 '12 at 22:05
  • They can "extend" them of course. I just give them the right place to do this. – user1615069 Nov 17 '12 at 22:06
  • This coming from something where *all* classes are in the same directory I doubt it really is the right place ;-) – PeeHaa Nov 17 '12 at 22:08
  • Hmm, I'll have to think about the design again, thanks for warning me here. – user1615069 Nov 17 '12 at 22:11

1 Answers1

2

You can achieve that using the use statement.

use Project\Folder\Subfolder\Another_Class as SomeAlias;

// ...

SomeAlias::doSomething();

// or

$object = new SomeAlias();
$object->doSomething();

Alternatively, you would have to reference the entire namespace:

\Project\Folder\Subfolder\Another_Class::doSomething();

// or

$object = new \Project\Folder\Subfolder\Another_Class();
$object->doSomething();

More information here.

Yes Barry
  • 9,514
  • 5
  • 50
  • 69
  • But then I'd have to use that for all files in that namespace. – user1615069 Nov 17 '12 at 21:46
  • There's no some other way, right? I have a lot of these classes there. – user1615069 Nov 17 '12 at 21:47
  • Check my edit. That is the only other way (that I'm aware of). – Yes Barry Nov 17 '12 at 21:48
  • I'll have to choose the whole reference then, thanks. Is this the way they do this in "big" projects? – user1615069 Nov 17 '12 at 21:49
  • Yes I do this sometimes. Unless I reference that class _a lot_ somewhere, in which case I use the first method. – Yes Barry Nov 17 '12 at 21:51
  • Cool thing would be the possibility to use something like ../Another_Class::method(). – user1615069 Nov 17 '12 at 21:52
  • 2
    Why are you using static method calls in the example? Do you really hate OOP so much? – tereško Nov 17 '12 at 21:53
  • 1
    @tereško Shouldn't I? Isn't it OOP either? – user1615069 Nov 17 '12 at 21:57
  • @user1615069 , do you know why it is called "object oriented" instead of "class oriented" programming? – tereško Nov 17 '12 at 21:59
  • 1
    Factory method is a known anti-pattern, which tries to force another set of responsibilities on the existing object. When used with polymorphism, it becomes an architectural black hole of complexity. And, of course, you are breaking the single responsibility principle. Also, your `framework::getConfig()` is just another example of global state. – tereško Nov 17 '12 at 22:03
  • What teresko said + You understand that makes stuff pretty hard to test right @azizpunjani. And you do test I or don't you? – PeeHaa Nov 17 '12 at 22:06
  • @user1615069 , in that case, start by watching the lecture listed a the bottom of [this post](http://stackoverflow.com/a/9855170/727208) ... and the "how about singleton" is covered in the *Global State and Singletons* lecture. – tereško Nov 17 '12 at 22:09
  • @azizpunjani , you still have not provided any example without global state or violation of SOLID principles (assuming you even know what they are). – tereško Nov 17 '12 at 22:20
  • @everyone. I only used static method calls because that's what the OP used. Personally, I rarely use static methods. – Yes Barry Nov 17 '12 at 22:23
  • @tereško the best explanation I've come across for static methods is this: Does it makes sense to call this function even if no object has been instantiated? If so, then using a static method makes sense; _however_, 99% of the time it's just an excuse to be _lazy_. – Yes Barry Nov 17 '12 at 22:35
  • @mmmshuddup , can you come up with an example, or did you just left a 1% margin to yourself as *a way out*? – tereško Nov 17 '12 at 22:37
  • @tereško I never said the 1% was for _me_. But I'm glad you asked, I created a simple class that uses microtime for a quick-n-dirty way to check execution time of small code blocks that utilizes static methods. It was easier. The class has _two_ methods, both of which are accessing static properties. And even in this case, I used static methods because I _wanted_ to, not because it was the "correct" way. – Yes Barry Nov 17 '12 at 22:45