[PATCH] Optional scalar type hinting

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.

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!"

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 ]]

It sounds like you want to be using decorators instead.

http://en.wikipedia.org/wiki/Decorator_pattern

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

(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

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 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