FAQ
*The Problem (as defined by Greg):*

foo.php:
<?php
namespace one::step;
function two(){}

namespace one;
class step {
static function two(){}
}
?>

main.php:
<?php
include 'foo.php';
// is this class one::step or namespace one::step?
one::step::two();
?>


*A Simpler Solution*
Force userland / general naming conventions in PHP.

# namespaces are always lowercase
# functions are always lowercase
# classes are always CamelCaps with initial uppercase letter enforced

thus:
//this is always the function two in namespace one::step
one::step::two();
//this is always the method two of class step in namespace one
one::Step::two();

thoughts, opinions, reasons why it wouldn't work?

regards,

nathan

Search Discussions

  • Ron Rademaker at Oct 17, 2008 at 10:58 am

    Nathan Rixham wrote:
    thus:
    //this is always the function two in namespace one::step
    one::step::two();
    //this is always the method two of class step in namespace one
    one::Step::two();

    thoughts, opinions, reasons why it wouldn't work?
    Though: this will break a awful lot of existing code
    Opinion: bad idea

    Ron

    regards,

    nathan
  • Derick Rethans at Oct 17, 2008 at 11:02 am

    On Fri, 17 Oct 2008, Nathan Rixham wrote:

    thoughts, opinions, reasons why it wouldn't work?
    Posts like this want me to shutdown this list, start a new one, hide it,
    and make it invite only.

    Derick
  • Vesselin Kenashkov at Oct 17, 2008 at 11:02 am
    AFAIK the classes and the namespaces both are case insensitive. This means a
    major change (to make them to be kept in a sensitive way) and will break the
    code that depends on the insensibility.
    IMHO - bad idea.
    And besides the casing usially is used to enforce good coding practices, not
    language features.
    On Fri, Oct 17, 2008 at 1:53 PM, Nathan Rixham wrote:

    *The Problem (as defined by Greg):*

    foo.php:
    <?php
    namespace one::step;
    function two(){}

    namespace one;
    class step {
    static function two(){}
    }
    ?>

    main.php:
    <?php
    include 'foo.php';
    // is this class one::step or namespace one::step?
    one::step::two();
    ?>


    *A Simpler Solution*
    Force userland / general naming conventions in PHP.

    # namespaces are always lowercase
    # functions are always lowercase
    # classes are always CamelCaps with initial uppercase letter enforced

    thus:
    //this is always the function two in namespace one::step
    one::step::two();
    //this is always the method two of class step in namespace one
    one::Step::two();

    thoughts, opinions, reasons why it wouldn't work?

    regards,

    nathan

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

    --
    Vesselin Kenashkov
    developer at
    www.webstudiobulgaria.com
  • Ronald Chmara at Oct 18, 2008 at 4:37 am

    On Oct 17, 2008, at 3:53 AM, Nathan Rixham wrote:
    *A Simpler Solution*
    Force userland / general naming conventions in PHP.

    # namespaces are always lowercase
    # functions are always lowercase
    # classes are always CamelCaps with initial uppercase letter enforced

    thus:
    //this is always the function two in namespace one::step
    one::step::two();
    //this is always the method two of class step in namespace one
    one::Step::two();

    thoughts, opinions, reasons why it wouldn't work?
    Assuming this is a real question:

    1. PHP is heading towards broad i18n. How do you "uppercase" or
    "lowercase" written languages that don't have a concept of case?

    2. PHP was designed for wide adoption, and the authors of libraries
    often used function and class cases that matched their library. So,
    PHP case smashes, to Handle the problem of pg_pconnect (all smashed),
    PG_pConnect (EXTENSION_argumentAction), Pg_Pconnect (first letter
    ucase), etc. etc. etc.
    Right now this all works. Changing it would break, well, darned near
    *everything*.

    3. The vast majority of user operating systems (and filesystems) out
    there do *NOT*, I repeat, do *NOT* all handle case in the same way, a
    sane way. Windows boxes are still lugging around DOS/VMS legacy with
    UPPERCAS.$1 files, Macs have their own breed of jollies as well, and
    anything that autoloads (such as namespace code) needs to handle all
    of these.

    Assuming that this is "A Modest Proposal":
    1. It needs to be more over the top to be funny to a broad, multi-
    lingual, global, audience.

    For example, you might have suggested that we add an include_instead
    () operator, so somebody who wants to use a function/method which is
    located in '/var/location1/file_class.inc', rather than the already
    loaded function/method in '/var/location2/file_functions.inc', can
    override an existing function/method, and for giggles, you might
    suggest that the operator have the power to override all internal
    functions, but just for local execution scope, spawning a new process/
    thread for each invocation, so a blog post can have 30-80 thousand
    processes with different scopes.... to render a web page.

    Okay, I'm shutting up now. :)

    -Bop
  • Nathan Rixham at Oct 18, 2008 at 3:09 pm

    Ronald Chmara wrote:
    On Oct 17, 2008, at 3:53 AM, Nathan Rixham wrote:

    *A Simpler Solution*
    Force userland / general naming conventions in PHP.

    # namespaces are always lowercase
    # functions are always lowercase
    # classes are always CamelCaps with initial uppercase letter enforced

    thus:
    //this is always the function two in namespace one::step
    one::step::two();
    //this is always the method two of class step in namespace one
    one::Step::two();

    thoughts, opinions, reasons why it wouldn't work?
    Assuming this is a real question:

    1. PHP is heading towards broad i18n. How do you "uppercase" or
    "lowercase" written languages that don't have a concept of case?

    2. PHP was designed for wide adoption, and the authors of libraries
    often used function and class cases that matched their library. So,
    PHP case smashes, to Handle the problem of pg_pconnect (all smashed),
    PG_pConnect (EXTENSION_argumentAction), Pg_Pconnect (first letter
    ucase), etc. etc. etc.
    Right now this all works. Changing it would break, well, darned near
    *everything*.

    3. The vast majority of user operating systems (and filesystems) out
    there do *NOT*, I repeat, do *NOT* all handle case in the same way, a
    sane way. Windows boxes are still lugging around DOS/VMS legacy with
    UPPERCAS.$1 files, Macs have their own breed of jollies as well, and
    anything that autoloads (such as namespace code) needs to handle all
    of these.

    Assuming that this is "A Modest Proposal":
    1. It needs to be more over the top to be funny to a broad,
    multi-lingual, global, audience.

    For example, you might have suggested that we add an include_instead()
    operator, so somebody who wants to use a function/method which is
    located in '/var/location1/file_class.inc', rather than the already
    loaded function/method in '/var/location2/file_functions.inc', can
    override an existing function/method, and for giggles, you might
    suggest that the operator have the power to override all internal
    functions, but just for local execution scope, spawning a new
    process/thread for each invocation, so a blog post can have 30-80
    thousand processes with different scopes.... to render a web page.

    Okay, I'm shutting up now. :)

    -Bop
    Thanks Bop,

    After more thought I came to pretty much the same thoughts - received
    some heavy replies but then that's my own fault for treating the
    internals list the brainstorming room at work!

    I jump the gun often and write before thinking things through 100%; even
    even I can see the namespace problem clearly enough to know that the
    problem lies in php being both a procedural and OOP language, unless you
    remove one or the other from namespaces there is always going to be a
    level of ambiguity somewhere; IMO Greg's solution #2 (introducing ::: to
    mark the end of a namespace) and stas' proposal #1 are the best I've
    seen. Personally though I'd love to see stas' #1 get implemented and
    "->" used for all functions in a namespace so..
    one::step::two(); //always static method of class
    one::step->two(); //always function of namespace.

    But it's still ambiguous (only in a rarely though) - if an object with a
    method "two" is assigned to the static variable of a class called one
    then problem comes back.

    I'd love to see a "perfect" solution; but know enough to realise it
    isn't going to come from me (and may well be impossible) so bailing out.

    I have to say this; the reason people like me pop on to internals and
    give brainstorming not thoroughly thought through (or discussed)
    opinions, is because there isn't a public "forum" for that kind of
    thing, if there was a place where userland and the internal's could meet
    up to even just discuss or thrash out ideas, get opinions, votes,
    whatever then it would alleviate the problem.

    Regards & Happy Weekend

    Nathan

    --

    nathan ( nathan@kraya.co.uk )
    {
    Senior Web Developer
    php + java + flex + xmpp + xml + ecmascript
    web development edinburgh | http://kraya.co.uk/
    }
  • Gregory Beaver at Oct 18, 2008 at 3:45 pm

    Nathan Rixham wrote:
    seen. Personally though I'd love to see stas' #1 get implemented and
    "->" used for all functions in a namespace so..
    one::step::two(); //always static method of class
    one::step->two(); //always function of namespace.

    But it's still ambiguous (only in a rarely though) - if an object with a
    method "two" is assigned to the static variable of a class called one
    then problem comes back.
    First of all, this is not going to happen (voted down). Second of all

    one::$step

    is how static variables are accessed, not one::step. So there is no
    potential for conflict.

    Greg
  • Nathan Rixham at Oct 18, 2008 at 4:32 pm

    Gregory Beaver wrote:
    Nathan Rixham wrote:
    seen. Personally though I'd love to see stas' #1 get implemented and
    "->" used for all functions in a namespace so..
    one::step::two(); //always static method of class
    one::step->two(); //always function of namespace.

    But it's still ambiguous (only in a rarely though) - if an object with a
    method "two" is assigned to the static variable of a class called one
    then problem comes back.
    First of all, this is not going to happen (voted down). Second of all

    one::$step

    is how static variables are accessed, not one::step. So there is no
    potential for conflict.

    Greg
    right enough; there is no conflict *joy*; and it's not introducing any
    new separator's into php, and I think it makes logical sense /ponders/

    I've been flittering between java, as3 and php all week and ended up
    highly confused, ditsy and using the wrong syntax everywhere - so
    apologies for my ramblings!

    cheers for the reply; and thanks for all you're hard work on the
    namespaces; the RFC you wrote on the wiki really outlined the problem
    perfectly and made it more accessible to the masses.

    Many Regards

    Nath

    --

    nathan ( nathan@kraya.co.uk )
    {
    Senior Web Developer
    php + java + flex + xmpp + xml + ecmascript
    web development edinburgh | http://kraya.co.uk/
    }

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedOct 17, '08 at 10:53a
activeOct 18, '08 at 4:32p
posts8
users7
websitephp.net

People

Translate

site design / logo © 2022 Grokbase