I would like to take this opportunity to query on a consensus:
Would you prefer to allow methods with type hinted return values to return null
at will, or add a marker noting that it *may* return null?
Example: Return null at will
public ArrayIterator getIterator()
{
// something happened, w
I will update to take functions into consideration. Will let you know when the
RFC/patch reflect it.
On Dec 22, 2011, at 7:44 PM, Ángel González wrote:
>> (I'm unsure about the T_DOUBLE_ARROW, although for parsing, I feel there
>> should be some token there
>> before the class name, though I'm u
On Dec 22, 2011, at 7:33 PM, Ángel González wrote:
> On 23/12/11 01:00, Will Fitch wrote:
>> On Dec 22, 2011, at 6:28 PM, Stas Malyshev wrote:
>>> In PHP, returning object if everything is OK and false if not is a very
>>> common pattern.
>>> Also, you understand that always allowing null means
On Dec 22, 2011, at 7:21 PM, Ángel González wrote:
> On 23/12/11 00:08, Will Fitch wrote:
>> Sent from my iPad
>> On Dec 22, 2011, at 5:51 PM, "Ángel González" wrote:
>>
>>> Your examples only show class methods with visibility qualifyiers, and
>>> looking at the changes to zend_language_parser
On Dec 22, 2011, at 7:55 PM, Stas Malyshev wrote:
> Hi!
>
>> And in those cases, they would continue to use the keyword "function"
>> and be considered unknown as they are today.
>
> Taking the most common case and ignoring it and saying "ok, then don't use
> it" is not a good way to design a
Hi!
And in those cases, they would continue to use the keyword "function"
and be considered unknown as they are today.
Taking the most common case and ignoring it and saying "ok, then don't
use it" is not a good way to design a feature in a general-purpose
language that would be used by lite
> (I'm unsure about the T_DOUBLE_ARROW, although for parsing, I feel there
> should be some token there
> before the class name, though I'm unconvinced on which)
What about this?
function foo (Class1 $a, Class2 $b) return Class3 {
/* Do something */
return new Class3($a, $b);
}
--
PHP
Sent from my iPhone
On Dec 22, 2011, at 7:14 PM, Stas Malyshev wrote:
> Hi!
>
>> Are you suggesting not allowing null to be returned, or provide an
>> indicator within the syntax that it may return null? PHP would be the
>> first language I'm aware of that would do so in either case.
>
> No I a
Hi:
On 23 Dec 2011, at 01:14, Stas Malyshev wrote:
> BTW, which languages you are talking about? PHP peers - Python, Ruby, Perl,
> Javascript (to some measure), etc. don't have typing as far as I know.
> Comparing PHP to statically compiled strictly typed languages does not seem
> very useful
On 23/12/11 01:00, Will Fitch wrote:
> On Dec 22, 2011, at 6:28 PM, Stas Malyshev wrote:
>> In PHP, returning object if everything is OK and false if not is a very
>> common pattern.
>> Also, you understand that always allowing null means that this construct:
>>
>> $foo = $this->returnsFoo();
>>
On 23/12/11 00:08, Will Fitch wrote:
> Sent from my iPad
> On Dec 22, 2011, at 5:51 PM, "Ángel González" wrote:
>
>> Your examples only show class methods with visibility qualifyiers, and
>> looking at the changes to zend_language_parser.y
>> it seems as if would only be available for methods. Wou
Hi!
Are you suggesting not allowing null to be returned, or provide an
indicator within the syntax that it may return null? PHP would be the
first language I'm aware of that would do so in either case.
No I am not suggesting that. I'm just pointing out the problems with the
concept of strict
On Dec 22, 2011, at 6:28 PM, Stas Malyshev wrote:
> Hi!
>
>> Most modern languages allow returning null in any case. This is a hail
>> Mary in the event something happens, but throwing an exception is
>> inappropriate. I see no reason to diverge from that.
>
> In PHP, returning object if everythi
On Thu, 22 Dec 2011, Will Fitch wrote:
> Sent from my iPad
> On Dec 22, 2011, at 5:51 PM, "Ángel González" wrote:
>
> > Your examples only show class methods with visibility qualifyiers, and
> > looking at the changes to zend_language_parser.y
> > it seems as if would only be available for metho
Hi!
Most modern languages allow returning null in any case. This is a hail
Mary in the event something happens, but throwing an exception is
inappropriate. I see no reason to diverge from that.
In PHP, returning object if everything is OK and false if not is a very
common pattern.
Also, you
On Thu, 22 Dec 2011, Will Fitch wrote:
> On Dec 22, 2011, at 10:11 AM, Dmitri Snytkine wrote:
>
> > I think the return type hinting really depends on variable type hinting.
> > A simple example whould bea typical getter function
> >
> > public function \Customer getCustomer(){
> > return $this
On Thu, Dec 22, 2011 at 06:08:26PM -0500, Will Fitch wrote:
> Most modern languages allow returning null in any case. This is a hail
> Mary in the event something happens, but throwing an exception is
> inappropriate. I see no reason to diverge from that.
Agreed, it is often convenient to return
Sent from my iPad
On Dec 22, 2011, at 5:51 PM, "Ángel González" wrote:
> Your examples only show class methods with visibility qualifyiers, and
> looking at the changes to zend_language_parser.y
> it seems as if would only be available for methods. Wouldn't return
> hints be available for plain f
On Thu, Dec 22, 2011 at 10:41:28AM -0800, Rasmus Lerdorf wrote:
> On 12/22/2011 07:08 AM, Keloran wrote:
> > i would love to see this expanded aswell (the way type hinting on function
> > variables was supposed to be), so that it could be
> >
> > string, int
> >
> > e.g.
> > function int test(boo
Your examples only show class methods with visibility qualifyiers, and
looking at the changes to zend_language_parser.y
it seems as if would only be available for methods. Wouldn't return
hints be available for plain functions?
In functional programming, it is common to return nullable types:
retu
So, are we in agreement that, within the scope of this RFC, type hinting is
going to be limited to and match parameter type hinting?
On Dec 22, 2011, at 3:35 PM, John Crenshaw wrote:
> From: Paul Dragoonis [mailto:dragoo...@gmail.com]
>
>> On Thu, Dec 22, 2011 at 6:41 PM, Rasmus Lerdorf wrote
Dmitri Snytkine wrote:
While web isn't typed, the php is not just for the web anymore, or is it?
Some databases expect typed input, else the data is not found.
For example passing string '1' instead of number 1 will not cause any errors
when searching MongoDB but you will not get the result you e
From: Paul Dragoonis [mailto:dragoo...@gmail.com]
> On Thu, Dec 22, 2011 at 6:41 PM, Rasmus Lerdorf wrote:
>
> > On 12/22/2011 07:08 AM, Keloran wrote:
> > > i would love to see this expanded aswell (the way type hinting on
> > function
> > > variables was supposed to be), so that it could be
>
On Dec 22, 2011, at 3:06 PM, Stas Malyshev wrote:
> Hi!
>
>> I'm going to have to disagree with you there. Type hinting DOES save
>> me a LOT of effort in development. I can stop worrying about checking
>> to make sure the parameter that I got is what I want it to be, and
>> just use it. The
Hi!
I'm going to have to disagree with you there. Type hinting DOES save
me a LOT of effort in development. I can stop worrying about checking
to make sure the parameter that I got is what I want it to be, and
just use it. The runtime will check and enforce that for me. When
I'm sorry but
That's the way to do it. If you have an idea, such as this, write it up, and
let's discuss. If we don't, we end up talking about things (like scalar type
hinting) that has been beaten to death on more than 100 occasions (sarcasm, but
not really...). We can then have a reference to point to sh
Stas,
> it's not a solution for the problem it is presented to be - it does> not make
> your code more robust or fail less or saves you effort on> development
I'm going to have to disagree with you there. Type hinting DOES save
me a LOT of effort in development. I can stop worrying about checki
On 12/22/2011 11:49 AM, John Crenshaw wrote:
> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
>
>> How is that hard?
>>
>> function age_lookup($age) {
>> return $coll->find(array('age' => (int)$age);
>> }
>>
>> but again here, doing a strong type check on the parameter isn't making your
Numeric isnt' a type at all, it's some type of unicorn.
Seriously, stop inventing new types because it will not make a language
better, instead will give people valid reasons to critisize the language.
Either add support for type hinting of all primitive types or don't add it,
keep the language as
Hi internals,
someone in the "Return Type Hinting for Methods RFC" thread had the idea
of a "numeric" type hint. I will capture this idea and propose a
"scalar" type hint. I understand the problem of the current discussion
about scalar type hints(int, float, string, double, ...). But there
sh
From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
> How is that hard?
>
> function age_lookup($age) {
> return $coll->find(array('age' => (int)$age);
> }
>
> but again here, doing a strong type check on the parameter isn't making your
> life easier. It simply pushes the responsibility to
On 12/22/2011 11:20 AM, Dmitri Snytkine wrote:
> Not sure what you mean by json wrapped.
> In mongo you do $coll->find(array('age' => $age);
>
> if $age is a string '21' your will not get any erros but neither will you
> get any results.
It is json underneath, but in your find() example, obviousl
Hi!
What I mean is that you can catch recoverable fatal error in your error
handler and at least be notified of what happened. Yes, you cannot go back
in your script to corrent anything after that but you can show a detailed
error message and send error email to developer.
Just the same thing y
What I mean is that you can catch recoverable fatal error in your error
handler and at least be notified of what happened. Yes, you cannot go back
in your script to corrent anything after that but you can show a detailed
error message and send error email to developer.
Just the same thing you can
On Dec 22, 2011, at 1:51 PM, Sebastian Bergmann wrote:
> Am 22.12.2011 19:41, schrieb Rasmus Lerdorf:
>> This is not a step forward. If the author of age_check() really doesn't
>> want to accept type-juggled arguments, then it is easy enough to do a
>> strict type check in the function itself. Th
On Dec 22, 2011, at 1:50 PM, Paul Dragoonis wrote:
> On Thu, Dec 22, 2011 at 6:41 PM, Rasmus Lerdorf wrote:
>
>> On 12/22/2011 07:08 AM, Keloran wrote:
>>> i would love to see this expanded aswell (the way type hinting on
>> function
>>> variables was supposed to be), so that it could be
>>>
>
Not sure what you mean by json wrapped.
In mongo you do $coll->find(array('age' => $age);
if $age is a string '21' your will not get any erros but neither will you
get any results.
Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytk
On 12/22/2011 11:18 AM, Will Fitch wrote:
> On Dec 22, 2011, at 1:41 PM, Rasmus Lerdorf wrote:
>
>> On 12/22/2011 07:08 AM, Keloran wrote:
>>> i would love to see this expanded aswell (the way type hinting on function
>>> variables was supposed to be), so that it could be
>>>
>>> string, int
>>>
>
Hi!
is_numeric is not good enough in some cases, like when searching for value
in MongoDB where it matches agains typed value.
function age_check(int $age)
{
// do stuff
}
This would require less code, easier to read and will catch wrong type at
runtime easy
On Dec 22, 2011, at 1:41 PM, Rasmus Lerdorf wrote:
> On 12/22/2011 07:08 AM, Keloran wrote:
>> i would love to see this expanded aswell (the way type hinting on function
>> variables was supposed to be), so that it could be
>>
>> string, int
>>
>> e.g.
>> function int test(bool $tester) {
>> if
On 12/22/2011 10:51 AM, Sebastian Bergmann wrote:
> Am 22.12.2011 19:41, schrieb Rasmus Lerdorf:
>> This is not a step forward. If the author of age_check() really doesn't
>> want to accept type-juggled arguments, then it is easy enough to do a
>> strict type check in the function itself. This puts
is_numeric is not good enough in some cases, like when searching for value
in MongoDB where it matches agains typed value.
function age_check(int $age)
{
// do stuff
}
This would require less code, easier to read and will catch wrong type at
runtime easy and throw
I agree that Return type hinting needs to be aligned with parameter type
hinting. That's basically what I said in previous post, that without
parameter type the return type hinting is not very useful, it's like
half-baked
While web isn't typed, the php is not just for the web anymore, or is it?
So
Hi!
function age_check($age)
{
if (!is_int($age)) {
throw new InvalidArgumentException;
}
}
With the above code, the caller needs to cast and the writer of the
age_check() function has to copy/paste/adapt these checks to all the
correct
Am 22.12.2011 19:41, schrieb Rasmus Lerdorf:
> This is not a step forward. If the author of age_check() really doesn't
> want to accept type-juggled arguments, then it is easy enough to do a
> strict type check in the function itself. This puts the effort in the
> correct place and doesn't encourag
On Thu, Dec 22, 2011 at 6:41 PM, Rasmus Lerdorf wrote:
> On 12/22/2011 07:08 AM, Keloran wrote:
> > i would love to see this expanded aswell (the way type hinting on
> function
> > variables was supposed to be), so that it could be
> >
> > string, int
> >
> > e.g.
> > function int test(bool $test
On 12/22/2011 07:08 AM, Keloran wrote:
> i would love to see this expanded aswell (the way type hinting on function
> variables was supposed to be), so that it could be
>
> string, int
>
> e.g.
> function int test(bool $tester) {
> if ($tester) { return 5; }
> return 99;
> }
Return type hintin
Hi!
That said, PHP is not Java, and type hinting in PHP is very
different. It is, in fact, type *hinting*. This is a runtime
feature. Only interface validation is verified at compile time, so
we have to consider performance vs. feature in these cases.
Naming it "hinting" was probably the wo
Hi!
Could we maybe keep this discussion contained to return value type
hints please? Optional variable type hinting is a completely different
topic that would require a separate RFC and implementation. If you are
interested in this you can propose a RFC for this.
Actually, as I said many times
On Dec 22, 2011, at 10:18 AM, Oleg Oshmyan wrote:
>> public function \Customer getCustomer(){
>> return $this->customer;
>> }
>>
>> If the $customer instance variable is not declared with the type Customer
>> then first of all IDE will not be able to spot an error, second compiler may
>> have a
On Dec 22, 2011, at 10:11 AM, Dmitri Snytkine wrote:
> I think the return type hinting really depends on variable type hinting.
> A simple example whould bea typical getter function
>
> public function \Customer getCustomer(){
> return $this->customer;
> }
The actual syntax would be:
public
> public function \Customer getCustomer(){
> return $this->customer;
> }
>
> If the $customer instance variable is not declared with the type Customer
> then first of all IDE will not be able to spot an error, second compiler may
> have a slighly harder time of detecting a mismatch.
The compiler
scalar type hinting was rejected in the past multiple times.
I think that expanding this RFC (against the wish of the original author of
the RFC) would be a sure way to guarantee the same result for this RFC as
well..
On Thu, Dec 22, 2011 at 4:08 PM, Keloran wrote:
> i would love to see this exp
On Thu, Dec 22, 2011 at 09:59:16AM -0500, Dmitri Snytkine wrote:
> I never said to make it mandatory, only to make it available. Just like the
> type hinting of function call is optional but not mandatory, which is a big
> advantage over Java in my opinion.
> After all, if you make return type hin
I think the return type hinting really depends on variable type hinting.
A simple example whould bea typical getter function
public function \Customer getCustomer(){
return $this->customer;
}
If the $customer instance variable is not declared with the type Customer
then first of all IDE will n
i would love to see this expanded aswell (the way type hinting on function
variables was supposed to be), so that it could be
string, int
e.g.
function int test(bool $tester) {
if ($tester) { return 5; }
return 99;
}
On Thu, Dec 22, 2011 at 2:59 PM, Dmitri Snytkine <
dsnytk...@ultralogistics.c
Could we maybe keep this discussion contained to return value type
hints please? Optional variable type hinting is a completely different
topic that would require a separate RFC and implementation. If you are
interested in this you can propose a RFC for this.
Nikita
On Thu, Dec 22, 2011 at 3:59 P
I never said to make it mandatory, only to make it available. Just like the
type hinting of function call is optional but not mandatory, which is a big
advantage over Java in my opinion.
After all, if you make return type hinting mandatory, it would break 100% of
all existing php scripts.
To clar
On Thu, Dec 22, 2011 at 03:33:40PM +0100, Sebastian Krebs wrote:
> > private \ArrayObject $customers;
> >
>
> Once more "Why is PHP not Java?"
That comment confuses matters. People use PHP for all sorts of reasons, the
desire to tighten up in some places, on some occasions, should not be treated
On Dec 22, 2011, at 9:09 AM, Dmitri Snytkine wrote:
> The return type hinting is probably the biggest thing happening in php in a
> long time.
> Is this too good to be true?
Hopefully not. We will see when the voting commences. :)
>
> With return type hinting I can see a huge improvenets in ph
On Thu, Dec 22, 2011 at 09:09:40AM -0500, Dmitri Snytkine wrote:
> The return type hinting is probably the biggest thing happening in php in a
> long time.
> Is this too good to be true?
>
> With return type hinting I can see a huge improvenets in php IDEs in
> spotting errors. Also it will be muc
2011/12/22 Dmitri Snytkine
> The return type hinting is probably the biggest thing happening in php in a
> long time.
> Is this too good to be true?
>
> With return type hinting I can see a huge improvenets in php IDEs in
> spotting errors. Also it will be much easier to auto generate wsdl files
The return type hinting is probably the biggest thing happening in php in a
long time.
Is this too good to be true?
With return type hinting I can see a huge improvenets in php IDEs in
spotting errors. Also it will be much easier to auto generate wsdl files
when return types are known to a compile
63 matches
Mail list logo
