FAQ
Hi all,

RFC: about class names as values

PHP uses class names as values, but only in a couple of places.
String constanst after the "new" or "instanceof" operator --correct me if
I'm missing others-- are treated as class names.

if( $obj instanceof MyClass ) {
// $obj is instanceof Bar/Foo/MyClass
}

but what happen if the class name is used on other places?

function newInstance($class) {
return new $class;
}

$obj = newInstance( MyClass ); // notice. undefined constant MyClass

so you have to end up by writting....

$obj = newInstance( '\Bar\Foo\MyClass' );

which lacks of any semantic, it's not a class name, it's just a string.

My idea is that PHP could include a constant on each class, a string with
the full qualified class name

echo MyClass::CLASS; // \Bar\Foo\MyClass
$obj = newInstance( MyClass::CLASS );

As the "CLASS" is currently a reserved word is guarantied that nobody is
using as it today.

What do you think about?

Martin Scotta

Search Discussions

  • Johannes Schlüter at Jan 6, 2011 at 1:08 am

    On Wed, 2011-01-05 at 21:53 -0300, Martin Scotta wrote:
    $obj = newInstance( MyClass ); // notice. undefined constant MyClass
    This describes the major change with your idea.

    What happens if a constant MyClass exists?

    Another question is something like this:

    <?php
    function factory($class) {
    return new $class();
    }

    factory( SomeClass );
    ?>


    To proper support this we'd have to make classes first class elements.
    For making this consistent it would make sense to make functions first
    class elements. And best drop the $ in front of variables and create a
    new language. Everything else becomes a mess.

    johannes
  • John LeSueur at Jan 6, 2011 at 1:51 am
    2011/1/5 Johannes Schlüter <johannes@php.net>
    On Wed, 2011-01-05 at 21:53 -0300, Martin Scotta wrote:
    $obj = newInstance( MyClass ); // notice. undefined constant MyClass
    This describes the major change with your idea.

    What happens if a constant MyClass exists?

    Another question is something like this:

    <?php
    function factory($class) {
    return new $class();
    }

    factory( SomeClass );
    ?>


    To proper support this we'd have to make classes first class elements.
    For making this consistent it would make sense to make functions first
    class elements. And best drop the $ in front of variables and create a
    new language. Everything else becomes a mess.

    johannes



    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    I think he's actually proposing creating for each class the magic class
    constant CLASS, so your example becomes:

    <?php

    function factory($class) {
    return new $class();
    }

    factory( SomeClass::CLASS );

    ?>

    This is actually doable without a magic class constant, but requires a
    function or class constant to be declared in each class.

    <?php
    class SomeClass {
    const CLASS = __NAMESPACE__ . '\' . __CLASS__;
    static function getNameWithNSPath()
    {
    return __NAMESPACE__ . '\' . __CLASS__;
    }
    }


    factory( SomeClass::getNameWithNSPath() );
    ?>

    Perhaps this could be simplified with traits, if __NAMESPACE__ and __CLASS__
    work in traits that way. In fact, that's an interesting question, what is
    __NAMESPACE__ in a trait defined in one namespace, then used in a class in a
    different namespace?

    I think the point is that the factory function could exist without any
    knowledge of the namespaces of the classes it would work on. Then, somewhere
    else where the class has been aliased or is otherwise accessible without the
    full namespace path, the developer wouldn't need to specify the full
    namespace path to the factory, but could ask the class itself what it's full
    namespace path was. I don't know that I agree with the idea, but I don't
    think it requires making classes first class elements.

    John
  • Martin Scotta at Jan 6, 2011 at 2:17 pm
    Yes, my intention was to only add a magic constant with the class, similar
    to this

    namespace Bar {
    class Foo {
    const KLASS = __CLASS__;
    }
    }

    namespace Buzz {
    use \Bar\Foo as BazFoo;

    class Bar extends BazFoo {
    const KLASS = __CLASS__;
    }

    $bar = new Bar;
    $baz = new BazFoo;

    var_dump( get_class($baz), BazFoo::KLASS);
    var_dump( get_class($bar), Bar::KLASS );
    }

    This is 100% valid PHP 5.3.3 code, but that includes a lot of effort from
    the developer. Someone miss to include the KLASS constant on a class and the
    result is undefined.

    If that PHP could add a magic constant --named CLASS or whatever you like--
    to each class it will reduce the amount of class names hardcoded onto
    strings, probably to zero.

    The only issue that I found today is related to interfaces. I'm not sure if
    they should include this sort of magic constant, but I would rather include
    them just for consistency but, as I previously said, I'm not sure about this
    one.

    Martin Scotta


    2011/1/5 John LeSueur <john.lesueur@gmail.com>

    2011/1/5 Johannes Schlüter <johannes@php.net>
    On Wed, 2011-01-05 at 21:53 -0300, Martin Scotta wrote:
    $obj = newInstance( MyClass ); // notice. undefined constant MyClass
    This describes the major change with your idea.

    What happens if a constant MyClass exists?

    Another question is something like this:

    <?php
    function factory($class) {
    return new $class();
    }

    factory( SomeClass );
    ?>


    To proper support this we'd have to make classes first class elements.
    For making this consistent it would make sense to make functions first
    class elements. And best drop the $ in front of variables and create a
    new language. Everything else becomes a mess.

    johannes



    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    I think he's actually proposing creating for each class the magic class
    constant CLASS, so your example becomes:


    <?php

    function factory($class) {
    return new $class();
    }

    factory( SomeClass::CLASS );

    ?>

    This is actually doable without a magic class constant, but requires a
    function or class constant to be declared in each class.

    <?php
    class SomeClass {
    const CLASS = __NAMESPACE__ . '\' . __CLASS__;
    static function getNameWithNSPath()
    {
    return __NAMESPACE__ . '\' . __CLASS__;
    }
    }


    factory( SomeClass::getNameWithNSPath() );
    ?>

    Perhaps this could be simplified with traits, if __NAMESPACE__ and
    __CLASS__ work in traits that way. In fact, that's an interesting question,
    what is __NAMESPACE__ in a trait defined in one namespace, then used in a
    class in a different namespace?

    I think the point is that the factory function could exist without any
    knowledge of the namespaces of the classes it would work on. Then, somewhere
    else where the class has been aliased or is otherwise accessible without the
    full namespace path, the developer wouldn't need to specify the full
    namespace path to the factory, but could ask the class itself what it's full
    namespace path was. I don't know that I agree with the idea, but I don't
    think it requires making classes first class elements.

    John
  • Martin Scotta at Jan 7, 2011 at 3:03 pm
    Hi all,

    I've wrote a simple snippet to show the importance of this feature.
    This little piece of code, at a glance, tries to instantiate 2 same objects
    by different ways, but fails because of a silently code bug.

    -- start of code
    <?php
    namespace B\C {
    class Foo {
    function test() {
    echo __CLASS__, PHP_EOL;
    }
    }
    }

    namespace A\B\C {
    class Foo {
    function test() {
    echo __CLASS__, PHP_EOL;
    }
    }
    }

    namespace A {
    $f1 = new B\C\Foo;
    $f1->test();

    $class = 'B\C\Foo';
    $f2 = new $class;
    $f2->test();
    }
    ?>
    --- end of code


    This works this way because class names in strings are treated as fully
    qualified class names.

    Although this script was created to reproduce an programmer error it helps
    to show the need for a safe way to pass class name as a values.

    As a side note, '\A\B\C\Foo' refers to the same class that 'A\B\C\Foo', but
    the string comparison will return false

    Regards,
    Martin Scotta
    On Thu, Jan 6, 2011 at 11:47 AM, Michael Morris wrote:

    +1 to this. In a similar vein (and similar reasons) consider ::PARENT as
    well. Since parent is also a reserved word here too is a case where no code
    in existence will be in conflict. So

    class Foo {}
    class Bar extends Foo{}

    echo Bar::PARENT; // "Foo"

    2011/1/6 Martin Scotta <martinscotta@gmail.com>

    Yes, my intention was to only add a magic constant with the class, similar
    to this

    namespace Bar {
    class Foo {
    const KLASS = __CLASS__;
    }
    }

    namespace Buzz {
    use \Bar\Foo as BazFoo;

    class Bar extends BazFoo {
    const KLASS = __CLASS__;
    }

    $bar = new Bar;
    $baz = new BazFoo;

    var_dump( get_class($baz), BazFoo::KLASS);
    var_dump( get_class($bar), Bar::KLASS );
    }

    This is 100% valid PHP 5.3.3 code, but that includes a lot of effort from
    the developer. Someone miss to include the KLASS constant on a class and
    the
    result is undefined.

    If that PHP could add a magic constant --named CLASS or whatever you
    like--
    to each class it will reduce the amount of class names hardcoded onto
    strings, probably to zero.

    The only issue that I found today is related to interfaces. I'm not sure
    if
    they should include this sort of magic constant, but I would rather
    include
    them just for consistency but, as I previously said, I'm not sure about
    this
    one.

    Martin Scotta


    2011/1/5 John LeSueur <john.lesueur@gmail.com>

    2011/1/5 Johannes Schlüter <johannes@php.net>
    On Wed, 2011-01-05 at 21:53 -0300, Martin Scotta wrote:
    $obj = newInstance( MyClass ); // notice. undefined constant MyClass
    This describes the major change with your idea.

    What happens if a constant MyClass exists?

    Another question is something like this:

    <?php
    function factory($class) {
    return new $class();
    }

    factory( SomeClass );
    ?>


    To proper support this we'd have to make classes first class elements.
    For making this consistent it would make sense to make functions first
    class elements. And best drop the $ in front of variables and create a
    new language. Everything else becomes a mess.

    johannes



    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    I think he's actually proposing creating for each class the magic class
    constant CLASS, so your example becomes:


    <?php

    function factory($class) {
    return new $class();
    }

    factory( SomeClass::CLASS );

    ?>

    This is actually doable without a magic class constant, but requires a
    function or class constant to be declared in each class.

    <?php
    class SomeClass {
    const CLASS = __NAMESPACE__ . '\' . __CLASS__;
    static function getNameWithNSPath()
    {
    return __NAMESPACE__ . '\' . __CLASS__;
    }
    }


    factory( SomeClass::getNameWithNSPath() );
    ?>

    Perhaps this could be simplified with traits, if __NAMESPACE__ and
    __CLASS__ work in traits that way. In fact, that's an interesting question,
    what is __NAMESPACE__ in a trait defined in one namespace, then used in a
    class in a different namespace?

    I think the point is that the factory function could exist without any
    knowledge of the namespaces of the classes it would work on. Then, somewhere
    else where the class has been aliased or is otherwise accessible without the
    full namespace path, the developer wouldn't need to specify the full
    namespace path to the factory, but could ask the class itself what it's full
    namespace path was. I don't know that I agree with the idea, but I don't
    think it requires making classes first class elements.

    John
  • Ben Schmidt at Jan 8, 2011 at 10:21 am
    I think doing something like this is a good idea for classes and
    interfaces.

    Ben.


    On 7/01/11 1:16 AM, Martin Scotta wrote:
    Yes, my intention was to only add a magic constant with the class, similar
    to this

    namespace Bar {
    class Foo {
    const KLASS = __CLASS__;
    }
    }

    namespace Buzz {
    use \Bar\Foo as BazFoo;

    class Bar extends BazFoo {
    const KLASS = __CLASS__;
    }

    $bar = new Bar;
    $baz = new BazFoo;

    var_dump( get_class($baz), BazFoo::KLASS);
    var_dump( get_class($bar), Bar::KLASS );
    }

    This is 100% valid PHP 5.3.3 code, but that includes a lot of effort from
    the developer. Someone miss to include the KLASS constant on a class and the
    result is undefined.

    If that PHP could add a magic constant --named CLASS or whatever you like--
    to each class it will reduce the amount of class names hardcoded onto
    strings, probably to zero.

    The only issue that I found today is related to interfaces. I'm not sure if
    they should include this sort of magic constant, but I would rather include
    them just for consistency but, as I previously said, I'm not sure about this
    one.

    Martin Scotta


    2011/1/5 John LeSueur<john.lesueur@gmail.com>

    2011/1/5 Johannes Schlüter<johannes@php.net>
    On Wed, 2011-01-05 at 21:53 -0300, Martin Scotta wrote:
    $obj = newInstance( MyClass ); // notice. undefined constant MyClass
    This describes the major change with your idea.

    What happens if a constant MyClass exists?

    Another question is something like this:

    <?php
    function factory($class) {
    return new $class();
    }

    factory( SomeClass );
    ?>


    To proper support this we'd have to make classes first class elements.
    For making this consistent it would make sense to make functions first
    class elements. And best drop the $ in front of variables and create a
    new language. Everything else becomes a mess.

    johannes



    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    I think he's actually proposing creating for each class the magic class
    constant CLASS, so your example becomes:


    <?php

    function factory($class) {
    return new $class();
    }

    factory( SomeClass::CLASS );

    ?>

    This is actually doable without a magic class constant, but requires a
    function or class constant to be declared in each class.

    <?php
    class SomeClass {
    const CLASS = __NAMESPACE__ . '\' . __CLASS__;
    static function getNameWithNSPath()
    {
    return __NAMESPACE__ . '\' . __CLASS__;
    }
    }


    factory( SomeClass::getNameWithNSPath() );
    ?>

    Perhaps this could be simplified with traits, if __NAMESPACE__ and
    __CLASS__ work in traits that way. In fact, that's an interesting question,
    what is __NAMESPACE__ in a trait defined in one namespace, then used in a
    class in a different namespace?

    I think the point is that the factory function could exist without any
    knowledge of the namespaces of the classes it would work on. Then, somewhere
    else where the class has been aliased or is otherwise accessible without the
    full namespace path, the developer wouldn't need to specify the full
    namespace path to the factory, but could ask the class itself what it's full
    namespace path was. I don't know that I agree with the idea, but I don't
    think it requires making classes first class elements.

    John
  • Martin Vium at Jan 9, 2011 at 2:08 pm
    I think adding a magic constant or method for getting the class name would
    be usefull in many scenarios, when referencing a specific class (e.g.
    factories, configurations). It would also work well with namespaces and
    refactoring tools e.g.:

    $mock = $this->getMock('\\My\\Custom\\Namespace\\MyClass');

    vs.

    use My\Custom\Namespace\MyClass;
    $mock = $this->getMock(MyClass::CLASS);
    On 8 January 2011 11:21, Ben Schmidt wrote:

    I think doing something like this is a good idea for classes and
    interfaces.

    Ben.



    On 7/01/11 1:16 AM, Martin Scotta wrote:

    Yes, my intention was to only add a magic constant with the class, similar
    to this

    namespace Bar {
    class Foo {
    const KLASS = __CLASS__;
    }
    }

    namespace Buzz {
    use \Bar\Foo as BazFoo;

    class Bar extends BazFoo {
    const KLASS = __CLASS__;
    }

    $bar = new Bar;
    $baz = new BazFoo;

    var_dump( get_class($baz), BazFoo::KLASS);
    var_dump( get_class($bar), Bar::KLASS );
    }

    This is 100% valid PHP 5.3.3 code, but that includes a lot of effort from
    the developer. Someone miss to include the KLASS constant on a class and
    the
    result is undefined.

    If that PHP could add a magic constant --named CLASS or whatever you
    like--
    to each class it will reduce the amount of class names hardcoded onto
    strings, probably to zero.

    The only issue that I found today is related to interfaces. I'm not sure
    if
    they should include this sort of magic constant, but I would rather
    include
    them just for consistency but, as I previously said, I'm not sure about
    this
    one.

    Martin Scotta


    2011/1/5 John LeSueur<john.lesueur@gmail.com>

    2011/1/5 Johannes Schlüter<johannes@php.net>
    On Wed, 2011-01-05 at 21:53 -0300, Martin Scotta wrote:

    $obj = newInstance( MyClass ); // notice. undefined constant MyClass
    This describes the major change with your idea.

    What happens if a constant MyClass exists?

    Another question is something like this:

    <?php
    function factory($class) {
    return new $class();
    }

    factory( SomeClass );
    ?>


    To proper support this we'd have to make classes first class elements.
    For making this consistent it would make sense to make functions first
    class elements. And best drop the $ in front of variables and create a
    new language. Everything else becomes a mess.

    johannes



    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    I think he's actually proposing creating for each class the magic class
    constant CLASS, so your example becomes:


    <?php

    function factory($class) {
    return new $class();
    }

    factory( SomeClass::CLASS );

    ?>

    This is actually doable without a magic class constant, but requires a
    function or class constant to be declared in each class.

    <?php
    class SomeClass {
    const CLASS = __NAMESPACE__ . '\' . __CLASS__;
    static function getNameWithNSPath()
    {
    return __NAMESPACE__ . '\' . __CLASS__;
    }
    }


    factory( SomeClass::getNameWithNSPath() );
    ?>

    Perhaps this could be simplified with traits, if __NAMESPACE__ and
    __CLASS__ work in traits that way. In fact, that's an interesting
    question,
    what is __NAMESPACE__ in a trait defined in one namespace, then used in a
    class in a different namespace?

    I think the point is that the factory function could exist without any
    knowledge of the namespaces of the classes it would work on. Then,
    somewhere
    else where the class has been aliased or is otherwise accessible without
    the
    full namespace path, the developer wouldn't need to specify the full
    namespace path to the factory, but could ask the class itself what it's
    full
    namespace path was. I don't know that I agree with the idea, but I don't
    think it requires making classes first class elements.

    John

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    --
    Mvh
    Martin Vium
    Senior System Arkitekt
    Sitevision
  • Martin Scotta at Jan 13, 2011 at 3:22 pm
    Hi all,

    I don't know how the internal development process of PHP works.

    First at all: was this feature approved?

    if that is a "yes"...
    is this feature going to be scheduled for some release?
    Is it supposed that I will submit a patch?

    Thanks you all,
    Martin Scotta

    On Sun, Jan 9, 2011 at 11:07 AM, Martin Vium wrote:

    I think adding a magic constant or method for getting the class name would
    be usefull in many scenarios, when referencing a specific class (e.g.
    factories, configurations). It would also work well with namespaces and
    refactoring tools e.g.:

    $mock = $this->getMock('\\My\\Custom\\Namespace\\MyClass');

    vs.

    use My\Custom\Namespace\MyClass;
    $mock = $this->getMock(MyClass::CLASS);
    On 8 January 2011 11:21, Ben Schmidt wrote:

    I think doing something like this is a good idea for classes and
    interfaces.

    Ben.



    On 7/01/11 1:16 AM, Martin Scotta wrote:

    Yes, my intention was to only add a magic constant with the class,
    similar
    to this

    namespace Bar {
    class Foo {
    const KLASS = __CLASS__;
    }
    }

    namespace Buzz {
    use \Bar\Foo as BazFoo;

    class Bar extends BazFoo {
    const KLASS = __CLASS__;
    }

    $bar = new Bar;
    $baz = new BazFoo;

    var_dump( get_class($baz), BazFoo::KLASS);
    var_dump( get_class($bar), Bar::KLASS );
    }

    This is 100% valid PHP 5.3.3 code, but that includes a lot of effort
    from
    the developer. Someone miss to include the KLASS constant on a class and
    the
    result is undefined.

    If that PHP could add a magic constant --named CLASS or whatever you
    like--
    to each class it will reduce the amount of class names hardcoded onto
    strings, probably to zero.

    The only issue that I found today is related to interfaces. I'm not sure
    if
    they should include this sort of magic constant, but I would rather
    include
    them just for consistency but, as I previously said, I'm not sure about
    this
    one.

    Martin Scotta


    2011/1/5 John LeSueur<john.lesueur@gmail.com>

    2011/1/5 Johannes Schlüter<johannes@php.net>
    On Wed, 2011-01-05 at 21:53 -0300, Martin Scotta wrote:

    $obj = newInstance( MyClass ); // notice. undefined constant MyClass
    This describes the major change with your idea.

    What happens if a constant MyClass exists?

    Another question is something like this:

    <?php
    function factory($class) {
    return new $class();
    }

    factory( SomeClass );
    ?>


    To proper support this we'd have to make classes first class elements.
    For making this consistent it would make sense to make functions first
    class elements. And best drop the $ in front of variables and create a
    new language. Everything else becomes a mess.

    johannes



    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    I think he's actually proposing creating for each class the magic
    class
    constant CLASS, so your example becomes:


    <?php

    function factory($class) {
    return new $class();
    }

    factory( SomeClass::CLASS );

    ?>

    This is actually doable without a magic class constant, but requires a
    function or class constant to be declared in each class.

    <?php
    class SomeClass {
    const CLASS = __NAMESPACE__ . '\' . __CLASS__;
    static function getNameWithNSPath()
    {
    return __NAMESPACE__ . '\' . __CLASS__;
    }
    }


    factory( SomeClass::getNameWithNSPath() );
    ?>

    Perhaps this could be simplified with traits, if __NAMESPACE__ and
    __CLASS__ work in traits that way. In fact, that's an interesting
    question,
    what is __NAMESPACE__ in a trait defined in one namespace, then used in
    a
    class in a different namespace?

    I think the point is that the factory function could exist without any
    knowledge of the namespaces of the classes it would work on. Then,
    somewhere
    else where the class has been aliased or is otherwise accessible
    without
    the
    full namespace path, the developer wouldn't need to specify the full
    namespace path to the factory, but could ask the class itself what it's
    full
    namespace path was. I don't know that I agree with the idea, but I
    don't
    think it requires making classes first class elements.

    John

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    --
    Mvh
    Martin Vium
    Senior System Arkitekt
    Sitevision
  • Chad Fulton at Jan 13, 2011 at 6:30 pm
    Take this with a grain of salt, but:
    On Thu, Jan 13, 2011 at 7:22 AM, Martin Scotta wrote:
    Hi all,

    I don't know how the internal development process of PHP works.

    First at all: was this feature approved?
    From my experience, don't consider something "approved" until it's in
    SVN, and even then maybe not (e.g. type hinting...), regardless of how
    many people say "I think that sounds like a good idea".
    if that is a "yes"...
    is this feature going to be scheduled for some release?
    See below.
    Is it supposed that I will submit a patch?
    Mostly, the burden is on the person requesting a feature to submit a
    patch, if for no other reason than that everyone is busy and that, as
    the requester, you probably have the most interest in getting the
    feature implemented.

    Once a patch is out there, you're going to need to convince at least
    one core dev to get behind your idea, since they are in the position
    of getting it into SVN, and they have the best big picture view of
    PHP. The core devs do often seem happy to help improve patches, if
    they think they're worthwhile.

    Then, perhaps it will get into SVN if a core dev likes it and no core
    devs oppose it too much.
    Then, perhaps it will be scheduled for a release.
    Thanks you all,
    Martin Scotta
  • Adi Nita at Jan 7, 2011 at 9:33 am
    Hi,

    To proper support this we'd have to make classes first class elements.
    For making this consistent it would make sense to make functions first
    class elements. And best drop the $ in front of variables and create a
    new language. Everything else becomes a mess.
    Closures are first-class citizens and it seems natural that they are so.
    Perhaps we should rethink what consistency means for PHP. I don't see any
    good reason why first-class objects could be evil, except that the $ could
    indeed be a problem.

    Regards,
    Adrian



    2011/1/6 Johannes Schlüter <johannes@php.net>
    On Wed, 2011-01-05 at 21:53 -0300, Martin Scotta wrote:
    $obj = newInstance( MyClass ); // notice. undefined constant MyClass
    This describes the major change with your idea.

    What happens if a constant MyClass exists?

    Another question is something like this:

    <?php
    function factory($class) {
    return new $class();
    }

    factory( SomeClass );
    ?>


    To proper support this we'd have to make classes first class elements.
    For making this consistent it would make sense to make functions first
    class elements. And best drop the $ in front of variables and create a
    new language. Everything else becomes a mess.

    johannes



    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedJan 6, '11 at 12:53a
activeJan 13, '11 at 6:30p
posts10
users7
websitephp.net

People

Translate

site design / logo © 2019 Grokbase