Re: [PHP-DEV] Return type hints
2008/4/15, Felipe Pena [EMAIL PROTECTED]:
Em Ter, 2008-04-15 às 01:05 -0400, Sam Barrow escreveu:
If somebody does have a patch for this or is working on one let me know.
Whether this will be implemented or not I would like to assist with this
patch so I can use it for personal use at the very least.
I already made two separated patches for param. and return value type
hints. I'll create a new thread and start discussion ASAP.
--
Regards,
Felipe Pena.
That's a simple function given. What if you need to use id many times. Then
your function will start with $id = (int)$id; or settype('int', $id);
Re: [PHP-DEV] Return type hints
Thouse who are asking about type hinting for function args are right. It is
logical to implement return type hinting with arg type hinting.
They should work either independantly (you can specify any on them or all
together) or if you declare return type - declare arg types too (then we
should have 'mixed' type too, some functions can return array or false on
error, ect).
Why we need type hinting?
Here is an example
array function myQuery(int $id){
$result = mysql_query('SELECT * FROM table WHERE id = '.$id);
// Make a array from result
return $array;
}
$id = '192b46';
$data = myQuery($id);
If some checks are implemented about what is passed, then this will be an
error (or exception witch can be cathed). And type conversion to int isn't
good, because you will get 192 instead if 19246. It's like array and object
type hinting now implemented. And i can be sure I will get an array as a
result.
Maybe it is good idea to make type conversions on function args, then we
don't need to make id = '.(int)$id ourselfs.
Re: [PHP-DEV] Return type hints
Christian Schneider We have 2 possibilities. * Throw an error * Make type conversion What to select is PHP developers team prerogative. About example - that's MySQL who is very tollerant, other databases may not threat well things like passing an ID to numeric field as string. That's bad style to me. If you have a numeric filed - pass numeric values. If you have character field - please pass strings. That's more like coding style and isn't related to this disscussion. And if you have a type-hinted language, then your ID will be integer anyway or your programm will segfault if you try to assing a string to int type variable. We are not talking about MySQL's capability to convert types itself and type hinting isn't related only to databases - i just took first example I could think of. About conversions - see how PHP converts types - that's written in the manual echo (int)42; - 42 echo (int)42foo; - 42 echo (int)foo; - 0 echo (int)foo42; - 0 At least on bad ID's like foo or foo42 you will have 0 and usualy there are no ids with value 0 in databases, so you will get No data avaliable - that's my approach witch proved to be good one over the years.
Re: [PHP-DEV] Return type hints
Em Ter, 2008-04-15 às 01:05 -0400, Sam Barrow escreveu: If somebody does have a patch for this or is working on one let me know. Whether this will be implemented or not I would like to assist with this patch so I can use it for personal use at the very least. I already made two separated patches for param. and return value type hints. I'll create a new thread and start discussion ASAP. -- Regards, Felipe Pena. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
I already made two separated patches for param. and return value type hints. I'll create a new thread and start discussion ASAP. Why not put it to the wiki? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
Chris Stockton schrieb:
Why on earth would you have int, string, resource, etc return type hints
and then turn around and suggest for parameter hinting just add a scalar
type? That makes no sense and is so inconsistent.
static int function retarded(scalar $value) {
return (int) $value; // lol
}
Let me turn your question around: Why on earth would someone restrict a
function to int when string works just as well?
function int foo_flexible(scalar $x) { return $x + 42; }
$foo = foo_flexible($value);
function int foo_retarded(int $x) { return $x + 42; }
$foo = foo_retarded((int)$value); # :-(
That said, I'll be using
function foo($x) { return $x + 42; }
anyway and let PHP warnings take care of the rest ;-)
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
You are missing the point, why be strict on return types, and liberal on
parameters? Be strict consistently or be liberal consistently. Or, keep php,
php. I could care less as long as things are consistent, although I think
only supporting scalar is silly regardless of type juggling.
-Chris
On Mon, Apr 14, 2008 at 7:28 AM, Christian Schneider [EMAIL PROTECTED]
wrote:
Chris Stockton schrieb:
Why on earth would you have int, string, resource, etc return type
hints
and then turn around and suggest for parameter hinting just add a scalar
type? That makes no sense and is so inconsistent.
static int function retarded(scalar $value) {
return (int) $value; // lol
}
Let me turn your question around: Why on earth would someone restrict a
function to int when string works just as well?
function int foo_flexible(scalar $x) { return $x + 42; }
$foo = foo_flexible($value);
function int foo_retarded(int $x) { return $x + 42; }
$foo = foo_retarded((int)$value); # :-(
That said, I'll be using
function foo($x) { return $x + 42; }
anyway and let PHP warnings take care of the rest ;-)
- Chris
Re: [PHP-DEV] Return type hints
On 14.04.2008, at 19:49, Christian Schneider wrote: Am 14.04.2008 um 19:04 schrieb Chris Stockton: You are missing the point, why be strict on return types, and liberal on parameters? Be strict Because IMHO a function can easily specify what it is returning but should be flexible in what it accepts - that's what a good PHP API is to me. Asking for consistency just for the sake of consistency seems wrong here. Especially when it sends out the message that function parameters should be (over-)specified to exact types. Right .. this is so beautiful. So we get type hints for parameters, then someone starts implements a patch for return types (for consistency) and goes a bit further than what we already have and suddenly (for consistency) the parameter type hints need to be adjusted as well. Err .. what? Who is missing the point here? I think this illustrates the consistency arguments that are thrown around since recently quite well. Either it makes sense or does not make sense in its own right. Do not use consistency as an excuse to add things. Now we have had this debate, but I guess it ends up being a fairly non technical debate about who likes what and who wants PHP to change in what ways .. oh well .. I give up .. this debate is a horse that is so dead it can never die anyways. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
If somebody does have a patch for this or is working on one let me know. Whether this will be implemented or not I would like to assist with this patch so I can use it for personal use at the very least. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
On 08.04.2008, at 12:13, Krister Karlström wrote:
Yes indeed you can implement it using the __call method, but it
would be more readable if the language structure itself would
support it. I suggested this just because I think that this is the
most common way of using overloading, thus this probably would make
sense to lot of users out there.
I think polymorphism is exactly the opposite from easier to read. For
the bulk of functions I will never need it (even if I am a type hint
lover) and so by default I now have to look for all variations of a
single method instead of knowing its either that one or its in
__call() (well there is also inheritance, but lets now make it any
harder for this fairly rare case). This is all a solution to a problem
we do not have (but are trying to get with type hints)/
I think type hint's would be good optional functionality. Those
who need
will use it, others will not. I'd probably use it in some cases.
Especially
if named parameters are implemented.
Sometimes what I really want is named parameter pass like
function myfunc(array $array, string $string = null, int $someint
= 0){
}
myfunc($myArray, someint = $mySomeInt);
Named parameters I see as much more useful, though I generally think
that there are ways to ensure that the number of parameters stays
small enough to not make named parameters necessary.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
On 07.04.2008, at 19:59, Stanislav Malyshev wrote: Hi! Right if at all I would agree on having a type hint scalar, but not a separate one per type. IMO (as already was discussed like 10 times?) scalar makes no sense. It doesn't save you any checks, and doesn't provide any useful information and can't perform any useful conversions, etc. for you. BTW, the statement to usefulness of scalar is that no C API function ever needed scalar as parameter type - and while we had a lot of formats for zend_parse_parameters, including objects, arrays, resources, numbers, strings of various kinds, callbacks, etc., we don't have scalar one. I consider it a strong indication that this idea is not as good as it might seem. Maybe we should be thinking more in terms of scalar sometimes, then we might not have gotten that BC break in array_merge(). regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
Why on earth would you have int, string, resource, etc return type hints
and then turn around and suggest for parameter hinting just add a scalar
type? That makes no sense and is so inconsistent.
static int function retarded(scalar $value) {
return (int) $value; // lol
}
Re: [PHP-DEV] Return type hints
Em, you have __call method in classes - via it you could implement ANY logic
for overloading. It's written in manual here:
http://www.php.net/manual/en/language.oop5.overloading.php
KISS should be followed - no C++ style overloading is needed, PHP is a
script language without strict type hinting.
2008/4/8, Krister Karlström [EMAIL PROTECTED]:
Hi!
This is maybe getting a bit out of topic now, but what about
function/method overloading using type hinting:
function myfunc(string $data) { }
function myfunc(int $data) { }
function myfunc(myClass $data) { }
This currently causes an error in PHP 5.2.5 that function myfunc() can't
be redeclared. This would in my opinion be very useful for methods in
classes.
Greetings,
Krister Karlström, Helsinki, Finland
Arvids Godjuks wrote:
I think type hint's would be good optional functionality. Those who need
will use it, others will not. I'd probably use it in some cases.
Especially
if named parameters are implemented.
Sometimes what I really want is named parameter pass like
function myfunc(array $array, string $string = null, int $someint = 0){
}
myfunc($myArray, someint = $mySomeInt);
--
* Ing. Krister Karlström, Zend Certified Engineer *
* Systemutvecklare, IT-Centralen *
* Arcada - Nylands Svenska Yrkeshögskola *
* Jan-Magnus Janssons plats 1, 00550 Helsingfors, Finland *
* Tel: +358(20)7699699 GSM: +358(50)5328390 *
* E-mail: [EMAIL PROTECTED] *
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
Yes it does, and not only for VB developers.
I'm plain PHP developer (with some small Pascal and Delphi background) and I
faced quite a lot situations when named parameters would give me a lot. In
stead had to write some nasty code like
myFunc($param1, $param2, array(), null, $paramX);
myFunc($param1, array(), $param4, $param5, $paramX);
And it wasn't a matter of placing function params in right order - I was
just impossible. Actual alternatives were in writing functions wrappers or
write specialized functions witch were doing the same taks, just didn't made
checks for params.
2008/4/8, Richard Quadling [EMAIL PROTECTED]:
On 08/04/2008, Arvids Godjuks [EMAIL PROTECTED] wrote:
I think type hint's would be good optional functionality. Those who need
will use it, others will not. I'd probably use it in some cases.
Especially
if named parameters are implemented.
Sometimes what I really want is named parameter pass like
function myfunc(array $array, string $string = null, int $someint = 0){
}
myfunc($myArray, someint = $mySomeInt);
I think Named Parameters would be nice for VB developers.
It makes a LOT of sense to have this I think.
Re: [PHP-DEV] Return type hints
Actually nothing could support my point about giving the wrong signals
better than these two postings: They are IMHO on the wrong track on how
to make an interface better.
Krister Karlström wrote:
This is maybe getting a bit out of topic now, but what about
function/method overloading using type hinting:
function myfunc(string $data) { }
function myfunc(int $data) { }
function myfunc(myClass $data) { }
sarcasm
Go back to Java please ;-)
/sarcasm
Arvids Godjuks wrote:
I think type hint's would be good optional functionality. Those who need
will use it, others will not. I'd probably use it in some cases.
Especially if named parameters are implemented.
Sometimes what I really want is named parameter pass like
function myfunc(array $array, string $string = null, int $someint = 0){
}
myfunc($myArray, someint = $mySomeInt);
While I think named parameters are a good idea I pointed out in older
postings that I think this is a very crippled approach to it: You still
have to define all the parameters you are going to accept. The real
power and flexibility comes in if you accept (and handle) arbitrary
argument lists.
plug
See http://itools.search.ch/ for an example of what I mean.
/plug
Okay, enough evangelism for today, back to work :-)
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
Yes indeed you can implement it using the __call method, but it would be
more readable if the language structure itself would support it. I
suggested this just because I think that this is the most common way of
using overloading, thus this probably would make sense to lot of users
out there.
But it was only a suggestion among others.
/Krister Karlström
Arvids Godjuks wrote:
Em, you have __call method in classes - via it you could implement ANY logic
for overloading. It's written in manual here:
http://www.php.net/manual/en/language.oop5.overloading.php
KISS should be followed - no C++ style overloading is needed, PHP is a
script language without strict type hinting.
2008/4/8, Krister Karlström [EMAIL PROTECTED]:
Hi!
This is maybe getting a bit out of topic now, but what about
function/method overloading using type hinting:
function myfunc(string $data) { }
function myfunc(int $data) { }
function myfunc(myClass $data) { }
This currently causes an error in PHP 5.2.5 that function myfunc() can't
be redeclared. This would in my opinion be very useful for methods in
classes.
Greetings,
Krister Karlström, Helsinki, Finland
Arvids Godjuks wrote:
I think type hint's would be good optional functionality. Those who need
will use it, others will not. I'd probably use it in some cases.
Especially
if named parameters are implemented.
Sometimes what I really want is named parameter pass like
function myfunc(array $array, string $string = null, int $someint = 0){
}
myfunc($myArray, someint = $mySomeInt);
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
Hi!
This is maybe getting a bit out of topic now, but what about
function/method overloading using type hinting:
function myfunc(string $data) { }
function myfunc(int $data) { }
function myfunc(myClass $data) { }
This currently causes an error in PHP 5.2.5 that function myfunc() can't
be redeclared. This would in my opinion be very useful for methods in
classes.
Greetings,
Krister Karlström, Helsinki, Finland
Arvids Godjuks wrote:
I think type hint's would be good optional functionality. Those who need
will use it, others will not. I'd probably use it in some cases. Especially
if named parameters are implemented.
Sometimes what I really want is named parameter pass like
function myfunc(array $array, string $string = null, int $someint = 0){
}
myfunc($myArray, someint = $mySomeInt);
--
* Ing. Krister Karlström, Zend Certified Engineer *
* Systemutvecklare, IT-Centralen *
* Arcada - Nylands Svenska Yrkeshögskola *
* Jan-Magnus Janssons plats 1, 00550 Helsingfors, Finland *
* Tel: +358(20)7699699 GSM: +358(50)5328390 *
* E-mail: [EMAIL PROTECTED] *
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
I think type hint's would be good optional functionality. Those who need
will use it, others will not. I'd probably use it in some cases. Especially
if named parameters are implemented.
Sometimes what I really want is named parameter pass like
function myfunc(array $array, string $string = null, int $someint = 0){
}
myfunc($myArray, someint = $mySomeInt);
Re: [PHP-DEV] Return type hints
On 07/04/2008, Timothy Chandler [EMAIL PROTECTED] wrote: I guess I should say it before anyone else does... It's not the PHP way - Timothy Chandler Simple Site Solutions And before PHP6 neither was native Unicode. And before PHP5 neither was a lot of the cool features of OOP (yeah PHP4 had it but in a different way). The PHP way is, at best, how thing were done until enough people wanted it and it is now how things are done. -- - 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] Return type hints
Em Seg, 2008-04-07 às 15:48 +1000, Timothy Chandler escreveu:
I guess I should say it before anyone else does...
It's not the PHP way
Do you mean the way that i initially suggest?
Anyway return type hints (probably)? will implemented,
at least it was accepted in 'Minutes PHP Developers Meeting'.
As far as i know, just wasn't decided the syntax.
- Timothy Chandler
Simple Site Solutions
Felipe Pena wrote:
Hello ladies and gentlemen,
I made a patch that implements an experimental return type hint,
therefore we need discuss much about this yet, right? :)
My idea uses (php-type) and +className as notation, see below.
- PHP types
function (string) foo(...) { } // Unicode string too
function (object) foo(...) { } // Strict
function (array) foo(...) { } // Strict
function (bool) foo(...) { } // Strict
function(int) foo(...) { } // Accepts numeric string
function (double) foo(...) { } // Accepts numeric string
:: Question ---
- Add (resource), (unicode), (void) ? |
---
- Userland types (like actual parameter type-hint)
function +className foo(...) { }
function +interfaceName foo(...) { }
// Uses the class/interface 'int', not the type
function +int foo(...) { }
:: Question
- Weird syntax?|
:: Examples
interface Itest { }
class bar implements Itest { }
class foo extends bar { }
class test {
static public function +Itest testing($instance) {
return $instance;
}
}
test::testing(new bar);
test::testing(new foo);
test::testing(new stdclass); // Error!
// Catchable fatal error: The returned value must implement interface
Itest
-
class foo {
public function +self getInstance() {
return $this;
}
}
$test = new foo;
var_dump($test-getInstance()); // OK!
object(foo)#1 (0) {
}
Finally, it's nice or poor syntax?
What must be improved/changed? (All?)
Patch: http://felipe.ath.cx/diff/return_type_hint.diff
Tests: http://felipe.ath.cx/diff/tests/
--
Regards,
Felipe Pena.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
Em Seg, 2008-04-07 às 01:32 -0700, [EMAIL PROTECTED] escreveu: :: Question - Weird syntax?| The syntax with the type casting seems abit weird as I've wrote above, I would suggest perhaps making each datatype name a reserved keyword, eg. int, integer, bool, bolean ect. I really tried avoid this. This is the reason for two notations. -- Regards, Felipe Pena. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
On Mon, Apr 7, 2008 at 2:28 PM, Felipe Pena [EMAIL PROTECTED] wrote:
class test {
static public function +Itest testing($instance) {
return $instance;
}
}
A more sane syntax, might be something like:
class test {
static function testing($instance) : Itest {
return $instance;
}
}
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
Or something like this would be nice too, please avoid using +TYPE or
(TYPE).
class test {
public static Itest function testing($instance) {
return $instance;
}
}
troels knak-nielsen wrote:
On Mon, Apr 7, 2008 at 2:28 PM, Felipe Pena [EMAIL PROTECTED] wrote:
class test {
static public function +Itest testing($instance) {
return $instance;
}
}
A more sane syntax, might be something like:
class test {
static function testing($instance) : Itest {
return $instance;
}
}
--
troels
--
*Jarismar Chaves da Silva*
Re: [PHP-DEV] Return type hints
Hello,
Em Seg, 2008-04-07 às 10:15 -0300, Jarismar Chaves da Silva escreveu:
Or something like this would be nice too, please avoid using +TYPE
or (TYPE).
class test {
public static Itest function testing($instance) {
return $instance;
}
}
troels knak-nielsen wrote:
On Mon, Apr 7, 2008 at 2:28 PM, Felipe Pena [EMAIL PROTECTED] wrote:
class test {
static public function +Itest testing($instance) {
return $instance;
}
}
A more sane syntax, might be something like:
class test {
static function testing($instance) : Itest {
return $instance;
}
}
--
troels
--
Jarismar Chaves da Silva
As i said previously:
I really tried avoid this.
This is the reason for two notations.
Actually 'integer', 'double', 'string', etc are allowed in function, class and
interface names.
Using only 1 notation, we would have that make them keywords.
--
Regards,
Felipe Pena.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
On Sun, 6 Apr 2008, Mike Lively wrote:
On Sun, Apr 6, 2008 at 8:41 PM, Felipe Pena [EMAIL PROTECTED] wrote:
- PHP types
function (string) foo(...) { } // Unicode string too
function (object) foo(...) { } // Strict
function (array) foo(...) { } // Strict
function (bool) foo(...) { } // Strict
function(int) foo(...) { } // Accepts numeric string
function (double) foo(...) { } // Accepts numeric string
If there ever were return type hinting in PHP I don't think it would be wise
to support PHP Types unless parameter hints were changed to support them.
It's just inconsistent.
Right, this shouldn't even be on the agenda before we have scalar type
hints. So, perhaps you can make a patch for that first Felipe?
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
Em Seg, 2008-04-07 às 15:44 +0200, Derick Rethans escreveu:
On Sun, 6 Apr 2008, Mike Lively wrote:
On Sun, Apr 6, 2008 at 8:41 PM, Felipe Pena [EMAIL PROTECTED] wrote:
- PHP types
function (string) foo(...) { } // Unicode string too
function (object) foo(...) { } // Strict
function (array) foo(...) { } // Strict
function (bool) foo(...) { } // Strict
function(int) foo(...) { } // Accepts numeric string
function (double) foo(...) { } // Accepts numeric string
If there ever were return type hinting in PHP I don't think it would be wise
to support PHP Types unless parameter hints were changed to support them.
It's just inconsistent.
Right, this shouldn't even be on the agenda before we have scalar type
hints. So, perhaps you can make a patch for that first Felipe?
I don't thought this before!
Sure, i'll try provide a patch.
Thanks.
--
Regards,
Felipe Pena.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
I have a scalar type hinting patch on my blog at www.sambarrow.com On Mon, 2008-04-07 at 10:57 -0300, Felipe Pena wrote: I don't thought this before! Sure, i'll try provide a patch. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
On 4/7/08 9:15 AM, Jarismar Chaves da Silva wrote:
Or something like this would be nice too, please avoid using +TYPE or
(TYPE).
class test {
public static Itest function testing($instance) {
return $instance;
}
}
I think this is the most intuitive approach. However, this means that regular
function declarations would be like:
Itest function testing($instance) {
return $instance;
}
Would this present a problem?
--
Ben Ramsey
http://benramsey.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
Stanislav Malyshev wrote: I'm not sure I understand - how array_reduce is related to having type hints? You could make array_reduce to do additional things, but that doesn't require introducing strong typing into php. The relation between array_reduce and scalar type hints is that API start to enforce certain types where they should not just because the programmer thinks it is a good idea. Currently the third parameter $initial of array_reduce only allows int. So instead of allowing any zval and leaving it to the callback function to deal with it a specific type is enforced. You can work around this by checking for NULL inside the callback and initializing it there but that does not work either if you use a built-in function as callback. - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
On 07.04.2008, at 18:49, Christian Schneider wrote: Felipe Pena wrote: Right, this shouldn't even be on the agenda before we have scalar type hints. So, perhaps you can make a patch for that first Felipe? I don't thought this before! Sure, i'll try provide a patch. Just so this side was mentioned once again too: There are people who consider type hints and especially scalar type hints A Bad Thing(tm) as it is contrary to the PHP strength of dynamic typing and automatic type conversion. Right if at all I would agree on having a type hint scalar, but not a separate one per type. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
On 07.04.2008, at 18:57, Stanislav Malyshev wrote: Hi! I just ran into this (IMHO unnecessary) limitation with array_reduce: Why should it only reduce to an int? Why not a string or an array? I plan on submitting a patch for PHP 6 to allow other types too. I'm not sure I understand - how array_reduce is related to having type hints? You could make array_reduce to do additional things, but that doesn't require introducing strong typing into php. PHP should be as flexible about types as possible. I never used array_reduce() so I do not know its history. But some of you might remember the change in behavior from array_merge() which was the result of a switch to a more strict parameter parsing API, which now returns false when you pass in NULL. A fair amount of people believe that this is the wrong direction to take. Continuously expanding type hints relates to this concern. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
Hi! Right if at all I would agree on having a type hint scalar, but not a separate one per type. IMO (as already was discussed like 10 times?) scalar makes no sense. It doesn't save you any checks, and doesn't provide any useful information and can't perform any useful conversions, etc. for you. BTW, the statement to usefulness of scalar is that no C API function ever needed scalar as parameter type - and while we had a lot of formats for zend_parse_parameters, including objects, arrays, resources, numbers, strings of various kinds, callbacks, etc., we don't have scalar one. I consider it a strong indication that this idea is not as good as it might seem. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
On 07/04/2008, Christian Schneider [EMAIL PROTECTED] wrote: Just so this side was mentioned once again too: There are people who consider type hints and especially scalar type hints A Bad Thing(tm) as it is contrary to the PHP strength of dynamic typing and automatic type conversion. We are told that user data is dirty. Cleaning it is essential. One of the simplest ways is to cast the data to the right type. If they enter a date, then make sure it is a date by converting it to a date - if it can't convert then it wasn't a date. Why would you retain the string as your PRIMARY value? If you intend to do date manipulation you have to convert it. To use scalars they have to be in the right type. I cannot take 2 days from a string which is a date without having to do some conversion. The net result is that most user data should end up in the correct type anyway. So at what stage does this dynamic juggling of scalars take place? And why is it considered non-dynamic having a function declaration tell third party developers the scalar type of the parameters should be? If it was truly dynamic, they would be juggled for me rather than have me do it in userland. About the only time juggling is effective is in string concatenation. And even then it misses booleans! Do I get true/false? No I get nothing or 1. So I have to process it. Type juggling just doesn't seem to fit well with me. -- - 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] Return type hints
Richard Quadling schrieb: Type juggling just doesn't seem to fit well with me. You seem to live in a completely different PHP world. Because in our case we use (yes, knowingly use) the PHP type juggling and it safes us lots of manual type conversions. We get input from all different sources as strings (_GET, MySQL, files) and in a lot of cases we just use it. We don't care if it's a string, a number or a float (or even null), if it yields the right result in our calculation it's fine. Now if a function only expects int (and truncates floats because of that) like array_reduce does with the $initial parameter then this function is crippled (for no good reason). Promoting type hints for PHP (and more so scalar type hints, especially specific scalar type hints like int) might give the impression to API developers that highly specified interfaces are better than more general ones. If we can learn something from the current hype around functional languages then it is the fact that generic, data type independant functions can be a very powerful tool. Something like array_* should be as generic as possible and API developers should also be aware of this topic and be given the right signals. Therefore my conclusion (abusing Einstein ;-)): Make interfaces as specific as *necessary* but *not more*. - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
Felipe Pena escribió:
Hello ladies and gentlemen,
I made a patch that implements an experimental return type hint,
therefore we need discuss much about this yet, right? :)
Thanks for raising this issue !!
function(int) foo(...) { } // Accepts numeric string
function (double) foo(...) { } // Accepts numeric string
hrmmm.. nope. neither double nor int should accept numeric string..
:: Question ---
- Add (resource), (unicode), (void) ? |
---
yes !!
:: Question
- Weird syntax?|
Yes, not intuitive at all...
What must be improved/changed? (All?)
Dunno, Have not tested the patch yet, but will :)
Thanks.
--
“If debugging is the process of removing bugs, then programming must be
the process of putting them in.” – Edsger Dijkstra
Cristian Rodríguez R.
Platform/OpenSUSE - Core Services
SUSE LINUX Products GmbH
Research Development
http://www.opensuse.org/
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] Return type hints
On Sun, Apr 6, 2008 at 8:41 PM, Felipe Pena [EMAIL PROTECTED] wrote:
- PHP types
function (string) foo(...) { } // Unicode string too
function (object) foo(...) { } // Strict
function (array) foo(...) { } // Strict
function (bool) foo(...) { } // Strict
function(int) foo(...) { } // Accepts numeric string
function (double) foo(...) { } // Accepts numeric string
If there ever were return type hinting in PHP I don't think it would be wise
to support PHP Types unless parameter hints were changed to support them.
It's just inconsistent.
:: Question
- Weird syntax?|
Yes, is there any reason why any special characters are needed?
Re: [PHP-DEV] Return type hints
I guess I should say it before anyone else does...
It's not the PHP way
- Timothy Chandler
Simple Site Solutions
Felipe Pena wrote:
Hello ladies and gentlemen,
I made a patch that implements an experimental return type hint,
therefore we need discuss much about this yet, right? :)
My idea uses (php-type) and +className as notation, see below.
- PHP types
function (string) foo(...) { } // Unicode string too
function (object) foo(...) { } // Strict
function (array) foo(...) { } // Strict
function (bool) foo(...) { } // Strict
function(int) foo(...) { } // Accepts numeric string
function (double) foo(...) { } // Accepts numeric string
:: Question ---
- Add (resource), (unicode), (void) ? |
---
- Userland types (like actual parameter type-hint)
function +className foo(...) { }
function +interfaceName foo(...) { }
// Uses the class/interface 'int', not the type
function +int foo(...) { }
:: Question
- Weird syntax?|
:: Examples
interface Itest { }
class bar implements Itest { }
class foo extends bar { }
class test {
static public function +Itest testing($instance) {
return $instance;
}
}
test::testing(new bar);
test::testing(new foo);
test::testing(new stdclass); // Error!
// Catchable fatal error: The returned value must implement interface
Itest
-
class foo {
public function +self getInstance() {
return $this;
}
}
$test = new foo;
var_dump($test-getInstance()); // OK!
object(foo)#1 (0) {
}
Finally, it's nice or poor syntax?
What must be improved/changed? (All?)
Patch: http://felipe.ath.cx/diff/return_type_hint.diff
Tests: http://felipe.ath.cx/diff/tests/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
On Wed, September 13, 2006 4:57 am, Terje Slettebø wrote: I'd say that's debatable. :) Yes, it can make it more convenient to handle data coming from outside the script (such as forms), but it can also hide bugs. While it can be argued that conversions between, say, arithmetic types (int and floats) may be useful, allowing conversion from something like NULL to empty string, integer 0, etc. (as PHP does) may be going a little Except that it's also very handy often-times. over board, as an uninitialised variable (such as a member variable) may not be easily discovered. You still haven't discovered E_NOTICE???... [much deleted] A year from now, are the purists going to be making missing type hints E_STRICT and E_DEPRECATED? :-) There's a point where I wonder why some people (not necessarily Terje) are using PHP at all. It's obvious they want an entirely different language... :-) -- Like Music? http://l-i-e.com/artists.htm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
On Wed, September 13, 2006 6:01 am, Richard Quadling wrote:
The issue then becomes what would happen to a value of the wrong type?
You either have the option of using PHP's own internal casting
mechanism, so f(int $i_int_expected) would internally cast the
supplied parameter as an int or you have to produce a WARNING with a
parameter of the wrong type message. But then what is passed to the
function? This would have to be determined somehow.
Could I just point out that MANY PHP functions do things like this:
/* returns int for blah blah
* returns false in case of error
*/
function foo($x){
if (world_has_ended()) return false;
}
So if you're going to insist on type hints, can we not at least make
it sensible and have syntax like:
int|bool function foo (){
}
So foo() returns int or bool.
Otherwise, you end up with (int) false strewn all through your code,
and it looks all messy.
There's a REASON why I'm writing PHP and not C, folks... :-)
--
Like Music?
http://l-i-e.com/artists.htm
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Why isn't base class constructors or destructors required to be called? (was: Re: [PHP-DEV] Return type hints)
When would the constructor be called automatically? I've used Delphi and you use the inherit verb (or inherited - long time ago - can't remember exactly). In PHP parent::__construct (though I think parent::__METHOD__ would be cleaner as this removes ambiguity on the actual name for all inherited methods). Well, let's look at C++, which I'm most familiar with. PHP is not C++ Ah, I was kind of waiting for that one... :) Yet, that says absolutely nothing about why PHP works the way it does. and speaking of constructors and destrcutors PHP goes morethe Delphi way. If constructors/destructors are not the PHP way, then why even have them? We do not claim to follow any other language precisely, PHP is it's own language with its own feature set. Naturally, but is it unreasonable to think that there's a reason for the way things work in PHP...? And to ask _why_ PHP doesn't let you ensure that a class has its constructor/destructor called? Why implement constructors/destructors in such a way that they may - or may not - be called? Do you feel lucky? Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Why isn't base class constructors or destructors required to be called? (was: Re: [PHP-DEV] Return type hints)
From: Marcus Boerger [EMAIL PROTECTED] PHP is not C++ and speaking of constructors and destrcutors PHP goes morethe Delphi way. I'd also like to know _why_ constructors/destructors are less fit for PHP, than these other languages? How can you be sure that objects of a class are properly initialised, and that they clean up after themselves? (Yes, I know the runtime cleans up after them, at script termination, if want to be sloppy, but that still doesn't cover the constructor case) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Why isn't base class constructors or destructors required to be called? (was: Re: [PHP-DEV] Return type hints)
Well, PHP is a loosely typed language. You have much more freedom when you write a code. Constructors are not an exception. It is very convinient that you may not call the parent constructor and many people do it, believe me! And also the flag for the internal classes that has been discussed is maybe enough for PHP. 2006/9/15, Terje Slettebø [EMAIL PROTECTED]: From: Marcus Boerger [EMAIL PROTECTED] PHP is not C++ and speaking of constructors and destrcutors PHP goes morethe Delphi way. I'd also like to know _why_ constructors/destructors are less fit for PHP, than these other languages? How can you be sure that objects of a class are properly initialised, and that they clean up after themselves? (Yes, I know the runtime cleans up after them, at script termination, if want to be sloppy, but that still doesn't cover the constructor case) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Why isn't base class constructors or destructors required to be called? (was: Re: [PHP-DEV] Return type hints)
From: Marian Kostadinov [EMAIL PROTECTED] Well, PHP is a loosely typed language. You have much more freedom when you write a code. Constructors are not an exception. It is very convinient that you may not call the parent constructor and many people do it, believe me! Why would you not call the base class constructor/destructor? Could you give an example? Regards, Terje 2006/9/15, Terje Slettebø [EMAIL PROTECTED]: From: Marcus Boerger [EMAIL PROTECTED] PHP is not C++ and speaking of constructors and destrcutors PHP goes morethe Delphi way. I'd also like to know _why_ constructors/destructors are less fit for PHP, than these other languages? How can you be sure that objects of a class are properly initialised, and that they clean up after themselves? (Yes, I know the runtime cleans up after them, at script termination, if want to be sloppy, but that still doesn't cover the constructor case) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Why isn't base class constructors or destructors required to be called? (was: Re: [PHP-DEV] Return type hints)
On 9/15/06, Terje Slettebø [EMAIL PROTECTED] wrote: From: Marcus Boerger [EMAIL PROTECTED] PHP is not C++ and speaking of constructors and destrcutors PHP goes morethe Delphi way. I'd also like to know _why_ constructors/destructors are less fit for PHP, than these other languages? Nobody said that. Marcus said PHP takes a more Delphi-like approach rather than a C++-like approach. PHP following some other language rather than your language of choice doesn't mean that its designed wrong. -- --Robert Deaton
Re: [PHP-DEV] Return type hints
Terje Slettebø wrote: The above was a contrived example, meant to illustrate the point. What's so bad about it? That it doesn't check the return value? I am not worried about the return value of the method. I am concerned that $this-something is unset yet does not throw a notice. This is only true for properties of objects. Any other variable in PHP does not behave this way. IMHO, PHP should either initialize that variable to a default type and value or throw a notice when you try and use it without setting its value. I completely agree. :) _Then_ I understood you; I thought you meant my example(code) was crap... :) Another weird thing of PHP's implementation of OO is that propagation of constructor calls to the base class is not ensured, something I can't for the life of me understand why, but that deserves its own thread... Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Why isn't base class constructors or destructors required to be called? (was: Re: [PHP-DEV] Return type hints)
(This went to me privately, but in order for this to benefit the discussion,
I reply to the list, as well. Besides, there's now another thread for this,
too)
Hi Richard.
When would the constructor be called automatically? I've used Delphi
and you use the inherit verb (or inherited - long time ago - can't
remember exactly). In PHP parent::__construct (though I think
parent::__METHOD__ would be cleaner as this removes ambiguity on the
actual name for all inherited methods).
Well, let's look at C++, which I'm most familiar with. Here's an example:
class Base
{
protected:
Base(int a) { ... }
};
class Derived : public Base
{
public:
Derived() : Base(123) // Base class constructor called here
{
...
}
}
In C++, the order of construction goes from the top base class to the most
derived class (although using virtual inheritance complicates that a
little), and destruction happens in the reverse order. One important point
is that the all the base class constructors (if any) are called before the
derived class's constructor body (i.e. what's between { and }) is
entered. This way, you may rely on properly constructed base classes, as
well as initialised member variables, in the constructor. The Derived() :
Base(123) syntax is, as may be familiar, an initialiser list, and may be
used to initialise both any base classes, as well as member variables.
With reference to another thread about uninitialised member variables: In
C++, unless these are initialised using the initialiser list, they will be
default-constructed, so they are also in a well-defined state, on entry to
the constructor body. The same goes for any base classes.
Now, what to do in PHP? As PHP is defined, the best might simply be to give
an error/warning/notice, if a base class hasn't been initialised (i.e. had
its constructor called) when the derived class constructor finishes. As PHP
doesn't have concepts like initialiser lists, or default-construction of
base classes and member variables (unless these are explicitly constructed
in these lists), it may not be much point in trying to do it that way in
PHP.
Regards,
Terje
On 14/09/06, Terje Slettebø [EMAIL PROTECTED] wrote:
Terje Slettebø wrote:
The above was a contrived example, meant to illustrate the point.
What's
so
bad about it? That it doesn't check the return value?
I am not worried about the return value of the method. I am concerned
that $this-something is unset yet does not throw a notice. This is
only true for properties of objects. Any other variable in PHP does
not
behave this way. IMHO, PHP should either initialize that variable to
a
default type and value or throw a notice when you try and use it
without
setting its value.
I completely agree. :) _Then_ I understood you; I thought you meant my
example(code) was crap... :)
Another weird thing of PHP's implementation of OO is that propagation of
constructor calls to the base class is not ensured, something I can't
for
the life of me understand why, but that deserves its own thread...
Regards,
Terje
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Why isn't base class constructors or destructors required to be called? (was: Re: [PHP-DEV] Return type hints)
Hello Terje, Thursday, September 14, 2006, 9:47:20 PM, you wrote: (This went to me privately, but in order for this to benefit the discussion, I reply to the list, as well. Besides, there's now another thread for this, too) Hi Richard. When would the constructor be called automatically? I've used Delphi and you use the inherit verb (or inherited - long time ago - can't remember exactly). In PHP parent::__construct (though I think parent::__METHOD__ would be cleaner as this removes ambiguity on the actual name for all inherited methods). Well, let's look at C++, which I'm most familiar with. PHP is not C++ and speaking of constructors and destrcutors PHP goes morethe Delphi way. We do not claim to follow any other language precisely, PHP is it's own language with its own feature set. It seems to me that you are using the wrong language. I guess you should have a look at Phyton. best regards marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
On 12/09/06, Terje Slettebø [EMAIL PROTECTED] wrote:
function f(Something $value) /** @return SomethingElse */
{
// ...
}
One of the good things about PHP is the loose typing (1.00 == 1 == 1
sort of thing as I understand it). This has been useful.
But one of the first things we are told about using PHP ITRW is to
always validate user input and to make sure you only accept what you
know to be valid data.
More often than not, this ends up casting the data to a specific type
(number of payments - int, date of birth - date, email address -
string (or user type of email), delete - Boolean). You may even have
functions which require/expect a parameter to be of a specific type.
We can already use type hinting for arrays and classes for parameters.
Type hinting could be extended to all types for user functions. Even
the possibility of accepting multiple types for a single parameter
could be used to support a mixed type.
Recently we had a discussion about parameter overloading on methods.
You can probably use __magic to produce the effect of parameter
overloading.
Whilst casting the return type is easy to do, having the return type
as part of the function declaration would be very useful for
auto-documentors.
As for syntax, I would go with ...
type function f(type $value)
It would be useful to also have VOID as a return type, but that may be
open for discussion.
But mixed type returns (normal type -string/int/real/Boolean - for
valid results AND Boolean False for failure) would need to be
considered.
--
-
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498amp;r=213474731
Standing on the shoulders of some very clever giants!
Re: [PHP-DEV] Return type hints
From: Richard Quadling [EMAIL PROTECTED]
On 12/09/06, Terje Slettebø [EMAIL PROTECTED] wrote:
function f(Something $value) /** @return SomethingElse */
{
// ...
}
One of the good things about PHP is the loose typing (1.00 == 1 == 1
sort of thing as I understand it). This has been useful.
I'd say that's debatable. :) Yes, it can make it more convenient to handle
data coming from outside the script (such as forms), but it can also hide
bugs. While it can be argued that conversions between, say, arithmetic types
(int and floats) may be useful, allowing conversion from something like NULL
to empty string, integer 0, etc. (as PHP does) may be going a little over
board, as an uninitialised variable (such as a member variable) may not be
easily discovered.
It's interesting to note that Java (a newer language than C++) actually has
a stronger type system (at least in some respects) than C++: While C/C++
allows things like implicit conversion between int/float/pointer and bool (a
legacy from C), Java does not, and if you think about it, it makes sense to
disallow that, as boolean values are conceptually different from these.
But one of the first things we are told about using PHP ITRW is to
always validate user input and to make sure you only accept what you
know to be valid data.
True, and at least with regard to function calls, with type hinting (as you
mention below), that testing is done for you, so you don't have to, leading
to less code and syntactic noise (and possibly better performance).
We can already use type hinting for arrays and classes for parameters.
Type hinting could be extended to all types for user functions.
I asked about this about 1 1/2 year ago (as well as the possibility of
function overloading - which _would_ be at least theoretically possible, now
that we have type hints), on this list, but got a very negative response to
that... So... I figured the PHP community wasn't ready for that, or didn't
think it fit the language. I still think type hints for fundamental types
could be a good idea, for catching errors early, such as passing NULL to a
function expecting string (as long as it avoids the usual implicit
conversion).
Anyway, with Sara Golemon's operator overloading extension, it's possible to
make your own Integer, Float, String, etc. types, and use them basically as
built-in types, making it possible to use them for type hints.
Even
the possibility of accepting multiple types for a single parameter
could be used to support a mixed type.
One way to do that could be to create a user-defined variant type (or
mixed type, as you say), that may contain a specified number of types.
Yes, I know that in PHP, basically all variables are variants, but with a
class, you may restrict it to just a few specific ones.
Likewise, it's possible to create type-checked tuple types (a sequence of
values, of specified types), and ditto arrays.
As it's mentioned in the user-contributed notes on autoloading, you may even
abuse the autoloader to implement parametric types (like templates in
C++). For example, if you write:
function f(Array_string $value)
{
}
The autoloader may synthesise the Array_string type, from a generic
typed array class, to produce a custom array type that enforces numerical
indexes and string values (the above is really short for Array_int_string,
where int gives the key type, and string gives the value type).
Again, this may be useful for expressing intentions in code, as well as
runtime-enforced conditions.
Recently we had a discussion about parameter overloading on methods.
You can probably use __magic to produce the effect of parameter
overloading.
I'm not sure what you mean by parameter overloading. Do you mean function
overloading? Yes, you can simulate that, using e.g. a dispatch based on
func_get_args(), but it's rather inelegant, compared to real overloading.
Also, it's impossible to overload existing functions in the standard library
(if it was, you could provide your own count(), array_*-functions, etc. for
user-defined array types.
Whilst casting the return type is easy to do, having the return type
as part of the function declaration would be very useful for
auto-documentors.
Not only that, but in my opinion the more important thing that you may
enforce a return type (forgetting to return a proper value from a function
could be caught this way).
As for syntax, I would go with ...
type function f(type $value)
Yes, that's _one_ possibility. Let's see it in all its glory (i.e. with a
lot of other qualifiers):
public abstract SomeClass function f(SomeOther $value)
Hm, maybe. Another alternative might be (closer to C/C++/Java syntax):
qualifiers function return type function name(parameters)
E.g.:
public abstract function Someclass f(SomeOther $value)
It would be useful to also have VOID as a return type, but that may be
open for discussion.
Yes, or perhaps more natural for PHP, null.
But mixed type returns (normal
Re: [PHP-DEV] Return type hints
On 13/09/06, Terje Slettebø [EMAIL PROTECTED] wrote:
From: Richard Quadling [EMAIL PROTECTED]
On 12/09/06, Terje Slettebø [EMAIL PROTECTED] wrote:
function f(Something $value) /** @return SomethingElse */
{
// ...
}
But one of the first things we are told about using PHP ITRW is to
always validate user input and to make sure you only accept what you
know to be valid data.
True, and at least with regard to function calls, with type hinting (as you
mention below), that testing is done for you, so you don't have to, leading
to less code and syntactic noise (and possibly better performance).
The issue then becomes what would happen to a value of the wrong type?
You either have the option of using PHP's own internal casting
mechanism, so f(int $i_int_expected) would internally cast the
supplied parameter as an int or you have to produce a WARNING with a
parameter of the wrong type message. But then what is passed to the
function? This would have to be determined somehow.
--
-
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498amp;r=213474731
Standing on the shoulders of some very clever giants!
Re: [PHP-DEV] Return type hints
Richard Quadling [EMAIL PROTECTED] schreef in bericht news:[EMAIL PROTECTED] On 13/09/06, Terje Slettebø [EMAIL PROTECTED] wrote: .. The issue then becomes what would happen to a value of the wrong type? You either have the option of using PHP's own internal casting mechanism, so f(int $i_int_expected) would internally cast the supplied parameter as an int or you have to produce a WARNING with a parameter of the wrong type message. But then what is passed to the function? This would have to be determined somehow. I think it would make sense to turn the value into NULL when the casting fails. And honestly, I would love this kind of type hinting. It has to be smart in the sense that if I say double, and it's a string containing 0.123, it will either be casted to a double (which may be unfortunate, since floats and doubles are inaccurate), or simply let through as a string, because it follows double formatting (that being /-?[0-9]+(\.[0-9]+)?/). But this way type hinting for core types is only optional for people and it's not as strict as in the vast majority of other languages out there. This kind of smart type hinting would be simply perfect. Ron -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
Terje Slettebø wrote: I'd say that's debatable. :) Yes, it can make it more convenient to handle data coming from outside the script (such as forms), but it can also hide bugs. While it can be argued that conversions between, say, arithmetic types (int and floats) may be useful, allowing conversion from something like NULL to empty string, integer 0, etc. (as PHP does) may be going a little over board, as an uninitialised variable (such as a member variable) may not be easily discovered. IMHO, that is covered by === and the NOTICE error level. -- Brian Moon - http://dealnews.com/ Its good to be cheap =) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
Terje Slettebø wrote:
I'd say that's debatable. :) Yes, it can make it more convenient to
handle
data coming from outside the script (such as forms), but it can also
hide
bugs. While it can be argued that conversions between, say, arithmetic
types
(int and floats) may be useful, allowing conversion from something like
NULL
to empty string, integer 0, etc. (as PHP does) may be going a little
over
board, as an uninitialised variable (such as a member variable) may not
be
easily discovered.
IMHO, that is covered by === and the NOTICE error level.
Scenario:
--- Start ---
class Something
{
public function __construct()
{
// Oops, forgot to initialise $this-something...
}
public function f()
{
return $this-something;
}
private $something;
}
error_reporting(E_ALL);
$something=new Something;
echo $something-f()+10; // Prints 10.
--- End ---
This will run without any notices, warnings or errors. If we meant to
initialise Something::something to a value, then there's no way to detect
that in f() (other than manual type-checking), since we can't specify the
type for Something::f()'s return type. Had we been able to specify e.g.
int as the return type, the call to Something::f() would give us an error
message, alerting us to the problem.
As the program stands, it has a silent bug...
How would you solve this with === or E_ALL?
Regards,
Terje
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
--- Start ---
class Something
{
public function __construct()
{
// Oops, forgot to initialise $this-something...
}
public function f()
{
return $this-something;
}
private $something;
}
error_reporting(E_ALL);
$something=new Something;
echo $something-f()+10; // Prints 10.
If you can't trust the return values of your methods, I would use:
$var = $something-f();
if($var!==NULL){
echo $var+10; // Prints 10.
}
However, its crap like this that reminds me why I don't use PHP OOP for
all my code. I can find no non-OOP code that behaves this way. Even my
favorite PHP trick, using settype() to initialize vars, does not set the
var to NULL.
--
Brian Moon
-
http://dealnews.com/
Its good to be cheap =)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
From: Brian Moon [EMAIL PROTECTED]
--- Start ---
class Something
{
public function __construct()
{
// Oops, forgot to initialise $this-something...
}
public function f()
{
return $this-something;
}
private $something;
}
error_reporting(E_ALL);
$something=new Something;
echo $something-f()+10; // Prints 10.
If you can't trust the return values of your methods, I would use:
$var = $something-f();
if($var!==NULL){
echo $var+10; // Prints 10.
}
Right... And you can always use return codes, instead of exceptions or
trigger_error(). The problem is that there's nothing that _enforces_ this
checking, and since it adds verbosity, it's typically not done. If you don't
believe me have a look at some of all of the C code out there, which
typically to a large degree don't check return values (and it shows...
Programs segfaulting and the like, if something unexpected happens), as it
makes the program convoluted and messy, and is easily forgotten. It's for
reasons like this that exceptions (and possibly trigger_error()) were
invented in the first place.
It's similar with the example above: Type-checked return values means you
don't have to write all these tedious manual checks, just to ensure program
correctness (and had the return type hint been mandatory, there's no way you
could forget it or not bother with it, either)..
However, its crap like this that reminds me why I don't use PHP OOP for
all my code. I can find no non-OOP code that behaves this way.
The above was a contrived example, meant to illustrate the point. What's so
bad about it? That it doesn't check the return value? Well... having to
check the return value, to ensure things didn't go wrong is something I left
a looong time ago, when I was programming C, before I started with C++ and
Java, which gives better ways of handling this, and have only had to take it
up again, in PHP.
Even my
favorite PHP trick, using settype() to initialize vars, does not set the
var to NULL.
settype() is still a manual operation - there's no way to automatically
guarantee initialisation. In a language like C++, the class members are
default-initialised, unless you explicitly initialise them, so there's no
way you can forget it or ignore it. The result: More robust programs.
Regards,
Terje
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
Hello Terje, at some point i might find time to do something. I guess all others who could do something in that area are occupied either by unicode or namespaces. This means we still have this on the todo. We are only open source and all do stuff in our free time best regards marcus Tuesday, September 12, 2006, 11:40:54 AM, you wrote: Hi again. To something different: I've read [1] that return type hints for functions have been considered for PHP 6, possibly even planned. In [1], it says: We will add support for type-hinted return values. I've searched the archives, but haven't found much on this since about a year ago. Does anyone have the latest on this? Is it planned, dropped, over somebody's smoking carcass, ;) or what? I've also tried the latest PHP 6 dev-version, a while ago, but it seems it's not in there, yet, at least. If not dropped, have a syntax for this been agreed on? Regards, Terje [1] http://www.php.net/~derick/meeting-notes.html#type-hinted-properties-and-return-values Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
Hi Marcus.
Thanks for replying. Yes, I understand that very well, having been involved
in open source projects, myself, as well [1]. If I felt really strongly for
this one, I could do it, myself. :) I was mostly just interested in knowing
if this one was still a go. In our systems, we've prepared for it, thus:
function f(Something $value) /** @return SomethingElse */
{
// ...
}
By the way, I appreciate all the work that you and the other developers are
doing for PHP.
Regards,
Terje
[1] I've been involved in Loki (http://sourceforge.net/projects/loki-lib),
co-authoring the port of the library to Borland C++ (which was non-trivial,
given that Loki uses cutting-edge C++), as well as having been project
admin. Another project I'm involved in is the C++ Concept Traits Library
(http://www.neoscientists.org/~tschwinger/boostdev/concept_traits/libs/conce
pt_traits/doc/), which is a library to implement concepts (like Haskell's
type classes) in C++. Unfortunately, I haven't had a chance to do anything
with either of these for a long time, due to work, so I full well understand
that people may be busy with other things. :)
- Original Message -
From: Marcus Boerger [EMAIL PROTECTED]
To: Terje Slettebø [EMAIL PROTECTED]
Cc: internals@lists.php.net
Sent: Tuesday, September 12, 2006 11:00 PM
Subject: Re: [PHP-DEV] Return type hints
Hello Terje,
at some point i might find time to do something. I guess all others who
could do something in that area are occupied either by unicode or
namespaces. This means we still have this on the todo. We are only open
source and all do stuff in our free time
best regards
marcus
Tuesday, September 12, 2006, 11:40:54 AM, you wrote:
Hi again.
To something different: I've read [1] that return type hints for
functions
have been considered for PHP 6, possibly even planned. In [1], it says:
We
will add support for type-hinted return values.
I've searched the archives, but haven't found much on this since about a
year ago. Does anyone have the latest on this? Is it planned, dropped,
over
somebody's smoking carcass, ;) or what?
I've also tried the latest PHP 6 dev-version, a while ago, but it seems
it's
not in there, yet, at least.
If not dropped, have a syntax for this been agreed on?
Regards,
Terje
[1]
http://www.php.net/~derick/meeting-notes.html#type-hinted-properties-and-return-values
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
