This is part of the definition of namespaces.
And yes, I want the INI option to just provide aliases.
If these are implemented by injecting
class a_A2 extends a::A2 {}
as interface classes or by internally providing a hash table alias is
only different from a technical point of view. The resul
Bart de Boer schrieb:
> namespace JessieStuff {
> class FirstClass { ... }
> class SecondClass {
> public $obj;
> function __construct() {
> $this->obj = new FirstClass();
> }
> }
> }
>
> Now we'd import this with prefixing everything and the
> result would be something tha
> /*
> * this encounters a namespace. The auto-prefix-import option
> * is active so EVERYTHING is inside the namespace is imported
> * with a prefix of "JessieStuff_".
> */
> require 'JessiePackage.php';
> $x=new JessieStuff_SimpleClass();
So let's say we've got a package like this:
namesp
l0t3k schrieb:
> Language behaviour should absolutely NOT depend on an .ini setting.
Using an .ini setting was just an idea so there would be a possibility
to have namespaces totally "hidden" from the beginning programmer. This
honors the KISS priciple: You require() some package and don't even n
Bart de Boer schrieb:
> So, if namespace JessieStuff contains multiple classes. They would all
> become JessieStuff_ClassName.
>
> Assuming the package relies on its own classes, it wouldn't be able to
> call them anymore because all their names have changed.
First of all, everything INSIDE a n
If Mike doesn't want to use namespaces, then Mike shouldn't use Jessies
package.
Bob
> -Original Message-
> From: Bart de Boer [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 30, 2005 11:45 PM
> To: internals@lists.php.net
> Subject: [PHP-DEV] Re: D
>> I already brought this up once: How difficult is it to introduce an
>> option to php.ini which has its standard setting in such a way that
>> every encountered namespace is automagically translated into "classic
>> prefixing" style?
Language behaviour should absolutely NOT depend on an .ini se
Let's say: Mike doesn't want to use namespaces but he wants to use a
package from Jessie. Jessie uses namespaces. Mike has his PHP configured
to "auto-prefix-import" everything. So if he uses your file foo.php
containg
namespace JessieStuff{ class Foo { ... } }
in conjunction with this setti
Oliver Grätz wrote:
Jessie Hernandez schrieb:
Please explain what you mean.
Didn't you get my mail? OK, I'll put it in here:
-
I already brought this up once: How difficult is it to introduce an
option to php.ini which has its standar
Jessie Hernandez schrieb:
> Please explain what you mean.
Didn't you get my mail? OK, I'll put it in here:
-
I already brought this up once: How difficult is it to introduce an
option to php.ini which has its standard setting in such a way
Hi Oliver,
"Oliver Grätz" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Jessie Hernandez schrieb:
> > In this case the FOO define will be used. When you do a namespace
import,
> > you can really only use classes without the namespace prefix (since
> > __autoload exists). To referen
Jessie Hernandez schrieb:
> In this case the FOO define will be used. When you do a namespace import,
> you can really only use classes without the namespace prefix (since
> __autoload exists). To reference a function name without the prefix, you
> must import it directly, as:
>
> import function
Hello Bob,
""Bob Silva"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Looking for some feedback on what the expected behavior should be for
class
> and/or constant ambiguity within namespaces. For instance:
>
>
>
> Classes.php:
>
>
>
> namespace A {
>
> const FOO = 123;
>
>
13 matches
Mail list logo
