FAQ
Hi,

The proposed patch implements namespace support for constants.
It allows to declare constants in namespaces in the same way as in classes.
And these constants may be used in the same may as namespaces' functions.

<?php
namespace Foo;
const BAR = 5;
var_dump(BAR);
?>

<?php
include "foo.php";
var_dump(Foo::BAR);
?>

I am going to commit this patch on Friday.
Any objections?

Thanks. Dmitry.

Search Discussions

  • Dmitry Stogov at Aug 22, 2007 at 10:07 am
    Sorry, The patch was removed.
    Resending it.

    Dmitry.
    -----Original Message-----
    From: Dmitry Stogov
    Sent: Wednesday, August 22, 2007 1:02 PM
    To: 'PHP Internals List'
    Subject: [PHP-DEV] Constans in namesapces


    Hi,

    The proposed patch implements namespace support for
    constants. It allows to declare constants in namespaces in
    the same way as in classes. And these constants may be used
    in the same may as namespaces' functions.

    <?php
    namespace Foo;
    const BAR = 5;
    var_dump(BAR);
    ?>

    <?php
    include "foo.php";
    var_dump(Foo::BAR);
    ?>

    I am going to commit this patch on Friday.
    Any objections?

    Thanks. Dmitry.
  • Johannes Schlüter at Aug 22, 2007 at 12:47 pm
    Hi Dmitry,
    On Wed, 2007-08-22 at 13:02 +0400, Dmitry Stogov wrote:
    Hi,

    The proposed patch implements namespace support for constants.
    It allows to declare constants in namespaces in the same way as in classes.
    And these constants may be used in the same may as namespaces' functions.
    I like the idea. Am I right with the assumption, from scrolling over the
    patch, that "const" outside any namespace would work, too, meaning we
    could get compile-time constants even outside a namespace?

    johannes
  • Dmitry Stogov at Aug 22, 2007 at 1:04 pm
    You can have "const" outside namespaces but they are not real compile-time
    constants.
    They are set during execution in the same way as define() does.

    <?php
    const DIR = dirname(__FILE__);
    echo DIR;
    ?>

    Thanks. Dmitry.
    -----Original Message-----
    From: Johannes Schlьter
    Sent: Wednesday, August 22, 2007 4:48 PM
    To: Dmitry Stogov
    Cc: 'PHP Internals List'
    Subject: Re: [PHP-DEV] Constans in namesapces


    Hi Dmitry,
    On Wed, 2007-08-22 at 13:02 +0400, Dmitry Stogov wrote:
    Hi,

    The proposed patch implements namespace support for constants. It
    allows to declare constants in namespaces in the same way as in
    classes. And these constants may be used in the same may as
    namespaces' functions.
    I like the idea. Am I right with the assumption, from
    scrolling over the patch, that "const" outside any namespace
    would work, too, meaning we could get compile-time constants
    even outside a namespace?

    johannes

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Pierre at Aug 22, 2007 at 1:12 pm

    On 8/22/07, Dmitry Stogov wrote:
    You can have "const" outside namespaces but they are not real compile-time
    constants.
    They are set during execution in the same way as define() does.

    <?php
    const DIR = dirname(__FILE__);
    echo DIR;
    ?>
    Off topic but this const makes me think about hidef (see pecl/hidef).
    It would be nice if we can have them resolved at compile time. At
    least when no instructions are involved in the definition (numbers or
    single quote strings).

    Cheers,
    --Pierre
  • Dmitry Stogov at Aug 22, 2007 at 2:56 pm
    We never resolved constants in compile time, because constants' values may
    be unknown in compile time.

    Thanks. Dmitry.
    -----Original Message-----
    From: Pierre
    Sent: Wednesday, August 22, 2007 5:12 PM
    To: Dmitry Stogov
    Cc: Johannes Schlьter; PHP Internals List
    Subject: Re: [PHP-DEV] Constants in namesapces

    On 8/22/07, Dmitry Stogov wrote:
    You can have "const" outside namespaces but they are not real
    compile-time constants. They are set during execution in
    the same way
    as define() does.

    <?php
    const DIR = dirname(__FILE__);
    echo DIR;
    ?>
    Off topic but this const makes me think about hidef (see
    pecl/hidef). It would be nice if we can have them resolved at
    compile time. At least when no instructions are involved in
    the definition (numbers or single quote strings).

    Cheers,
    --Pierre

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Pierre at Aug 22, 2007 at 3:08 pm

    On 8/22/07, Dmitry Stogov wrote:
    We never resolved constants in compile time,
    I know that, hence my "see pecl hidef" comment.
    because constants' values may
    be unknown in compile time.
    The idea behind that was to get constants like internal constants. If
    it is a integer, a float or a single quote string, it can be known at
    compile time, just like class constants (no expression, function or
    double quotes string).

    --Pierre
  • Antony Dovgal at Aug 22, 2007 at 1:20 pm

    On 22.08.2007 17:03, Dmitry Stogov wrote:
    You can have "const" outside namespaces but they are not real compile-time
    constants.
    They are set during execution in the same way as define() does.

    <?php
    const DIR = dirname(__FILE__);
    echo DIR;
    ?>
    Don't you think it's bad idea to use the same 'const' syntax, but different behavior?
    I believe it would be really confusing for users, as class constants are set in compile time,
    thus 'const DIR = dirname(__FILE__);' is not possible.

    --
    Wbr,
    Antony Dovgal
  • David Zülke at Aug 22, 2007 at 1:28 pm
    yes. keep it consistent. if that means sacrificing features, so be it.


    David



    Am 22.08.2007 um 15:20 schrieb Antony Dovgal:
    On 22.08.2007 17:03, Dmitry Stogov wrote:
    You can have "const" outside namespaces but they are not real
    compile-time
    constants.
    They are set during execution in the same way as define() does.
    <?php
    const DIR = dirname(__FILE__);
    echo DIR;
    ?>
    Don't you think it's bad idea to use the same 'const' syntax, but
    different behavior?
    I believe it would be really confusing for users, as class
    constants are set in compile time, thus 'const DIR = dirname
    (__FILE__);' is not possible.

    --
    Wbr, Antony Dovgal

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Dmitry Stogov at Aug 22, 2007 at 2:57 pm
    Good point.
    We'll need to discuss this.

    Thanks. Dmitry.
    -----Original Message-----
    From: Antony Dovgal
    Sent: Wednesday, August 22, 2007 5:21 PM
    To: Dmitry Stogov
    Cc: 'Johannes Schlьter'; 'PHP Internals List'
    Subject: Re: [PHP-DEV] Constants in namesapces

    On 22.08.2007 17:03, Dmitry Stogov wrote:
    You can have "const" outside namespaces but they are not real
    compile-time constants. They are set during execution in
    the same way
    as define() does.

    <?php
    const DIR = dirname(__FILE__);
    echo DIR;
    ?>
    Don't you think it's bad idea to use the same 'const' syntax,
    but different behavior? I believe it would be really
    confusing for users, as class constants are set in compile time,
    thus 'const DIR = dirname(__FILE__);' is not possible.

    --
    Wbr,
    Antony Dovgal
  • Stanislav Malyshev at Aug 22, 2007 at 5:08 pm

    Don't you think it's bad idea to use the same 'const' syntax, but
    different behavior?
    I believe it would be really confusing for users, as class constants are
    set in compile time, thus 'const DIR = dirname(__FILE__);' is not possible.
    That's a good point. However, "constant constants" - i.e., ones not
    allowing expressions - would be much less useful, since many uses of the
    constants - as used by define() - imply runtime evaluation - such as
    pathes, configuration-derived variables, etc.
    On the other hand, const in classes indeed doesn't allow us to define
    runtime expressions. This is, however, offset by the fact that we have
    per-class variables, where we can store expressions. In namespaces we
    don't have (and probably don't want) per-namespace variables, so if you
    need to keep something like dirname(__FILE__) somewhere inside
    namespace, you have no option.
    We could try to solve this by changing const to some other keyword. The
    downside would be that we'd have further complicated the syntax. We
    could modify define() or add ns_define() which would automagically add
    namespace prefix. More options?

    If anybody has any good idea of how to solve this, suggestions are
    welcome. The summary of the problem is as follows:
    1. We need some syntax to define per-namespace values.
    2. For these values are to be useful they should allow runtime definition
    3. const syntax looks like class constants which allow only compile-time
    definition
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Antony Dovgal at Aug 22, 2007 at 5:40 pm

    On 22.08.2007 21:08, Stanislav Malyshev wrote:
    Don't you think it's bad idea to use the same 'const' syntax, but
    different behavior?
    I believe it would be really confusing for users, as class constants are
    set in compile time, thus 'const DIR = dirname(__FILE__);' is not possible.
    That's a good point. However, "constant constants" - i.e., ones not
    allowing expressions - would be much less useful, since many uses of the
    constants - as used by define() - imply runtime evaluation - such as
    pathes, configuration-derived variables, etc.
    Which basically means class constants are useless in their current state, right?
    On the other hand, const in classes indeed doesn't allow us to define
    runtime expressions. This is, however, offset by the fact that we have
    per-class variables, where we can store expressions. In namespaces we
    don't have (and probably don't want) per-namespace variables, so if you
    need to keep something like dirname(__FILE__) somewhere inside
    namespace, you have no option.
    We could try to solve this by changing const to some other keyword. The
    downside would be that we'd have further complicated the syntax. We
    could modify define() or add ns_define() which would automagically add
    namespace prefix. More options?

    If anybody has any good idea of how to solve this, suggestions are
    welcome. The summary of the problem is as follows:
    1. We need some syntax to define per-namespace values.
    2. For these values are to be useful they should allow runtime definition
    I don't think it's _required_ for the constants to be useful.
    It would be good to have, but not required.
    I prefer consistent behavior vs inconsistency with more features.
    3. const syntax looks like class constants which allow only compile-time
    definition

    --
    Wbr,
    Antony Dovgal
  • Stanislav Malyshev at Aug 22, 2007 at 5:50 pm

    Which basically means class constants are useless in their current
    state, right?
    No, they are useful for some things (pre-defined values) and useless for
    others (expressions). The problem is that in classes we can do these
    other things - with variables. And in global space, with define(). In
    namespaces, we can't.
    I don't think it's _required_ for the constants to be useful.
    Well, depends on how you define requirements. Having out-of-class
    constants is not required either - Java does fine without it :) However,
    thinking about how people would use namespaces, I think it would be
    very useful. And btw we have some precedent of reusing syntax - "static"
    means different things as "static function" and "static variable", and
    very well might to acquire yet another meaning as static:: IIRC. I don't
    say it's necessarily good thing, but it's not without precedent.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Antony Dovgal at Aug 22, 2007 at 6:11 pm

    On 22.08.2007 21:50, Stanislav Malyshev wrote:
    I don't think it's _required_ for the constants to be useful.
    Well, depends on how you define requirements. Having out-of-class
    constants is not required either - Java does fine without it :) However,
    thinking about how people would use namespaces, I think it would be
    very useful.
    I believe useful things should not bring confusion, which is clearly the case.
    We do have runtime constants created with define(), so the critical need in runtime
    namespace constants is quite questionable to me.
    And btw we have some precedent of reusing syntax - "static"
    means different things as "static function" and "static variable", and
    very well might to acquire yet another meaning as static:: IIRC. I don't
    say it's necessarily good thing, but it's not without precedent.
    Inconsistencies and mistakes done in the past cannot be a reason to
    create more of them, so I don't understand why you even mentioned 'static'.

    --
    Wbr,
    Antony Dovgal
  • Stanislav Malyshev at Aug 22, 2007 at 6:46 pm

    We do have runtime constants created with define(), so the critical need
    in runtime namespace constants is quite questionable to me.
    "Critical need" is a matter of definition. You can do
    define(__NAMESPACE__.'::foo', 'bar') but frankly, it sucks. const foo =
    'bar' looks so much better. That said, you are welcome to propose
    non-confusing syntax achieving the same :)
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Antony Dovgal at Aug 22, 2007 at 6:34 pm

    On 22.08.2007 22:25, Stanislav Malyshev wrote:
    We do have runtime constants created with define(), so the critical need
    in runtime namespace constants is quite questionable to me.
    "Critical need" is a matter of definition. You can do
    define(__NAMESPACE__.'::foo', 'bar') but frankly, it sucks. const foo =
    'bar' looks so much better. That said, you are welcome to propose
    non-confusing syntax achieving the same :)
    I propose to define these constants in compile time or change class constants to be defined in runtime.
    Either ways are ok to me.

    --
    Wbr,
    Antony Dovgal
  • Stanislav Malyshev at Aug 22, 2007 at 6:43 pm

    I propose to define these constants in compile time or change class
    constants to be defined in runtime.
    The latter would be hard to do since class definition is a runtime
    thing. Unless we make all classes be defined in runtime (and accept
    slowdown following from it) we don't have any point in time where class
    constants could be defined. Also, we don't have a good way to keep the
    expression and scope necessary for evaluating it.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Stanislav Malyshev at Aug 22, 2007 at 6:48 pm

    The latter would be hard to do since class definition is a runtime
    Read "compile-time" here :)
    thing. Unless we make all classes be defined in runtime (and accept
    slowdown following from it) we don't have any point in time where class
    constants could be defined. Also, we don't have a good way to keep the
    expression and scope necessary for evaluating it.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Dmitry Stogov at Aug 23, 2007 at 9:46 am
    I think we must cut the patch to use only "compile-time" constants in
    namespaces.
    For runtime constants we can use existing define().

    This will fix inconsistency.


    We also can extend define() with additional argument that will allow to
    create namespace constant.

    function define(string $var, mixed $val, bool namespace_constant = false);

    Thanks. Dmitry.

    -----Original Message-----
    From: Stanislav Malyshev
    Sent: Wednesday, August 22, 2007 10:43 PM
    To: Antony Dovgal
    Cc: Dmitry Stogov; 'PHP Internals List'
    Subject: Re: [PHP-DEV] Constants in namesapces

    I propose to define these constants in compile time or change class
    constants to be defined in runtime.
    The latter would be hard to do since class definition is a runtime
    thing. Unless we make all classes be defined in runtime (and accept
    slowdown following from it) we don't have any point in time
    where class
    constants could be defined. Also, we don't have a good way to
    keep the
    expression and scope necessary for evaluating it.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Antony Dovgal at Aug 23, 2007 at 10:15 am

    On 23.08.2007 13:46, Dmitry Stogov wrote:
    I think we must cut the patch to use only "compile-time" constants in
    namespaces.
    For runtime constants we can use existing define().

    This will fix inconsistency.


    We also can extend define() with additional argument that will allow to
    create namespace constant.

    function define(string $var, mixed $val, bool namespace_constant = false);
    Sounds good to me.
    Any other ideas? Anyone?

    --
    Wbr,
    Antony Dovgal
  • Johannes Schlüter at Aug 23, 2007 at 11:57 am
    Hi,
    On Thu, 2007-08-23 at 13:46 +0400, Dmitry Stogov wrote:
    I think we must cut the patch to use only "compile-time" constants in
    namespaces.
    For runtime constants we can use existing define().

    This will fix inconsistency.
    I think that would be good.
    We also can extend define() with additional argument that will allow to
    create namespace constant.

    function define(string $var, mixed $val, bool namespace_constant = false);
    It would be

    function define(string $var, mixed $val,
    bool case_insensitive = false, bool namespace_constant = false);

    since we already have the case-insesitive flag. In my opinion

    define(__NAMESPACE__.'::FOOBAR', $value);

    is good enough and clearer than

    define('FOOBAR', $value, false, true);

    where one has to think what "false" and "true" mean in that context.

    johannes
    Thanks. Dmitry.

    -----Original Message-----
    From: Stanislav Malyshev
    Sent: Wednesday, August 22, 2007 10:43 PM
    To: Antony Dovgal
    Cc: Dmitry Stogov; 'PHP Internals List'
    Subject: Re: [PHP-DEV] Constants in namesapces

    I propose to define these constants in compile time or change class
    constants to be defined in runtime.
    The latter would be hard to do since class definition is a runtime
    thing. Unless we make all classes be defined in runtime (and accept
    slowdown following from it) we don't have any point in time
    where class
    constants could be defined. Also, we don't have a good way to
    keep the
    expression and scope necessary for evaluating it.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Dmitry Stogov at Aug 23, 2007 at 1:10 pm
    I agree with you. define('FOOBAR', $value, false, true) looks terrible.

    define(__NAMESPACE__.'::FOOBAR', $value) will work out of the box.

    The updated patch is attached.

    Thanks. Dmitry.

    -----Original Message-----
    From: Johannes Schlьter
    Sent: Thursday, August 23, 2007 3:56 PM
    To: Dmitry Stogov
    Cc: 'Stanislav Malyshev'; 'Antony Dovgal'; 'PHP Internals List'
    Subject: RE: [PHP-DEV] Constants in namesapces


    Hi,
    On Thu, 2007-08-23 at 13:46 +0400, Dmitry Stogov wrote:
    I think we must cut the patch to use only "compile-time"
    constants in
    namespaces. For runtime constants we can use existing define().

    This will fix inconsistency.
    I think that would be good.
    We also can extend define() with additional argument that
    will allow
    to create namespace constant.

    function define(string $var, mixed $val, bool namespace_constant =
    false);
    It would be

    function define(string $var, mixed $val,
    bool case_insensitive = false, bool namespace_constant = false);

    since we already have the case-insesitive flag. In my opinion

    define(__NAMESPACE__.'::FOOBAR', $value);

    is good enough and clearer than

    define('FOOBAR', $value, false, true);

    where one has to think what "false" and "true" mean in that context.
    johannes
    Thanks. Dmitry.

    -----Original Message-----
    From: Stanislav Malyshev
    Sent: Wednesday, August 22, 2007 10:43 PM
    To: Antony Dovgal
    Cc: Dmitry Stogov; 'PHP Internals List'
    Subject: Re: [PHP-DEV] Constants in namesapces

    I propose to define these constants in compile time or change
    class constants to be defined in runtime.
    The latter would be hard to do since class definition is a runtime
    thing. Unless we make all classes be defined in runtime
    (and accept
    slowdown following from it) we don't have any point in time
    where class
    constants could be defined. Also, we don't have a good way to
    keep the
    expression and scope necessary for evaluating it.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Stanislav Malyshev at Aug 23, 2007 at 7:56 pm
    define(__NAMESPACE__.'::FOOBAR', $value) will work out of the box.
    Yep, works, but looks not so nice either. I have an idea: add an
    operator which prepends __NAMESPACE__.'::'. I.e. say we name if
    ns_fullname (I know, this name sucks, get me better one :), so you'd say:

    define(ns_fullname('FOOBAR'), $value)

    IMHO it looks better. Maybe we can even think about some character to do
    this operator :)
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Antony Dovgal at Aug 23, 2007 at 8:17 pm

    On 23.08.2007 23:56, Stanislav Malyshev wrote:

    define(__NAMESPACE__.'::FOOBAR', $value) will work out of the box.
    Yep, works, but looks not so nice either. I have an idea: add an
    operator which prepends __NAMESPACE__.'::'.
    Special FUNCTION to do "__NAMESPACE__.'::'?!
    Sheesh..
    I.e. say we name if
    ns_fullname (I know, this name sucks, get me better one :), so you'd say:

    define(ns_fullname('FOOBAR'), $value)

    IMHO it looks better. Maybe we can even think about some character to do
    this operator :)

    --
    Wbr,
    Antony Dovgal
  • Stanislav Malyshev at Aug 23, 2007 at 8:30 pm

    Special FUNCTION to do "__NAMESPACE__.'::'?!
    Sheesh..
    Operator, not function.

    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Johannes Schlüter at Aug 23, 2007 at 8:55 pm

    On Thu, 2007-08-23 at 13:30 -0700, Stanislav Malyshev wrote:
    Special FUNCTION to do "__NAMESPACE__.'::'?!
    Sheesh..
    Operator, not function.
    I don't think it's worth having an additional operator. const will work
    for much stuff, and the rest should imo do fine with that
    __NAMESPACE__.'::FOOBAR' thing.

    johannes
  • Gregory Beaver at Aug 23, 2007 at 10:37 pm

    Stanislav Malyshev wrote:

    define(__NAMESPACE__.'::FOOBAR', $value) will work out of the box.
    Yep, works, but looks not so nice either. I have an idea: add an
    operator which prepends __NAMESPACE__.'::'. I.e. say we name if
    ns_fullname (I know, this name sucks, get me better one :), so you'd say:

    define(ns_fullname('FOOBAR'), $value)

    IMHO it looks better. Maybe we can even think about some character to do
    this operator :)
    define_ns('FOOBAR', $value);

    Greg
  • Stanislav Malyshev at Aug 23, 2007 at 10:52 pm
    define_ns('FOOBAR', $value);
    Can be, but there's two downsides:
    1. define_ns would be weird construct - it would be combined
    function/operator
    2. operators with underscores look bad...
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Larry Garfield at Aug 24, 2007 at 5:14 am

    On Thursday 23 August 2007, Stanislav Malyshev wrote:
    define_ns('FOOBAR', $value);
    Can be, but there's two downsides:
    1. define_ns would be weird construct - it would be combined
    function/operator
    2. operators with underscores look bad...
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
    Didn't someone at some point already suggest:

    define('foo', $bar); // runtime, not namespace-affected

    const foo = 'bar'; // compile-time, namespace-affected

    That way the const works the same with the same limitations as a class const
    (which, being inside a class, is namespace-affected), while define() keeps
    working just as it always has.

    --
    Larry Garfield AIM: LOLG42
    larry@garfieldtech.com ICQ: 6817012

    "If nature has made any one thing less susceptible than all others of
    exclusive property, it is the action of the thinking power called an idea,
    which an individual may exclusively possess as long as he keeps it to
    himself; but the moment it is divulged, it forces itself into the possession
    of every one, and the receiver cannot dispossess himself of it." -- Thomas
    Jefferson
  • Richard Lynch at Aug 26, 2007 at 3:40 am

    On Thu, August 23, 2007 5:52 pm, Stanislav Malyshev wrote:
    define_ns('FOOBAR', $value);
    Can be, but there's two downsides:
    1. define_ns would be weird construct - it would be combined
    function/operator
    2. operators with underscores look bad...
    At the risk of starting another packages versus namespace debacle... :-v

    I would have found this easier to grok as:
    ns_define('FOOBAR', $value);

    That may, however, merely be my admittedly twisted world-view.

    I could live with this:
    NSdefine('FOOBAR', $value);

    Disclaimer: I'm the person least likely to use the dang thing, so name
    it whatever you want. :-)

    --
    Some people have a "gift" link here.
    Know what I want?
    I want you to buy a CD from some indie artist.
    http://cdbaby.com/browse/from/lynch
    Yeah, I get a buck. So?
  • Stanislav Malyshev at Aug 23, 2007 at 4:58 pm

    We also can extend define() with additional argument that will allow to
    create namespace constant.

    function define(string $var, mixed $val, bool namespace_constant = false);
    That'd be hard - in runtime, you don't have namespace name. So either we
    should make define() an operator, or pass namespace name to it.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Richard Lynch at Aug 26, 2007 at 3:49 am

    On Wed, August 22, 2007 8:03 am, Dmitry Stogov wrote:
    You can have "const" outside namespaces but they are not real
    compile-time
    constants.
    They are set during execution in the same way as define() does.

    <?php
    const DIR = dirname(__FILE__);
    echo DIR;
    ?>
    You do realize this is going to engender a few zillion threads on
    PHP-General benchmarking the two and endless arguments about which is
    faster/better...

    <?php
    const DIR = dirname(__FILE__);
    define(DIR, dirname(__FILE__);
    ?>

    I personally find it kinda silly to have TWO syntaxes for defining
    constants in the global space, one of which looks like a declarative
    statement in C, which will lead to a whole new swath of arguments
    about what is "better"

    Why is 'define' any different than 'class' or 'function'?

    Seems to me that if you want these namespace thingies that badly, then
    'define' should follow the same rules as any other declarative
    keyword.

    If you 'define' something in the namespace, it's in the namespace.

    If you want global scope, 'define' it outside a namespace and be done
    with it.

    Seems to me you're just complicating things with no real-world need
    here...

    What are your real-world "I need this because..." code samples?

    --
    Some people have a "gift" link here.
    Know what I want?
    I want you to buy a CD from some indie artist.
    http://cdbaby.com/browse/from/lynch
    Yeah, I get a buck. So?
  • Dmitry Stogov at Aug 27, 2007 at 5:39 am
    We already have class constant that use declarative syntax and of course
    define() inside of class doesn't declare class constant.
    The same was done for namespaces.

    Thanks. Dmitry.
    -----Original Message-----
    From: Richard Lynch
    Sent: Sunday, August 26, 2007 7:50 AM
    To: Dmitry Stogov
    Cc: 'PHP Internals List'
    Subject: RE: [PHP-DEV] Constants in namesapces

    On Wed, August 22, 2007 8:03 am, Dmitry Stogov wrote:
    You can have "const" outside namespaces but they are not real
    compile-time constants.
    They are set during execution in the same way as define() does.

    <?php
    const DIR = dirname(__FILE__);
    echo DIR;
    ?>
    You do realize this is going to engender a few zillion
    threads on PHP-General benchmarking the two and endless
    arguments about which is faster/better...

    <?php
    const DIR = dirname(__FILE__);
    define(DIR, dirname(__FILE__);
    ?>

    I personally find it kinda silly to have TWO syntaxes for
    defining constants in the global space, one of which looks
    like a declarative statement in C, which will lead to a whole
    new swath of arguments about what is "better"

    Why is 'define' any different than 'class' or 'function'?

    Seems to me that if you want these namespace thingies that
    badly, then 'define' should follow the same rules as any
    other declarative keyword.

    If you 'define' something in the namespace, it's in the namespace.

    If you want global scope, 'define' it outside a namespace and
    be done with it.

    Seems to me you're just complicating things with no
    real-world need here...

    What are your real-world "I need this because..." code samples?

    --
    Some people have a "gift" link here.
    Know what I want?
    I want you to buy a CD from some indie artist.
    http://cdbaby.com/browse/from/lynch
    Yeah, I get a buck. So?

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Dmitry Stogov at Aug 30, 2007 at 6:10 am
    Hi Richard,

    "const" is usefull to declare "compile-time" constants in current scope
    (class or namespace). The syntax is the same. It is not allowed to use
    functions and variables in such declarations (this ability was proposed but
    then it was removed before commit).

    define() is a runtime function that allows declaring constant at run-time.
    Of course this function defines constants in global scope.

    Thanks. Dmitry.
    -----Original Message-----
    From: Richard Lynch
    Sent: Sunday, August 26, 2007 7:50 AM
    To: Dmitry Stogov
    Cc: 'PHP Internals List'
    Subject: RE: [PHP-DEV] Constants in namesapces

    On Wed, August 22, 2007 8:03 am, Dmitry Stogov wrote:
    You can have "const" outside namespaces but they are not real
    compile-time constants.
    They are set during execution in the same way as define() does.

    <?php
    const DIR = dirname(__FILE__);
    echo DIR;
    ?>
    You do realize this is going to engender a few zillion
    threads on PHP-General benchmarking the two and endless
    arguments about which is faster/better...

    <?php
    const DIR = dirname(__FILE__);
    define(DIR, dirname(__FILE__);
    ?>

    I personally find it kinda silly to have TWO syntaxes for
    defining constants in the global space, one of which looks
    like a declarative statement in C, which will lead to a whole
    new swath of arguments about what is "better"

    Why is 'define' any different than 'class' or 'function'?

    Seems to me that if you want these namespace thingies that
    badly, then 'define' should follow the same rules as any
    other declarative keyword.

    If you 'define' something in the namespace, it's in the namespace.

    If you want global scope, 'define' it outside a namespace and
    be done with it.

    Seems to me you're just complicating things with no
    real-world need here...

    What are your real-world "I need this because..." code samples?

    --
    Some people have a "gift" link here.
    Know what I want?
    I want you to buy a CD from some indie artist.
    http://cdbaby.com/browse/from/lynch
    Yeah, I get a buck. So?

    --
    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
postedAug 22, '07 at 9:08a
activeAug 30, '07 at 6:10a
posts34
users9
websitephp.net

People

Translate

site design / logo © 2022 Grokbase