On 19/11/2007, Sam Barrow <sam@sambarrow.com> 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 <hannes.magnusson@gmail.com> wrote:
> > > On Nov 19, 2007 12:13 AM, David Coallier <davidc@php.net> 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!"
