FAQ
hi,

would it be possible to "clean up" the naming while being at it?

I would prefer longer but clearer/less confusing names rather than
trying to reduce the type strokes.

For example:

ZVAL_ARR() > ZVAL_ARRAY
ZVAL_NEW_ARR() > ZVAL_NEW_ARRAY (btw, ZVAL_NEW_ARRAY is wrongly
documented in the wiki draft, section about arrays)

Other engine's APIs use full names, to go back and forth between these
convention is error prone and not too clean. Thoughts?

Yes, it is a detail, but better to fix this now than latter :)

Cheers,
--
Pierre

@pierrejoye | http://www.libgd.org

Search Discussions

  • Dmitry Stogov at May 7, 2014 at 10:33 am
    I would be just glad. Having clear uniform naming would be fine.
    We should just come to agreement about the actual names and I don't think
    it's a big problem.

    Thanks. Dmitry.

    On Wed, May 7, 2014 at 12:54 PM, Pierre Joye wrote:

    hi,

    would it be possible to "clean up" the naming while being at it?

    I would prefer longer but clearer/less confusing names rather than
    trying to reduce the type strokes.

    For example:

    ZVAL_ARR() > ZVAL_ARRAY
    ZVAL_NEW_ARR() > ZVAL_NEW_ARRAY (btw, ZVAL_NEW_ARRAY is wrongly
    documented in the wiki draft, section about arrays)

    Other engine's APIs use full names, to go back and forth between these
    convention is error prone and not too clean. Thoughts?

    Yes, it is a detail, but better to fix this now than latter :)

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Marc Bennewitz at May 7, 2014 at 5:57 pm
    Hi,

    I would also prefer to name it was it represents. I mean a ZVAL
    represents a PHP typed value and not a C typed one. So for example
    IS_LONG would be IS_INTEGER and IS_DOUBLE would become IS_FLOAT.

    Marc
    On 07.05.2014 12:33, Dmitry Stogov wrote:
    I would be just glad. Having clear uniform naming would be fine.
    We should just come to agreement about the actual names and I don't think
    it's a big problem.

    Thanks. Dmitry.

    On Wed, May 7, 2014 at 12:54 PM, Pierre Joye wrote:

    hi,

    would it be possible to "clean up" the naming while being at it?

    I would prefer longer but clearer/less confusing names rather than
    trying to reduce the type strokes.

    For example:

    ZVAL_ARR() > ZVAL_ARRAY
    ZVAL_NEW_ARR() > ZVAL_NEW_ARRAY (btw, ZVAL_NEW_ARRAY is wrongly
    documented in the wiki draft, section about arrays)

    Other engine's APIs use full names, to go back and forth between these
    convention is error prone and not too clean. Thoughts?

    Yes, it is a detail, but better to fix this now than latter :)

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Andrea Faulds at May 7, 2014 at 6:00 pm

    On 7 May 2014, at 18:57, Marc Bennewitz wrote:

    I would also prefer to name it was it represents. I mean a ZVAL represents a PHP typed value and not a C typed one. So for example IS_LONG would be IS_INTEGER and IS_DOUBLE would become IS_FLOAT.

    However, integers in PHP are usually abbreviated to just “int”s, so I think that one should be IS_INT. :)

    --
    Andrea Faulds
    http://ajf.me/
  • Marc Bennewitz at May 7, 2014 at 6:01 pm
    On 07.05.2014 19:59, Andrea Faulds wrote:
    On 7 May 2014, at 18:57, Marc Bennewitz wrote:

    I would also prefer to name it was it represents. I mean a ZVAL
    represents a PHP typed value and not a C typed one. So for example
    IS_LONG would be IS_INTEGER and IS_DOUBLE would become IS_FLOAT.
    However, integers in PHP are usually abbreviated to just “int”s, so I
    think that one should be IS_INT. :) agreed
    --
    Andrea Faulds
    http://ajf.me/


  • Marc Bennewitz at May 8, 2014 at 6:21 pm

    On 07.05.2014 19:59, Andrea Faulds wrote:
    On 7 May 2014, at 18:57, Marc Bennewitz wrote:

    I would also prefer to name it was it represents. I mean a ZVAL
    represents a PHP typed value and not a C typed one. So for example
    IS_LONG would be IS_INTEGER and IS_DOUBLE would become IS_FLOAT.
    However, integers in PHP are usually abbreviated to just “int”s, so I
    think that one should be IS_INT. :)
    After looking something deeper into documentation/code I'm really unsure
    what the PHP integer type is named.

    - The documentation is talking about "integer" mostly but on some points
    it's talking about "int" also.
       - http://php.net/manual/language.types.integer.php

    - On documented function arguments and return values it's named "int"

    - Type-Functions are named "int" but the type is named "integer" mainly
       - is_int (alias is_integer and is_long)
       - intval
       - gettype returns "integer"
       - settype expects "integer" or, since PHP 4.2.0, "int"

    - Constants use the abbr. "INT"
       - PHP_INT_MAX
       - PHP_INT_SIZE

    - On type casting both exists I don't know if one is an alias
       -
    http://php.net/manual/language.types.type-juggling.php#language.types.typecasting

    - None of the both are reserved words

    PS: With "boolean" and "bool" it's the same mix.
    --
    Andrea Faulds
    http://ajf.me/


  • Rowan Collins at May 7, 2014 at 6:11 pm

    Marc Bennewitz wrote (on 07/05/2014):
    Hi,

    I would also prefer to name it was it represents. I mean a ZVAL
    represents a PHP typed value and not a C typed one. So for example
    IS_LONG would be IS_INTEGER and IS_DOUBLE would become IS_FLOAT.

    Marc
    Ooh, that reminds me of something I've been meaning to file a bug for,
    and maybe even attempt a patch, if I can understand where it comes from:
    the message shown *to the user* when an internal function is passed an
    invalid value uses "double" and "long" instead of "float" and "int".

    To somebody not familiar with C or similar languages, the message
    "some_function() expects parameter 1 to be long, string given" is
    somewhat cryptic to say the least, particularly because long is an
    adjective not a noun in standard English, so it could easily be misread
    as something like "parameter 1 is not long enough".

    Just a pet peeve...
    --
    Rowan Collins
    [IMSoP]
  • Andrea Faulds at May 7, 2014 at 6:52 pm

    On 7 May 2014, at 19:11, Rowan Collins wrote:

    Marc Bennewitz wrote (on 07/05/2014):
    Hi,

    I would also prefer to name it was it represents. I mean a ZVAL represents a PHP typed value and not a C typed one. So for example IS_LONG would be IS_INTEGER and IS_DOUBLE would become IS_FLOAT.

    Marc
    Ooh, that reminds me of something I've been meaning to file a bug for, and maybe even attempt a patch, if I can understand where it comes from: the message shown *to the user* when an internal function is passed an invalid value uses "double" and "long" instead of "float" and "int".

    To somebody not familiar with C or similar languages, the message "some_function() expects parameter 1 to be long, string given" is somewhat cryptic to say the least, particularly because long is an adjective not a noun in standard English, so it could easily be misread as something like "parameter 1 is not long enough".

    Just a pet peeve...

    …that’s probably from zend_parse_parameters, no?

    --
    Andrea Faulds
    http://ajf.me/
  • Rowan Collins at May 7, 2014 at 7:29 pm

    Andrea Faulds wrote (on 07/05/2014):
    On 7 May 2014, at 19:11, Rowan Collins wrote:

    Ooh, that reminds me of something I've been meaning to file a bug
    for, and maybe even attempt a patch, if I can understand where it
    comes from: the message shown *to the user* when an internal function
    is passed an invalid value uses "double" and "long" instead of
    "float" and "int".
    …that’s probably from zend_parse_parameters, no?
    Following the code by eye, I think the patch would just be the attached
    - I haven't actually got a build environment to test it in, though, I'm
    just killing time while a colleague tests something.

    Using "integer" rather than "int" matches zend_get_type_by_const, which
    is is used for the "given" part of the message; floats are "double" in
    that function, which is documented behaviour of gettype
    [http://php.net/gettype].

    The only downside I can think of of this change is that since error
    messages have no machine-readable form, people may be relying on
    matching the original text. Everything's a breaking change to someone I
    guess... [http://xkcd.com/1172/]

    Regards,
    --
    Rowan Collins
    [IMSoP]
  • Marc Bennewitz at May 7, 2014 at 8:22 pm

    On 07.05.2014 21:29, Rowan Collins wrote:
    Andrea Faulds wrote (on 07/05/2014):
    On 7 May 2014, at 19:11, Rowan Collins <rowan.collins@gmail.com
    wrote:
    Ooh, that reminds me of something I've been meaning to file a bug
    for, and maybe even attempt a patch, if I can understand where it
    comes from: the message shown *to the user* when an internal function
    is passed an invalid value uses "double" and "long" instead of
    "float" and "int".
    …that’s probably from zend_parse_parameters, no?
    Following the code by eye, I think the patch would just be the attached
    - I haven't actually got a build environment to test it in, though, I'm
    just killing time while a colleague tests something.

    Using "integer" rather than "int" matches zend_get_type_by_const, which
    is is used for the "given" part of the message; floats are "double" in
    that function, which is documented behaviour of gettype
    [http://php.net/gettype].
    gettype should be the only part where the PHP type is named "double" and
    this is documented as follows: ""double" (for historical reasons
    "double" is returned in case of a float, and not simply "float")".

    For fun: Behind this very old BC safe change "gettype()" contains a
    warning to not use this function for type checks but to use the
    is_*-functions.

    -> I also would prefer to change "double" to "float" within the function
    "gettype" or ad a new function like "typeof()" and deprecate the old one
    for BC reasons ... but this is another request.

    * is_double() is an alias of is_float()
    * doubleval() is an alias of floatval()
    * on Type-Casting it's documented as:
       "(float), (double), (real) - cast to float"
    The only downside I can think of of this change is that since error
    messages have no machine-readable form, people may be relying on
    matching the original text. Everything's a breaking change to someone I
    guess... [http://xkcd.com/1172/]

    Regards,
    --
    Rowan Collins
    [IMSoP]
  • Rowan Collins at May 8, 2014 at 12:13 am

    On 07/05/2014 21:21, Marc Bennewitz wrote:
    On 07.05.2014 21:29, Rowan Collins wrote:
    Andrea Faulds wrote (on 07/05/2014):
    On 7 May 2014, at 19:11, Rowan Collins <rowan.collins@gmail.com
    wrote:
    Ooh, that reminds me of something I've been meaning to file a bug
    for, and maybe even attempt a patch, if I can understand where it
    comes from: the message shown *to the user* when an internal function
    is passed an invalid value uses "double" and "long" instead of
    "float" and "int".
    …that’s probably from zend_parse_parameters, no?
    Following the code by eye, I think the patch would just be the attached
    - I haven't actually got a build environment to test it in, though, I'm
    just killing time while a colleague tests something.

    Using "integer" rather than "int" matches zend_get_type_by_const, which
    is is used for the "given" part of the message; floats are "double" in
    that function, which is documented behaviour of gettype
    [http://php.net/gettype].
    gettype should be the only part where the PHP type is named "double" and
    this is documented as follows: ""double" (for historical reasons
    "double" is returned in case of a float, and not simply "float")".
    Actually, further digging reveals that gettype() does actually have its
    own implementation (it just happened to be identical).
    zend_get_type_by_const is used in a handful of places, but mostly for
    reflecting typehints (which can't be "float" or "double" AFAIK).

    There were a lot of tests expecting the old wording, and a few other
    messages with "double" instead of "float", so I went through and changed
    them all. The only odd case I (or rather a PHPT test) spotted is the
    list of class constants when you echo a whole class (see changes to
    ext/reflection/tests/bug29986.phpt).

    The complete set of changes is on a branch here:
    https://github.com/IMSoP/php-src/compare/zpp-type-names

    If nothing else, this has been an interesting experience in getting my
    hands dirty with building and testing. :)

    [PS: Apologies for topic drifting this thread.]

    Regards,

    --
    Rowan Collins
    [IMSoP]

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedMay 7, '14 at 8:55a
activeMay 8, '14 at 6:21p
posts11
users5
websitephp.net

People

Translate

site design / logo © 2022 Grokbase