SitePoint Sponsor

User Tag List

Page 6 of 7 FirstFirst ... 234567 LastLast
Results 126 to 150 of 174
  1. #126
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    Well you can talk about your fancy symbol tables all you want, but all your example is doing is, at run-time, is renaming Database (in Database.php) to MyProject.Database and renaming Database (DB.php) to MyProject.Database. You could do the same at build time.
    But in PHP, there is no difference between build time and run time, they are one and the same.

  2. #127
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    But in PHP, there is no difference between build time and run time, they are one and the same.
    I wasn't using "build-time" in the compiled/linked language sense. By "build-time" I meant when you are building the application, running unit tests, deployment scripts, etc.
    Christopher

  3. #128
    SitePoint Enthusiast
    Join Date
    Jul 2005
    Location
    United Kingdom
    Posts
    86
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    My point is that if either way you have to change your code to avoid namespace clashes. Say you start with this code:
    PHP Code:
    class File{
        function 
    __construct() { echo 'File'; }

    and you discover that you have a name clash, you can either do:
    PHP Code:
    namespace foo {
        class 
    File{
            function 
    __construct() { echo 'foo:File'; }
        }
    }

    $foo = new foo:File(); 
    or you can do:
    PHP Code:
    class foo_File {
        function 
    __construct() { echo 'foo_File'; }
    }

    $foo = new foo_File(); 
    Both require a change, neither protects you more from namespace clashes, and the namespace solution is more verbose. I just can't get excited about using colons instead of underscores. And the reasons given are things like "I haven't heard of Python programmers complaining about it" or "go and code the whole thing in ASM while you're at it" which are not too persuasive.
    Consider the following:
    PHP Code:
    <?php
    require_once('foo/file.class.php');

    $obj = new foo_file();
    ?>
    Now imagine that in use in a full script, and with many classes, all being referred to with the _ notation.

    Now consider this:
    PHP Code:
    <?php
    require_once('foo/file.class.php');

    import foo:class;
    // or even import foo:*;

    $obj = new file();
    ?>
    Now imagine working with many different namespaces, some of which are nested. I know which i'd rather.

    Namespaces, as has been pointed out by the PHP development team many times, are a syntactical nicety. They are by no means 'required', but that doesn't make them any less useful. The problem at the moment is that the bulk of the proposed solutions involve imposing a full-blown package management system on anyone opting to use namespaces, which many people won't want and also makes the solution harder to create.

    Incidentally, just because it's good practice to have classes in their own discrete files, there's nothing wrong with declaring a class in the same file as some procedural code, or multiple classes in the same file neither should there be anything wrong with this.

    Filesystem structure should be decided in userland, not by any namespace system. I'm tempted to go learn some C, the Zend API and code up a proof-of-concept patch based on Jessies earlier work actually.
    Last edited by Lazesharp; Jul 27, 2005 at 02:50.

  4. #129
    SitePoint Addict pachanga's Avatar
    Join Date
    Mar 2004
    Location
    Russia, Penza
    Posts
    265
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    I don't see anything diminishing. If I just rename the "old" database class name there are two changes (one inside database_old.php and the other for the new statement). The code above requires two changes as well
    With namespace support you don't have to rename original classes. Well one is still required to resolve name clashes(if any) using long names prefixed with namespaces but there's no need to sed through lots of files renaming 'Foo' to 'Old_Foo'. And what if one has strict file naming convention, e.g. class 'Foo' is stored in 'Foo.class.php'? Does one need to change it to 'Old_Foo.class.php' also? That's way too much fuss...

  5. #130
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    PHP Code:
    class File{
        function 
    __construct() { echo 'File'; }

    and you discover that you have a name clash, you can either do:
    PHP Code:
    namespace foo {
        class 
    File{
            function 
    __construct() { echo 'foo:File'; }
        }
    }

    $foo = new foo:File(); 
    or you can do:
    PHP Code:
    class foo_File {
        function 
    __construct() { echo 'foo_File'; }
    }

    $foo = new foo_File(); 
    Both require a change, neither protects you more from namespace clashes, and the namespace solution is more verbose.
    If it doesn't stop name clashes, it isn't a namespace is it? You are getting package name clashes, not namespace clashes. That's the problem with the patch.

    For namespaces to give you something more than prefixing, they must work in such a way that File can be defined the same way, regardless of which namespace it is in:

    PHP Code:
    class File {
        function 
    __construct() { echo 'File'; }

    You only ever use the name of the namespace once you are outside it, because when you are inside, you are always inside it, regardless of the name. Every class should think that it is in a nameless namespace, though classes outside the namespace should know better.

    With the example:

    PHP Code:
    require 'dev/database.php'
    require 
    'classes/database.php'

    $conn = new DatabaseConnection(...); 
    $conn = new Old_DatabaseConnection(...); 
    You forget thay Old_DatabaseConnection could be used in other files, so you have n places to update the name, and then another n places to update again once your new DatabaseConnection is working.

    Douglas
    Hello World

  6. #131
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    The objectivity of all this discourse is quite impressive. I was going to recommend tildes which I find quite beautifully wave-like. I'm a much bigger fan of them than all those dotty colons and periods.
    I said it was something I didn't like, not something that would stop me using it

    And besides, tides are unreliable, some fonts they are up, some fonts they are in the middle. And I'd like to save them for when PHP supports native regexes, "return fase if foo =~ /[bar]+/"

    Douglas
    Hello World

  7. #132
    SitePoint Enthusiast
    Join Date
    Jul 2005
    Location
    United Kingdom
    Posts
    86
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DougBTX
    And I'd like to save them for when PHP supports native regexes, "return fase if foo =~ /[bar]+/"
    Off Topic:

    "When"... Wishful thinking. That's be nice, but I think PHP should look to support PCRE 6 first (assuming the PCRE library actually gets updated in line with Perl).

  8. #133
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by 33degrees
    I know this is probably trivial, but those single colons really bug me....wouldn't it make more sense to be double colons?
    Well, it's one less character to type.

    Regarding the Python solution being elegant I don't think that is true. Reusing the filesystemas your namespaces may seem efficient, but it's like using my toaster as a magazine rack. You can only really overload functionality if there is never going to be a conflict. That's why inheritance gets you into such a mess - commonoality of code doesn't always corespond to commonality of purpose.

    I am no Python expert, but I can see lot's of hidden complication. For example in Python, how do you manage relative paths? How do you handle multiple versions? How do you refactor when moving a class from one package to another. That these answers are not obvious, and have to be explained, is pretty damning from the elegance point of view.

    It may seem elegant from a coding angle, but it's anything but when viewed from a management and configuration angle. Namespaces are about large projects and you have to have large project thinking.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  9. #134
    SitePoint Enthusiast
    Join Date
    Jul 2005
    Location
    United Kingdom
    Posts
    86
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    Regarding the Python solution being elegant I don't think that is true. Reusing the filesystemas your namespaces may seem efficient, but it's like using my toaster as a magazine rack. You can only really overload functionality if there is never going to be a conflict. That's why inheritance gets you into such a mess - commonoality of code doesn't always corespond to commonality of purpose.

    I am no Python expert, but I can see lot's of hidden complication. For example in Python, how do you manage relative paths? How do you handle multiple versions? How do you refactor when moving a class from one package to another. That these answers are not obvious, and have to be explained, is pretty damning from the elegance point of view.

    It may seem elegant from a coding angle, but it's anything but when viewed from a management and configuration angle. Namespaces are about large projects and you have to have large project thinking.
    Off Topic:

    I like your way of thinking....

    *glances at PHPLondon*


    Whenever I look back at the solution on the internals list, or indeed some of the ideas floating around on this topic, I get this horrible sick feeling in the pit of my stomach that this patch is being developed purely for the sake of adding namespaces.

    Namespace support in PHP should be developed to solve a problem, not for the sake of adding namespaces.

    It's this way of thinking that has led me to advocate the much simpler idea that namespaces should be a means of separating groups of classes and the import keyword should do nothing more than import a namespace (or class from a namespace) into the current symbol table (be that the global one or another namespace).

  10. #135
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DougBTX
    And I'd like to save them for when PHP supports native regexes, "return fase if foo =~ /[bar]+/"

    Douglas
    Perl bigot
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  11. #136
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Lazesharp
    It's this way of thinking that has led me to advocate the much simpler idea that namespaces should be a means of separating groups of classes and the import keyword should do nothing more than import a namespace (or class from a namespace) into the current symbol table (be that the global one or another namespace).
    It is easier from userland PHP, which is what we want, but from an internals point of view it is nowhere near as simple as prefixing class names, whether in userland as arborint suggests or internally as the pach above does.

    I knwo this is the wrong place to ask, but internally, where do classes go in the symbol table, and how much symbol handling code needs to be rewritten to support multiple tables?

    Currently we have code like this, it looks like classes are just global. Could be lots of code to change...

    PHP Code:
    function foo() {
      class 
    Bar {
        function 
    talk() {
          echo 
    'hi world';
        }
      }
    }

    $bar = new Bar// Class Bar not found

    foo();

    $bar = new Bar;
    $bar->talk(); 
    Douglas
    Hello World

  12. #137
    SitePoint Enthusiast
    Join Date
    Jul 2005
    Location
    United Kingdom
    Posts
    86
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DougBTX
    I knwo this is the wrong place to ask, but internally, where do classes go in the symbol table, and how much symbol handling code needs to be rewritten to support multiple tables?
    I believe currently the patch being written uses two hash tables, one that contains all declared classes (already part of PHP) and a new one that contains all the declared namespaces (iirc). As far as I know, when you declare a class within a namespace, it adds it to the classes hash table with the full URI to that class (e.g. 'ns:class'). I'm not sure exactly how it handles it, but it seems to do ok.

    The current patch actually looks to handle things rather well, but then the author started talking about imposing file structure rules, introducing a new php.ini directive (class_path) and automatically including the files whenever 'import' is called. Eurgh!

    Thankfully, it seems that all or most of those responsabilities are now going to be (rightfully) delegated to __autoload.

  13. #138
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    Perl bigot
    That there is Ruby
    Hello World

  14. #139
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DougBTX
    That there is Ruby
    Yes, but it is a Ruby Perlism, and I know where your true loyalties lie

    You know you can have your PHP card revoked for suggesting regex become first class citizens, right? "That thar' is line noise"

  15. #140
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Lazesharp
    Whenever I look back at the solution on the internals list, or indeed some of the ideas floating around on this topic, I get this horrible sick feeling in the pit of my stomach that this patch is being developed purely for the sake of adding namespaces.

    Namespace support in PHP should be developed to solve a problem, not for the sake of adding namespaces.
    This is my point exactly. There seem to be people who just think namespaces are cool, when in fact they add complexity to code that is unnecessary except for maybe a few rare cases. The idea if having a class that is called by different names in different programs (or even the same program) sounds like a recipe to create more problems than it solves.

    I can't think of a reason to use namespaces to develop new code unless people are serious about liking colons better than underscores. Namespaces may have some use in integrating legacy code, but I still fail to see where renaming wouldn't be a better solution. The contribution of a librarian/packager utility that could maintain multiple files and do kind of renaming across all files would probably be a better contribution to PHP than namespaces.
    Christopher

  16. #141
    SitePoint Addict mx2k's Avatar
    Join Date
    Jan 2005
    Posts
    256
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Namespaces are helpful when organizing & grouping classes together, preventing name clashing with other code, and helps to prevent having to retype elongated class names.

    you want your code to be descriptive and readable, but at the same time not overally verbose. You also want to be able to have things in chunks & units to increase the ability to maintain your code.

    And i know that not everyone uses an IDE, but this would also help with not having all your project classes loaded at once for autocomplete, and can be a pain to scroll through all those names and underscores.

    and it would be nice to have namespaces not tied to the file structure. This could be useful in code libraries or frameworks, but i don't see how this would help the website folder structure or if you're team or yourself already has a set method of directory structure.

    maybe possibly and optionally function that could look up one designated file with all the includes/requires for that namespace if you importing the whole namespace rather than just the class.

    imports MyFramework.Web;

  17. #142
    SitePoint Enthusiast
    Join Date
    Jul 2005
    Location
    United Kingdom
    Posts
    86
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    I can't think of a reason to use namespaces to develop new code unless people are serious about liking colons better than underscores. Namespaces may have some use in integrating legacy code, but I still fail to see where renaming wouldn't be a better solution.
    The only real advantage is that you can do this:
    PHP Code:
    namespace foo {
        class 
    bar {}
    }

    // Import into current namespace
    namespace test1 {
        
    import foo:*;

        
    $obj = new bar();
    }

    // Use full URI instead
    namespace test2 {
        
    $obj = new foo:bar();

    If you think about the applications for this in the real world, especially larger applications and anything that is redistributable (frameworks, PEAR packages etc.). Namespaces are fundamentally different from simply renaming, yet they do serve a similar purpose.

  18. #143
    SitePoint Enthusiast
    Join Date
    Jul 2005
    Location
    United Kingdom
    Posts
    86
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mx2k
    maybe possibly and optionally function that could look up one designated file with all the includes/requires for that namespace if you importing the whole namespace rather than just the class.

    imports MyFramework.Web;
    __autoload() does just that in the current implementation of the solution.

  19. #144
    SitePoint Addict mx2k's Avatar
    Join Date
    Jan 2005
    Posts
    256
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Lazesharp
    __autoload() does just that in the current implementation of the solution.

    yes, but it becomes a little more tricky if you have classes under the same name space in difference folders seperated by layers rather by naming convention or some other kind of folder structure. Autoload could become a nightmare of a function, especially for maintainability.

  20. #145
    SitePoint Enthusiast
    Join Date
    Jul 2005
    Location
    United Kingdom
    Posts
    86
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Then use require_once instead and load all the files for a namespace manually. I don't see the problem with it all, I rarely use __autoload() at all (infact, I don't aside from a simple dependancy resolution system that uses it).

    For the record, it's not bad practice to use require/include...

  21. #146
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Lazesharp
    Then use require_once instead and load all the files for a namespace manually. I don't see the problem with it all, I rarely use __autoload() at all (infact, I don't aside from a simple dependancy resolution system that uses it).

    For the record, it's not bad practice to use require/include...
    You're missing the point. That doesn't solve the problem.

  22. #147
    SitePoint Enthusiast
    Join Date
    Jul 2005
    Location
    United Kingdom
    Posts
    86
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I understand problem, I just fail to see how namespaces causes it, surely it's a problem that would exist even without namespace support.

  23. #148
    SitePoint Addict mx2k's Avatar
    Join Date
    Jan 2005
    Posts
    256
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    actually require/includes or autoload isn't a problem, i was just simply suggesting extra hooks to help keep things managable. the point was, namespaces help to manage code internally and to keep things organized, especially dealing with larger projects.

  24. #149
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't like to use require_once() as there is no way clean way to deal with the failure of the file fetch. If the file is not fetchable, you get an error, which not only ugly, it's a security risk.

    Sure, you could mask the error being displayed, but where do you go from there huh? Do you use something like this for each file required...

    PHP Code:
    if( !file_exists( ... ) ) { 
    ... 
    report and log error ...
    }
    require_once( ... ); 
    I just think we need something a bit more sophisticated that your average require_once(), that's all. __autoload is a start but it's not entirely a complete solution

  25. #150
    SitePoint Enthusiast
    Join Date
    Jul 2005
    Location
    United Kingdom
    Posts
    86
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Easy!
    PHP Code:
    function require_once_facade() {
        
    // Code to handle loading and failing of requires

    Of course, without being so crude, but you get the idea.


Bookmarks

Posting Permissions

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