YANP (Yet Another Namespace Proposal) for PHP

[mx2k]

well i've done something like that for the short term to orgranize a small code library/framework that i'm building for myself and its ok for that. this isn't the actual function, but its the basic jist of it

             function  imports( $file )
        {
            if(! file_exists( $file ) 
             { 
                    // let the error handler take care of it
                    trigger_error('file:'. $file .' does not exist ', E_USER_NOTICE);
                    return false;
             }  else {
                    return (require_once($file));
             }
        } 

[Lazesharp]

Off Topic:

Might I suggest is_readable() instead of file_exists()?

[Captain Proton]

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.

Oh come on, that is paranoid. If you require files that don't exist in your source code, you're just being stupid.

Next thing you'll tell us is to do comparisons like this ($bla === true AND $bla !== false) ?

[DougBTX]

Oh come on, that is paranoid. If you require files that don't exist in your source code, you're just being stupid.

Correct, code that bad shouldn't make it onto production servers.

Douglas

[Dr Livingston]

Oh come on, that is paranoid. If you require files that don't exist in your source code, you're just being stupid.

It's not a case of the file being a requirement or not. If the file is required, then of course it'll be on the server... If you make that assumption of course?

What if the file that is required has been deleted by a third party for example, or a sector of the disk is void due to a disk error?

That isn't being paranoid, it's about being careful of how to handle an error which is fatal in most cases. I'm not talking about how best to present this error, or how it's logged, but how to handle it in the most efficient manner, without introducing bloat.

That is why I don't like using require_once( ... ), as there is absolutely nothing that you can do with it, that is actually useful to the developer. If it find the file, great, if not you get an error and nothing more

Apart from using @ to mask the error, how else could you use this function I ask? Just how elegant is your solution, since your being cynical?

[DougBTX]

How about this:

include_once 'my_file.php'; 

And some generic error handling using set_error_handler?

Later,
Douglas

[Captain Proton]

What if the file that is required has been deleted by a third party for example, or a sector of the disk is void due to a disk error?

That falls under my definition of paranoid.

If the error is fatal anyhow (a fatal error by definition cannot be handled), it doesn't matter how you handle it.

Just how elegant is your solution, since your being cynical?

A simple require_once for files which I know to exist and a file_exist() check for files that have a dynamic file name.

[Etnu]

Full blown packaging systems are really unnecessary for php. A simple solution like require_once('SomeFile.php','MyNameSpace'); or

namespace Foo
{
    class Bar
    {
    }
} 

would be more than sufficient.

The problem with php has never been correctly loading packages from the right place, it's been with name conflicts.

I've taken to naming my APIs after Greek Gods (I'm not even kidding) to avoid naming conflicts. That way all I have to do is remember what a given diety is the God of to know what the class does.

[Captain Proton]

I didn't now there was a god for database connections

[Lazesharp]

A simple solution like require_once('SomeFile.php','MyNameSpace');[/php]

Assuming that every include file would contain nothing but a single class... include/require should not be tied to the namespace in any way shape or form, procedural and OO code should be able to be mixed freely without any problems.

[DougBTX]

Assuming that every include file would contain nothing but a single class... include/require should not be tied to the namespace in any way shape or form, procedural and OO code should be able to be mixed freely without any problems.

What syntax would you use for a variable in a namespace?

as in:

namespace foo {
  $bar = 'hello world';
}

foo::bar;
foo::$bar;
$foo::bar; // ? 

Douglas

[Dr Livingston]

a fatal error by definition cannot be handled

Exactly... This is the point that I'm trying to put across. This is something that justs kills your script off, and I feel that we as developers should be able to to something before the final nail is hammered into the coffin

I'd go with this one,

foo::$bar; 

Since it appears your looking at a class parameter no?

[DougBTX]

Just a normal variable in another namespace

[Lazesharp]

What syntax would you use for a variable in a namespace?

as in:

namespace foo {
  $bar = 'hello world';
}

foo::bar;
foo::$bar;
$foo::bar; // ? 

Douglas

Personally, I'd find

foo:$bar 

to be the most suitable because it looks alot like the syntax for a property of a class.

Also, you quoted me in that post, variables in namespaces have nothing to do with the point I was making, if you misunderstood, i'll put it differently. Include/require should not be synonymous with import. It is and should always be solely for including code from an external file, whether that file contains a class, a namespace or plain old procedural code is up to the author.

[Ryan Wray]

Exactly... This is the point that I'm trying to put across. This is something that justs kills your script off, and I feel that we as developers should be able to to something before the final nail is hammered into the coffin

The two constructs [include and require] are identical in every way except how they handle failure. include() produces a Warning while require() results in a Fatal Error. In other words, use require() if you want a missing file to halt processing of the page.

I don't understand why you don't just use include_once, then. include_once produces a Warning, allowing you to gracefully do as you please.

[DougBTX]

include and include_once both return true on success if you want to test for that.

[DougBTX]

Had it been anyone else, I wouldn't have mentioned Ruby seeing as it looks like it turned into a swear word here (Maybe the the moderators will replace it with stared '*'s for us )

Here's an interesting article on that: What You Can't Say

[Captain Proton]

That's an interesting read. I guess it means speaking about other languages in this forum is a taboo

[bonefry]

Here's an interesting article on that: What You Can't Say

Very nice article Speaking about other languages (especially Ruby) became taboo after a long series of "Ruby has namespaces PHP doesn't" and things like that. It's ok but within limits (i.e. without getting religios about it). And after that limit, there is a place on this forum were you can talk freely about Ruby and it's called "Perl, Python and Other Languages"

[chiefmonkey]

The lack of namespaces is one of my major gripes about PHP5. However I subscribe to the PHP internals list and it seems that it will be added in 5.1

George

[Lazesharp]

The lack of namespaces is one of my major gripes about PHP5. However I subscribe to the PHP internals list and it seems that it will be added in 5.1

George

Post 5.1 actually, and that's if the patch gets approved.

[chiefmonkey]

Post 5.1 actually, and that's if the patch gets approved.

Bah, I must pay more attention to the mailing list. I was hoping that namespaces would be there for the new projects.

George

[DougBTX]

became taboo after a long series of "Ruby has namespaces PHP doesn't"

I doubt it, mainly because Ruby doesn't have namespaces in the first place

Douglas

[dagfinn]

I haven't been able to read this thread until now, but it's interesting. To hopefully make it clearer why it would be useful, a possible minimum set of requirements for a namespace system could be that it should help the following two nightmare scenarios:

• We want to integrate two large and complex applications. Both of them use a class library containing a Form class, and the Form class is used frequently in both. So any kind of include or require from one to the other invites a name clash which is all over the place. With today's PHP, we need to change all the occurences of the class name in one of the applications, possibly in lots of different files. Even finding all of them could be a problem.
• We want to introduce a new version of a class library, but the API has been changed. We want make the change by gradual refactoring, but that requires including both versions simultaneously as we're making the change. As it stands now, this is extremely difficult in practice because of a large number of name conflicts between the old and the new version.

To make both of these scenarios even worse, just add type hinting.