FAQ
Hi all,

import Foo::Bar AS DomDocument;
import Foo::Exception;
import MyStuff::Dom::XsltProcessor;

Result in a "Fatal error: Import name '...' conflicts with defined
class"
Of course i want to refer to my own exception in my application or
framework as "Exception", and of course i want to use it without
prefixes (import myStuff::Exception AS MyStuffException), i wouldn't
use namespace otherwise (there is no other benefit, right?).
It's not that one accidentally puts an "import Foo::Exception" in his
file ..

Is there a good reason for this bevhaviour that i don't see? There is
still ::Exception to access the class in the global namespace.

regards,
Benjamin

Search Discussions

  • Greg Beaver at Oct 2, 2007 at 7:03 pm

    Benjamin Schulz wrote:
    Hi all,

    import Foo::Bar AS DomDocument;
    import Foo::Exception;
    import MyStuff::Dom::XsltProcessor;

    Result in a "Fatal error: Import name '...' conflicts with defined class"
    Of course i want to refer to my own exception in my application or
    framework as "Exception", and of course i want to use it without
    prefixes (import myStuff::Exception AS MyStuffException), i wouldn't use
    namespace otherwise (there is no other benefit, right?).
    It's not that one accidentally puts an "import Foo::Exception" in his
    file ..

    Is there a good reason for this bevhaviour that i don't see? There is
    still ::Exception to access the class in the global namespace.

    regards,
    Benjamin
    Hi Benjamin,

    If you are aliasing a class to the same name as an existing class, you
    should also import that class with another name:

    <?php
    import ::Exception as Notused;
    import Foo::Exception;
    ?>

    This is somewhat unintuitive, but is pretty simple to solve.

    Greg
  • Stanislav Malyshev at Oct 2, 2007 at 8:05 pm

    <?php
    import ::Exception as Notused;
    import Foo::Exception;
    ?>
    I wouldn't actually recommend using such code. If you have
    Foo::Exception just use Foo::Exception - it's short enough :)

    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Benjamin Schulz at Oct 3, 2007 at 9:50 am

    On 02.10.2007, at 22:04, Stanislav Malyshev wrote:


    <?php
    import ::Exception as Notused;
    import Foo::Exception;
    ?>
    I wouldn't actually recommend using such code. If you have
    Foo::Exception just use Foo::Exception - it's short enough :)
    And what if not? "throw App::package::subpackage::Exception" in a
    file that has the namespace "App::package::subpackage" is just wrong,
    importing the Exception as a different name as well. Importing the
    global Exception as something else - i don't even know what to answer
    to that ... this problem makes the whole concept just seem broken, is
    there even a concept? ;)

    regards,
    Benjamin
  • Gregory Beaver at Oct 3, 2007 at 1:57 pm

    Benjamin Schulz wrote:
    On 02.10.2007, at 22:04, Stanislav Malyshev wrote:

    <?php
    import ::Exception as Notused;
    import Foo::Exception;
    ?>
    I wouldn't actually recommend using such code. If you have
    Foo::Exception just use Foo::Exception - it's short enough :)
    And what if not? "throw App::package::subpackage::Exception" in a file
    that has the namespace "App::package::subpackage" is just wrong,
    importing the Exception as a different name as well. Importing the
    global Exception as something else - i don't even know what to answer to
    that ... this problem makes the whole concept just seem broken, is there
    even a concept? ;)

    regards,
    Benjamin
    <?php
    namespace test;
    class Exception {}
    $a = new Exception('hi');
    ?>

    The above code works just fine.

    Yes there is a concept. import is best used within a namespace. So,
    namespace your code and there is no need to import global classes.

    Greg
  • Benjamin Schulz at Oct 3, 2007 at 4:10 pm

    <?php
    namespace test;
    class Exception {}
    $a = new Exception('hi');
    ?>

    The above code works just fine.

    Yes there is a concept. import is best used within a namespace. So,
    namespace your code and there is no need to import global classes.
    Yep, it works if your whole application uses one namespace, but what
    if you have a core package that defines some exceptions and another
    package, with a different namespace, that wants to use the core
    exceptions? Like

    namespace App;
    class Exception extends Exception { ... }

    and in another File:

    namespace App::Db;
    import App::Exception;
    ....

    This doesn't work. And worse: imagine PEAR would bring a
    PEAR::Exception along, PEAR would be my basic framework and i
    wouldn't care about ::Exception, i don't even know it's there - i am
    using PEAR. In every Script i would like to use PEAR::Exception in a
    convenient way i have to write:

    <?php
    import ::Exception AS WTF;
    import PEAR::Exception;
    ?>
    (Nevermind if this example doesn't fit the PEAR-idea, just s/PEAR/
    randomFramework/g then)

    You think this makes sense?
    Or what about this:
    pear/Mail_IMAP/IMAP.php (dunno if this file exists):
    <?php
    namespace PEAR::Mail::IMAP;
    import ::Exception AS WTF;
    import PEAR::Exception;

    class Imap {
    ...
    }

    All this seems just wrong to me, sorry. And i fully agree with Markus:
    But how to know in advance, e.g. think about other libraries, which
    public classes possibly exist? Isn't this problematic then?
    Let's say i PEAR would have namespaces and there is a class
    PEAR::DB::Mysql, i use this class as:
    <?php
    import PEAR::DB::Mysql;

    class MyDb extends Mysql {
    ...
    }

    And surprisingly someday mysqlnd declares a class named "Mysql", that
    would break my code even though i explicitly declared that i want
    "PEAR::DB::Mysql" not some different Mysql class that comes from some
    fancy extension the admin added today.
    So, why this behaviour?

    regards,
    Benjamin
  • Stanislav Malyshev at Oct 3, 2007 at 8:57 pm
    import ::Exception AS WTF;
    import isn't the means to shuffle standard class names around. Import is
    the means to make names shorter. You already have one Exception in
    global space, you'd have to use other name for other class.

    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Marcus Boerger at Oct 3, 2007 at 3:17 pm
    Hello Benjamin,

    if your exception is so general that it is called exception you can
    obviously simply use exception. If your exception is actually doing
    something than name that something. Meaning the name of the exception class
    is carrying information already. Thus every exception should be specialized.
    Now namespaces are a tool to help you structure your code and avoid naming
    issues. They are not a tool to shorten your names or aid you in typing less.
    And especially namespaces are not there to overcome any naming limitations
    or tricking the naming rules.

    marcus

    Wednesday, October 3, 2007, 11:19:00 AM, you wrote:
    On 02.10.2007, at 22:04, Stanislav Malyshev wrote:
    <?php
    import ::Exception as Notused;
    import Foo::Exception;
    ?>
    I wouldn't actually recommend using such code. If you have
    Foo::Exception just use Foo::Exception - it's short enough :)
    And what if not? "throw App::package::subpackage::Exception" in a
    file that has the namespace "App::package::subpackage" is just wrong,
    importing the Exception as a different name as well. Importing the
    global Exception as something else - i don't even know what to answer
    to that ... this problem makes the whole concept just seem broken, is
    there even a concept? ;)
    regards,
    Benjamin



    Best regards,
    Marcus
  • Benjamin Schulz at Oct 3, 2007 at 3:33 pm

    if your exception is so general that it is called exception you can
    obviously simply use exception.
    Maybe _my_ exception is a generic exception in _my_ framework and
    implements some helper functions i need? But the discussion is not
    about exceptions, it's about classnames that PHP declares i don't
    want to care about, because i put my classes in "namespaces". Maybe i
    don't use DOM and i don't know (i don't want to know) that there is a
    "XsltProcessor" class, i implemented a xsltprocessor myself, a
    generic one ;). So i need to name it GenericXsltProcessor because
    luckily currently there is no other class with that name (yet)? Come
    on ...
    Who knows what classes SPL or some pecl extension will declare some
    day, to me this is like a guarantee that future PHP releases, or
    extensions, will break applications that use namespaces. Sounds quite
    ironic to me.

    regards,
    Benjamin
  • Marcus Boerger at Oct 3, 2007 at 3:44 pm
    Hello Benjamin,

    Wednesday, October 3, 2007, 5:33:21 PM, you wrote:
    if your exception is so general that it is called exception you can
    obviously simply use exception.
    Maybe _my_ exception is a generic exception in _my_ framework and
    implements some helper functions i need?
    The exception example is well an exception. Here you must inherit exception.
    That is simply how PHP works, it is an intended limitation. That said in
    this case you should not use Exception for your own stuff. Name it after
    your library or product, like MyProductException.
    But the discussion is not
    about exceptions, it's about classnames that PHP declares i don't
    want to care about, because i put my classes in "namespaces". Maybe i
    don't use DOM and i don't know (i don't want to know) that there is a
    "XsltProcessor" class, i implemented a xsltprocessor myself, a
    generic one ;). So i need to name it GenericXsltProcessor because
    luckily currently there is no other class with that name (yet)? Come
    on ...
    Right, you might want to have a class DOM because DOM means something
    different for your company.
    Who knows what classes SPL or some pecl extension will declare some
    day, to me this is like a guarantee that future PHP releases, or
    extensions, will break applications that use namespaces. Sounds quite
    ironic to me.
    SPL like any other extension will get it's own namespace or has to use
    prefixed classnames.

    Generally you should do all your stuff in a namespace and do not import
    anything into the global namespace. That should avoid the problem. If not we
    need to fix that.
    regards,
    Benjamin



    Best regards,
    Marcus
  • Benjamin Schulz at Oct 3, 2007 at 4:19 pm

    The exception example is well an exception. Here you must inherit
    exception.
    That is simply how PHP works, it is an intended limitation. That
    said in
    this case you should not use Exception for your own stuff. Name it
    after
    your library or product, like MyProductException.
    Hey, i have an idea, why not use namespaces and call it
    MyProduct::Exception and name everything MyProduct::* - this way i
    won't get in conflict with global classes, oh wait ...

    Right, you might want to have a class DOM because DOM means something
    different for your company.
    Yep, that's why i call it Company::DomDocument, and hey, everyone
    with a different namespace can import it in his file as
    "DomDocument", right? That sounds very comfortable to me. *sigh*

    Generally you should do all your stuff in a namespace and do not
    import
    anything into the global namespace.
    You know that import works per File, right? There is no risk that one
    accidently tries to catch a MyProduct::Exception if he consciously
    used "import MyProduct::Exception;" in his file.

    regards,
    Benjamin
  • Moritz Bechler at Oct 3, 2007 at 5:13 pm
    Hi internals,

    I think you are conentrating on the Exception (and even internal class)
    examples a bit too much. Take the following example:

    --------
    a.php:
    <?php

    // 1. Some library which does not use namespaces and defines a class Foo
    include("b.php");
    // 2. Some part of a library using namespaces
    include("c.php");
    // 3. Some other part of the namespace-using library
    include("d.php");
    ?>
    --------
    b.php:
    <?php
    class Foo {
    }
    ?>
    --------
    c.php:
    <?php
    namespace Bar;

    class Foo {
    }
    ?>
    --------
    d.php:
    <?php
    namespace Bar::Other;
    import Bar::Foo;
    ?>
    --------

    Running this example produces a "Fatal error: Import name 'Foo'
    conflicts with defined class in [...]/d.php on line 4". This problem
    does not only exist with internal classes (which is bad enough - still
    remember DateTime?) but also when some non-namespaced code might be used
    in conjunction.

    As using namespaces is about preventing naming collisions having to
    assume that some class "Foo" does not exist while developing the library
    using namespaces is just inacceptable and makes the namespace
    implementation pretty useless.
    And if you start arguing that you should not use import in cases where
    you don't control the global scope you could pretty much argue not to
    use it at all and remove it (which makes namespaces some eye-candy for
    very long class names).

    best regards

    Moritz Bechler
  • Markus Fischer at Oct 2, 2007 at 8:14 pm
    Hi,

    Greg Beaver wrote:
    Benjamin Schulz wrote:
    Of course i want to refer to my own exception in my application or
    framework as "Exception", and of course i want to use it without
    prefixes (import myStuff::Exception AS MyStuffException), i wouldn't use
    namespace otherwise (there is no other benefit, right?).
    If you are aliasing a class to the same name as an existing class, you
    should also import that class with another name:

    <?php
    import ::Exception as Notused;
    import Foo::Exception;
    ?>

    This is somewhat unintuitive, but is pretty simple to solve.
    But how to know in advance, e.g. think about other libraries, which
    public classes possibly exist? Isn't this problematic then?

    - - Markus
  • Stanislav Malyshev at Oct 2, 2007 at 8:21 pm

    But how to know in advance, e.g. think about other libraries, which
    public classes possibly exist? Isn't this problematic then?
    That should be simple - if you write library using namespaces, no public
    classes would exist except for the internal ones :)

    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Stanislav Malyshev at Oct 2, 2007 at 8:25 pm

    But how to know in advance, e.g. think about other libraries, which
    public classes possibly exist? Isn't this problematic then?
    That should be simple - if you write library using namespaces, no public
    classes would exist except for the internal ones :)
    By "public" I of course mean "belonging to the global space", even
    though it's not correct use of the term :)
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Marcus Boerger at Oct 3, 2007 at 3:11 pm
    Hello Stanislav,

    perfectly right :-)

    Tuesday, October 2, 2007, 10:21:20 PM, you wrote:
    But how to know in advance, e.g. think about other libraries, which
    public classes possibly exist? Isn't this problematic then?
    That should be simple - if you write library using namespaces, no public
    classes would exist except for the internal ones :)
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com



    Best regards,
    Marcus
  • Marcus Boerger at Oct 3, 2007 at 3:10 pm
    Hello Benjamin,

    naive question: how do you define your exception which needs to onherit
    Exception?

    Are you doing this:

    class Exception extends ::exception { }

    ???

    marcus

    p.s.: I think that is really ugly and actually sounds like replacing a core
    functionality...

    Tuesday, October 2, 2007, 1:56:04 PM, you wrote:
    Hi all,
    import Foo::Bar AS DomDocument;
    import Foo::Exception;
    import MyStuff::Dom::XsltProcessor;
    Result in a "Fatal error: Import name '...' conflicts with defined
    class"
    Of course i want to refer to my own exception in my application or
    framework as "Exception", and of course i want to use it without
    prefixes (import myStuff::Exception AS MyStuffException), i wouldn't
    use namespace otherwise (there is no other benefit, right?).
    It's not that one accidentally puts an "import Foo::Exception" in his
    file ..
    Is there a good reason for this bevhaviour that i don't see? There is
    still ::Exception to access the class in the global namespace.
    regards,
    Benjamin



    Best regards,
    Marcus
  • Stanislav Malyshev at Oct 3, 2007 at 7:11 pm

    naive question: how do you define your exception which needs to onherit
    Exception?

    Are you doing this:

    class Exception extends ::exception { }
    Inside namespace - yes, that's the best way. In fact, I think Exception
    extends Exception may work too, but that would be seriously confusing :)

    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedOct 2, '07 at 11:56a
activeOct 3, '07 at 8:57p
posts18
users7
websitephp.net

People

Translate

site design / logo © 2022 Grokbase