Re: for the sake of conversation - syntax
| From: | Stut | Date: | Tue, 30 Sep 2008 14:36:28 +0000 |
| Subject: | Re: for the sake of conversation - syntax | ||
| References: | 1 2 3 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-281173@lists.php.net to get a copy of this message | ||
On 30 Sep 2008, at 14:00, Nathan Rixham wrote:
Stut wrote:Where did /classpath come from? Seems to me that's no better than simply using include. I see no value in replacing / with . in the path.On 29 Sep 2008, at 12:47, Nathan Rixham wrote:just RssParser.. I'd see "import" being a replacement for include import com.mydom.thatpackage.RssParser; same as import '/classpath/com/mydom/thatpackage/RssParser.php';import com.anotherdom.MysqlDbHandler as DbHandlerA; import com.somedom.DbHandler as DbHandlerB; # "as" makes this easier import com.mydom.thatpackage.RssParser; # we don't have to "as"Would this then be available as RssParser:: or would you need to specify the full name.
The ability to have multiple namespaces per file leads to issues with the "as" or "into" syntax. Which namespace from that file are you aliasing? This ambiguity is a killer.see above + in this case compiler would loop through the directory 'org/nicedom/alway/usethese/' and include all files (one class per file)import net.php.pecl.Tidy into TidySpace; # "into namespace" import org.nicedom.alwaysusethese.*; # why not?How does PHP work out where these "packages" are?
Except you can't, like I said. Try it. You cannot execute code during variable declaration in classes, you can only initialise to literal values.my mistake I meant: private DbHandlerA $dba = new DbHandlerA(); private DbHandlerB $dbb = new DbHandlerB(); scope type variablename = new class(); obviously calling __construct as per normal.public class MyClass # visibility on classes { private $dba:DbHandlerA = new DbHandlerA(); private $dbb:DbHandlerB = new DbHandlerB();Can't do this. This would require the compilation phase to execute code. This is what constructors were made for.
I'm not referring to the namespace prefix, I'm referring to the tidy_ prefix.surely that would defeat the point of namespaces.. if the function exists in two or more namespaces/packages then namespace prefix is required.{One would hope that when namespaces are ubiquitous there will be no need to prefix functions with package identifiers.if( TidySpace::tidy_is_xml( $xml ) ) { #namespace function call $this->xmlString = TidySpace::tidy_repair_string( $xml );
with NAMESPACE { } syntax would be cool as wellAgreed.
Unfortunately they've all been proprietary, but the basic syntax for all of them was similar to PHP and they didn't have complex concepts like packages or classes and only one of them had functions.why not throw out your ideal/made up procedural php language syntax; would be interested to see how what I as an OO dev would prefer compares to what you as a procedural dev would prefer.all purely a made up example; I'd be interested to here any comments or what your ideal language (/modified php) would look like.I've never really thought about how I'd like a languages syntax to be, I've just accepted the way it is. Having said that I've built a couple of compilers in my time and for the most part they were a combination of C, C++ and Perl, much like PHP. So in that respect PHP is the one that clearly makes the most sense to me for procedural languages. In terms of OO I've always liked the Objective-C way of doing things. It seems more natural than the C++ syntax. -Stut
thanks for the reply - probably a wasted convo but an interesting one that may lead somewhere!Namespace syntax discussions are ongoing on the internals list. Nothing has been officially released yet so nothing has been finalised. There was a cracking suggestion a week or so ago that the $ prefix for variables should be removed. Can you imagine the community backlash at such a pointless change!! -Stut -- http://stut.net/