www.webdeveloper.com
Results 1 to 6 of 6

Thread: Namespace, use keyword and psr-4

  1. #1
    Join Date
    Feb 2008
    Posts
    19

    Question Namespace, use keyword and psr-4

    Hi

    I was wondering if anyone had any thoughts on these points:

    I'm using namespace's so far quite successfully which is a pleasant surprise to what I've been advised. The problem I have isn't to do with code errors it's more to do with practicality.

    I've started building a project which calls on lots of independent classes. The who project is brought in by composers autoload classmap together with the odd rouge files array within the composer.json file. Everything works as it's meant to but I've found the following issue:

    1. When creating a new class that extends a base controller I've found that I've needed to reiterate a whole bunch of 'use' statements which is only going to get longer. Regardless of length I find it awkward that I can't just say something like 'use parent' then I would only need the list once. The whole point of extending a class should mean that I don't need to set everything up again.

    This is a simple example.
    PHP Code:
    <?php namespace a\b\c\d;
        
        use \
    a\b\c\Alpha;
        use \
    a\b\c\Bravo;
        use \
    a\b\c\Charlie;
        use \
    a\b\c\Delta;
        use \
    a\b\c\Echo;
        use \
    a\b\c\Foxtrot;
        use \
    a\b\c\Golf;
        use \
    a\b\c\Hotel;
        use \
    a\b\c\India;
        use \
    a\b\c\Juliet;
        use \
    a\b\c\Kilo;
        use \
    a\b\c\Lima;
        use \
    a\b\c\Mike;
        use \
    a\b\c\November;
        use \
    a\b\c\Oscar;
        
        class 
    MyClass extends Base
    [INDENT]{[/INDENT]
    [
    INDENT]}[/INDENT]
    2. I have all of my namespace's reflect the actual path. My project is laid out neatly so it made sense not to confuse matter by giving them alias names and confusing anyone that needs to update my code. With this in mind I thought I'd look at PSR-4 autoloading through the composer autoload jason file. I've been trying to get my head around examples but I think if I can work it out then would that mean that I no longer need to use the 'use' keyword which would solve point 1.?

    3. If point 2. solves point 1. then my question turns to how the PSR-4 autoloading with namespaces can work for me. The following is an example of my composer.json file:

    Code:
    "autoload": {
    "classmap": [ "a/b/c", "a/b/c/a", "a/b/c/b", "a/b/d" ], "files": [ "x/y/z.php" ] }

    Every time I look at the PSR-4 description I'm confused on firstly how to implement it on a classmap group (i.e. I just want to pick a directory and autoload all php files inside) and how I would just say something like:

    Code:
    "autoload": {
    "classmap": [ "a\\b\\c" : "a/b/c", "a\\b\\c\\a": "a/b/c/a", "a\\b\\c\\b": "a/b/c/b", "a\\b\\d": "a/b/d", ], "files": [ "x\\y\\z": "x/y/z.php" ] }
    Obviously the psr-4 group is missing but I don't know if classmap exists within a psr-4 group or if a psr-4 exists within a classmap group if at all either?
    I just can't get my head around this psr thing at all.

    PS: I tried searching google but since the word 'use' interferes with the context of the keyword 'use' it doesn't get me many results :/

    i.e. "How do I use the use keyword" is a problem in search terms

  2. #2
    Join Date
    May 2014
    Posts
    1,083
    ... and welcome to why I stopped using the train wreck of confusion known as namespaces. I'd punch myself in the face if I ended up with code like that. Not sure what you're trying to accomplish there, but it looks so needlessly and pointlessly convoluted I'd suggest pitching it all in the trash and forgetting that namespace rubbish even exists.

    Though to be fair I say the same thing about passing data in JSON so... YMMV. I'm one of those creepy guys who thinks Machine Language is simpler than that, and still uses ASCII control codes when passing data.
    Java is to JavaScript as Ham is to Hamburger.

  3. #3
    Join Date
    Feb 2008
    Posts
    19
    Lol deathshadow.

    I think we already established that you hate namespaces and I can see why. The reason I've gone with them is that so far in testing I've not had a problem but I really didn't see this coming

    For PHP to come so far in being sensible this seems like a last minute hack which hasn't been thought about. Even the PSR stuff seems overly confusing (and restrictive). Composer seems better than what I've heard about PEAR but then again I seemed to manage this long without ever touching PEAR. The truth of the matter is that I've had my head buried in the sand since version 4 (4.4.9? I think), I had no clue version 5 had so many changes so all this is kinda new to me and I'm working on something open source that can stand the test of time (well maybe until version 6 at least).

    I'm one for creating simple but elegant coding solutions. Some frameworks built today seem at the very core overly complex wrapped up in pretension. I think if we all coded smarter in both senses of the word we wouldn't need to keep laying down these MUST do this MUST do that rules. I'm sick of following the fashion on coding standards as we switch between which standard organisation has hit the front of Forbes Magazine. W3c can't seem to make a decision let alone all of the other brand names in the industry of 'standards'.

    Oops - this was reply just supposed to say lol

  4. #4
    Join Date
    May 2014
    Posts
    1,083
    Quote Originally Posted by DAL. View Post
    I've not had a problem but I really didn't see this coming
    Which is what happened when I tried to use them; it's like crossing train tracks when the train is supersonic... you never hear it coming.

    Quote Originally Posted by DAL. View Post
    For PHP to come so far in being sensible this seems like a last minute hack which hasn't been thought about.
    I never found namespaces to be sensible when introduced when we already had the new object model; (if you can call PHP 5.3 'new') the only reason I can see to use them is to restrict scope, but since you can access them globally that kind-of defeats the point of restricting scope... well, other than yet another lame attempt at addressing namespace collisions, and really the ONLY way to do that is pay attention as a coder and to not blindly cut/paste code together from different sources.

    PSR is just an attempt to standardize practices... I agree with some of it and disagree with other parts; much of it is just common sense from a security standpoint. Honestly since PHP-FIG has little if anything to do with the ACTUAL PHP coding standards, it's a cute suggestion, but not something I'd take as the gospel. Their idea of making frameworks interoperable is 'cute' -- assuming you believe in using frameworks in the first place...

    Quote Originally Posted by DAL. View Post
    Composer seems better than what I've heard about PEAR but then again I seemed to manage this long without ever touching PEAR.
    They're both pointless garbage and more unstable in implementation than PHP itself (and given the changes to PHP the past decade, that's saying something). I won't use either for the simple reason you cannot guarantee a hosting provider will even allow you access to either -- meaning unless you are micro-managing your own hosting or restricting your product to people who can do so, PEAR and COMPOSER are completely and utterly useless on a 'generic' application where you don't know where it will be hosted. You might as well use ASP or JSP instead of at that point.

    Quote Originally Posted by DAL. View Post
    The truth of the matter is that I've had my head buried in the sand since version 4 (4.4.9? I think), I had no clue version 5 had so many changes so all this is kinda new to me and I'm working on something open source that can stand the test of time (well maybe until version 6 at least).
    There are a lot of good changes, and a LOT of garbage. Object scope and PDO being the highlights. The full object model of PHP 5+, in particular the scope controls of 'restricted' and 'private' fix a LOT of the possible security issues; something I think namespaces was trying to do, and failed miserably at.

    Quote Originally Posted by DAL. View Post
    I'm one for creating simple but elegant coding solutions. Some frameworks built today seem at the very core overly complex wrapped up in pretension. I think if we all coded smarter in both senses of the word we wouldn't need to keep laying down these MUST do this MUST do that rules.
    Well, rules are good in that they make it simpler -- just follow the rules and you are good - but you have to question certain rules that contradict reason.

    I mean, I have my own set of rules:

    1) only one <?php ?> pairing per file...

    2) that <?php should be the first thing in the file, ?> should be the last.

    3) always use ?> since omitting it like some people say to do means any code appendage will be executed, not shown; running code client side HAS to be more secure than server-side, and it's not like you can't just put <?php or ?> in a code appendage.

    4) security info like mysql un/pw/host should NEVER be stored in the global scope.

    5) the connection to the database should NEVER be stored in the global scope. (so no mysql_ functions)

    6) the connection to the database and ability to run queries should NEVER be passed to code that outputs markup

    I could go on for a bit. Some of those might look like what the various PSR levels say -- but mine were established for internal security, NOT interopability... in my mind interoperability isn't necessarily a great objective given it just opens security holes...

    But then I'm the nut who thinks that include/require should only be able to open files with a .php extension, we should only have been allowed to use _once versions in the first place, readfile should NOT be allowed to open files with a .php extension, and that the PHP 'shorttags' of <?php <?= and ?> should be removed from PHP entirely to make it work like a REAL programming language and not blindly output stuff when called directly. I'd possibly even say we need a NEW file extension, .phpi that is the ONLY file type allowed to be called by include/require, and that the server could block user side direct access to.

    Why? because it would plug major security holes.

    But as you said, much of PHP-FIG's "must" I'm not wild about being "must" -- I much prefer "NEVER" to "MUST". It's usually better to say what you shouldn't be doing as opposed to what you MUST do... and even my above rules I don't treat as the gospel and will break them when/if it makes sense or there's no risk. I'm different in that though, seems like most people seem to get their panties in a wad if you tell them "don't do that!"

    Quote Originally Posted by DAL. View Post
    I'm sick of following the fashion on coding standards as we switch between which standard organisation has hit the front of Forbes Magazine.
    Heh, as I say, taking technical advice from the pages of Forbes is like taking financial advice from the pages of Popular Electronics.

    Most everything that you find being popularized that way is more sick buzzword than a matter of fact, and that's why when it comes to PHP I restrict myself to what's on PHP.NET and on a STOCK PHP install. Anything else I take with a mountain of salt.
    Last edited by deathshadow; 06-14-2014 at 07:42 PM.
    Java is to JavaScript as Ham is to Hamburger.

  5. #5
    Join Date
    Feb 2008
    Posts
    19
    Fantastic comments! I really appreciate your feedback, I like your way of thinking.

    The reason I got mixed up in all of this mess with composer in the first place was that I was looking into Symphony and Laravel (ver4). It seems like a nice idea but I'm forced down the vendor directory route which is messing up my clean living areas for my code structure. It also at this point suggests that their is a huge flaw in configuration options with namespace's and the fact that you rightly mention that not everyone has access to secure shell or has privileges to run certain commands.

    I used to use a lot of mysql_ functions and have recently taken a dive into the PDO class. It has made addressing the database (mysql) 100 times easier once I replaced my standard db class. One thing that PDO didn't seem to get right that I've come across was making it possible to getColumnMeta which seems unsupported over many other db engines. A request to include addressing these was submitted back in 2010 as a future feature request but the note ends there, I'm yet to test with sqlite, oracle and postgres.

    As for the closing php tag, I thought I was one of the cool kids by omitting it, damn, now I have to got put them all back in. Damn you Jeffrey Way!

    php short tags, Yuk! I've never used them nor have I ever liked the short version of the if statement (I didn't even want to remember the real name for it), I guess that style if statement may be down to personal preference but I find easier on the eyes to have if displayed as a traditional block.

    I'm not even sure why include would have so many variations. If you go to the fridge to make a cheese sandwich and you can't get the cheese then I don't think I'd be happy continuing with just a butter sandwich!

    I like the idea of rules too but I tend to find that only 80% from each list works for me. One thing that seems to have never made it to the rule book which has me concerned recently (I've inherited a load of legacy project written in CodeIgniter with my new job) is that the view within an MVC framework should have very little logic if at all any. I'm looking at views at the moment that have so much php mixed html with if blocks here and for loops there and stuff that clearly should have been packed away in models or controllers it's unreal. I then found the source of the problem: CodeIgniter's tutorial! WOW!

    Haha, according to Popular Electronics the best way to run end of year financial reports are...

    There's way too many buzzwords out there and they are churning them out at an alarming rate, I'd be concerned about your sodium levels.

  6. #6
    Join Date
    May 2014
    Posts
    1,083
    Quote Originally Posted by DAL. View Post
    It seems like a nice idea but I'm forced down the vendor directory route which is messing up my clean living areas for my code structure.
    ... and that's the conclusion I came to several years ago -- simple fact was they just don't work the way I work... or what I would even consider a rational way TO work. Though to be fair, I say the same thing about jQuery, Bootstrap, and HTML 5

    Quote Originally Posted by DAL. View Post
    One thing that PDO didn't seem to get right that I've come across was making it possible to getColumnMeta which seems unsupported over many other db engines.
    I've never grasped the need for it -- that's the type of data that if you have ANY business accessing a table, you should already know it. But then, I usually consider most metadata in programming to be unneccessary micromanagement.

    Quote Originally Posted by DAL. View Post
    As for the closing php tag, I thought I was one of the cool kids by omitting it, damn, now I have to got put them all back in. Damn you Jeffrey Way!
    Note I said it's not like you can't append either tag; the only REAL reason for either argument is security and how to react to extra space or code at the end -- in terms of injected code neither approach makes a difference, just leaving extra whitespace...

    ... and to be honest, if you can't clean up/delete or use a editor that automatically strips trailing whitespace, you probably shouldn't be editing .php files in the first place.

    Quote Originally Posted by DAL. View Post
    I'm not even sure why include would have so many variations.
    I think in terms of include and require, it's a matter of HTML style lazyness vs. programming thinking. I don't "get" include, it's just sloppy to not throw an error if the file isn't found. REQUIRE makes sense to me, I call an include, it damned well better exist!

    The _once variations make even MORE sense to me, but I come from programming languages where you don't blindly past together includes; you fill your libraries/units with FUNCTIONS. If you try to include it more than once, it should bomb with an error saying "You already have that".

    Which is why IMHO "require_once" should be the only type of include PHP has... even if it is slower than a normal 'include'.

    Quote Originally Posted by DAL. View Post
    I'm looking at views at the moment that have so much php mixed html with if blocks here and for loops there and stuff that clearly should have been packed away in models or controllers it's unreal.
    MVC in PHP has NEVER made sense to me, because MVC was created for EVENT DRIVEN programming, something that PHP is decidedly NOT! The theoretical concepts that it has just do not correspond to how websites work -- and attempting to shoe-horn the fat woman's size 17 into a size 9 shoe that are most MVC "frameworks" reflect this. Take codeignitor, which has a 2 megabyte archived download and hundreds of thousands of lines of code that leave me asking "FOR WHAT?!?" -- it reminds me of some of the bloated Clipper and COBOL crap I dealt with in the '80's, where programmers were paid by the k-loc so they spent hours recreating existing system functionality and loading up on redundant comments just to pad their paychecks. The end result is three to five megabyte projects that probably could have been fit on a single sided single density 5.25" floppy without the stupid "framework".

    I do agree with the concept of certain separations, but the MVC model doesn't correspond to what PHP is, which is to say GLUE. PHP is best used as a glue -- to glue markup together, database operations together, and markup to database operations.

    The model I use, which lacks a cutesy acronym, basically follows the "one index to rule them all" method -- which is to say that ALL user access is routed through as single index.php. I use a .htaccess to force the issue on that -- This file processes user inputs , handles user logins, passes it to the processing libraries, loads then calls the appropriate template files. I maintain separation of database operations from template operations, but I wouldn't use the term 'view' since it's NOT an active system, it's a passive one!

    ... and really logic for processing in the template is needed to give you proper control over the markup. The "view" idea works when you have a single static view; websites do not have single static views like a single application does. The very notion does not correspond to what a website IS.

    Quote Originally Posted by DAL. View Post
    I then found the source of the problem: CodeIgniter's tutorial! WOW!
    SO many of the tutorials online make me cringe; they run against everything I learned about programming 30 years ago and are typically so full of security holes, sloppy code, and just plain bad advice I can only assume that the writers don't know enough about the topic to be writing a tutorial... they pretty much prove "those who can't, teach."

    Particularly when talking about interpreted languages that can just blindly include any file for execution with a legacy that had no serious concept of "scope"; hence the reason PHP is "insecure by design" just like every other web technology.
    Last edited by deathshadow; 06-14-2014 at 10:57 PM.
    Java is to JavaScript as Ham is to Hamburger.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center



Recent Articles