FAQ
I found a patch by Derick online to allow for scalar type hinting, and
made it work with the newest snapshot of PHP 5.3. I also added the
ability to type hint for resources. I would like to ask that it be added
to the next PHP release. It allows type hinting for int, float, bool,
string, resource, and object, I also added the ability to use the
secondary keywords for all of these types (such as double, real, long,
etc.).

It will maintain 100% backwards compatibility, as the type hinting is
100% optional, implemented in the same way as array/class type hinting.

I have the patch on my PC, please let me know where and when i can
submit it. I'd be happy to do the patching and submission myself, just
asking for permission here.

Search Discussions

  • Richard Quadling at Nov 15, 2007 at 4:07 pm

    On 15/11/2007, Sam Barrow wrote:
    I found a patch by Derick online to allow for scalar type hinting, and
    made it work with the newest snapshot of PHP 5.3. I also added the
    ability to type hint for resources. I would like to ask that it be added
    to the next PHP release. It allows type hinting for int, float, bool,
    string, resource, and object, I also added the ability to use the
    secondary keywords for all of these types (such as double, real, long,
    etc.).

    It will maintain 100% backwards compatibility, as the type hinting is
    100% optional, implemented in the same way as array/class type hinting.

    I have the patch on my PC, please let me know where and when i can
    submit it. I'd be happy to do the patching and submission myself, just
    asking for permission here.
    What happens for type conversion? Is the param cast to the hinted type?

    The idea of type hinting for array and class is to make sure you get
    something appropriate.

    Rarely would you think of an array and cast it as an integer (or vice
    versa), so it makes sense.

    But with a string ("0"), an integer (0) or a boolean (false), they are
    all the same, so does this mean we would be having to cast all the
    params to the function/method?




    --
    -----
    Richard Quadling
    Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
    "Standing on the shoulders of some very clever giants!"
  • Jeremy Privett at Nov 15, 2007 at 4:35 pm

    Richard Quadling wrote:
    On 15/11/2007, Sam Barrow wrote:

    I found a patch by Derick online to allow for scalar type hinting, and
    made it work with the newest snapshot of PHP 5.3. I also added the
    ability to type hint for resources. I would like to ask that it be added
    to the next PHP release. It allows type hinting for int, float, bool,
    string, resource, and object, I also added the ability to use the
    secondary keywords for all of these types (such as double, real, long,
    etc.).

    It will maintain 100% backwards compatibility, as the type hinting is
    100% optional, implemented in the same way as array/class type hinting.

    I have the patch on my PC, please let me know where and when i can
    submit it. I'd be happy to do the patching and submission myself, just
    asking for permission here.
    What happens for type conversion? Is the param cast to the hinted type?

    The idea of type hinting for array and class is to make sure you get
    something appropriate.

    Rarely would you think of an array and cast it as an integer (or vice
    versa), so it makes sense.

    But with a string ("0"), an integer (0) or a boolean (false), they are
    all the same, so does this mean we would be having to cast all the
    params to the function/method?
    I imagine that it will behave the same was as the other type hinting and
    just bomb out if the incoming data is of the wrong type. It kind of
    defeats the purpose of type "hinting" if it's really just type "casting"
    in the method call.

    To your point, I think it would really only help those OCD developers
    among us who always use === and try to make PHP behave like a strongly
    typed language.

    ---
    Jeremy Privett
    C.E.O. & C.S.A.
    Omega Vortex Corporation
  • Marcus Boerger at Nov 15, 2007 at 4:26 pm
    Hello Sam,

    we discussed this a million times already I think. And the conclusion is
    to not allow type hinting for base types.

    marcus

    Thursday, November 15, 2007, 4:27:17 PM, you wrote:
    I found a patch by Derick online to allow for scalar type hinting, and
    made it work with the newest snapshot of PHP 5.3. I also added the
    ability to type hint for resources. I would like to ask that it be added
    to the next PHP release. It allows type hinting for int, float, bool,
    string, resource, and object, I also added the ability to use the
    secondary keywords for all of these types (such as double, real, long,
    etc.).
    It will maintain 100% backwards compatibility, as the type hinting is
    100% optional, implemented in the same way as array/class type hinting.
    I have the patch on my PC, please let me know where and when i can
    submit it. I'd be happy to do the patching and submission myself, just
    asking for permission here.



    Best regards,
    Marcus
  • Derick Rethans at Nov 18, 2007 at 8:25 pm

    On Thu, 15 Nov 2007, Marcus Boerger wrote:

    we discussed this a million times already I think. And the conclusion is
    to not allow type hinting for base types.
    I am actually thinking that it might be a good thing to add more and
    more. I know my quick hack isn't the best implementation though.

    Derick
  • Cristian Rodriguez at Nov 18, 2007 at 10:52 pm

    2007/11/18, Derick Rethans <derick@php.net>:

    I am actually thinking that it might be a good thing to add more and
    more. I know my quick hack isn't the best implementation though.
    Yes and it is an alternative and not a mandatory thing to use.. as long as :

    <?php

    function foo(int $num) {
    return $num

    }

    foo("12345") // emit fatal error, NOT accept it as valid integer

    all is fine and Im all for it ;)
  • David Coallier at Nov 18, 2007 at 11:14 pm

    On Nov 18, 2007 5:52 PM, Cristian Rodriguez wrote:
    2007/11/18, Derick Rethans <derick@php.net>:
    I am actually thinking that it might be a good thing to add more and
    more. I know my quick hack isn't the best implementation though.
    Yes and it is an alternative and not a mandatory thing to use.. as long as :

    <?php

    function foo(int $num) {
    return $num

    }

    foo("12345") // emit fatal error, NOT accept it as valid integer

    all is fine and Im all for it ;)
    --
    http://www.kissofjudas.net/
    I was thinking at something along the lines of objects also for instance:

    $i = new Integer(33);

    function foo(Integer $var) {
    }

    foo ($i); else it emits a fatal error. But also if you do

    $i = "Name"; that would emit a fatal error because the value is
    suposed to be an int. This might look a bit too much like java, but as
    an extension it could be something quite interesting I believe.

    String, Object, Integer, Scalar, Float and what else.

    So thinking of something like

    $string = new String("Foo");
    $string = "bar" or $string->setValue("Bar"); would do

    $float = new Float(4.242);
    $float->setValue('foobar'); // That emits an error
    $float->setValue(3.14159);

    echo $float; (__toString) or echo $float->getValue; to echo it's content/value

    and so on.

    Would that be "too" java-ish to be something considered in php6 ? ;-)
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    --
    David Coallier,
    Founder & Software Architect,
    Agora Production (http://agoraproduction.com)
    51.42.06.70.18
  • Sam Barrow at Nov 18, 2007 at 11:34 pm
    I have thought about this, using obects for all variables, but all of
    the extra code amounts to alot in a large application, and when using
    hundreds of small strings and integers scattered throughtout your
    application, this would cause a serious performance drop.
    On Sun, 2007-11-18 at 18:13 -0500, David Coallier wrote:
    On Nov 18, 2007 5:52 PM, Cristian Rodriguez wrote:
    2007/11/18, Derick Rethans <derick@php.net>:
    I am actually thinking that it might be a good thing to add more and
    more. I know my quick hack isn't the best implementation though.
    Yes and it is an alternative and not a mandatory thing to use.. as long as :

    <?php

    function foo(int $num) {
    return $num

    }

    foo("12345") // emit fatal error, NOT accept it as valid integer

    all is fine and Im all for it ;)
    --
    http://www.kissofjudas.net/
    I was thinking at something along the lines of objects also for instance:

    $i = new Integer(33);

    function foo(Integer $var) {
    }

    foo ($i); else it emits a fatal error. But also if you do

    $i = "Name"; that would emit a fatal error because the value is
    suposed to be an int. This might look a bit too much like java, but as
    an extension it could be something quite interesting I believe.

    String, Object, Integer, Scalar, Float and what else.

    So thinking of something like

    $string = new String("Foo");
    $string = "bar" or $string->setValue("Bar"); would do

    $float = new Float(4.242);
    $float->setValue('foobar'); // That emits an error
    $float->setValue(3.14159);

    echo $float; (__toString) or echo $float->getValue; to echo it's content/value

    and so on.

    Would that be "too" java-ish to be something considered in php6 ? ;-)
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    --
    David Coallier,
    Founder & Software Architect,
    Agora Production (http://agoraproduction.com)
    51.42.06.70.18
  • Hannes Magnusson at Nov 19, 2007 at 12:24 am

    On Nov 19, 2007 12:13 AM, David Coallier wrote:
    I was thinking at something along the lines of objects also for instance:

    $i = new Integer(33);

    function foo(Integer $var) {
    }

    foo ($i); else it emits a fatal error. But also if you do

    $i = "Name"; that would emit a fatal error because the value is
    suposed to be an int. This might look a bit too much like java, but as
    an extension it could be something quite interesting I believe.

    String, Object, Integer, Scalar, Float and what else.

    So thinking of something like

    $string = new String("Foo");
    $string = "bar" or $string->setValue("Bar"); would do

    $float = new Float(4.242);
    $float->setValue('foobar'); // That emits an error
    $float->setValue(3.14159);

    echo $float; (__toString) or echo $float->getValue; to echo it's content/value

    and so on.
    That has got to be the worst idea I've heard on internals for over a month.
    Besides, you can do this in userland already anyway:

    <?php
    class InvalidTypeException extends Exception {}
    class UnknownTypeException extends Exception {}

    class Types {
    const INTEGER = 1;
    const FLOAT = 2;
    const STRING = 3;
    const OBJECT = 4;
    const BOOLEAN = 5;

    private $val, $type;

    public function __construct($val, $type) {
    $this->type = $type;
    $this->setValue($val);
    }
    public function setValue($val) {
    switch($this->type) {
    case self::INTEGER:
    if (!is_int($val)) {
    throw new InvalidTypeException;
    }
    break;

    case self::FLOAT:
    if (!is_float($val)) {
    throw new InvalidTypeException;
    }
    break;

    case self::STRING:
    if (!is_string($val)) {
    throw new InvalidTypeException;
    }
    break;

    case self::OBJECT:
    if (!is_object($val)) {
    throw new InvalidTypeException;
    }
    break;

    case self::BOOLEAN:
    if (!is_bool($val)) {
    throw new InvalidTypeException;
    }
    break;

    default:
    throw new UnknownTypeException;

    }
    $this->val = $val;
    }
    public function getValue() {
    return $this->val;
    }
    public function __toString() {
    return (string)$this->getValue();
    }
    }

    class Integer extends Types {
    public function __construct($val) {
    parent::__construct($val, Types::INTEGER);
    }
    }
    class String extends Types {
    public function __construct($val) {
    parent::__construct($val, Types::STRING);
    }
    }
    class Float extends Types {
    public function __construct($val) {
    parent::__construct($val, Types::FLOAT);
    }
    }
    class Object extends Types {
    public function __construct($val) {
    parent::__construct($val, Types::OBJECT);
    }
    }
    class Boolean extends Types {
    public function __construct($val) {
    parent::__construct($val, Types::BOOLEAN);
    }
    }
    function type_hint_integer(Integer $val) {
    echo $val, "\n";
    }
    function type_hint_string(String $val) {
    echo $val, "\n";
    }
    function type_hint_float(Float $val) {
    echo $val, "\n";
    }



    type_hint_integer(new Integer(123));
    type_hint_string(new String("string"));
    type_hint_float(new Float(0.25));

    -Hannes
  • David Coallier at Nov 19, 2007 at 2:50 am

    On Nov 18, 2007 7:24 PM, Hannes Magnusson wrote:
    On Nov 19, 2007 12:13 AM, David Coallier wrote:
    I was thinking at something along the lines of objects also for instance:

    $i = new Integer(33);

    function foo(Integer $var) {
    }

    foo ($i); else it emits a fatal error. But also if you do

    $i = "Name"; that would emit a fatal error because the value is
    suposed to be an int. This might look a bit too much like java, but as
    an extension it could be something quite interesting I believe.

    String, Object, Integer, Scalar, Float and what else.

    So thinking of something like

    $string = new String("Foo");
    $string = "bar" or $string->setValue("Bar"); would do

    $float = new Float(4.242);
    $float->setValue('foobar'); // That emits an error
    $float->setValue(3.14159);

    echo $float; (__toString) or echo $float->getValue; to echo it's content/value

    and so on.
    That has got to be the worst idea I've heard on internals for over a month.
    Besides, you can do this in userland already anyway:
    haha :) Yes, you can do many things in userland.
    <?php
    class InvalidTypeException extends Exception {}
    class UnknownTypeException extends Exception {}

    class Types {
    const INTEGER = 1;
    const FLOAT = 2;
    const STRING = 3;
    const OBJECT = 4;
    const BOOLEAN = 5;

    private $val, $type;

    public function __construct($val, $type) {
    $this->type = $type;
    $this->setValue($val);
    }
    public function setValue($val) {
    switch($this->type) {
    case self::INTEGER:
    if (!is_int($val)) {
    throw new InvalidTypeException;
    }
    break;

    case self::FLOAT:
    if (!is_float($val)) {
    throw new InvalidTypeException;
    }
    break;

    case self::STRING:
    if (!is_string($val)) {
    throw new InvalidTypeException;
    }
    break;

    case self::OBJECT:
    if (!is_object($val)) {
    throw new InvalidTypeException;
    }
    break;

    case self::BOOLEAN:
    if (!is_bool($val)) {
    throw new InvalidTypeException;
    }
    break;

    default:
    throw new UnknownTypeException;

    }
    $this->val = $val;
    }
    public function getValue() {
    return $this->val;
    }
    public function __toString() {
    return (string)$this->getValue();
    }
    }

    class Integer extends Types {
    public function __construct($val) {
    parent::__construct($val, Types::INTEGER);
    }
    }
    class String extends Types {
    public function __construct($val) {
    parent::__construct($val, Types::STRING);
    }
    }
    class Float extends Types {
    public function __construct($val) {
    parent::__construct($val, Types::FLOAT);
    }
    }
    class Object extends Types {
    public function __construct($val) {
    parent::__construct($val, Types::OBJECT);
    }
    }
    class Boolean extends Types {
    public function __construct($val) {
    parent::__construct($val, Types::BOOLEAN);
    }
    }
    function type_hint_integer(Integer $val) {
    echo $val, "\n";
    }
    function type_hint_string(String $val) {
    echo $val, "\n";
    }
    function type_hint_float(Float $val) {
    echo $val, "\n";
    }



    type_hint_integer(new Integer(123));
    type_hint_string(new String("string"));
    type_hint_float(new Float(0.25));
    Nice implementation, so ? Still more code to include in your code.
    Anyways, the "Optional" part in the subject means ... optional. Which
    means that it does not *have* to be used and that the default hinting
    will still be loose.

    That gives the chance to anyone to use either strongly-typed code or
    loosely-typed code. You know as much as I do that it's quite easy to
    do (implement - like you just did), but if it's not in by default,
    people won't care about doing it or implementing it.

    On the other hand, if it's there, some people might be tempted to use
    it, and will. But hey.. php's a loosely typed language and it'll
    definitely stay that way. But only giving the choice to someone to use
    what he feels like is quite interesting in my opinion.

    Anyways, no need to get all grumpy, you can just say you don't like
    the idea, that'll do just as well. Anyways, that was a thought, it's
    quite easy to implement as an extension and would be light and simple
    for anyone to either use or ignore it.

    -Hannes


    --
    David Coallier,
    Founder & Software Architect,
    Agora Production (http://agoraproduction.com)
    51.42.06.70.18
  • Sam Barrow at Nov 19, 2007 at 5:06 am
    I both like and dislike the fact that PHP is so loosely typed. It makes
    it very easy, which I like, however it is sometimes not strict enough,
    allowing for undetected errors, which of course I don't like.

    I think the ideal solution here is to make it a hybrid type of language,
    where typing is dynamic, but still controllable using type hinting. You
    can use whichever you want where you want. Functions can have 3
    parameters, two hinted and one not.

    Keep in mind this is not strict typing. Key word: "hinting".

    If all is 100% optional, your application can take advantage of the
    flexibility of dynamic typing in places where it's needed, and also take
    advantage of the control that type hinting gives you where it's
    appropriate. Most languages either allow you to do whatever you want,
    making some code chaotic and some bugs harder to detect, whereas some
    are the complete opposite, imposing very strict limits on your
    variables, and severely limiting your flexibility. PHP could be the
    middle ground, with maximum flexibility, but also maximum control.

    I'm currently using my type hinting patch with PHP 5.3 for an
    application I'm working on with about 10,000 lines of code and hundreds
    of functions, big and small. I'm using type hinting in most of the
    functions, but not all. It's been very helpful so far, especially with
    the "scalar" and "number" type hints.
    On Sun, 2007-11-18 at 21:50 -0500, David Coallier wrote:
    On Nov 18, 2007 7:24 PM, Hannes Magnusson wrote:
    On Nov 19, 2007 12:13 AM, David Coallier wrote:
    I was thinking at something along the lines of objects also for instance:

    $i = new Integer(33);

    function foo(Integer $var) {
    }

    foo ($i); else it emits a fatal error. But also if you do

    $i = "Name"; that would emit a fatal error because the value is
    suposed to be an int. This might look a bit too much like java, but as
    an extension it could be something quite interesting I believe.

    String, Object, Integer, Scalar, Float and what else.

    So thinking of something like

    $string = new String("Foo");
    $string = "bar" or $string->setValue("Bar"); would do

    $float = new Float(4.242);
    $float->setValue('foobar'); // That emits an error
    $float->setValue(3.14159);

    echo $float; (__toString) or echo $float->getValue; to echo it's content/value

    and so on.
    That has got to be the worst idea I've heard on internals for over a month.
    Besides, you can do this in userland already anyway:
    haha :) Yes, you can do many things in userland.
    <?php
    class InvalidTypeException extends Exception {}
    class UnknownTypeException extends Exception {}

    class Types {
    const INTEGER = 1;
    const FLOAT = 2;
    const STRING = 3;
    const OBJECT = 4;
    const BOOLEAN = 5;

    private $val, $type;

    public function __construct($val, $type) {
    $this->type = $type;
    $this->setValue($val);
    }
    public function setValue($val) {
    switch($this->type) {
    case self::INTEGER:
    if (!is_int($val)) {
    throw new InvalidTypeException;
    }
    break;

    case self::FLOAT:
    if (!is_float($val)) {
    throw new InvalidTypeException;
    }
    break;

    case self::STRING:
    if (!is_string($val)) {
    throw new InvalidTypeException;
    }
    break;

    case self::OBJECT:
    if (!is_object($val)) {
    throw new InvalidTypeException;
    }
    break;

    case self::BOOLEAN:
    if (!is_bool($val)) {
    throw new InvalidTypeException;
    }
    break;

    default:
    throw new UnknownTypeException;

    }
    $this->val = $val;
    }
    public function getValue() {
    return $this->val;
    }
    public function __toString() {
    return (string)$this->getValue();
    }
    }

    class Integer extends Types {
    public function __construct($val) {
    parent::__construct($val, Types::INTEGER);
    }
    }
    class String extends Types {
    public function __construct($val) {
    parent::__construct($val, Types::STRING);
    }
    }
    class Float extends Types {
    public function __construct($val) {
    parent::__construct($val, Types::FLOAT);
    }
    }
    class Object extends Types {
    public function __construct($val) {
    parent::__construct($val, Types::OBJECT);
    }
    }
    class Boolean extends Types {
    public function __construct($val) {
    parent::__construct($val, Types::BOOLEAN);
    }
    }
    function type_hint_integer(Integer $val) {
    echo $val, "\n";
    }
    function type_hint_string(String $val) {
    echo $val, "\n";
    }
    function type_hint_float(Float $val) {
    echo $val, "\n";
    }



    type_hint_integer(new Integer(123));
    type_hint_string(new String("string"));
    type_hint_float(new Float(0.25));
    Nice implementation, so ? Still more code to include in your code.
    Anyways, the "Optional" part in the subject means ... optional. Which
    means that it does not *have* to be used and that the default hinting
    will still be loose.

    That gives the chance to anyone to use either strongly-typed code or
    loosely-typed code. You know as much as I do that it's quite easy to
    do (implement - like you just did), but if it's not in by default,
    people won't care about doing it or implementing it.

    On the other hand, if it's there, some people might be tempted to use
    it, and will. But hey.. php's a loosely typed language and it'll
    definitely stay that way. But only giving the choice to someone to use
    what he feels like is quite interesting in my opinion.

    Anyways, no need to get all grumpy, you can just say you don't like
    the idea, that'll do just as well. Anyways, that was a thought, it's
    quite easy to implement as an extension and would be light and simple
    for anyone to either use or ignore it.

    -Hannes


    --
    David Coallier,
    Founder & Software Architect,
    Agora Production (http://agoraproduction.com)
    51.42.06.70.18
  • Richard Quadling at Nov 19, 2007 at 11:37 am

    On 19/11/2007, Sam Barrow wrote:
    I both like and dislike the fact that PHP is so loosely typed. It makes
    it very easy, which I like, however it is sometimes not strict enough,
    allowing for undetected errors, which of course I don't like.

    I think the ideal solution here is to make it a hybrid type of language,
    where typing is dynamic, but still controllable using type hinting. You
    can use whichever you want where you want. Functions can have 3
    parameters, two hinted and one not.

    Keep in mind this is not strict typing. Key word: "hinting".

    If all is 100% optional, your application can take advantage of the
    flexibility of dynamic typing in places where it's needed, and also take
    advantage of the control that type hinting gives you where it's
    appropriate. Most languages either allow you to do whatever you want,
    making some code chaotic and some bugs harder to detect, whereas some
    are the complete opposite, imposing very strict limits on your
    variables, and severely limiting your flexibility. PHP could be the
    middle ground, with maximum flexibility, but also maximum control.

    I'm currently using my type hinting patch with PHP 5.3 for an
    application I'm working on with about 10,000 lines of code and hundreds
    of functions, big and small. I'm using type hinting in most of the
    functions, but not all. It's been very helpful so far, especially with
    the "scalar" and "number" type hints.
    On Sun, 2007-11-18 at 21:50 -0500, David Coallier wrote:
    On Nov 18, 2007 7:24 PM, Hannes Magnusson wrote:
    On Nov 19, 2007 12:13 AM, David Coallier wrote:
    I was thinking at something along the lines of objects also for instance:

    $i = new Integer(33);

    function foo(Integer $var) {
    }

    foo ($i); else it emits a fatal error. But also if you do

    $i = "Name"; that would emit a fatal error because the value is
    suposed to be an int. This might look a bit too much like java, but as
    an extension it could be something quite interesting I believe.

    String, Object, Integer, Scalar, Float and what else.

    So thinking of something like

    $string = new String("Foo");
    $string = "bar" or $string->setValue("Bar"); would do

    $float = new Float(4.242);
    $float->setValue('foobar'); // That emits an error
    $float->setValue(3.14159);

    echo $float; (__toString) or echo $float->getValue; to echo it's content/value

    and so on.
    That has got to be the worst idea I've heard on internals for over a month.
    Besides, you can do this in userland already anyway:
    haha :) Yes, you can do many things in userland.
    <?php
    class InvalidTypeException extends Exception {}
    class UnknownTypeException extends Exception {}

    class Types {
    const INTEGER = 1;
    const FLOAT = 2;
    const STRING = 3;
    const OBJECT = 4;
    const BOOLEAN = 5;

    private $val, $type;

    public function __construct($val, $type) {
    $this->type = $type;
    $this->setValue($val);
    }
    public function setValue($val) {
    switch($this->type) {
    case self::INTEGER:
    if (!is_int($val)) {
    throw new InvalidTypeException;
    }
    break;

    case self::FLOAT:
    if (!is_float($val)) {
    throw new InvalidTypeException;
    }
    break;

    case self::STRING:
    if (!is_string($val)) {
    throw new InvalidTypeException;
    }
    break;

    case self::OBJECT:
    if (!is_object($val)) {
    throw new InvalidTypeException;
    }
    break;

    case self::BOOLEAN:
    if (!is_bool($val)) {
    throw new InvalidTypeException;
    }
    break;

    default:
    throw new UnknownTypeException;

    }
    $this->val = $val;
    }
    public function getValue() {
    return $this->val;
    }
    public function __toString() {
    return (string)$this->getValue();
    }
    }

    class Integer extends Types {
    public function __construct($val) {
    parent::__construct($val, Types::INTEGER);
    }
    }
    class String extends Types {
    public function __construct($val) {
    parent::__construct($val, Types::STRING);
    }
    }
    class Float extends Types {
    public function __construct($val) {
    parent::__construct($val, Types::FLOAT);
    }
    }
    class Object extends Types {
    public function __construct($val) {
    parent::__construct($val, Types::OBJECT);
    }
    }
    class Boolean extends Types {
    public function __construct($val) {
    parent::__construct($val, Types::BOOLEAN);
    }
    }
    function type_hint_integer(Integer $val) {
    echo $val, "\n";
    }
    function type_hint_string(String $val) {
    echo $val, "\n";
    }
    function type_hint_float(Float $val) {
    echo $val, "\n";
    }



    type_hint_integer(new Integer(123));
    type_hint_string(new String("string"));
    type_hint_float(new Float(0.25));
    Nice implementation, so ? Still more code to include in your code.
    Anyways, the "Optional" part in the subject means ... optional. Which
    means that it does not *have* to be used and that the default hinting
    will still be loose.

    That gives the chance to anyone to use either strongly-typed code or
    loosely-typed code. You know as much as I do that it's quite easy to
    do (implement - like you just did), but if it's not in by default,
    people won't care about doing it or implementing it.

    On the other hand, if it's there, some people might be tempted to use
    it, and will. But hey.. php's a loosely typed language and it'll
    definitely stay that way. But only giving the choice to someone to use
    what he feels like is quite interesting in my opinion.

    Anyways, no need to get all grumpy, you can just say you don't like
    the idea, that'll do just as well. Anyways, that was a thought, it's
    quite easy to implement as an extension and would be light and simple
    for anyone to either use or ignore it.

    -Hannes


    --
    David Coallier,
    Founder & Software Architect,
    Agora Production (http://agoraproduction.com)
    51.42.06.70.18
    What if type hinting just generated an E_NOTICE. Nothing more for the
    time being.

    Call it an experimental option.

    I already use hungarian notation for all my params ( cause I'm
    unimaginative with my var names I suppose!), so the type hinting would
    help me enforce this and reduce errors in the long run (code goes from
    me to other developers who only glance at the dox)

    --
    -----
    Richard Quadling
    Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
    "Standing on the shoulders of some very clever giants!"
  • Alexey Zakhlestin at Nov 19, 2007 at 12:17 pm

    On 11/19/07, Richard Quadling wrote:

    What if type hinting just generated an E_NOTICE. Nothing more for the
    time being.

    Call it an experimental option.

    I already use hungarian notation for all my params ( cause I'm
    unimaginative with my var names I suppose!), so the type hinting would
    help me enforce this and reduce errors in the long run (code goes from
    me to other developers who only glance at the dox)
    I like this idea

    but E_STRICT seems to fit better :)
  • Sam Barrow at Nov 19, 2007 at 1:21 pm
    I just finished redoing this patch by the way, it's available on
    sambarrow.com, along with my custom superglobals patch.
    On Mon, 2007-11-19 at 15:17 +0300, Alexey Zakhlestin wrote:
    On 11/19/07, Richard Quadling wrote:

    What if type hinting just generated an E_NOTICE. Nothing more for the
    time being.

    Call it an experimental option.

    I already use hungarian notation for all my params ( cause I'm
    unimaginative with my var names I suppose!), so the type hinting would
    help me enforce this and reduce errors in the long run (code goes from
    me to other developers who only glance at the dox)
    I like this idea

    but E_STRICT seems to fit better :)

    --
    Alexey Zakhlestin
    http://blog.milkfarmsoft.com/
  • Sam Barrow at Nov 19, 2007 at 1:20 pm
    Good idea about reducing the error warning level, isn't this currently
    fatal? We could just turn it into an e_notice or e_warning.
    On Mon, 2007-11-19 at 11:37 +0000, Richard Quadling wrote:
    On 19/11/2007, Sam Barrow wrote:
    I both like and dislike the fact that PHP is so loosely typed. It makes
    it very easy, which I like, however it is sometimes not strict enough,
    allowing for undetected errors, which of course I don't like.

    I think the ideal solution here is to make it a hybrid type of language,
    where typing is dynamic, but still controllable using type hinting. You
    can use whichever you want where you want. Functions can have 3
    parameters, two hinted and one not.

    Keep in mind this is not strict typing. Key word: "hinting".

    If all is 100% optional, your application can take advantage of the
    flexibility of dynamic typing in places where it's needed, and also take
    advantage of the control that type hinting gives you where it's
    appropriate. Most languages either allow you to do whatever you want,
    making some code chaotic and some bugs harder to detect, whereas some
    are the complete opposite, imposing very strict limits on your
    variables, and severely limiting your flexibility. PHP could be the
    middle ground, with maximum flexibility, but also maximum control.

    I'm currently using my type hinting patch with PHP 5.3 for an
    application I'm working on with about 10,000 lines of code and hundreds
    of functions, big and small. I'm using type hinting in most of the
    functions, but not all. It's been very helpful so far, especially with
    the "scalar" and "number" type hints.
    On Sun, 2007-11-18 at 21:50 -0500, David Coallier wrote:
    On Nov 18, 2007 7:24 PM, Hannes Magnusson wrote:
    On Nov 19, 2007 12:13 AM, David Coallier wrote:
    I was thinking at something along the lines of objects also for instance:

    $i = new Integer(33);

    function foo(Integer $var) {
    }

    foo ($i); else it emits a fatal error. But also if you do

    $i = "Name"; that would emit a fatal error because the value is
    suposed to be an int. This might look a bit too much like java, but as
    an extension it could be something quite interesting I believe.

    String, Object, Integer, Scalar, Float and what else.

    So thinking of something like

    $string = new String("Foo");
    $string = "bar" or $string->setValue("Bar"); would do

    $float = new Float(4.242);
    $float->setValue('foobar'); // That emits an error
    $float->setValue(3.14159);

    echo $float; (__toString) or echo $float->getValue; to echo it's content/value

    and so on.
    That has got to be the worst idea I've heard on internals for over a month.
    Besides, you can do this in userland already anyway:
    haha :) Yes, you can do many things in userland.
    <?php
    class InvalidTypeException extends Exception {}
    class UnknownTypeException extends Exception {}

    class Types {
    const INTEGER = 1;
    const FLOAT = 2;
    const STRING = 3;
    const OBJECT = 4;
    const BOOLEAN = 5;

    private $val, $type;

    public function __construct($val, $type) {
    $this->type = $type;
    $this->setValue($val);
    }
    public function setValue($val) {
    switch($this->type) {
    case self::INTEGER:
    if (!is_int($val)) {
    throw new InvalidTypeException;
    }
    break;

    case self::FLOAT:
    if (!is_float($val)) {
    throw new InvalidTypeException;
    }
    break;

    case self::STRING:
    if (!is_string($val)) {
    throw new InvalidTypeException;
    }
    break;

    case self::OBJECT:
    if (!is_object($val)) {
    throw new InvalidTypeException;
    }
    break;

    case self::BOOLEAN:
    if (!is_bool($val)) {
    throw new InvalidTypeException;
    }
    break;

    default:
    throw new UnknownTypeException;

    }
    $this->val = $val;
    }
    public function getValue() {
    return $this->val;
    }
    public function __toString() {
    return (string)$this->getValue();
    }
    }

    class Integer extends Types {
    public function __construct($val) {
    parent::__construct($val, Types::INTEGER);
    }
    }
    class String extends Types {
    public function __construct($val) {
    parent::__construct($val, Types::STRING);
    }
    }
    class Float extends Types {
    public function __construct($val) {
    parent::__construct($val, Types::FLOAT);
    }
    }
    class Object extends Types {
    public function __construct($val) {
    parent::__construct($val, Types::OBJECT);
    }
    }
    class Boolean extends Types {
    public function __construct($val) {
    parent::__construct($val, Types::BOOLEAN);
    }
    }
    function type_hint_integer(Integer $val) {
    echo $val, "\n";
    }
    function type_hint_string(String $val) {
    echo $val, "\n";
    }
    function type_hint_float(Float $val) {
    echo $val, "\n";
    }



    type_hint_integer(new Integer(123));
    type_hint_string(new String("string"));
    type_hint_float(new Float(0.25));
    Nice implementation, so ? Still more code to include in your code.
    Anyways, the "Optional" part in the subject means ... optional. Which
    means that it does not *have* to be used and that the default hinting
    will still be loose.

    That gives the chance to anyone to use either strongly-typed code or
    loosely-typed code. You know as much as I do that it's quite easy to
    do (implement - like you just did), but if it's not in by default,
    people won't care about doing it or implementing it.

    On the other hand, if it's there, some people might be tempted to use
    it, and will. But hey.. php's a loosely typed language and it'll
    definitely stay that way. But only giving the choice to someone to use
    what he feels like is quite interesting in my opinion.

    Anyways, no need to get all grumpy, you can just say you don't like
    the idea, that'll do just as well. Anyways, that was a thought, it's
    quite easy to implement as an extension and would be light and simple
    for anyone to either use or ignore it.

    -Hannes


    --
    David Coallier,
    Founder & Software Architect,
    Agora Production (http://agoraproduction.com)
    51.42.06.70.18
    What if type hinting just generated an E_NOTICE. Nothing more for the
    time being.

    Call it an experimental option.

    I already use hungarian notation for all my params ( cause I'm
    unimaginative with my var names I suppose!), so the type hinting would
    help me enforce this and reduce errors in the long run (code goes from
    me to other developers who only glance at the dox)

    --
    -----
    Richard Quadling
    Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
    "Standing on the shoulders of some very clever giants!"

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Sam Barrow at Nov 19, 2007 at 5:30 am
    What is the general opinion on multiple class inheritance. I have a need
    for it. I have objects for all user input fields.

    $username = new field ;
    $username -> name = 'username' ;
    $username -> maxLen = 32 ;

    I have three types of fields. Fields that are automatically put in the
    database, such as timestamps, fields that are inputted but not stored,
    such as "confirm password", and fields that are inputted by the user AND
    stored in the database, such as username and password.

    Now i have 3 classes:

    - abstractField (has methods and properties that apply to all fields).
    - inputField, extends abstractField (has methods and properties for
    display of input form elements and labels).
    - dbField, extends abstractField (has methods for storing and retrieving
    in db, etc.).

    However for fields that are inputted AND stored in the db, i need to
    extend both inputField and dbField.

    - inputDbField extends inputField, dbField.

    Sure, there may be quick hacks to do this, but the only proper way seems
    to be to extend both classes, and I don't want to duplicate any code
    (dbField and inputField are both pretty big, and any modifications will
    also have to be replicated).

    And no, I don't want to use interfaces. Interfaces will barely do
    anything for me, I'll still have to duplicate my method bodies, and
    properties.
  • Edward Z. Yang at Nov 19, 2007 at 5:36 am

    Sam Barrow wrote:
    What is the general opinion on multiple class inheritance. I have a need
    for it.
    Use object composition?

    --
    Edward Z. Yang GnuPG: 0x869C48DA
    HTML Purifier <http://htmlpurifier.org> Anti-XSS Filter
    [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]
  • Larry Garfield at Nov 19, 2007 at 6:03 am
    It sounds like you want to be using decorators instead.

    http://en.wikipedia.org/wiki/Decorator_pattern
    On Sunday 18 November 2007, Sam Barrow wrote:
    What is the general opinion on multiple class inheritance. I have a need
    for it. I have objects for all user input fields.

    $username = new field ;
    $username -> name = 'username' ;
    $username -> maxLen = 32 ;

    I have three types of fields. Fields that are automatically put in the
    database, such as timestamps, fields that are inputted but not stored,
    such as "confirm password", and fields that are inputted by the user AND
    stored in the database, such as username and password.

    Now i have 3 classes:

    - abstractField (has methods and properties that apply to all fields).
    - inputField, extends abstractField (has methods and properties for
    display of input form elements and labels).
    - dbField, extends abstractField (has methods for storing and retrieving
    in db, etc.).

    However for fields that are inputted AND stored in the db, i need to
    extend both inputField and dbField.

    - inputDbField extends inputField, dbField.

    Sure, there may be quick hacks to do this, but the only proper way seems
    to be to extend both classes, and I don't want to duplicate any code
    (dbField and inputField are both pretty big, and any modifications will
    also have to be replicated).

    And no, I don't want to use interfaces. Interfaces will barely do
    anything for me, I'll still have to duplicate my method bodies, and
    properties.

    --
    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
  • Edward Z. Yang at Nov 19, 2007 at 6:09 am

    Larry Garfield wrote:
    It sounds like you want to be using decorators instead.
    The decorator pattern is inappropriate for this case, because Sam wants
    to extend the interface, not change the behavior of an existing one.

    --
    Edward Z. Yang GnuPG: 0x869C48DA
    HTML Purifier <http://htmlpurifier.org> Anti-XSS Filter
    [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]
  • Larry Garfield at Nov 19, 2007 at 6:43 am

    On Monday 19 November 2007, Edward Z. Yang wrote:
    Larry Garfield wrote:
    It sounds like you want to be using decorators instead.
    The decorator pattern is inappropriate for this case, because Sam wants
    to extend the interface, not change the behavior of an existing one.
    class AbstractField {
    // ...
    }

    class InputField {

    protected $field;

    function __construct($field) {
    $this->$field = $field;
    }

    function __call($method, $args) {
    return call_user_func_array(array($this->field, $method), $args);
    }
    // Other methods.
    }

    class DBField {

    protected $field;

    function __construct($field) {
    $this->$field = $field;
    }

    function __call($method, $args) {
    return call_user_func_array(array($this->field, $method), $args);
    }
    // Other methods.
    }

    $myfield = new InputField(new DBField(new AbstractField(...)));

    This is a case where you don't want type-hinting, actually. :-) You could do
    the same thing with an AbstractField interface that DBField and InputField
    also implement and pass through, which might be faster because you eliminate
    the _call()/call_user_func_array() choke point, but it's more code to write.
    Pick your poison.

    --
    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
  • Edward Z. Yang at Nov 19, 2007 at 7:07 am

    Larry Garfield wrote:
    $myfield = new InputField(new DBField(new AbstractField(...))); [snip]
    Nah, what you're talking about now is a chain of responsibility, where
    events are in the form of method calls. :-)

    --
    Edward Z. Yang GnuPG: 0x869C48DA
    HTML Purifier <http://htmlpurifier.org> Anti-XSS Filter
    [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]
  • Sam Barrow at Nov 19, 2007 at 3:54 pm
    Whether it's implemented or not, I'm going to write a patch for multiple
    class inheritance. Does anyone here whos knows about the Zend Engine
    willing to help me out just a little bit, to get me started? I'm stuck
    at the syntax interpretation right now.
    On Mon, 2007-11-19 at 02:07 -0500, Edward Z. Yang wrote:
    Larry Garfield wrote:
    $myfield = new InputField(new DBField(new AbstractField(...))); [snip]
    Nah, what you're talking about now is a chain of responsibility, where
    events are in the form of method calls. :-)

    --
    Edward Z. Yang GnuPG: 0x869C48DA
    HTML Purifier <http://htmlpurifier.org> Anti-XSS Filter
    [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]
  • Cristian Rodriguez at Nov 19, 2007 at 8:54 pm

    2007/11/19, Sam Barrow <sam@sambarrow.com>:
    Whether it's implemented or not, I'm going to write a patch for multiple
    class inheritance.
    I have the feeling that you are trying to use the wrong language.

    Hopefully people on this lists still preserves their sanity and will
    not be wiliing to implement a concept that is know to work correclty
    only in very few implementations, if any, that causes ambiguity and
    opens the door for all sorts of unneeded complexity.
  • Sam Barrow at Nov 19, 2007 at 9:51 pm
    I doubt it will be implemented, but for my application it would be
    incredibly helpful and worth it to me to write a patch even if I am the
    only one to use it.
    On Mon, 2007-11-19 at 17:53 -0300, Cristian Rodriguez wrote:
    2007/11/19, Sam Barrow <sam@sambarrow.com>:
    Whether it's implemented or not, I'm going to write a patch for multiple
    class inheritance.
    I have the feeling that you are trying to use the wrong language.

    Hopefully people on this lists still preserves their sanity and will
    not be wiliing to implement a concept that is know to work correclty
    only in very few implementations, if any, that causes ambiguity and
    opens the door for all sorts of unneeded complexity.


    --
    http://www.kissofjudas.net/
  • Arnold Daniels at Nov 19, 2007 at 10:10 pm
    It would probably better to implement something like prototyping,
    where there is only 1 parent, but there can be muliple prototype
    classes from which methods are inherited.
    On Nov 19, 2007, at 10:49 PM, Sam Barrow wrote:

    I doubt it will be implemented, but for my application it would be
    incredibly helpful and worth it to me to write a patch even if I am
    the
    only one to use it.
    On Mon, 2007-11-19 at 17:53 -0300, Cristian Rodriguez wrote:
    2007/11/19, Sam Barrow <sam@sambarrow.com>:
    Whether it's implemented or not, I'm going to write a patch for
    multiple
    class inheritance.
    I have the feeling that you are trying to use the wrong language.

    Hopefully people on this lists still preserves their sanity and will
    not be wiliing to implement a concept that is know to work correclty
    only in very few implementations, if any, that causes ambiguity and
    opens the door for all sorts of unneeded complexity.


    --
    http://www.kissofjudas.net/
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Sam Barrow at Nov 19, 2007 at 11:23 pm
    That would serve my purpose, as long as i can inherit methods and
    properties from multiple parents.
    On Mon, 2007-11-19 at 23:09 +0100, Arnold Daniels wrote:
    It would probably better to implement something like prototyping,
    where there is only 1 parent, but there can be muliple prototype
    classes from which methods are inherited.
    On Nov 19, 2007, at 10:49 PM, Sam Barrow wrote:

    I doubt it will be implemented, but for my application it would be
    incredibly helpful and worth it to me to write a patch even if I am
    the
    only one to use it.
    On Mon, 2007-11-19 at 17:53 -0300, Cristian Rodriguez wrote:
    2007/11/19, Sam Barrow <sam@sambarrow.com>:
    Whether it's implemented or not, I'm going to write a patch for
    multiple
    class inheritance.
    I have the feeling that you are trying to use the wrong language.

    Hopefully people on this lists still preserves their sanity and will
    not be wiliing to implement a concept that is know to work correclty
    only in very few implementations, if any, that causes ambiguity and
    opens the door for all sorts of unneeded complexity.


    --
    http://www.kissofjudas.net/
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Gergely Hodicska at Nov 19, 2007 at 11:51 pm

    That would serve my purpose, as long as i can inherit methods and
    properties from multiple parents.
    Sorry if it is off to this list. Sam maybe you should check some PHP
    mixins implementation:
    http://www.symfony-project.org/book/1_0/17-Extending-Symfony#Mixins
    http://www.achievo.org/blog/archives/46-Mixins-in-PHP.html


    Best Regards,
    Felhő
  • Sam Barrow at Nov 19, 2007 at 9:58 pm
    This was a good idea, however it could be even more useful if used to
    calculate the execution time of your scripts. But since it only counts
    whole seconds, for this microtime() would be better. Would it be
    possible to add $_SERVER['REQUEST_MICROTIME']?
  • Rasmus Lerdorf at Nov 20, 2007 at 10:20 am

    Sam Barrow wrote:
    This was a good idea, however it could be even more useful if used to
    calculate the execution time of your scripts. But since it only counts
    whole seconds, for this microtime() would be better. Would it be
    possible to add $_SERVER['REQUEST_MICROTIME']?
    This has nothing to do with execution time, it simply gives you the time
    of the request in order to save a system call because that system call
    has already been done up the chain. Doing an automatic microtime call,
    would add an additional system call to applications that may never use
    it, so no, that would not be a good idea.

    -Rasmus
  • Sebastian Bergmann at Nov 20, 2007 at 10:56 am

    Sam Barrow schrieb:
    [...]
    Seriously, how hard can it be to start a new thread by not replying to
    a message of an existing thread?

    --
    Sebastian Bergmann http://sebastian-bergmann.de/
    GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
  • Larry Garfield at Nov 19, 2007 at 6:11 am
    (Sorry, hit reply too soon.)

    Or, alternatively, you can mostly implement "friend" functions of a sort:

    http://www.garfieldtech.com/blog/php-magic-call

    but they have a performance penalty:

    http://www.garfieldtech.com/blog/magic-benchmarks
    On Sunday 18 November 2007, Sam Barrow wrote:
    What is the general opinion on multiple class inheritance. I have a need
    for it. I have objects for all user input fields.

    $username = new field ;
    $username -> name = 'username' ;
    $username -> maxLen = 32 ;

    I have three types of fields. Fields that are automatically put in the
    database, such as timestamps, fields that are inputted but not stored,
    such as "confirm password", and fields that are inputted by the user AND
    stored in the database, such as username and password.

    Now i have 3 classes:

    - abstractField (has methods and properties that apply to all fields).
    - inputField, extends abstractField (has methods and properties for
    display of input form elements and labels).
    - dbField, extends abstractField (has methods for storing and retrieving
    in db, etc.).

    However for fields that are inputted AND stored in the db, i need to
    extend both inputField and dbField.

    - inputDbField extends inputField, dbField.

    Sure, there may be quick hacks to do this, but the only proper way seems
    to be to extend both classes, and I don't want to duplicate any code
    (dbField and inputField are both pretty big, and any modifications will
    also have to be replicated).

    And no, I don't want to use interfaces. Interfaces will barely do
    anything for me, I'll still have to duplicate my method bodies, and
    properties.

    --
    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
  • Sam Barrow at Nov 19, 2007 at 6:14 am
    I was considering something like this, just seems like more of a hack to
    me than the right way to do it, plus the performance hit you mentioned.
    On Mon, 2007-11-19 at 00:11 -0600, Larry Garfield wrote:
    (Sorry, hit reply too soon.)

    Or, alternatively, you can mostly implement "friend" functions of a sort:

    http://www.garfieldtech.com/blog/php-magic-call

    but they have a performance penalty:

    http://www.garfieldtech.com/blog/magic-benchmarks
    On Sunday 18 November 2007, Sam Barrow wrote:
    What is the general opinion on multiple class inheritance. I have a need
    for it. I have objects for all user input fields.

    $username = new field ;
    $username -> name = 'username' ;
    $username -> maxLen = 32 ;

    I have three types of fields. Fields that are automatically put in the
    database, such as timestamps, fields that are inputted but not stored,
    such as "confirm password", and fields that are inputted by the user AND
    stored in the database, such as username and password.

    Now i have 3 classes:

    - abstractField (has methods and properties that apply to all fields).
    - inputField, extends abstractField (has methods and properties for
    display of input form elements and labels).
    - dbField, extends abstractField (has methods for storing and retrieving
    in db, etc.).

    However for fields that are inputted AND stored in the db, i need to
    extend both inputField and dbField.

    - inputDbField extends inputField, dbField.

    Sure, there may be quick hacks to do this, but the only proper way seems
    to be to extend both classes, and I don't want to duplicate any code
    (dbField and inputField are both pretty big, and any modifications will
    also have to be replicated).

    And no, I don't want to use interfaces. Interfaces will barely do
    anything for me, I'll still have to duplicate my method bodies, and
    properties.

    --
    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
  • Sebastian Bergmann at Nov 19, 2007 at 4:29 pm

    Sam Barrow schrieb:
    What is the general opinion on multiple class inheritance.
    It is a concept that only works correctly in CLOS?

    --
    Sebastian Bergmann http://sebastian-bergmann.de/
    GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
  • Sam Barrow at Nov 18, 2007 at 11:35 pm
    I've been working on your patch, adding types and making it more stable.
    Worked pretty good for me though, with the exception of a couple things
    (some code was different in 5.3 than in your diff files, but that makes
    sense as you wrote this patch in 2006).

    I think more type hinting in all areas would be good, and if this is
    something that is going to be implemented, I am willing to do as much of
    the work as I'd have to.
    On Sun, 2007-11-18 at 21:25 +0100, Derick Rethans wrote:
    On Thu, 15 Nov 2007, Marcus Boerger wrote:

    we discussed this a million times already I think. And the conclusion is
    to not allow type hinting for base types.
    I am actually thinking that it might be a good thing to add more and
    more. I know my quick hack isn't the best implementation though.

    Derick
  • Baptiste Autin at Nov 19, 2007 at 12:19 am
    I know well the sacred "loose typing" anthem, but is there any hope to see
    the class properties type hinted one day? (and the return value as well)

    I mean, as an OPTION, as it is already done with function parameters...

    Class A {
    }
    Class B {
    public A $a;
    }

    Because:
    1. It is so strange to see that in PHP5 only the function parameters
    have this feature implemented today. It's like a half-done job.
    2. Many design patterns make use of composition (versus inheritance -
    thanks the GoF) and a composition would be more readable with such a
    feature.
    3. Model-driven, reverse-enginering tools would appreciate this too.

    Other question: would it be conceivable to gather the ENV / GET / POST (and
    so on) variables into one or more system classes? (sorts of "context
    classes") so that one would always have the choice between looking into the
    traditional arrays $_xxx, or into the system classes (I'm sure this point
    has already been discussed, but I wasn't there :-).
  • Sam Barrow at Nov 19, 2007 at 12:24 am
    I think type hinting of all variables eventually would be great, as long
    as it stays completely optional.
    On Mon, 2007-11-19 at 01:18 +0100, Baptiste Autin wrote:
    I know well the sacred "loose typing" anthem, but is there any hope to see
    the class properties type hinted one day? (and the return value as well)

    I mean, as an OPTION, as it is already done with function parameters...

    Class A {
    }
    Class B {
    public A $a;
    }

    Because:
    1. It is so strange to see that in PHP5 only the function parameters
    have this feature implemented today. It's like a half-done job.
    2. Many design patterns make use of composition (versus inheritance -
    thanks the GoF) and a composition would be more readable with such a
    feature.
    3. Model-driven, reverse-enginering tools would appreciate this too.

    Other question: would it be conceivable to gather the ENV / GET / POST (and
    so on) variables into one or more system classes? (sorts of "context
    classes") so that one would always have the choice between looking into the
    traditional arrays $_xxx, or into the system classes (I'm sure this point
    has already been discussed, but I wasn't there :-).
  • Cristian Rodriguez at Nov 17, 2007 at 1:40 am
    2007/11/15, Sam Barrow <sam@sambarrow.com>:
    I found a patch by Derick online to allow for scalar type hinting, and
    made it work with the newest snapshot of PHP 5.3.
    IIRC Hannes had a patch to implement this the right way, but
    unfortunately it has not been merged.
    .
    Hopefully he can publish an updated version somewhere because I agree
    that having this functionality is a good thing.
  • David Coallier at Nov 17, 2007 at 1:59 am
    We actually had spoken of that on irc a few times and a while ago, the
    answer I got back was basically, "If you want java, use java"...
    On Nov 16, 2007 8:40 PM, Cristian Rodriguez wrote:
    2007/11/15, Sam Barrow <sam@sambarrow.com>:
    I found a patch by Derick online to allow for scalar type hinting, and
    made it work with the newest snapshot of PHP 5.3.
    IIRC Hannes had a patch to implement this the right way, but
    unfortunately it has not been merged.
    .
    Hopefully he can publish an updated version somewhere because I agree
    that having this functionality is a good thing.


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


    --
    David Coallier,
    Founder & Software Architect,
    Agora Production (http://agoraproduction.com)
    51.42.06.70.18
  • Marcus Boerger at Nov 19, 2007 at 4:27 pm
    Hello Sam,

    since the thread turned to autoboxing. You guys may want to have a look at
    Pecl/SPL_Types which provides the base functionality to implement autoboxing
    already. Right now it provides only a Bool and an Enum class though.

    marcus

    Thursday, November 15, 2007, 4:27:17 PM, you wrote:
    I found a patch by Derick online to allow for scalar type hinting, and
    made it work with the newest snapshot of PHP 5.3. I also added the
    ability to type hint for resources. I would like to ask that it be added
    to the next PHP release. It allows type hinting for int, float, bool,
    string, resource, and object, I also added the ability to use the
    secondary keywords for all of these types (such as double, real, long,
    etc.).
    It will maintain 100% backwards compatibility, as the type hinting is
    100% optional, implemented in the same way as array/class type hinting.
    I have the patch on my PC, please let me know where and when i can
    submit it. I'd be happy to do the patching and submission myself, just
    asking for permission here.



    Best regards,
    Marcus

Related Discussions

People

Translate

site design / logo © 2022 Grokbase