On 19/11/2007, Sam Barrow <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > On Nov 19, 2007 12:13 AM, David Coallier <[EMAIL PROTECTED]> 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