Stut wrote:
On 30 Sep 2008, at 14:00, Nathan Rixham wrote:
Stut wrote:
On 29 Sep 2008, at 12:47, Nathan Rixham wrote:
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.
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';
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.
/classpath was purely an illustration; the idea (or my thought behind)
replacing / with . and using packages as such; would be do give all of
us developers a set standard for file hierarchy / storing classes -
think java classes/packages actionscript 3 classes; never any cross
over; doesn't matter if 3 different companies all have a /db/handler.php
as it's always saved in net/companydomain/packagename/db/handler.php -
again back to the classpath; illustrating a set "class root" directory
for all classes.
/classes/
/modules/
/templates/
etc; but only defining /classes" at this time
to me anyways; this form of working in java and actionscript 3 (and some
other languages) makes sense and keeps things nice and standard.
import net.php.pecl.Tidy into TidySpace; # "into namespace"
import org.nicedom.alwaysusethese.*; # why not?
How does PHP work out where these "packages" are?
see above + in this case compiler would loop through the directory
'org/nicedom/alway/usethese/' and include all files (one class per file)
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.
internal virtual namespace within that class only; for internal use by
that class; non accessible to anything else - to allow for function
libraries that aren't in packages / classes and could have conflicting
function names. Rather than including a couple of files normally; it
makes sense to me to import the contents of these function libs into a
temporary internal namespace. I fear I have not the words; but *I* know
I mean :p
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.
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.
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.
indeed you can't; but you can in other languages and this is all
entirely functional; tis a feature of as3 that I like :)
{
if( TidySpace::tidy_is_xml( $xml ) ) { #namespace function call
$this->xmlString = TidySpace::tidy_repair_string( $xml );
One would hope that when namespaces are ubiquitous there will be no
need to prefix functions with package identifiers.
surely that would defeat the point of namespaces.. if the function
exists in two or more namespaces/packages then namespace prefix is
required.
I'm not referring to the namespace prefix, I'm referring to the tidy_
prefix.
ahhh I misread; yeah that's the idea of the "import file into namespace"
- we could all loose those function prefixes :) however there would
still be old function libraries written like this we may need to import
[/include/]
with NAMESPACE {
}
syntax would be cool as well
Agreed.
+1 from me too [again lol]
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
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.
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.
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
I've been following the discussions for some time (months... longer..)
on and off; too late for 5.3 :)
saw that great remove the $ suggestion myself - made me chuckle; a great
suggestion! loved the immediate reply somebody made to it too "erm that
would make every line of php ever written so far obsolete" or words to
that effect.. *slammed*
regards
--
nathan ( nathan@xxxxxxxxxxx )
{
Senior Web Developer
php + java + flex + xmpp + xml + ecmascript
web development edinburgh | http://kraya.co.uk/
}
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
