# [PATCH] Optional scalar type hinting - Thread: https://externals.io/message/33158 - Original archive: https://news-web.php.net/php.internals/33158 - Started by Sam Barrow on 2007-11-15T15:27:17+00:00 - Messages: 37 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/33158.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #33158 — Sam Barrow — 2007-11-15T15:27:17+00:00 URL: https://externals.io/message/33158#33158 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. --- ## #33159 — Richard Quadling — 2007-11-15T16:06:59+00:00 URL: https://externals.io/message/33158#33159 · In reply to: #33158 > > 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!" --- ## #33160 — Marcus Boerger — 2007-11-15T16:26:19+00:00 URL: https://externals.io/message/33158#33160 · In reply to: #33158 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 --- ## #33161 — Jeremy Privett — 2007-11-15T16:34:55+00:00 URL: https://externals.io/message/33158#33161 · In reply to: #33159 Richard Quadling wrote: > > > > […] > > 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 --- ## #33189 — Cristian Rodriguez — 2007-11-17T01:40:15+00:00 URL: https://externals.io/message/33158#33189 · In reply to: #33158 2007/11/15, Sam Barrow : > > 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. --- ## #33190 — David Coallier — 2007-11-17T01:59:42+00:00 URL: https://externals.io/message/33158#33190 · In reply to: #33189 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"... > 2007/11/15, Sam Barrow : > > […] > > 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, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 --- ## #33257 — Derick Rethans — 2007-11-18T20:25:55+00:00 URL: https://externals.io/message/33158#33257 · In reply to: #33160 > 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 -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #33265 — Cristian Rodriguez — 2007-11-18T22:52:30+00:00 URL: https://externals.io/message/33158#33265 · In reply to: #33257 2007/11/18, Derick Rethans : > 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 : 2007/11/18, Derick Rethans : > > > […] > > Yes and it is an alternative and not a mandatory thing to use.. as long as : > > > 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 ? ;-) > > -- > > > > -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 --- ## #33269 — Sam Barrow — 2007-11-18T23:34:34+00:00 URL: https://externals.io/message/33158#33269 · In reply to: #33266 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. > > > […] > > 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 ? ;-) > > > […] > > > > -- > David Coallier, > Founder & Software Architect, > Agora Production (http://agoraproduction.com) > 51.42.06.70.18 --- ## #33270 — Sam Barrow — 2007-11-18T23:35:20+00:00 URL: https://externals.io/message/33158#33270 · In reply to: #33257 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. > > > > […] > > 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 --- ## #33273 — Hannes Magnusson — 2007-11-19T00:24:01+00:00 URL: https://externals.io/message/33158#33273 · In reply to: #33266 > 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: 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 --- ## #33277 — David Coallier — 2007-11-19T02:50:14+00:00 URL: https://externals.io/message/33158#33277 · In reply to: #33273 > > > […] > > 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. > 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 --- ## #33279 — Sam Barrow — 2007-11-19T05:06:05+00:00 URL: https://externals.io/message/33158#33279 · In reply to: #33277 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. > > > […] > > haha :) Yes, you can do many things in userland. > > > […] > > 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. > > > > […] > > > > -- > David Coallier, > Founder & Software Architect, > Agora Production (http://agoraproduction.com) > 51.42.06.70.18 --- ## #33280 — Sam Barrow — 2007-11-19T05:30:32+00:00 URL: https://externals.io/message/33158#33280 · In reply to: #33277 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. --- ## #33281 — Edward Z. Yang — 2007-11-19T05:36:22+00:00 URL: https://externals.io/message/33158#33281 · In reply to: #33280 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 Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] --- ## #33282 — Larry Garfield — 2007-11-19T06:03:40+00:00 URL: https://externals.io/message/33158#33282 · In reply to: #33280 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 --- ## #33283 — Edward Z. Yang — 2007-11-19T06:09:32+00:00 URL: https://externals.io/message/33158#33283 · In reply to: #33282 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 Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] --- ## #33284 — Larry Garfield — 2007-11-19T06:11:37+00:00 URL: https://externals.io/message/33158#33284 · In reply to: #33280 (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 --- ## #33285 — Sam Barrow — 2007-11-19T06:14:32+00:00 URL: https://externals.io/message/33158#33285 · In reply to: #33284 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. > (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 > > > > […] > > > -- > 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 --- ## #33288 — Larry Garfield — 2007-11-19T06:44:25+00:00 URL: https://externals.io/message/33158#33288 · In reply to: #33283 > Larry Garfield wrote: > > […] > > 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 --- ## #33289 — Edward Z. Yang — 2007-11-19T07:07:11+00:00 URL: https://externals.io/message/33158#33289 · In reply to: #33288 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 Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] --- ## #33301 — Richard Quadling — 2007-11-19T11:37:05+00:00 URL: https://externals.io/message/33158#33301 · In reply to: #33279 > 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. > > > > […] 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!" --- ## #33303 — Alexey Zakhlestin — 2007-11-19T12:17:27+00:00 URL: https://externals.io/message/33158#33303 · In reply to: #33301 > 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/ --- ## #33308 — Sam Barrow — 2007-11-19T13:18:45+00:00 URL: https://externals.io/message/33158#33308 · In reply to: #33301 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. > > > […] > > 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!" --- Next page: https://externals.io/message/33158.md?page=2