SitePoint Sponsor

User Tag List

Page 4 of 7 FirstFirst 1234567 LastLast
Results 76 to 100 of 174
  1. #76
    SitePoint Wizard stereofrog's Avatar
    Join Date
    Apr 2004
    Location
    germany
    Posts
    4,324
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DougBTX
    Hmm, as Marcus says, "everything is done at parsing time". So, a proof of concept could just be a function like this:

    PHP Code:
    function require_in($file$namespace) {
      
    $content file_get_contents($file);
      
    $content str_replace('all_class_names',
                             
    "$namespace_all_class_names",
                             
    $content);
      eval(
    $content);

    The tricky line is line 3, any ideas?
    For example,
    PHP Code:
    $kls 0;
    $out "";
    foreach(
    token_get_all($src) as $tok) {
        if(
    is_array($tok)) {
            if(
    $tok[0] == T_STRING && $kls)
                
    $out .= "prefix_";
            if(
    $tok[0] != T_WHITESPACE)
                
    $kls  = ($tok[0] == T_CLASS);
            
    $out .= $tok[1];
        } else
            
    $out .= $tok;


  2. #77
    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
    Somehow I understood it would - there's no point to the whole thing if it doesn't.
    There is nothing along those lines in the test cases, includes are done like this:

    PHP Code:
    ini_set'class_path'dirname__FILE__ ) . '/namespace' );

    import ns:class1;
    import ns:class2 as ns_class2;

    $full = new ns:class1();
    var_dump$full->mem1 );

    $alias = new class1();
    var_dump$alias->mem1 );

    $alias2 = new ns_class2();
    var_dump$alias2->mem2 ); 
    Where /namespace has a folder called 'ns' which contains class1.php, class2.php etc. In the testcase there is ambiguity as to whether the ns: comes from the namespace in class1.php, or from the filesystem.

    Douglas
    Hello World

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

    Thanks chaps. I was once going to write a proof of concept in PHP along the lines you are going. I feel the real version should be at the language level, but a pure PHP solution would give a point of discussion. Here are myrandom accumulated thoughts that have been knocking around in my head for a while.

    You could simply have the namespace along PEAR lines for a pure PHP hack...
    PHP Code:
    $a = new MyName_A(); 
    ...as that would be compatible with the conventions out there. It also means that classes that already have that format could be skipped by the namespacing operation or simply have the names changed.
    PHP Code:
    $object = new Pear_Object(); 
    ...could become...
    PHP Code:
    $object MyNamespace_Object(); 
    Regarding nested includes...

    If there are any requires_in()'s inside the imported library, then that namespace should stand. While class names can clash, it should be relatively easy to avoid namespace nameclashes. I don't see the need for...
    PHP Code:
    $d = new A:B:C:D(); 
    Also, if a file has been included before globally, then it should not be namespaced. I mean the exact location (not just the filename). This is to prevent common classes being loaded a ridiculous number of times. Does PHP keep a list of required files anywhere?

    Rgarding eval(), you don't need it. You would need a cache anyway, so just copy the modified source into the cache and require() it from there (you get require_once() for free this way). If you are using an accelerator, this takes away the performance impact of eval().

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

  4. #79
    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 lastcraft
    I don't see the need for...
    $d = new A:B:C();
    Are you sure ? If they do it once, they'd better do it right and not place such restraints.

    Also, I like how namespace are implemented in Python were a namespace is a directory.
    So, if we want to use a namespace:

    import namespace
    obj = namespace.object()

    or

    from namespace import object
    obj = obiect()

    were namespace is a directory like this:

    ..
    __init__.py
    object.py

    were the file __init__.py is executed when the module is imported and it's not required.

    I think this could be a good namespace model for PHP.

  5. #80
    SitePoint Addict
    Join Date
    Jan 2005
    Location
    Ireland
    Posts
    349
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    Does PHP keep a list of required files anywhere?
    Yes, you can get an array of included files from the function get_include_files().

  6. #81
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bonefry
    Also, I like how namespace are implemented in Python were a namespace is a directory.

    I think this could be a good namespace model for PHP.
    That's certainly interesting! So in PHP we'd set a class directory that contains those "namespaces" that are actually mere subdirectories. Seems intuitive and handy; there's no namespace foo { } cluttering the code. This'd get us nested namespaces on the side.

  7. #82
    ********* 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
    Also, I like how namespace are implemented in Python were a namespace is a directory.
    Frankly I find it ghastly and it's the most annoying thing moving from C++ to Java . It means everytime a class changes package you have to shuffle a load of files about as well. And it's just unnecessary. Why pull a restriction out of thin air for no identifiable gain. Hm, programmers have a habit of over organising at the best of times...

    Another problem occours when you want your test scripts in the same package as the classes. OK, that's a problem peculiar to java scopes (and you can get around it with a parallel directory structure in Java), but it prevents you having a simple classes folder or tests folder for smaller projects. And that's just the beginning.

    I don't think a simple thing like namespaces should dictate the build structure of a project. Anyway, how do you ensure compatibility with the code already out there. The point of namespaces is to allow libraries to interoperate. Hardly much use if that doesn't work.

    Again I think there is a real different between namespaces, a means of managing external code, and packages, which are an internal project structure.

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

  8. #83
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    Back to PHP namespaces...

    What does the patch look like in practice? What sort of code do you write with the namespace patch?

    yours, Marcus
    I read through this rather drivelly thread again and I didn't see where anyone had answered Marcus' obvious question of what code using the namespace patch actually look like. Was it just lost in the *absolutely facinating* LanguageX is more readable than LanguageY posts?
    Christopher

  9. #84
    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
    I read through this rather drivelly thread again and I didn't see where anyone had answered Marcus' obvious question of what code using the namespace patch actually look like.
    Try post 41 back on page 2: http://www.sitepoint.com/forums/show...9&postcount=41

    There isn't much to say, except ***** about PHP. Even Marcus did it!

    The code looks like this:

    PHP Code:
    namespace ns 

            class 
    class1 
            

                    public 
    $mem1 1
            } 

    And I'd say another +1 for file structure shouldn't depict application structure, and vice versa. Soon you'll be saying we should only ever have one class per PHP file.

    What if I wanted to use the same class in two different places in my code under different namespaces? I think a full solution would have to be able to handle that.

    Later,
    Douglas
    Hello World

  10. #85
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DougBTX
    Try post 41 back on page 2: http://www.sitepoint.com/forums/show...9&postcount=41

    There isn't much to say, except ***** about PHP. Even Marcus did it!

    The code looks like this:

    PHP Code:
    namespace ns 

            class 
    class1 
            

                    public 
    $mem1 1
            } 

    Does that mean, for example, I could do:

    MyDB.php
    PHP Code:
    namespace MyCode {
        class 
    DB {
        ....
        }

    And then:
    PHP Code:
    include 'DB.php';    // from PEAR
    include 'mycode/MyDB.php';
    $peardb = new DB();
    $mydb = new MyCode:DB(); 
    Or is it:
    PHP Code:
    include 'DB.php';    // from PEAR
    include 'mycode/MyDB.php';
    $peardb = new DB();
    namespace 
    MyCode {
        
    $mydb = new DB();

    Christopher

  11. #86
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Here's how think the patch works (baring in mind my C is rusty and I'm unfamiliar with the PHP source..)

    When you do namespace ns { }, a global is set to the current namespace:

    Code:
    +void zend_do_begin_namespace(znode *ns_token, znode *ns_name TSRMLS_DC)
    +{
    +	/* allocate space for the namespace prefix */
    +	CG(namespace_prefix) = emalloc(ns_name->u.constant.value.str.len + 2);
    +
    +	/* get the namespace prefix */
    +	strncpy(CG(namespace_prefix), ns_name->u.constant.value.str.val, ns_name->u.constant.value.str.len + 1);
    +	strcat(CG(namespace_prefix), ":");
    +
    +	/* get the lowercased namespace prefix */
    +	CG(namespace_prefix_lc) = zend_str_tolower_dup(CG(namespace_prefix), ns_name->u.constant.value.str.len + 1);
    +
    +	/* save the prefix length */
    +	CG(namespace_prefix_len) = ns_name->u.constant.value.str.len + 1;
    +}
    The global is then used to rename the class if it is set:

    Code:
    +void zend_prefix_class_name_node(znode *class_name TSRMLS_DC)
    +{
    +	zend_uint new_length = 0;
    +	char *org_class_name = NULL;
    +
    +	if (CG(namespace_prefix) != NULL) {
    +		new_length = CG(namespace_prefix_len) + class_name->u.constant.value.str.len;
    +		org_class_name = estrdup(class_name->u.constant.value.str.val);
    +
    +		STR_REALLOC(class_name->u.constant.value.str.val, new_length + 1);
    +
    +		/* get the full class name */
    +		strncpy(class_name->u.constant.value.str.val, CG(namespace_prefix), CG(namespace_prefix_len) + 1);
    +		strcat(class_name->u.constant.value.str.val, org_class_name);
    +
    +		/* get the new string length */
    +		class_name->u.constant.value.str.len = new_length;
    +
    +		efree(org_class_name);
    +	}
    +}
    So, "yes".

    Regards,
    Douglas
    Hello World

  12. #87
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It seems, import 'foo:bar' seems to transplate directly to "include foo/bar.php". Example:

    Code:
    +	/* copy the class name to the include file string, replacing colons with
    +	   slashes */
    +	for (; *class_name != '\0'; ++class_name, ++include_file_ptr)
    +	{
    +		if (*class_name != ':') {
    +			*include_file_ptr = *class_name;
    +		} else {
    +			*include_file_ptr = '/';
    +		}
    +	}
    +
    +	/* add the .php extension */
    +	strcpy(include_file_ptr, ".php");
    huh?

    Douglas

    Edit: and, oh gosh, I'll have to delete this post, code in a language that isn't PHP! The Horror! The Shame!
    Hello World

  13. #88
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DougBTX
    It seems, import 'foo:bar' seems to transplate directly to "include foo/bar.php". Example:
    It is namespace plus import? So it essentially turns
    PHP Code:
    import MyCode:MyDB.php;
    $mydb = new MyCode:DB(); 
    Into:
    PHP Code:
    include 'MyCode/DB.php';
    $mydb = new MyCode_DB(); 
    How apparently unhelpful. Nothing like adding overhead to do something I could do more clearly myself. Plus adding a bunch of internal rewriting of names which doesn't seem problematic at all. Was this fired off by the same blind archer who shot autoload in the general direction of PHP? Given enough time we should have several overlapping features here that will have to be depricated in PHP6.
    Christopher

  14. #89
    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 lastcraft
    Frankly I find it ghastly and it's the most annoying thing moving from C++ to Java . It means everytime a class changes package you have to shuffle a load of files about as well. And it's just unnecessary. Why pull a restriction out of thin air for no identifiable gain. Hm, programmers have a habit of over organising at the best of times...

    Another problem occours when you want your test scripts in the same package as the classes. OK, that's a problem peculiar to java scopes (and you can get around it with a parallel directory structure in Java), but it prevents you having a simple classes folder or tests folder for smaller projects. And that's just the beginning.

    I don't think a simple thing like namespaces should dictate the build structure of a project. Anyway, how do you ensure compatibility with the code already out there. The point of namespaces is to allow libraries to interoperate. Hardly much use if that doesn't work.

    Again I think there is a real different between namespaces, a means of managing external code, and packages, which are an internal project structure.
    BTW: a package is a namespace in Java. And the directory structure is necessary to avoid filename clashes. Furthermore, it would be compatible with the current PEAR directory organization. Furthermore, I hate Java style package {} declarations.

    I haven't explained much better about modules in Python. Let me explain again. But this time I will do it in PHP (somewhat).
    PHP Code:
    // So we have the a directory called util
    // that has 2 files: [i]__init.php[/i] and [i]sys.php[/i]
    // [i]__init.php[/i] - is executed when the module has been imported
    // [i]sys.php[/i] has the following structure:

    $path = array();

    class 
    MyClass {
       
    // implementation here ...
    }

    // ************
    // So, if we want to use MyClass and $path from another file
    // we would do something like this:

    import util.sys;

    echo 
    util:sys:$path;
    $object = new util:sys:MyClass();

    // or something like this

    from util import sys;

    echo 
    sys:$path;
    $object = new sys:MyClass();

    // or something like this

    from util.sys import *

    echo 
    $path;
    $object = new MyClass(); 
    Namespaces are a complicated problem, and they can't have a simple answer.

  15. #90
    SitePoint Zealot
    Join Date
    Jul 2005
    Posts
    194
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Namespaces aren't difficuilt, the main problem is the crappy PHP code

  16. #91
    ********* 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
    Namespaces are a complicated problem, and they can't have a simple answer.
    I think you see it as difficult, becuase you are conflating two mechanisms.

    Package scoping and namespaces have tremendous overlap, and so languages typically only have one mechanism or the other. This means each system will be abused to cover the role of the other. Java has a package system of one package per file and one public class per package, complete with scope rules to match.

    The namespace behaviour is pretty incidental. It's a global (real world sense) property where the namespaces are declared with a common root by teh package author, typically an inverted URL. This is just a string prefix though, and has nothing to with a file system. In that sense Java has both mechanisms, but the namespace part does not live independently of the packages.

    C++ has a namespace system. There is no protection within it, it's just there to stop nameclashes.

    In a PHP app. you only run a single top level script from many in the appication. This makes PHP packaging both harder and less necessary. However there are a lot of libraries out there with similar goals (template engine anybody) and code that is not currently namespaced.

    We need namespaces, not packages.

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

  17. #92
    SitePoint Enthusiast
    Join Date
    Jul 2005
    Location
    United Kingdom
    Posts
    86
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hello everyone, while this is my first post, i'm no stranger to PHP and regularly read sitepoint.

    I'm quite amazed at how much everyone seems to over complicate something that could essentially be so simple. It seems like people are trying to base the PHP object model on Java completely. Yes it has some similarities, but read: PHP is not Java, and never will be.

    This is an important point because it seems that this is the best reason for people wishing to tie application structure to namespaces. I agree with lastcraft that namespaces should by no means dictate application structure and I feel that this might well be reflected by the PHP core developers when they were developing "Namespaces" in the early 5.0 betas (note: they called them namespaces, not packages).

    Down to the real point here: It's my general belief that trying to auto-include files for namespace imports is just making things harder for everyone. For me the term "import" with relation to namespaces means and has always meant simply to import a single class from (or contents of) a namespace into the global scope. There is no overwhelming reason why a namespace import should trigger an arbitrary require_once(), what's wrong with requiring the files yourself? If you take a look at C# (possible C++/VB.NETs namespace models too, but since I haven't used them I can't give them as examples) you'll notice that the structure of the files has nothing to do with namespaces, and whats more, they call them "namespaces" not "packages" (emphasising lastcrafts point here).

    In short, I believe that PHP namespaces would be hugely valuable in preventing naming conflicts and generally allowing developers to use simpler class names. All I want out of namespaces, is to be able to do this:

    foo.php
    PHP Code:
    <?php
    namespace foo {
        class 
    test {
            function 
    __construct() { echo 'foo:test'; }
        }
    }
    ?>
    bar.php
    PHP Code:
    <?php
    namespace bar {
        class 
    test {
            function 
    __construct() { echo 'bar:test'; }
        }
    }
    ?>
    test.php
    PHP Code:
    <?php
    require_once("foo.php");
    require_once(
    "bar.php");

    // Create object without importing into the global scope
    $test = new foo:test();

    // Import into global scope then create object
    // import foo:* would have a similar effect in this example, that's fairly self-explanatory.
    import foo:test;
    $test = new test();

    // Triggers a Parse error "Cannot redefine class" etc.
    import bar:test;
    ?>
    And if you're too lazy to sort out the requires yourself? Use __autoload (and if you have any sense, cache the generated requires in a PHP file for future use since __autoload introduces overhead).

    I see no reason for namespaces to have anything to do with paths, if the developer of this current patch continues along these lines, it'll eventually die and we won't see namespaces for a very long time. I'm quite tempted to post to internals with a summary of the thoughts i've posted here.

    PHP isn't a toaster.

    Disclaimer: I haven't re-read anything i've written and I've been writing fairly quickly, so I might not have been particularly clear and more importantly, I might have come across as having a nasty tone, this was not my intention at all.

  18. #93
    SitePoint Enthusiast
    Join Date
    Jul 2005
    Location
    United Kingdom
    Posts
    86
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Small additional note, if namespaces were logically as simple as my proposal, there'd be no problem with nesting namespaces (which many people would find useful for Frameworks or public APIs where they could have many layers e.g. MyFramework:Controller:FrontController could be the class URI for a FrontController Class in an MVC framework).

  19. #94
    SitePoint Zealot
    Join Date
    Jul 2005
    Posts
    194
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well, I am against the use of include_path and __autoload() for this namespace support, even if I have to rewrite PHP... I would still prefer that over the current suggestion <g>

  20. #95
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Lazesharp
    Use __autoload (and if you have any sense, cache the generated requires in a PHP file for future use since __autoload introduces overhead).
    Is the difference really that significant? Any statistics on that?

    I liked what you said there. This approach has all we need with PHP.

    Multiple autoloads! Oh, joy!
    PHP Code:
    namespace Controller
    {
        function 
    __autoload($class) {
            
    $path PATH_FRAMEWORK.'/controllers/'.$class.'.php';
            return (
    file_exists($path) && (include_once $path))
        }

    Purdy... mmm.

  21. #96
    SitePoint Enthusiast
    Join Date
    Jul 2005
    Location
    United Kingdom
    Posts
    86
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ezku
    Is the difference really that significant? Any statistics on that?

    I liked what you said there. This approach has all we need with PHP.
    Very little to be honest, for most people, __autoload would be fine on it's own, but if you're very picky about performance, it'd be the best way to go, especially if you have a lot of globally included files without explicitly using include/require.

    Something like this would illustrate it's use better:

    PHP Code:
    <?php
    function __autoload($class) {
        
    // Code to locate class, assume it fills $classpath with path to file.  
        // Append require_once to this file
        
    $handle fopen(__FILE__'a');
        if (
    fwrite($handle"require_once($classpath);\n") === TRUE)
            require_once(
    $classpath);
        else
            throw new 
    Exception("Can't write to cache");
    }
    ?>
    Obviously with some better error handling etc. but you get the idea.

  22. #97
    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
    I'm quite amazed at how much everyone seems to over complicate something that could essentially be so simple. It seems like people are trying to base the PHP object model on Java completely.
    Hy Lazesharp,

    Although you might be right, please stop promoting this myth. I am also a Java/C++/Python programmer and I don't quite understand from were the ideea that PHP promotes Java object model emerged.

    The reason why I said Python style modules could be good for PHP (and please note Python is in no way related to Java) is that I don't like
    require "/long/file/path/that/could/change/class.php";

    I would like a standard mechanism with which to say
    import namespace.class;
    and don't worry about the filesystem anymore.

    Also, I think __autoload is the worst ideea ever. Just a minor hack of zend to keep unhappy programmers that miss namespaces on board.

  23. #98
    SitePoint Zealot
    Join Date
    Jul 2005
    Posts
    194
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Oh well, I am working on my own implementation of namespaces, in PHP now. Rewriting two small parts of the PHP codebase :+

  24. #99
    SitePoint Enthusiast
    Join Date
    Jul 2005
    Location
    United Kingdom
    Posts
    86
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hello bonefry,

    My statement that people appear to confuse Java and PHPs object-model was by no means influenced by your posts above. Generally aspects of PHP 5s object-model HAVE been inspired by Java (if you look at most of the features on the www.php.net/oop5 page, you'll notice that most are almost exactly the same as what Java is capable of). I was merely stating that treating PHP as though it IS Java is wrong.

    I by no means meant that Java is the _only_ language that ties packages to paths, I merely meant that people have decided to copy "how Java has done it" when thinking how to go about it in PHP.

    With regards to __autoload, it's not a replacement for namespaces, personally, I dislike it in some ways, because I think it's bad practice to rely on it, but like it in others, in that it allows a slightly more flexible approach to including files (see my example about caching requires using autoload above).

    In response to your point about long paths, I agree, long paths are nasty, all the more reason not to tie imports to a path system, because everyone does it differently. Instead have a single __autoload that dictates the namespace-class-path relationships and whenever the paths change, you have a single piece of code to update.

    Example time:

    Lets assume the style of namespaces i described above. The following script would trigger __autoload('ns:class')

    PHP Code:
    <?php
    $obj 
    = new ns:class();
    ?>
    Lets also assume that an __autoload function has already been defined in the global scope as follows:
    PHP Code:
    <?php
    function __autoload($uri) {
        
    // Class could contain a full namespace URI
        // We want the path format to be ns1/ns2/ns3/.../nsN/classname.php
        
    $path str_replace(':''/'$uri) . '.php';

        
    // $path would now be ns/class.php so we require it if it exists
        
    if (file_exists($path))
            require_once(
    $path);
    }
    ?>
    Of course, the logic for such an autoload could be very simple, or very complex, it would very much be dependant on the complexity of your application structure. The important point here is that it would allow the user to decide how to structure things, PHP is a very dynamic and highly versatile language. Implementing this in userland would actually be the best way to go about binding paths to a class/namespace.
    Last edited by Lazesharp; Jul 26, 2005 at 06:20.

  25. #100
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Re __autoload: I have found it fitting nicely into my style of code organization, but I agree that one should not rely on it.

    I have created a PHP5 Singleton class called Classloader, which is used by the __autoload() to include a class file when a class is needed. However, in order to use it you must first register the path to the library where the class file is located, which is then added to the include_path variable. So you get all the benefits: classes are organized one per file, you don't have to explicitly include each class (particularly useful with large libraries) and at the same time it is clear in the code what libraries a class needs. When it comes to third-party libraries which don't follow my organization schema (e.g. ADOdb or SimpleTest) they can easily be included the usual way.


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
  •