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.
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/
- 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?
- 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 stringIf 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
Em Seg, 2008-04-07 às 15:44 +0200, Derick Rethans escreveu:
- 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 stringIf 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.
I have a scalar type hinting patch on my blog at www.sambarrow.com
I don't thought this before!
Sure, i'll try provide a patch.
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.
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.
- Chris
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.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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
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
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
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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
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....
}
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
Hi!
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);
Now let's think - what happens if $x is not scalar? So the real code
would be like this:
function foo_flexible(scalar $x) { return $x + 42; }
if(!is_scalar($value)) {
$foo = foo_flexible($value);
} else {
// ok, what do I do now?
}
And so for each instance. Ugly.
That said, I'll be using
function foo($x) { return $x + 42; }
anyway and let PHP warnings take care of the rest ;-)
Amen to that.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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 cschneid@cschneid.com
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
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.
consistently or be liberal consistently. Or, keep php, php. I could
care less as long as things are
Keeping PHP close to the original principles of KISS and "make common
things easy" is also a goal of mine.
- Chris
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 strictBecause 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
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.
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.
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.
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
2008/4/15, Felipe Pena felipensp@gmail.com:
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);
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=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
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
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);
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: krister.karlstrom@arcada.fi *
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 krister.karlstrom@arcada.fi:
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, FinlandArvids 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: krister.karlstrom@arcada.fi *
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.phpKISS should be followed - no C++ style overloading is needed, PHP is a
script language without strict type hinting.2008/4/8, Krister Karlström krister.karlstrom@arcada.fi:
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, FinlandArvids 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);
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 needwill 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
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:
<sarcasm> Go back to Java please ;-) </sarcasm>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) { }
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
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/
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=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
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 SolutionsFelipe 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.