SitePoint Sponsor

User Tag List

Page 5 of 7 FirstFirst 1234567 LastLast
Results 101 to 125 of 174
  1. #101
    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 bonefry
    Although you might be right, please stop promoting this myth.
    Where is the myth? Here is the quote from the internals list:

    http://news.php.net/php.internals/17332
    Files under the directories in the class_path have
    the namespace names as directories and the class names named exactly as the
    file that declares it (like Java)
    (emphasis added)

    Douglas
    Hello World

  2. #102
    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 DougBTX
    Where is the myth? Here is the quote from the internals list:

    http://news.php.net/php.internals/17332
    (emphasis added)

    Douglas
    Hmm, that sucks.
    It doesn't apply to PHP. Namespaces should be available for variables and functions also. Not only for classes.

  3. #103
    SitePoint Enthusiast
    Join Date
    Jul 2005
    Location
    United Kingdom
    Posts
    86
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bonefry
    Hmm, that sucks.
    It doesn't apply to PHP. Namespaces should be available for variables and functions also. Not only for classes.
    I believe that is the intention of the patch currently being worked on...

  4. #104
    ********* 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 bonefry
    I would like a standard mechanism with which to say
    import namespace.class;
    and don't worry about the filesystem anymore.
    I feel we should keep it down to just namespaces. How about...
    PHP Code:
    add_path('very/long/path'); 
    ...for this?

    Although you could go...
    PHP Code:
    $path 'very/long/path';
    require_once(
    "$path/my_file.php"); 
    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  5. #105
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    PHP Code:
     $path 'very/long/path';
    require_once(
    "$path/my_file.php"); 
    Are you serious Marcus?

  6. #106
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    PHP Code:
     $path 'very/long/path';
    require_once(
    "$path/my_file.php"); 
    Are you serious Marcus?
    I hope he is serious. That is acutally simple flexible code. I am really missing the point of doing this:
    PHP Code:
    import MyCode:MyClass;
    $obj = new MyCode:MyClass(); 
    rather than
    PHP Code:
    include 'MyCode/MyClass.php';
    $obj = new MyCode_MyClass(); 
    It is just to make PHP look more like other languages. Or maybe to add statements that have more side effects to replace ones that have less. I am honestly getting to the point where I think autoload and namespaces might be considered a bad code smell in PHP.
    Christopher

  7. #107
    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:
    $obj = new MyCode_MyClass(); 
    If you can set the MyCode part inside the including page, then we have namespace support.

    Douglas
    Hello World

  8. #108
    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 arborint
    It is just to make PHP look more like other languages. Or maybe to add statements that have more side effects to replace ones that have less. I am honestly getting to the point where I think autoload and namespaces might be considered a bad code smell in PHP.
    And maybe now you consider that "the reference" bug is actually normal.
    Oh common. It's about a standard mechanism to include modules. I haven't heard of Python programmers complaining about it.
    Maybe we should strip PHP of classes too. That way nobody will complain anymore about OOP in PHP.

  9. #109
    SitePoint Addict mx2k's Avatar
    Join Date
    Jan 2005
    Posts
    256
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    you would need to modify the php core when it comes to class identifiers, it doesn't even allow you to do this (bassically use constants or dots)

    PHP Code:
    define("Framework""Framework_");
    define("Web""Web_");
    define("Mail""Mail");

    class 
    Framework_Web_Mail {

    }

    $x = new Framework.Web.Mail
    but to those who don't think we need namespaces, if you have ever had to intergrate different projects or code bases of any kind, you know this would come in handy. especially where there people who always use simple class names like user, mail, ui, page, and etc.

    plus i wouldn't mind doing something like

    imports ui as Framework.Web.UI
    $t = new ui.Page

  10. #110
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bonefry
    And maybe now you consider that "the reference" bug is actually normal.
    I haven't heard of Python programmers complaining about it
    You forgot to mark these comments as off-topic.
    Quote Originally Posted by bonefry
    Oh common. It's about a standard mechanism to include modules. .
    I haven't a clue what a "module" is as there is no such thing in PHP. There already is a flexible way to load files.
    Christopher

  11. #111
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mx2k
    but to those who don't think we need namespaces, if you have ever had to intergrate different projects or code bases of any kind, you know this would come in handy. especially where there people who always use simple class names like user, mail, ui, page, and etc.
    Ultimately what is being advocated here is run-time renaming as a shortcut instead of build-time renaming.
    Christopher

  12. #112
    SitePoint Enthusiast
    Join Date
    Jan 2003
    Posts
    36
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    Ultimately what is being advocated here is run-time renaming as a shortcut instead of build-time renaming.
    Not following you here. What do you mean with renaming? Namespaces (as I understand them, there are various definitions floating around in this thread) do not rename things, but provide means to avoid clashes of two named entities in the global symbol table of the running script. From what I know they can do this by acting as a layer between two symbol tables. I agree with those that said it's immensely helpful to have such a mechanism at hand if you need to integrate class architecture from different, non-related projects.

    For me I would be satisfied if I had a way to alias those entities imported via include(_once) and require_(once), probably in a similar way as Python does. In quasi-code:

    PHP Code:
     require_once '/path/to/my/project/Database.php' as MyProject;
     
    $db1 = new MyProject.Database($dsn);
     
     
    // ...
     
     
    require_once '/some/other/legacy/framework/DB.php' as Old;
     
    $db2 = new Old.Database($dsn); 
    "It is a mistake to think you can solve any
    major problems just with potatoes." -Douglas Adams

  13. #113
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mordred
    Not following you here. What do you mean with renaming? Namespaces (as I understand them, there are various definitions floating around in this thread) do not rename things, but provide means to avoid clashes of two named entities in the global symbol table of the running script. From what I know they can do this by acting as a layer between two symbol tables. I agree with those that said it's immensely helpful to have such a mechanism at hand if you need to integrate class architecture from different, non-related projects.

    For me I would be satisfied if I had a way to alias those entities imported via include(_once) and require_(once), probably in a similar way as Python does. In quasi-code:

    PHP Code:
     require_once '/path/to/my/project/Database.php' as MyProject;
     
    $db1 = new MyProject.Database($dsn);
     
     
    // ...
     
     
    require_once '/some/other/legacy/framework/DB.php' as Old;
     
    $db2 = new Old.Database($dsn); 
    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.

    Your motivation was that it is "it's immensely helpful to have such a mechanism at hand if you need to integrate class architecture from different, non-related projects." So the focus in on just those cases where there are libraries that one would want to integrate that actually have name clashes your current code. Do you have examples?
    Christopher

  14. #114
    SitePoint Enthusiast
    Join Date
    Jan 2003
    Posts
    36
    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.
    No, that's not exactly what I wanted to illustrate with my example. You misunderstand me and my fancy symbol tables.

    You could do the same at build time.
    Sure, I can add prefixes/suffixes to all class, constant, function, variable names to prevent clashes. But how should I know that my prefix won't clash with a different framework? How do you ensure that? Besides, it's not only the names in the declaration of those variables, but also where they are used, as in function calls/type hinting. Add variable variables and reflection to it and you can change almost every name in your application. Error-prone and a major headache when it comes to refactoring your application.

    Your motivation was that it is "it's immensely helpful to have such a mechanism at hand if you need to integrate class architecture from different, non-related projects." So the focus in on just those cases where there are libraries that one would want to integrate that actually have name clashes your current code. Do you have examples?
    How much code do you need? Seriously, what's the point of asking for examples - is the problem that hard to understand? But if you really like to know, I have a pet project under development that has a File class. Unfortunately during one exploratory test it clashed with PEAR's File class. So which class name should I have changed at "build" time? The one who is used less in my current system (PEAR::File), or the one that's probably used more by other people (PEAR::File) left untouched? Should both be changed?

    May I ask what you think are the reasons that

    a) this namespace proposal was made and
    b) so many other languages have a concept of namespaces?
    "It is a mistake to think you can solve any
    major problems just with potatoes." -Douglas Adams

  15. #115
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mordred
    Sure, I can add prefixes/suffixes to all class, constant, function, variable names to prevent clashes. But how should I know that my prefix won't clash with a different framework? How do you ensure that? Besides, it's not only the names in the declaration of those variables, but also where they are used, as in function calls/type hinting. Add variable variables and reflection to it and you can change almost every name in your application. Error-prone and a major headache when it comes to refactoring your application.
    We you can't ensure that. But you will get the name clash whether you have namespaces or not. Namespaces and renaming are solutions to clashes, not predictors. Would you add the overhead of namespaces if you knew there was no clashes?
    Quote Originally Posted by mordred
    How much code do you need? Seriously, what's the point of asking for examples - is the problem that hard to understand? But if you really like to know, I have a pet project under development that has a File class. Unfortunately during one exploratory test it clashed with PEAR's File class. So which class name should I have changed at "build" time? The one who is used less in my current system (PEAR::File), or the one that's probably used more by other people (PEAR::File) left untouched? Should both be changed?
    Of course the most practical for you would be for them to rename PEAR. So, so far I have heard of one problem, yours. And what a suprise you must have had to discover that someone else has created a class named "File". Who would have seen that one coming!
    Quote Originally Posted by mordred
    May I ask what you think are the reasons that

    a) this namespace proposal was made and
    b) so many other languages have a concept of namespaces?
    Nothing big really. Just sloppy, lazy programmers who would rather patch than do it right and should probably be using a different language.
    Christopher

  16. #116
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mx2k
    PHP Code:
    define("Framework""Framework_");
    define("Web""Web_");
    define("Mail""Mail");

    class 
    Framework_Web_Mail { }

    $x = new Framework.Web.Mail
    An ugly hack if I ever saw one.
    Quote Originally Posted by bonefry
    Also, I think __autoload is the worst ideea ever. Just a minor hack of zend to keep unhappy programmers that miss namespaces on board.
    And why's that? What's wrong with lazy-loading classes? How does that collide with having namespaces?

    Really, what's the problem with having namespaces just as you have the global namespace - with no extra quirks? Lazesharp's solution is so incredibly simple and elegant that I can't really come up with an excuse not to want it done in PHP asap. The prospect of cascading namespaces with __autoloads is something I personally find very enticing.

  17. #117
    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 Ezku
    Lazesharp's solution is so incredibly simple and elegant that I can't really come up with an excuse not to want it done in PHP asap.
    Come up with a code patch and we'll all love you!

    I'm a bit in awe at the moment, some good stuff out there. You can even see a prediction for how basing namespaces on filenames will limit you in ways you can't expect at the outset.

    Douglas
    Hello World

  18. #118
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    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.
    And you could go and code the whole thing in ASM while you're at it.
    Your motivation was that it is "it's immensely helpful to have such a mechanism at hand if you need to integrate class architecture from different, non-related projects." So the focus in on just those cases where there are libraries that one would want to integrate that actually have name clashes your current code. Do you have examples?
    Namespaces most certainly wouldn't be a mere tool to better integrate foreign class structures. They could be used to chop the sections of a single project to nice, tight bunches with simple class names as an added bonus. I guess this is what they call packages.

    A solution such as proposed by Lazesharp would allow you to be simple and merely use namespaces to prevent clashes - and what a relief would that already be -, but also delve in deeper and devise a neat little package management system customized to accommodate any and all structures you can just come to think of. I honestly can't see why you're opposing this so firmly.

  19. #119
    SitePoint Addict mx2k's Avatar
    Join Date
    Jan 2005
    Posts
    256
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    An ugly hack if I ever saw one.
    i was just playing around with the identifier to see what i could get away with because technically you can concatinate strings & constants using dots, and i was wondering if would be possible to do this with class identifier, buts its not. I'm not a huge fan of underscores.

  20. #120
    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 mx2k
    I'm not a huge fan of underscores.
    That's something I dislike about Python.
    Hello World

  21. #121
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ezku
    And you could go and code the whole thing in ASM while you're at it.
    Namespaces most certainly wouldn't be a mere tool to better integrate foreign class structures. They could be used to chop the sections of a single project to nice, tight bunches with simple class names as an added bonus. I guess this is what they call packages.

    A solution such as proposed by Lazesharp would allow you to be simple and merely use namespaces to prevent clashes - and what a relief would that already be -, but also delve in deeper and devise a neat little package management system customized to accommodate any and all structures you can just come to think of. I honestly can't see why you're opposing this so firmly.
    I'm not opposing this. I just haven't seen it as very necessary. It is a optional feature that people who think namespaces are neat will use, but that's about it.

    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(); 
    Bboth 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.
    Christopher

  22. #122
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DougBTX
    Originally Posted by mx2k
    I'm not a huge fan of underscores.

    That's something I dislike about Python.
    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.
    Christopher

  23. #123
    SitePoint Enthusiast
    Join Date
    Jun 2004
    Location
    Stillwater, MN
    Posts
    96
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Namespace name clashes happen rarely as opposed to having all of your classes in a global scope.

    If you do have a namespace name clash it is a lot easier to change one line of code than many lines of code depending on how many classes you have.

    Also having an import directive saves typing for when the benefits of using namespaces are not neccesary.

    However with this model
    PHP Code:
    require 'database.php' as NewDb;
    require 
    'database_old.php' as OldDb;

    $conn = new NewDb:DatabaseConnection(...);
    $conn = new OldDb:DatabaseConnection(...); 
    don't the problems above diminish? Import would be redunant too; if you didn't have name clashes just ignore the 'as' parameter.

    Namespaces in any implementation reduce renaming by giving a set of classes a (most of the time) unique identification while the classes could have commonly used names.

  24. #124
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I know this is probably trivial, but those single colons really bug me....wouldn't it make more sense to be double colons?

  25. #125
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Radley
    If you do have a namespace name clash it is a lot easier to change one line of code than many lines of code depending on how many classes you have.

    Also having an import directive saves typing for when the benefits of using namespaces are not neccesary.

    However with this model
    PHP Code:
    require 'database.php' as NewDb;
    require 
    'database_old.php' as OldDb;

    $conn = new NewDb:DatabaseConnection(...);
    $conn = new OldDb:DatabaseConnection(...); 
    don't the problems above diminish? Import would be redunant too; if you didn't have name clashes just ignore the 'as' parameter.
    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. Again the above code strikes me as less clear than:
    PHP Code:
    require 'database.php';
    require 
    'database_old.php';

    $conn = new DatabaseConnection(...);
    $conn = new Old_DatabaseConnection(...); 
    Quote Originally Posted by Radley
    Namespaces in any implementation reduce renaming by giving a set of classes a (most of the time) unique identification while the classes could have commonly used names.
    As I showed above namespaces really don't reduce renaming, nor do they really allow use of "common" names because when you use the class you are just swapping underscores for colons.

    It seems that what namespaces are really for is kludging together two or more codebases that have name clashes that for some reason cannot rename. This makes more sense for compiled libraries and non-open source code obviously. And I really don't buy the notion that you require a new lanugage construct because you want to use a PEAR class and your own classes but they must have the same names. Namespaces are not more convenient, nor clearer, nor faster ... they are a workaround and should be considered as such.
    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?
    I still think my tildes are prettier.
    Christopher


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
  •