Stut wrote:
On 30 Sep 2008, at 16:57, Nathan Rixham wrote:
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.
Hasn't this already been attempted with PEAR? Don't get me wrong, I
really like the idea. And when phar becomes ubiquitous I would love to
see this adopted as a standard installation structure for libraries but
I can't see it happening, at least not enough for it to change the
behaviour of file inclusion. But you can hope I guess.
not sure.. for some reason I always bypass pear whenever possible;
probably because I like the excuse to re-invent the wheel :)
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
Consider this...
file1.php:
package arse
{
class bandit
{
...
}
}
package nipple
{
class clamp
{
...
}
}
file2.php:
import file1 as chest;
Which package have I aliased as chest in file2.php?
This could be solved using "import file1 into chest" which presumably
would then give me chest::arse::bandit and chest::nipple::clamp but
that's pretty nasty.
see I'd lock it to one class per file; multiple files/classes per
package :) I think one should always keep their arse and nipple seperate.
consider:
file: /classes/net/stut/body/arse.php
package net.stut.body.arse
{
class bandit
{
...
}
}
file: /classes/net/stut/body/nipple.php
package net.stut.body.nipple
{
class clamp
{
...
}
}
file: /classes/net/stut/body/chest.php
package /classes/net/stut/body/chest
{
import net.stut.body.nipple;
class chest
{
...
}
}
or
file: /classes/net/stut/body/chest.php
import net.stut.body.nipple;
$u = new arse::bandit;
whhhhhhiiiiiiiiiiiiiicccchhhhhhh leads me back to my earlier q of how
would this new style work when doing things the procedural way.. even
the above three lines; any potential problems there?
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 :)
This is a pretty fundamental limitation of the way PHP works. I don't
see it changing anytime soon, and I'm pretty happy about that.
Initialisations like this are only really useful in static classes where
you don't have a constructor. Personally I'd not use this ability if it
did exist because I prefer to use constructors to group initialisations
together but each to their own.
-Stut
concurred; could live with out; rather used to just initialising all my
classes/vars in __construct anyhows - this said was my "ideal" php
barstewarduzation.
--
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
