FAQ
Hello internals,

while working with php 5 the last days i find it more and more
annoying that we allow NULL with type hints. From my perspective
allowing NULL with typehints would happen only very rare. So i
looked into the issue once again and prepared a patch.

first i looked back the mails for this issue and found three
possible solutions:

1) (Zeev) allow NULL only when it is the first default argument.
Here the disadvantage is that you cannot have non default parameters
after one that allows NULL. Also this would introduce a BC break if
we'd go this way after 5.0 is out because it changes the standard
behavior.

2) (Andi) introduce 'not null' after php 5.0. This won't introduce
a BC break. But it would require two new keywords 'NOT' and 'NULL'.
The latter is not a problem because it is a define at the moment
and the patch (a) shows that it easy to change it into a keyword.
The problem is the new keyword 'not' which would introduce a BC
break for everyone using the word 'not' already.

3) (Myself) introduce 'or null'. Obviously this would introduce a
BC break when implemented after PHP 5.0 is out. The advantage is
that it only requires NULL as an additional keyword (see above)
and that it reflects the code it replaces. The replacement code
is to check whether the parameter is an instance of the typehint
"or" if specified check if it is null:

func(Classname or NULL $param) {}

replaces

func($param) {
if ($param instanceof Classname or is_null($param)) {
// ok
} else {
// error
}
}

Having listed the three ideas i think we must address this issue
now and cannot delay it until after php 5.0 is out. Because of
2's additional keyword and 1's disadvantage i like 3 most. The
patch (b) implements it and adds a testfile.

Patch (c) also implements typehints for 'array' and 'class'.
Array checks the parameter for being an array and class checks
the parameter to be an instance of any class. These two we
agreed to do already and so i added an updated patch for it
which also includes the 'or null'.

(a) http://somabo.de/php/ext/ze2/ze2-null-patch-20040501.diff.txt
(b) http://somabo.de/php/ext/ze2/ze2-type-hints-null-20040501.diff.txt
(c) http://somabo.de/php/ext/ze2/ze2-type-hints-20040501.diff.txt

p.s.: As a sideeffect these patches speedup NULL handling.

Best regards,
Marcus

Search Discussions

  • Michael Walter at May 1, 2004 at 8:27 pm

    Marcus Boerger wrote:
    Hello internals,
    [...]
    How about
    function foo(Class? bar)
    instead? Too much magic?

    Cheers,
    Michael
  • Derick Rethans at May 1, 2004 at 8:52 pm

    On Sat, 1 May 2004, Michael Walter wrote:

    Marcus Boerger wrote:
    Hello internals,
    [...]
    How about
    function foo(Class? bar)
    instead? Too much magic?
    Too much magic indeed.

    Derick
  • John Coggeshall at May 1, 2004 at 9:27 pm
    I agree with the idea that it would be nice to force an instance of a
    particular class, etc. to be passed. However, if we are going to
    introduce another keyword anyway why not keep BC intact by by
    introducing the 'force' keyword:

    function myfunction(force ClassName $param, NextClass $another) {

    }

    Where 'force' would prevent $param from being passed as anything but an
    acceptable ClassName. Alternatively, for the sake of parsing you could
    do:

    function myfunction(Classname forced $foo) {

    }

    I remember discussing 'array' as a typehint (big +1 there), but I don't
    see anything gained from such a type-hint. When exactly would you use it
    (that you couldn't use the existing type hinting).. I guess the obvious
    answer is when you don't know the type of class being passed, but if you
    don't know that how do you plan on actually using the parameter at all?

    John

    --
    -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
    John Coggeshall http://www.coggeshall.org/
    The PHP Developer's Handbook http://www.php-handbook.com/
    -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
  • Marcus Boerger at May 1, 2004 at 10:05 pm
    Hello John,

    Saturday, May 1, 2004, 11:27:32 PM, you wrote:
    I agree with the idea that it would be nice to force an instance of a
    particular class, etc. to be passed. However, if we are going to
    introduce another keyword anyway why not keep BC intact by by
    introducing the 'force' keyword:
    the point of solution 3 was not to introduce a new keyword other than null.
    And adding null as a keyword dosn't have implications other that ppl may
    have a fucntion called 'null'. But i don't think that happens often. Using
    force or forced on the other hand seems to happen often at least i used it
    myself.
    I remember discussing 'array' as a typehint (big +1 there),
    good so far
    but I don't
    see anything gained from such a type-hint. When exactly would you use it
    (that you couldn't use the existing type hinting).. I guess the obvious
    answer is when you don't know the type of class being passed, but if you
    don't know that how do you plan on actually using the parameter at all?
    What are you speaking of here?
    array means the parameter must be an array.
    class means the parameter must be any class instance which can be used for
    reflection as an example.


    Best regards,
    Marcus
  • Andi Gutmans at May 2, 2004 at 4:09 pm
    Hi Marcus,

    It probably makes sense to go with (3) because as Zeev says, the majority
    of the times you don't want to allow NULL.
    If we decide to go this direction we definitely need to implement it before
    PHP 5 because otherwise it'll be a big BC break.
    I wouldn't use the syntax you proposed but you:
    function func(MyClass $obj or null);

    Concerning type hints, I don't think that a type hint of "class" is useful.
    If you don't use a base class as a type hint (which you will almost always
    use) then how useful will this really be? Also, it's not really Class but
    it's an Object, so we'd have to add another reserved word. In my opinion,
    I'd only go with the "array" part of the typehints patch.

    On another note, I think PHP 5 is already stable and quite mature. It's an
    order of magnitude more stable than PHP 4 was when it was released. I think
    we should start thinking of a deep feature freeze and a release date. As
    we're in the beginning of May I think sometime towards July makes sense.
    This does mean that we really need to stop adding stuff. I agree to open
    the typehints issue because it could potentially lead to a BC break
    depending what solution we take.

    Andi
    At 10:09 PM 5/1/2004 +0200, Marcus Boerger wrote:
    Hello internals,

    while working with php 5 the last days i find it more and more
    annoying that we allow NULL with type hints. From my perspective
    allowing NULL with typehints would happen only very rare. So i
    looked into the issue once again and prepared a patch.

    first i looked back the mails for this issue and found three
    possible solutions:

    1) (Zeev) allow NULL only when it is the first default argument.
    Here the disadvantage is that you cannot have non default parameters
    after one that allows NULL. Also this would introduce a BC break if
    we'd go this way after 5.0 is out because it changes the standard
    behavior.

    2) (Andi) introduce 'not null' after php 5.0. This won't introduce
    a BC break. But it would require two new keywords 'NOT' and 'NULL'.
    The latter is not a problem because it is a define at the moment
    and the patch (a) shows that it easy to change it into a keyword.
    The problem is the new keyword 'not' which would introduce a BC
    break for everyone using the word 'not' already.

    3) (Myself) introduce 'or null'. Obviously this would introduce a
    BC break when implemented after PHP 5.0 is out. The advantage is
    that it only requires NULL as an additional keyword (see above)
    and that it reflects the code it replaces. The replacement code
    is to check whether the parameter is an instance of the typehint
    "or" if specified check if it is null:

    func(Classname or NULL $param) {}

    replaces

    func($param) {
    if ($param instanceof Classname or is_null($param)) {
    // ok
    } else {
    // error
    }
    }

    Having listed the three ideas i think we must address this issue
    now and cannot delay it until after php 5.0 is out. Because of
    2's additional keyword and 1's disadvantage i like 3 most. The
    patch (b) implements it and adds a testfile.

    Patch (c) also implements typehints for 'array' and 'class'.
    Array checks the parameter for being an array and class checks
    the parameter to be an instance of any class. These two we
    agreed to do already and so i added an updated patch for it
    which also includes the 'or null'.

    (a) http://somabo.de/php/ext/ze2/ze2-null-patch-20040501.diff.txt
    (b) http://somabo.de/php/ext/ze2/ze2-type-hints-null-20040501.diff.txt
    (c) http://somabo.de/php/ext/ze2/ze2-type-hints-20040501.diff.txt

    p.s.: As a sideeffect these patches speedup NULL handling.

    Best regards,
    Marcus

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Marcus Boerger at May 2, 2004 at 5:17 pm
    Hello Andi,

    Sunday, May 2, 2004, 6:09:22 PM, you wrote:
    Hi Marcus,
    I wouldn't use the syntax you proposed but you:
    function func(MyClass $obj or null);
    an updated patch can be found here:
    http://somabo.de/php/ext/ze2/ze2-type-hints-20040502.diff.txt

    Concerning type hints, I don't think that a type hint of "class" is useful.
    If you don't use a base class as a type hint (which you will almost always
    use) then how useful will this really be? Also, it's not really Class but
    it's an Object, so we'd have to add another reserved word. In my opinion,
    I'd only go with the "array" part of the typehints patch.
    the updated patch neither contain 'class' not 'object'. Adding Object as a
    reserved work is a bad ide imo because i thing many ppl use it for basic
    classes. The reasons i chose class in the first place were that i didn't
    want to add a new keyword and that i had the term 'instance of any class'
    in mind.
    On another note, I think PHP 5 is already stable and quite mature. It's an
    order of magnitude more stable than PHP 4 was when it was released. I think
    we should start thinking of a deep feature freeze and a release date. As
    we're in the beginning of May I think sometime towards July makes sense.
    This does mean that we really need to stop adding stuff. I agree to open
    the typehints issue because it could potentially lead to a BC break
    depending what solution we take.
    more or less agreed. what i fear is missing the chance to act on bad test
    experience. but we can't wait forever, so how about a branch now, that
    could attract even more testers and hence give more feedback?

    best regards
    marcus
  • Andi Gutmans at May 9, 2004 at 10:39 am
    I really would like to finalize this issue ASAP because it's the last
    *feature* I see for PHP 5.0. The main reason why I think we need to
    finalize it is because depending on the solution we choose, it would break
    BC if we fix it after 5.0.
    Consider the following options for a parameter with default value which
    allows null:
    MyClass $a or NULL = 5
    MyClass $a = 5 or NULL
    MyClass or NULL $a = 5

    I think all of these are pretty ugly and I don't feel comfortable with
    adding them to the language.
    The following (Zeev's idea) is much simpler and nicer, but I'm not 100%
    sure if this is the perfect solution:
    nullable MyClass $a = 5

    Ideas/comments?

    Andi
    At 07:17 PM 5/2/2004 +0200, Marcus Boerger wrote:
    Hello Andi,

    Sunday, May 2, 2004, 6:09:22 PM, you wrote:
    Hi Marcus,
    I wouldn't use the syntax you proposed but you:
    function func(MyClass $obj or null);
    an updated patch can be found here:
    http://somabo.de/php/ext/ze2/ze2-type-hints-20040502.diff.txt

    Concerning type hints, I don't think that a type hint of "class" is useful.
    If you don't use a base class as a type hint (which you will almost always
    use) then how useful will this really be? Also, it's not really Class but
    it's an Object, so we'd have to add another reserved word. In my opinion,
    I'd only go with the "array" part of the typehints patch.
    the updated patch neither contain 'class' not 'object'. Adding Object as a
    reserved work is a bad ide imo because i thing many ppl use it for basic
    classes. The reasons i chose class in the first place were that i didn't
    want to add a new keyword and that i had the term 'instance of any class'
    in mind.
    On another note, I think PHP 5 is already stable and quite mature. It's an
    order of magnitude more stable than PHP 4 was when it was released. I think
    we should start thinking of a deep feature freeze and a release date. As
    we're in the beginning of May I think sometime towards July makes sense.
    This does mean that we really need to stop adding stuff. I agree to open
    the typehints issue because it could potentially lead to a BC break
    depending what solution we take.
    more or less agreed. what i fear is missing the chance to act on bad test
    experience. but we can't wait forever, so how about a branch now, that
    could attract even more testers and hence give more feedback?

    best regards
    marcus


    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Stanislav Malyshev at May 9, 2004 at 10:42 am
    AG>>sure if this is the perfect solution:
    AG>>nullable MyClass $a = 5

    I must be missing something, but why typehinted variable should have any
    default except for null anyway? If someone says "I want only MyClass
    here!", why he should be able to put 5 there?
    --
    Stanislav Malyshev, Zend Products Engineer
    stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
  • Wez Furlong at May 9, 2004 at 10:45 am
    In the class case it doesn't make sense, but for other types it does.

    --Wez.
    AG>>sure if this is the perfect solution:
    AG>>nullable MyClass $a = 5

    I must be missing something, but why typehinted variable
    should have any
    default except for null anyway? If someone says "I want only MyClass
    here!", why he should be able to put 5 there?
  • Stanislav Malyshev at May 9, 2004 at 10:52 am
    WF>>In the class case it doesn't make sense, but for other types it does.

    We have typehints for other types? From current code I gathered an
    impression that zend_verify_arg_type() expects class name to be there.
    Anyway, why would you need typehints for scalar types?
    --
    Stanislav Malyshev, Zend Products Engineer
    stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
  • Wez Furlong at May 9, 2004 at 10:58 am
    I was thinking "in general" and not about the specifics of what we have
    now.

    --Wez.
    WF>>In the class case it doesn't make sense, but for other
    types it does.

    We have typehints for other types? From current code I gathered an
    impression that zend_verify_arg_type() expects class name to
    be there.
    Anyway, why would you need typehints for scalar types?
  • Andi Gutmans at May 9, 2004 at 11:09 am

    At 01:52 PM 5/9/2004 +0300, Stanislav Malyshev wrote:
    WF>>In the class case it doesn't make sense, but for other types it does.

    We have typehints for other types? From current code I gathered an
    impression that zend_verify_arg_type() expects class name to be there.
    Anyway, why would you need typehints for scalar types?
    There will be type hints for arrays too. Obviously, with PHP's dynamic
    typing we can't have type hints for scalar values.


    Andi
  • Stanislav Malyshev at May 9, 2004 at 11:12 am
    AG>>There will be type hints for arrays too. Obviously, with PHP's dynamic
    AG>>typing we can't have type hints for scalar values.

    Well, with arrays it's the same thing - any non-array (while null being
    array for the matter) default should not be accepted. Here it's more
    complicated since we can have constant arrays, which we may or may not to
    allow (I think it's a simple compile-time check anyway, so it may be good
    to allow array initializers).
    --
    Stanislav Malyshev, Zend Products Engineer
    stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
  • Andi Gutmans at May 9, 2004 at 11:14 am

    At 02:12 PM 5/9/2004 +0300, Stanislav Malyshev wrote:
    AG>>There will be type hints for arrays too. Obviously, with PHP's dynamic
    AG>>typing we can't have type hints for scalar values.

    Well, with arrays it's the same thing - any non-array (while null being
    array for the matter) default should not be accepted. Here it's more
    complicated since we can have constant arrays, which we may or may not to
    allow (I think it's a simple compile-time check anyway, so it may be good
    to allow array initializers).
    Yeah I agree. Already today, we have a special rule for constant arrays
    initialization.

    Andi
  • Andi Gutmans at May 9, 2004 at 10:46 am

    At 01:42 PM 5/9/2004 +0300, Stanislav Malyshev wrote:
    AG>>sure if this is the perfect solution:
    AG>>nullable MyClass $a = 5

    I must be missing something, but why typehinted variable should have any
    default except for null anyway? If someone says "I want only MyClass
    here!", why he should be able to put 5 there?
    Well maybe it's a bad example but he can put NULL instead of 5.

    Andi
  • John Coggeshall at May 9, 2004 at 10:52 am

    On Sun, 2004-05-09 at 06:46, Andi Gutmans wrote:
    At 01:42 PM 5/9/2004 +0300, Stanislav Malyshev wrote:
    AG>>sure if this is the perfect solution:
    AG>>nullable MyClass $a = 5

    I must be missing something, but why typehinted variable should have any
    default except for null anyway? If someone says "I want only MyClass
    here!", why he should be able to put 5 there?
    I think I mentioned something pretty close to this (maybe I used
    forceable instead of nullable). However, it's not really obvious to me
    why you should be allowed to do the default assignment in this case. Can
    someone either give a quick example as to why I would want to assign a
    default value like this? Other than that, +1 on nullable in concept.

    John

    --
    -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
    John Coggeshall http://www.coggeshall.org/
    The PHP Developer's Handbook http://www.php-handbook.com/
    -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
  • Stanislav Malyshev at May 9, 2004 at 10:57 am
    AG>>>AG>>nullable MyClass $a = 5
    AG>>>
    AG>>>I must be missing something, but why typehinted variable should have any
    AG>>>default except for null anyway? If someone says "I want only MyClass
    AG>>>here!", why he should be able to put 5 there?
    AG>>
    AG>>Well maybe it's a bad example but he can put NULL instead of 5.

    Well, that was exactly my point, though not expressed explicitly:
    if you can put null there, you don't need 'nullable'. If you say 'MyClass
    $a', it doesn't allow null, if you say 'MyClass $a = null', it allows
    null. Or, other way around, if you say 'nullable MyClass $a', it defaults
    to null, otherwise it has no default. I think we should prohibit to put
    any default to typehinted variables except null in any case - since it
    doesn't make any sense except promoting code based on is_object checks
    etc. - the exact thing we wanted to avoid with typehints.

    --
    Stanislav Malyshev, Zend Products Engineer
    stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
  • Andi Gutmans at May 9, 2004 at 11:08 am

    At 01:57 PM 5/9/2004 +0300, Stanislav Malyshev wrote:
    AG>>>AG>>nullable MyClass $a = 5
    AG>>>
    AG>>>I must be missing something, but why typehinted variable should have any
    AG>>>default except for null anyway? If someone says "I want only MyClass
    AG>>>here!", why he should be able to put 5 there?
    AG>>
    AG>>Well maybe it's a bad example but he can put NULL instead of 5.

    Well, that was exactly my point, though not expressed explicitly:
    if you can put null there, you don't need 'nullable'. If you say 'MyClass
    $a', it doesn't allow null, if you say 'MyClass $a = null', it allows
    null. Or, other way around, if you say 'nullable MyClass $a', it defaults
    to null, otherwise it has no default. I think we should prohibit to put
    any default to typehinted variables except null in any case - since it
    doesn't make any sense except promoting code based on is_object checks
    etc. - the exact thing we wanted to avoid with typehints.
    I think it makes sense not to allow default initialization of non-NULL
    values when there's a class type hint.

    Andi
  • Stanislav Malyshev at May 9, 2004 at 11:14 am
    AG>>I think it makes sense not to allow default initialization of non-NULL
    AG>>values when there's a class type hint.

    Having this, do we actually need both "= null" and "nullable" keyword?
    They seem to be almost the same meaning, though not exactly - you can say
    'nullable' on first parameter of two-parameter function, while you
    couldn't - at least, until now - say '= null' for it.

    --
    Stanislav Malyshev, Zend Products Engineer
    stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
  • Andi Gutmans at May 9, 2004 at 11:21 am

    At 02:14 PM 5/9/2004 +0300, Stanislav Malyshev wrote:
    AG>>I think it makes sense not to allow default initialization of non-NULL
    AG>>values when there's a class type hint.

    Having this, do we actually need both "= null" and "nullable" keyword?
    They seem to be almost the same meaning, though not exactly - you can say
    'nullable' on first parameter of two-parameter function, while you
    couldn't - at least, until now - say '= null' for it.
    I don't quite understand. = NULL is if you want to suggest that this
    parameter is optional (default value). nullable is if you want the typehint
    to not error out if null is passed for the object. I think these two are
    two different things and should have different syntax.
    Maybe I misunderstood what you're saying.
    Andi
  • Wez Furlong at May 9, 2004 at 10:44 am

    The following (Zeev's idea) is much simpler and nicer, but
    I'm not 100%
    sure if this is the perfect solution:
    nullable MyClass $a = 5
    I agree; this is the nicest so far, and like you, and I'm not 100% sure
    if it is the perfect solution.

    +1 on this, unless someone comes up with something better :)

    --Wez.
  • Derick Rethans at May 9, 2004 at 10:57 am

    On Sun, 9 May 2004, Andi Gutmans wrote:

    I really would like to finalize this issue ASAP because it's the last
    *feature* I see for PHP 5.0. The main reason why I think we need to
    finalize it is because depending on the solution we choose, it would break
    BC if we fix it after 5.0.
    Consider the following options for a parameter with default value which
    allows null:
    MyClass $a or NULL = 5
    MyClass $a = 5 or NULL
    MyClass or NULL $a = 5

    I think all of these are pretty ugly and I don't feel comfortable with
    adding them to the language.
    The following (Zeev's idea) is much simpler and nicer, but I'm not 100%
    sure if this is the perfect solution:
    nullable MyClass $a = 5
    null or MyClass $a = 5 ?

    I've no idea what nullable is supposed to mean... (well, I do :)


    I was also wondering if the following would also work:

    class b extends a { }

    function foo (a $obj) { }

    $b = new b;
    foo($b);

    (ie, an inherited class also passes the hint check)

    Derick
  • Stanislav Malyshev at May 9, 2004 at 10:58 am
    DR>>I was also wondering if the following would also work:
    DR>>
    DR>>class b extends a { }
    DR>>
    DR>>function foo (a $obj) { }
    DR>>
    DR>>$b = new b;
    DR>>foo($b);
    DR>>
    DR>>(ie, an inherited class also passes the hint check)

    This should definitely work. As I see from current code, it also does :)
    --
    Stanislav Malyshev, Zend Products Engineer
    stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
  • Marcus Boerger at May 9, 2004 at 1:25 pm
    Hello Stanislav,

    Sunday, May 9, 2004, 12:58:48 PM, you wrote:

    DR>>>I was also wondering if the following would also work:
    DR>>>
    DR>>>class b extends a { }
    DR>>>
    DR>>>function foo (a $obj) { }
    DR>>>
    DR>>>$b = new b;
    DR>>>foo($b);
    DR>>>
    DR>>>(ie, an inherited class also passes the hint check)
    This should definitely work. As I see from current code, it also does :)
    It works. What we cannot do is inheriting a function and specifying
    a base class typehint:

    class Root {
    }
    class Base {
    function f(Base $p) {}
    }
    class Leaf {
    function f(Root $p) {}
    }

    It is doable as the following patch shows:
    http://somabo.de/php/ext/ze2/ze2-type-hint-classes-20040327.diff.txt
    (the patch me be a little bit outdated though).

    I guess this can pretty good wait for 5.1.

    marcus
  • Andi Gutmans at May 9, 2004 at 11:07 am

    At 12:57 PM 5/9/2004 +0200, Derick Rethans wrote:
    On Sun, 9 May 2004, Andi Gutmans wrote:

    I really would like to finalize this issue ASAP because it's the last
    *feature* I see for PHP 5.0. The main reason why I think we need to
    finalize it is because depending on the solution we choose, it would break
    BC if we fix it after 5.0.
    Consider the following options for a parameter with default value which
    allows null:
    MyClass $a or NULL = 5
    MyClass $a = 5 or NULL
    MyClass or NULL $a = 5

    I think all of these are pretty ugly and I don't feel comfortable with
    adding them to the language.
    The following (Zeev's idea) is much simpler and nicer, but I'm not 100%
    sure if this is the perfect solution:
    nullable MyClass $a = 5
    null or MyClass $a = 5 ?
    I don't like this. I think it's too long and ugly.
    I've no idea what nullable is supposed to mean... (well, I do :)


    I was also wondering if the following would also work:

    class b extends a { }

    function foo (a $obj) { }

    $b = new b;
    foo($b);

    (ie, an inherited class also passes the hint check)
    Yep. It's an instanceof check.

    Andi
  • Derick Rethans at May 9, 2004 at 5:24 pm

    On Sun, 9 May 2004, Andi Gutmans wrote:

    null or MyClass $a = 5 ?
    I don't like this. I think it's too long and ugly.
    I've no idea what nullable is supposed to mean... (well, I do :)
    I thought about this a bit more, but couldn't actually see why something
    like "nullable" is needed at all. Simple solution: If you expect an
    object of a specific class; if it also might be NULL, don't use a class
    hint at all. So *why* do we even need "bloat" like "nullable" or
    something similar.

    regards,
    Derick
  • Christian Schneider at May 9, 2004 at 9:36 pm

    Derick Rethans wrote:
    I thought about this a bit more, but couldn't actually see why something
    like "nullable" is needed at all. Simple solution: If you expect an
    I second that. I think it's the creeping feature creature at work here.
    I think we should _not_ complicate the PHP syntax here.

    Just a thought: Allow default values to violate the type hint (maybe
    only a default value of null).

    - Chris
  • Stanislav Malyshev at May 10, 2004 at 7:43 am
    CS>>Just a thought: Allow default values to violate the type hint (maybe
    CS>>only a default value of null).

    Non-null defaults for class-typehinted variable is definitely bad. This
    means you code has to check somewhere if it's default or not - then why
    typehint it? If your method accepts non-objects - it should not be marked
    as "accepts only objects of this type".
    --
    Stanislav Malyshev, Zend Products Engineer
    stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
  • Jason Garber at May 10, 2004 at 3:31 pm
    Hello,

    I've been following this discussion from the beginning. To be pointed, I
    think that the whole matter is rather a serious case of "overfunctionality".

    Consider allowing a type hint such as
    function foo(MyClass $bar)

    The only way I see that as being useful is to be able to assume that you
    can safely say $bar->DoSomething() from within your function WITHOUT
    FIRST HAVING TO write an if() statement that verifies that it is not null.

    Even allowing null as a default parameter is somewhat disturbing. The
    programmer should ditch the typehint if he needs any behavior other than
    the one described above, and use a simple if() statement to find out if it
    is the correct class.

    If it is deemed necessary to allow a NULL default parameter, then let's
    keep it simple - function foo(MyClass $bar = NULL)



    IMHO, PHP has always been a language that can be used very simply, but
    still has the low-level power to accommodate all the other things that one
    wishes to accomplish. Let's keep it that way.


    __________________________________________________________
    Jason Garber
    President & Chief Technology Officer
    IonZoft, Inc.
    814.742.8030 :: jason@ionzoft.com :: http://IonZoft.com
    __________________________________________________________
  • Ferdinand Beyer at May 10, 2004 at 4:00 pm

    On 10 May 2004 at 11:31, Jason Garber wrote:

    The only way I see that as being useful is to be able to assume that you
    can safely say $bar->DoSomething() from within your function WITHOUT
    FIRST HAVING TO write an if() statement that verifies that it is not
    null.

    On the other hand in many situations it is useful to be able to pass
    an empty value, e.g. setHandler(HandlerClass $a) could be called
    with setHandler(null) to remove the handler.

    For string values you can pass an empty string, for numbers 0 or a
    negative number and for objects null.

    In other languages it is always possible to pass null instead of the
    object (e.g. Java), in C/C++, every pointer may be set to null.

    I agree that it is a bad idea to introduce another weird syntax. We
    should either always allow null or never. I would prefer the first
    solution but could easily live with the second.

    --
    Ferdinand Beyer
    <fb@fbeyer.com>
  • Marcus Boerger at May 10, 2004 at 4:31 pm
    Hello Ferdinand,

    Monday, May 10, 2004, 6:01:12 PM, you wrote:
    On 10 May 2004 at 11:31, Jason Garber wrote:

    The only way I see that as being useful is to be able to assume that you
    can safely say $bar->DoSomething() from within your function WITHOUT
    FIRST HAVING TO write an if() statement that verifies that it is not
    null.
    On the other hand in many situations it is useful to be able to pass
    an empty value, e.g. setHandler(HandlerClass $a) could be called
    with setHandler(null) to remove the handler.
    This is simply a design mistake. If you set something to NULL then
    that is very different from removing or with PHP syntax unsetting
    an entry. What you need is another method to do that say
    unsetHandler().
    For string values you can pass an empty string, for numbers 0 or a
    negative number and for objects null.
    And for all but the objects you can be pass NULL, too. Which then
    has a complete different effect/sense/result/semantik since:
    NULL !== 0
    NULL !== ""
    NULL === NULL
    In other languages it is always possible to pass null instead of the
    object (e.g. Java), in C/C++, every pointer may be set to null.
    We don't have ponters. We pass references with PHP 5. And for references
    C++ doesn't allow NULL either. It is in some situations accomplishable
    but then results in SEGVs.
  • Andi Gutmans at May 10, 2004 at 4:16 pm
    I think it's hard to put closure on this type hints issue.
    The main problem as I see it, is that most PHP users, unlike Java users,
    usually do pass instantiated objects to functions which except objects, and
    as mentioned here, people would like to do $obj->method() without having to
    test for NULL. This pretty much means that we need to allow a type hint
    mechanism to not allow null.
    As no good syntax has been found for the less common case of allowing
    NULL's, I think the best solution for now is not to allow null in the
    regular type hint syntax, and have people who want to allow NULL's not use
    type hints at all (in any case, they need to manually check their parameter
    so they'll do one more manual check).
    We can then wait and see how much feedback we receive on this issue after
    5.0 and if necessary, revisit this. In any case, if the default is not to
    allow null pretty much any solution we will come up with will keep BC.

    That's my 2c.
    Andi
  • Hans Lellelid at May 10, 2004 at 6:22 pm

    Andi Gutmans wrote:
    As no good syntax has been found for the less common case of allowing
    NULL's, I think the best solution for now is not to allow null in the
    regular type hint syntax, and have people who want to allow NULL's not
    use type hints at all (in any case, they need to manually check their
    parameter so they'll do one more manual check).
    We can then wait and see how much feedback we receive on this issue
    after 5.0 and if necessary, revisit this. In any case, if the default is
    not to allow null pretty much any solution we will come up with will
    keep BC.
    Why not allow NULL if null is specified as the default value? i.e. if
    the parameter is optional? This change sounds like you can no longer
    use typehints for optional parameters. I have tons of code that looks
    like this:

    public function save(Connection $con = null) {
    if ($con === null) { $con = .....; }
    ...
    }

    I like that typehints will force $con to be of type Connection if not
    NULL. I like this & feel it would be very unfortunate (and obviously
    very breaking) for this to go away.

    Hans
  • Andi Gutmans at May 11, 2004 at 8:44 am

    At 02:21 PM 5/10/2004 -0400, Hans Lellelid wrote:
    Andi Gutmans wrote:
    As no good syntax has been found for the less common case of allowing
    NULL's, I think the best solution for now is not to allow null in the
    regular type hint syntax, and have people who want to allow NULL's not
    use type hints at all (in any case, they need to manually check their
    parameter so they'll do one more manual check).
    We can then wait and see how much feedback we receive on this issue after
    5.0 and if necessary, revisit this. In any case, if the default is not to
    allow null pretty much any solution we will come up with will keep BC.
    Why not allow NULL if null is specified as the default value? i.e. if the
    parameter is optional? This change sounds like you can no longer use
    typehints for optional parameters. I have tons of code that looks like this:

    public function save(Connection $con = null) {
    if ($con === null) { $con = .....; }
    ...
    }

    I like that typehints will force $con to be of type Connection if not
    NULL. I like this & feel it would be very unfortunate (and obviously very
    breaking) for this to go away.
    Moving to the semantics that type hints don't allow NULL is not consistent
    with allowing NULL default values. In this case, you will have to not use
    type hints. As I mentioned, it's best to go this way for 5.0 and see
    responses and see how applications are being written during 5.0 adoption.

    Andi
  • Timm Friebe at May 11, 2004 at 9:49 am

    On Mon, 2004-05-10 at 18:16, Andi Gutmans wrote:
    I think it's hard to put closure on this type hints issue. [...]
    As no good syntax has been found for the less common case of allowing
    NULL's, I think the best solution for now is not to allow null in the
    regular type hint syntax, and have people who want to allow NULL's not use
    type hints at all (in any case, they need to manually check their parameter
    so they'll do one more manual check).
    Will this affect optional arguments? I.e., will the following still
    work?

    class UserClass {
    public static function forName($name, ClassLoader $c= NULL) {
    // ...
    }
    }

    $works= UserClass::forName('MySQLConnection');

    (not passing any value for the optional parameter) vs.

    $fails= UserClass::forName('MySQLConnection', NULL);

    (passing NULL as "value" for the optional parameter)

    - Timm
  • Jevon Wright at May 11, 2004 at 10:51 am
    If so, maybe allow the type hint to always succeed, if it's got NULL as the
    default parameter?

    (that way foo() wouldn't act differently to foo(NULL), even though they both
    mean the same thing, ignoring the type hint)

    Jevon

    ----- Original Message -----
    From: "Timm Friebe" <thekid@thekid.de>
    To: <internals@lists.php.net>
    Sent: Tuesday, May 11, 2004 9:44 PM
    Subject: Re: [PHP-DEV] [RFC] Type hints

    On Mon, 2004-05-10 at 18:16, Andi Gutmans wrote:
    I think it's hard to put closure on this type hints issue. [...]
    As no good syntax has been found for the less common case of allowing
    NULL's, I think the best solution for now is not to allow null in the
    regular type hint syntax, and have people who want to allow NULL's not
    use
    type hints at all (in any case, they need to manually check their
    parameter
    so they'll do one more manual check).
    Will this affect optional arguments? I.e., will the following still
    work?

    class UserClass {
    public static function forName($name, ClassLoader $c= NULL) {
    // ...
    }
    }

    $works= UserClass::forName('MySQLConnection');

    (not passing any value for the optional parameter) vs.

    $fails= UserClass::forName('MySQLConnection', NULL);

    (passing NULL as "value" for the optional parameter)

    - Timm

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Andi Gutmans at May 11, 2004 at 12:23 pm

    At 11:44 AM 5/11/2004 +0200, Timm Friebe wrote:
    On Mon, 2004-05-10 at 18:16, Andi Gutmans wrote:
    I think it's hard to put closure on this type hints issue. [...]
    As no good syntax has been found for the less common case of allowing
    NULL's, I think the best solution for now is not to allow null in the
    regular type hint syntax, and have people who want to allow NULL's not use
    type hints at all (in any case, they need to manually check their parameter
    so they'll do one more manual check).
    Will this affect optional arguments? I.e., will the following still
    work?

    class UserClass {
    public static function forName($name, ClassLoader $c= NULL) {
    // ...
    }
    }

    $works= UserClass::forName('MySQLConnection');

    (not passing any value for the optional parameter) vs.

    $fails= UserClass::forName('MySQLConnection', NULL);

    (passing NULL as "value" for the optional parameter)
    Nope, why would it work? If we make the type hint strict (which I think we
    should) then you can't define it to NULL.
    Doing so would be kind of inconsistent.

    Andi
  • Jason Garber at May 11, 2004 at 12:36 pm
    Consider this below:
    At 5/11/2004 03:23 PM +0300, Andi Gutmans wrote:
    At 11:44 AM 5/11/2004 +0200, Timm Friebe wrote:
    On Mon, 2004-05-10 at 18:16, Andi Gutmans wrote:
    I think it's hard to put closure on this type hints issue. [...]
    As no good syntax has been found for the less common case of allowing
    NULL's, I think the best solution for now is not to allow null in the
    regular type hint syntax, and have people who want to allow NULL's not use
    type hints at all (in any case, they need to manually check their parameter
    so they'll do one more manual check).
    Will this affect optional arguments? I.e., will the following still
    work?

    class UserClass {
    public static function forName($name, ClassLoader $c= NULL) {
    // ...
    }
    }
    class UserClass{
    public static function forName($name, $c = NULL) {
    if(is_null($c))
    //...
    elseif($c instanceof ClassLoader)
    //...
    else
    //Throw an error
    }
    }

    Using this method, you can easily solve the issue pointed out above, while
    allowing the type hint to be strict.

    ~Jason
    $works= UserClass::forName('MySQLConnection');

    (not passing any value for the optional parameter) vs.

    $fails= UserClass::forName('MySQLConnection', NULL);

    (passing NULL as "value" for the optional parameter)
    Nope, why would it work? If we make the type hint strict (which I think we
    should) then you can't define it to NULL.
    Doing so would be kind of inconsistent.

    Andi

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Timm Friebe at May 11, 2004 at 1:06 pm

    On Tue, 2004-05-11 at 14:36, Jason Garber wrote:
    Consider this below: [...]
    class UserClass{
    public static function forName($name, $c = NULL) {
    if(is_null($c))
    //...
    elseif($c instanceof ClassLoader)
    //...
    else
    //Throw an error
    }
    }

    Using this method, you can easily solve the issue pointed out above, while
    allowing the type hint to be strict.
    Jason, I know how to build a workaround; but this is just kludgy.

    Marcus complained in his original mail that he was "annoyed" by the fact
    of having to check on a type-hinted parameter being NULL. How about I
    suggest I'm annoyed about having to check non-type-hinted parameters in
    the way you suggested above?

    - Timm
  • Hans Lellelid at May 11, 2004 at 1:37 pm
    Hi,

    Timm Friebe wrote:
    Jason, I know how to build a workaround; but this is just kludgy.

    Marcus complained in his original mail that he was "annoyed" by the fact
    of having to check on a type-hinted parameter being NULL. How about I
    suggest I'm annoyed about having to check non-type-hinted parameters in
    the way you suggested above?
    +++1! Probably 50% of the classhints I use are for optional parameters.
    To lose this will mean losing 50% of my typehints. I don't think it's
    a pain to check non-null for optional params. For non-optional params I
    probably wouldn't check for non-NULL in most cases, anyway. If a value
    expects an object and is passed NULL then I'm fine with it breaking in
    an ugly E_FATAL way.

    I would add what I feel is an important point: PHP5's use of interfaces
    and abstract classes has brought an increased strictness to PHP OO. I
    think everyone is happy with these language features, but I think it's
    fair to say that these features are going to result in a much greater
    use of optional params -- in order to satisfy interface requirements but
    allow classes to have more flexible signatures. Thus, removing the
    ability to use class typehints on optional parameters will only become a
    larger problem than it is now. (and I think it's already a pretty big
    problem)

    Hans
  • Christian Schneider at May 11, 2004 at 1:11 pm

    Jason Garber wrote:
    public static function forName($name, $c = NULL) {
    if(is_null($c))
    //...
    elseif($c instanceof ClassLoader)
    //...
    else
    //Throw an error
    Error handling can be boring/tricky/cluttering and that's why most
    people will simply omit it or die() here. It's basically dead code which
    is A Bad Thing IMHO.

    I think

    function forName($name, ClassLoader $classloader = NULL)
    {
    if (!$classloader)
    $classloader = new ClassLoader;

    ...
    }

    would be much nicer, doesn't have error handling bloat and is as safe.

    All we'd need is to ignore the type hint for the default value. Simple,
    easy to understand and also safe as the two are close to each other (the
    same line) so no danger of discrepancy here. IMHO :-)

    But I got to the conclusion that as long as we don't introduce a new
    keyword/syntax for allowing/disallowing null I'm happy :-)

    Over and out,
    - Chris
  • Timm Friebe at May 11, 2004 at 1:00 pm

    On Tue, 2004-05-11 at 14:23, Andi Gutmans wrote:
    At 11:44 AM 5/11/2004 +0200, Timm Friebe wrote:
    [...]
    Will this affect optional arguments? I.e., will the following still
    work?
    [...]
    Nope, why would it work? If we make the type hint strict (which I think we
    should) then you can't define it to NULL.
    Doing so would be kind of inconsistent.
    Aren't optional parameters and allowing NULL for typehints two different
    pairs of shoes?

    At least passing NO parameters and NULL as parameter is easily
    distinguishable in userland:

    $ php -r 'function test() { var_dump(func_num_args()); } test();'
    int(0)

    $ php -r 'function test() { var_dump(func_num_args()); } test(NULL);'
    int(1)


    - Timm
  • Sebastian Bergmann at May 11, 2004 at 1:57 pm

    Timm Friebe wrote:
    Aren't optional parameters and allowing NULL for typehints two
    different pairs of shoes?
    IMHO, they are. And should stay that way. Unfortunately the only way we
    currently have to denote a class-hinted parameter as optional is

    Class $object = null

    :-(
  • Marcus Boerger at May 10, 2004 at 4:25 pm
    Hello Jason,

    Monday, May 10, 2004, 5:31:38 PM, you wrote:
    Hello,
    I've been following this discussion from the beginning. To be pointed, I
    think that the whole matter is rather a serious case of "overfunctionality".
    Consider allowing a type hint such as
    function foo(MyClass $bar)
    The only way I see that as being useful is to be able to assume that you
    can safely say $bar->DoSomething() from within your function WITHOUT
    FIRST HAVING TO write an if() statement that verifies that it is not null.
    Even allowing null as a default parameter is somewhat disturbing. The
    programmer should ditch the typehint if he needs any behavior other than
    the one described above, and use a simple if() statement to find out if it
    is the correct class.
    Until here i very much agree. To clearify: The reason i provided all the
    patches is that i simply want the descibed behavior as default and if at all
    a syntax addition to allow NULL explicitly.
    If it is deemed necessary to allow a NULL default parameter, then let's
    keep it simple - function foo(MyClass $bar = NULL)
    As i pointed out before this solution comes with a slight disadvantage and
    it also contains some magic. It is simply semantically very different from
    secifying the allowed types and setting a default value. Combining them is
    therefore magic that is hard to understand.
    IMHO, PHP has always been a language that can be used very simply, but
    still has the low-level power to accommodate all the other things that one
    wishes to accomplish. Let's keep it that way.
    Yes we have very good solution which one must not use. In C++ or Java you
    are forced to use all the syntax or you will fail.

    best regards
    marcus
  • Jason Garber at May 10, 2004 at 4:31 pm
    Hi Marcus,

    You are totally correct. I should have clarified my statement on the
    default parameter vs allowing nulls as they are very different.

    To sum it up, as Andi said:

    "I think the best solution for now is not to allow null in the regular type
    hint syntax, and have people who want to allow NULL's not use type hints at
    all..."

    +1


    __________________________________________________________
    Jason Garber
    President & Chief Technology Officer
    IonZoft, Inc.
    814.742.8030 :: jason@ionzoft.com :: http://IonZoft.com
    __________________________________________________________


    At 5/10/2004 06:24 PM +0200, Marcus Boerger wrote:
    Hello Jason,

    Monday, May 10, 2004, 5:31:38 PM, you wrote:
    Hello,
    I've been following this discussion from the beginning. To be pointed, I
    think that the whole matter is rather a serious case of
    "overfunctionality".
    Consider allowing a type hint such as
    function foo(MyClass $bar)
    The only way I see that as being useful is to be able to assume that you
    can safely say $bar->DoSomething() from within your function WITHOUT
    FIRST HAVING TO write an if() statement that verifies that it is not null.
    Even allowing null as a default parameter is somewhat disturbing. The
    programmer should ditch the typehint if he needs any behavior other than
    the one described above, and use a simple if() statement to find out if it
    is the correct class.
    Until here i very much agree. To clearify: The reason i provided all the
    patches is that i simply want the descibed behavior as default and if at all
    a syntax addition to allow NULL explicitly.
    If it is deemed necessary to allow a NULL default parameter, then let's
    keep it simple - function foo(MyClass $bar = NULL)
    As i pointed out before this solution comes with a slight disadvantage and
    it also contains some magic. It is simply semantically very different from
    secifying the allowed types and setting a default value. Combining them is
    therefore magic that is hard to understand.
    IMHO, PHP has always been a language that can be used very simply, but
    still has the low-level power to accommodate all the other things that one
    wishes to accomplish. Let's keep it that way.
    Yes we have very good solution which one must not use. In C++ or Java you
    are forced to use all the syntax or you will fail.

    best regards
    marcus

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Magnus Määttä at May 9, 2004 at 11:10 pm

    On Sunday 09 May 2004 19.24, Derick Rethans wrote:
    On Sun, 9 May 2004, Andi Gutmans wrote:
    null or MyClass $a = 5 ?
    I don't like this. I think it's too long and ugly.
    I've no idea what nullable is supposed to mean... (well, I do :)
    I thought about this a bit more, but couldn't actually see why something
    like "nullable" is needed at all. Simple solution: If you expect an
    object of a specific class; if it also might be NULL, don't use a class
    hint at all. So *why* do we even need "bloat" like "nullable" or
    something similar.
    I agree. I can't see any use for this.

    /Magnus

    --
    Where's the man could ease a heart like a satin gown?
    -- Dorothy Parker, "The Satin Dress"
  • Hans Lellelid at May 10, 2004 at 1:48 am

    Derick Rethans wrote:
    I thought about this a bit more, but couldn't actually see why something
    like "nullable" is needed at all. Simple solution: If you expect an
    object of a specific class; if it also might be NULL, don't use a class
    hint at all. So *why* do we even need "bloat" like "nullable" or
    something similar.
    As someone who has invested many, many thousands of lines of code in
    PHP5, it is in my interest to have things work they way they currently
    work. Requiring a new keyword is a pretty big BC break to existing PHP5
    releases, and while I understand that PHP5 is not stable & hence I
    shouldn't be complaining if you all do decide to break things (still
    dealing with aftermath of __toString() change) I also don't think the
    current implementation is all that bad.

    Allowing NULL even if there is a typehint doesn't bother me personally
    at all :) Perhaps if it must be changed, then NULL could be allowed
    only for parameters that had a default type of NULL? That would be
    equally acceptible, and simpler than having new PHP keyword.

    My $0.02,

    Hans
  • Marcus Boerger at May 9, 2004 at 3:55 pm
    Hello Andi,

    Sunday, May 9, 2004, 12:39:15 PM, you wrote:
    The following (Zeev's idea) is much simpler and nicer, but I'm not 100%
    sure if this is the perfect solution:
    nullable MyClass $a = 5
    Ideas/comments?
    I think this is probably the best idea so far.
    BUT it is very hard to implement :-(
    A working patch can be found here:
    http://somabo.de/php/ext/ze2/ze2-type-hints-20040509.diff.txt
    (Patch also contains two new tests)

    Look at it in deatil, you'll dislike it! But i tried several other ways and
    couldn't get anything else to work. I trued to do it with two subrules one
    for nullable and one for the typehint and it didn't work because somehow the
    parser gets confused on that (to me this looks like a bison error). And even
    a full blowup of the parameter parsing rule didn't work.

    I tried valgrind on it and it seemed to be happy. But i am nearly sure there
    is a memory leak somewhere. If not then there should be an error in the way
    it was implemented before. If you are interested in this patch i'll have a
    deeper look. But i'd prefer if someone could find a better way to do it.

    best regards
    marcus
  • Justin Hannus at May 12, 2004 at 12:16 pm
    IMHO if php is going to have the option to use type hinted parameters (which
    I really like) then it should have the option to use type hinted variables
    as well. Half stepping with the type hints are just going to complicate
    things. Afterall, NULL is a value and not a type. And if you use a type
    hinted parameter in your function - the argument passed to it, when
    declared, should be type hinted as well or throw an E_STRICT. Like many
    things this is probably easier said than done but.....

    <?php

    class UserClass {
    public static function forName($name, ClassLoader $c) {
    // ...
    }
    }

    ClassLoader $cl = NULL;
    UserClass::forName("somename", $cl); // passes the type hint

    $cl2 = NULL;
    UserClass::forName("somename", $cl); // throws an E_STRICT

    ?>

    No funny synatx no magic just clean code.
  • Timm Friebe at May 2, 2004 at 4:44 pm

    On Sat, 2004-05-01 at 22:09, Marcus Boerger wrote:
    Hello internals,

    while working with php 5 the last days i find it more and more
    annoying that we allow NULL with type hints.
    From my perspective allowing NULL with typehints would happen
    only very rare.
    I don't think this is true. I think there are a number of cases where
    passing NULL is used to "unset" or "delete" something. For example, say
    a class supports debugging using a listener model:

    class Foo {
    function setEventListener(Listener $l) { ... }
    }

    $foo= new Foo();
    $foo->setEventListener(new ConsoleListener());
    // ...
    $foo->setEventListener(NULL);

    This makes perfect sense to me and also gets rid of the constraint of
    having to define an "unsetEventListener" method.

    To wrap it up: Would you agree that being able to pass NULL to any
    pointer argument in C is annoying?

    [...]
    2) (Andi) introduce 'not null' after php 5.0. This won't introduce
    a BC break. But it would require two new keywords 'NOT' and 'NULL'.
    The latter is not a problem because it is a define at the moment
    and the patch (a) shows that it easy to change it into a keyword.
    The problem is the new keyword 'not' which would introduce a BC
    break for everyone using the word 'not' already.
    I like this idea best: No magic such as "only when it is the first
    default argument" (the question "why" will inevitably come up sooner or
    later); plus no BC break.

    Concerning the new keyword argument, how about using the exclamation
    mark (already meaning "not"), as in:

    * function foo(Classname !NULL $val) { }
    The same as Andi's suggestion, but using ! instead of "not"

    * function foo(Classname $val !NULL) { }
    Ditto, but using postfix notation. Comes close to default value
    syntax which people are already used to.

    * function foo(Classname $val != NULL) { }
    This would be even more similar to the default value syntax.

    - Timm

Related Discussions

People

Translate

site design / logo © 2022 Grokbase