SitePoint Sponsor |
|
User Tag List
Results 126 to 150 of 174
-
Jul 27, 2005, 00:15 #126
- Join Date
- Sep 2004
- Location
- Zagreb, Croatia
- Posts
- 830
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by arborint
-
Jul 27, 2005, 00:29 #127
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by BerislavLopac
Christopher
-
Jul 27, 2005, 01:02 #128
- Join Date
- Jul 2005
- Location
- United Kingdom
- Posts
- 86
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by arborint
PHP Code:<?php
require_once('foo/file.class.php');
$obj = new foo_file();
?>
Now consider this:
PHP Code:<?php
require_once('foo/file.class.php');
import foo:class;
// or even import foo:*;
$obj = new file();
?>
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.
-
Jul 27, 2005, 02:45 #129
- Join Date
- Mar 2004
- Location
- Russia, Penza
- Posts
- 265
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by arborint
-
Jul 27, 2005, 04:23 #130
- Join Date
- Nov 2001
- Location
- Bath, UK
- Posts
- 2,498
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by arborint
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'; }
}
With the example:
PHP Code:require 'dev/database.php';
require 'classes/database.php';
$conn = new DatabaseConnection(...);
$conn = new Old_DatabaseConnection(...);
DouglasHello World
-
Jul 27, 2005, 04:59 #131
- Join Date
- Nov 2001
- Location
- Bath, UK
- Posts
- 2,498
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by arborint
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]+/"
DouglasHello World
-
Jul 27, 2005, 05:02 #132
- Join Date
- Jul 2005
- Location
- United Kingdom
- Posts
- 86
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by DougBTX
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).
-
Jul 27, 2005, 05:38 #133
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by 33degrees
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, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Jul 27, 2005, 05:59 #134
- Join Date
- Jul 2005
- Location
- United Kingdom
- Posts
- 86
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by lastcraft
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).
-
Jul 27, 2005, 06:21 #135
- Join Date
- Jun 2003
- Location
- Iowa, USA
- Posts
- 3,749
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by DougBTX
Jason Sweat ZCE - jsweat_php@yahoo.com
Book: PHP Patterns
Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
Detestable (adjective): software that isn't testable.
-
Jul 27, 2005, 06:30 #136
- Join Date
- Nov 2001
- Location
- Bath, UK
- Posts
- 2,498
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Lazesharp
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();
Hello World
-
Jul 27, 2005, 06:34 #137
- Join Date
- Jul 2005
- Location
- United Kingdom
- Posts
- 86
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by DougBTX
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.
-
Jul 27, 2005, 07:21 #138
- Join Date
- Nov 2001
- Location
- Bath, UK
- Posts
- 2,498
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by sweatje
Hello World
-
Jul 27, 2005, 08:18 #139
- Join Date
- Jun 2003
- Location
- Iowa, USA
- Posts
- 3,749
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by DougBTX
You know you can have your PHP card revoked for suggesting regex become first class citizens, right? "That thar' is line noise"
-
Jul 27, 2005, 09:12 #140
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Lazesharp
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
-
Jul 27, 2005, 10:06 #141
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;
-
Jul 27, 2005, 10:10 #142
- Join Date
- Jul 2005
- Location
- United Kingdom
- Posts
- 86
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by arborint
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();
}
-
Jul 27, 2005, 10:11 #143
- Join Date
- Jul 2005
- Location
- United Kingdom
- Posts
- 86
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by mx2k
-
Jul 27, 2005, 18:11 #144
Originally Posted by Lazesharp
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.
-
Jul 28, 2005, 02:18 #145
- 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...
-
Jul 28, 2005, 02:34 #146
- Join Date
- Nov 2004
- Location
- Romania
- Posts
- 848
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Lazesharp
-
Jul 28, 2005, 03:06 #147
- 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.
-
Jul 29, 2005, 10:01 #148
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.
-
Jul 29, 2005, 10:23 #149
- 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( ... );
-
Jul 29, 2005, 10:26 #150
- 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
}
Bookmarks