Re: [PHP-DEV] [PATCH] Optional scalar type hinting
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,
Re: [PHP-DEV] [PATCH] Optional scalar type hinting
On 11/19/07, Richard Quadling [EMAIL PROTECTED] 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Optional scalar type hinting
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 +, Richard Quadling wrote:
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
Re: [PHP-DEV] [PATCH] Optional scalar type hinting
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 [EMAIL PROTECTED] 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Optional scalar type hinting
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Optional scalar type hinting
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 -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Optional scalar type hinting
2007/11/18, Derick Rethans [EMAIL PROTECTED]:
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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Optional scalar type hinting
On Nov 18, 2007 5:52 PM, Cristian Rodriguez [EMAIL PROTECTED] wrote:
2007/11/18, Derick Rethans [EMAIL PROTECTED]:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Optional scalar type hinting
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 [EMAIL PROTECTED] wrote:
2007/11/18, Derick Rethans [EMAIL PROTECTED]:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Optional scalar type hinting
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Optional scalar type hinting
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:
?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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Optional scalar type hinting
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
Re: [PHP-DEV] [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.
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
Re: [PHP-DEV] [PATCH] Optional scalar type hinting
2007/11/15, Sam Barrow [EMAIL PROTECTED]: 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
Re: [PHP-DEV] [PATCH] Optional scalar type hinting
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 [EMAIL PROTECTED] wrote: 2007/11/15, Sam Barrow [EMAIL PROTECTED]: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Optional scalar type hinting
On 15/11/2007, Sam Barrow [EMAIL PROTECTED] 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=ZEND002498r=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
Re: [PHP-DEV] [PATCH] Optional scalar type hinting
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] Optional scalar type hinting
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Optional scalar type hinting
Richard Quadling wrote: On 15/11/2007, Sam Barrow [EMAIL PROTECTED] 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
