Alain Williams skrev:
Nice in some ways, except that it is different from the way that type hinting
works in PHP5 classes - again: keep to one way of doing things.
': RetType' might be possible, but it is very different from where type hints
are given currently in PHP.
Stick with:
I'm +1 for this syntax
function int myfunction(int $param)
{
return $someint;
}
C/C++ like, easy to understand
And bad idea about making a return type function - looks very useless and
will not be used a lot. Work with objects with methods returning an object
of some kind, then you can do
On Wed, Apr 30, 2008 at 09:23:17AM +0300, Arvids Godjuks wrote:
I'm +1 for this syntax
function int myfunction(int $param)
{
return $someint;
}
C/C++ like, easy to understand
+1 -- least confusion to most people.
Taking it a bit further, if the function returns a reference (eg to
On Tue, 2008-04-29 at 22:13 -0400, Jessie Hernandez wrote:
Sam Barrow wrote:
Well in summation I think this is something that should be implemented,
I don't see any arguments against implementing this atleast for arrays
and classes, like we already have for function parameters.
The
On Wed, 2008-04-30 at 09:23 +0300, Arvids Godjuks wrote:
I'm +1 for this syntax
function int myfunction(int $param)
{
return $someint;
}
C/C++ like, easy to understand
And bad idea about making a return type function - looks very
useless and will not be used a lot. Work with
On Wed, 2008-04-30 at 08:27 +0100, Alain Williams wrote:
On Wed, Apr 30, 2008 at 09:23:17AM +0300, Arvids Godjuks wrote:
I'm +1 for this syntax
function int myfunction(int $param)
{
return $someint;
}
C/C++ like, easy to understand
+1 -- least confusion to most people.
On Wed, 2008-04-30 at 12:58 +0200, LAUPRETRE François (P) wrote:
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
First is that function
definition and code is usually written by the same person in the same
(very small) context, and this person has to be somewhat
absent-minded
Hello Sam.
Would you agree in general the function int name() { syntax is favored? If
you need help working out the grammar for such changes let me know. This is
something that I think would add value to PHP as a whole and would not mind
lending some time for.
-Chris
On Wed, Apr 30, 2008 at
Hi!
Right, return type hinting is useless in such cases, but it is
interesting when we check whether a method is compatible with an
implemented interface or an extended/abstract class. In this case,
When exactly you check that? PHP has no static type checking, and in
runtime actual values,
You have added is_int, is_numeric, and === operator. I've been reading your
posts and you should really stop confusing using that argument. Truth is,
types are relevant.
$foo = 1;
$bar = '1';
if($foo === $bar) {
echo I am never echo'ed;
}
Until you make $foo === $bar, you should really stop
On Wed, 2008-04-30 at 09:26 -0700, Chris Stockton wrote:
Hello Sam.
Would you agree in general the function int name() { syntax is
favored? If you need help working out the grammar for such changes let
me know. This is something that I think would add value to PHP as a
whole and would not
Alain Williams skrev:
Taking it a bit further, if the function returns a reference (eg to its
argument):
function int myfunction(int $param)
Alternative could be:
function int myfunction(int $param)
But I think that the first form is better.
From one whose job it is to
On Wed, Apr 30, 2008 at 10:42:04PM +0200, Keryx Web wrote:
Alain Williams skrev:
Taking it a bit further, if the function returns a reference (eg to its
argument):
function int myfunction(int $param)
Alternative could be:
function int myfunction(int $param)
But I think that
Well in summation I think this is something that should be implemented,
I don't see any arguments against implementing this atleast for arrays
and classes, like we already have for function parameters.
The only thing left would be to decide on the syntax
public array function x() { // Probably
On Tue, Apr 29, 2008 at 5:22 PM, Sam Barrow [EMAIL PROTECTED] wrote:
Well in summation I think this is something that should be implemented,
I don't see any arguments against implementing this atleast for arrays
and classes, like we already have for function parameters.
The only thing
Mine uses less code to accomplish the same thing, doesn't introduce new
tokens, and has an easier syntax. I'm still working on it, but I can
give an update in a couple days. I just wanted to see what people
thought about the implementation aspect of it.
On Tue, 2008-04-29 at 17:37 +0200, Pierre
On Tue, Apr 29, 2008 at 5:40 PM, Sam Barrow [EMAIL PROTECTED] wrote:
Mine uses less code to accomplish the same thing, doesn't introduce new
tokens, and has an easier syntax.
Ok, sorry to have tried to get this feature in. I do think that going
down the way you choosed right now is the best
As I've pointed out,
public array x()
will become ambiguous once we introduce a type function, which is
not unlikely at this point
David
Am 29.04.2008 um 17:22 schrieb Sam Barrow:
Well in summation I think this is something that should be
implemented,
I don't see any arguments
Hi!
Well in summation I think this is something that should be implemented,
I don't see any arguments against implementing this atleast for arrays
and classes, like we already have for function parameters.
I think we had plenty of arguments against it last time it was
discussed. You could
On Tue, 2008-04-29 at 18:00 +0200, David Zülke wrote:
As I've pointed out,
public array x()
will become ambiguous once we introduce a type function, which is
not unlikely at this point
That's what I thought, that's why I said number 1 is the most likely.
David
Am
Sam Barrow wrote:
Well in summation I think this is something that should be implemented,
I don't see any arguments against implementing this atleast for arrays
and classes, like we already have for function parameters.
The only thing left would be to decide on the syntax
public array function
On Sat, Apr 26, 2008 at 05:11:29PM -0700, Chris Stockton wrote:
*cough* lambda *cough*
That would be nice, but the scoping of variables in PHP doesn't seem to
make that nice, the code below results in '' Undefined variable: aa ''
if I take the 'global' statement out, if I leave it in the echo in
Alain Williams wrote:
On Sat, Apr 26, 2008 at 05:11:29PM -0700, Chris Stockton wrote:
*cough* lambda *cough*
That would be nice, but the scoping of variables in PHP doesn't seem to
make that nice, the code below results in '' Undefined variable: aa ''
if I take the 'global' statement out, if
On Sunday 27 April 2008, Alain Williams wrote:
On Sat, Apr 26, 2008 at 05:11:29PM -0700, Chris Stockton wrote:
*cough* lambda *cough*
That would be nice, but the scoping of variables in PHP doesn't seem to
make that nice, the code below results in '' Undefined variable: aa ''
if I take the
I like the first too, if this can be implemented I think it is a
suitable syntax.
On Sat, 2008-04-26 at 00:13 +0100, Alain Williams wrote:
public function int doThing(string $foo) { return 1; }
The above is the best (ie omit 'return' or 'returns').
This also is consistent with C and with
Wouldn't the most consistent way be to omit function altogether when
using a return type hint?
public static function zomg() {
return $somethingArbitrary;
}
public static string foo() {
return $mustBeString;
}
otoh, should there ever be a type function (e.g. for anonymous
funcs) down
On Sat, Apr 26, 2008 at 2:06 PM, David Zülke [EMAIL PROTECTED] wrote:
Wouldn't the most consistent way be to omit function altogether when
using a return type hint?
public static function zomg() {
return $somethingArbitrary;
}
public static string foo() {
return $mustBeString;
}
i
Am 27.04.2008 um 00:24 schrieb Nathan Nobbe:
On Sat, Apr 26, 2008 at 2:06 PM, David Zülke [EMAIL PROTECTED]
wrote:
Wouldn't the most consistent way be to omit function altogether
when
using a return type hint?
public static function zomg() {
return $somethingArbitrary;
}
public static
*cough* lambda *cough*
On Sat, Apr 26, 2008 at 4:26 PM, David Zülke [EMAIL PROTECTED] wrote:
Am 27.04.2008 um 00:24 schrieb Nathan Nobbe:
On Sat, Apr 26, 2008 at 2:06 PM, David Zülke [EMAIL PROTECTED] wrote:
Wouldn't the most consistent way be to omit function altogether when
using a
But anonymous functions and lambda expressions are not the same thing...
David
Am 27.04.2008 um 02:11 schrieb Chris Stockton:
*cough* lambda *cough*
On Sat, Apr 26, 2008 at 4:26 PM, David Zülke [EMAIL PROTECTED]
wrote:
Am 27.04.2008 um 00:24 schrieb Nathan Nobbe:
On Sat, Apr 26, 2008
Anonymous functions as you know them today come from lambda calculus which
was created before computers were even made. Generally it is agreed anon
func == labmda can be used interchangeably.
Most developers will understand what:
public function lambda sowat () { return function OR lambda,
Attached is my return type hinting patch. It allows type hinting for
parameters and return values. Int, float, bool, string, num, scalar,
resource, object, array, and class names are supported for both
parameters and return values. Objects with __toString methods are
allowed to pass for scalar
Hi!
In general, it'd be very nice to have some definition of the proposed
feature beyond the patch. It would probably answer some of my questions
that follow :)
parameters and return values. Objects with __toString methods are
allowed to pass for scalar and string type hints.
What about
On Fri, 2008-04-25 at 10:06 -0700, Stanislav Malyshev wrote:
Hi!
In general, it'd be very nice to have some definition of the proposed
feature beyond the patch. It would probably answer some of my questions
that follow :)
parameters and return values. Objects with __toString methods
Can anyone help me with this?
Here is the current function declaration rule:
T_FUNCTION { $1.u.opline_num = CG(zend_lineno); } is_reference T_STRING
optional_function_return_type { zend_do_begin_function_declaration($1,
$4, 0, $3.op_type, NULL, $5 TSRMLS_CC); } '(' parameter_list ')' '{'
On Fri, 2008-04-25 at 10:06 -0700, Stanislav Malyshev wrote:
I notice it introduces new keyword -
returns. Is it necessary? Each new keyword means broken code.
I have adapted the patch to reuse the return keyword.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
On Fri, Apr 25, 2008 at 02:16:02PM -0400, Sam Barrow wrote:
Can anyone help me with this?
Here is the current function declaration rule:
T_FUNCTION { $1.u.opline_num = CG(zend_lineno); } is_reference T_STRING
optional_function_return_type { zend_do_begin_function_declaration($1,
$4, 0,
Why note the following (which would be more C like):
function return int a($arg1, $arg2) {
}
It gets a little long when you're using classes
abstract protected function return int dostuff() {
}
vs
abstract protected function dostuff() return int {
}
--
PHP Internals
Hi!
Why note the following (which would be more C like):
function return int a($arg1, $arg2) {
}
In C I am familiar with return keyword is never used in function
definition.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
I figured it out, the syntax is now as follows:
function a($b, $c) returns d {
}
I'll post an update soon.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sam Barrow wrote:
I figured it out, the syntax is now as follows:
function a($b, $c) returns d {
}
I'll post an update soon.
That's certainly a non-intuitive syntax. How about we take a page out of
the book of other C-style languages before trying to invent something
else? I agree
On Fri, 2008-04-25 at 14:08 -0500, Jeremy Privett wrote:
Sam Barrow wrote:
I figured it out, the syntax is now as follows:
function a($b, $c) returns d {
}
I'll post an update soon.
That's certainly a non-intuitive syntax. How about we take a page out of
the book of
On Fri, Apr 25, 2008 at 1:15 PM, Sam Barrow [EMAIL PROTECTED] wrote:
On Fri, 2008-04-25 at 14:08 -0500, Jeremy Privett wrote:
Sam Barrow wrote:
I figured it out, the syntax is now as follows:
function a($b, $c) returns d {
}
I'll post an update soon.
That's
On Fri, 2008-04-25 at 13:24 -0600, Nathan Nobbe wrote:
On Fri, Apr 25, 2008 at 1:15 PM, Sam Barrow [EMAIL PROTECTED] wrote:
On Fri, 2008-04-25 at 14:08 -0500, Jeremy Privett wrote:
Sam Barrow wrote:
I figured it out, the syntax is now as follows:
On Fri, Apr 25, 2008 at 12:25 PM, Sam Barrow [EMAIL PROTECTED] wrote:
On Fri, 2008-04-25 at 13:24 -0600, Nathan Nobbe wrote:
On Fri, Apr 25, 2008 at 1:15 PM, Sam Barrow [EMAIL PROTECTED] wrote:
On Fri, 2008-04-25 at 14:08 -0500, Jeremy Privett wrote:
Sam Barrow wrote:
Hello everybody,
I am new here (just reading for last couple of days), so firstly nice
to meet you:)
This discussion seems quite interesting for me and it would be nice
if I can join...
Sam Barrow napisal:
im not sure the following has been explicitly proposed, but how about
omitting the
I don't know, maybe it does work. But either way I'm not introducing a
new keyword, I changed the patch to reuse the return keyword.
Yes, long strings of keywords:
abstract protected string function dostuff()
On Fri, 2008-04-25 at 14:22 -0700, Chris Stockton wrote:
On Fri, Apr 25, 2008 at
Hello Sam,
I think you misunderstand, let me retype for you.
strlen('abstract protected function string dostuff()') strlen('abstract
protected function dostuff() return string')
Making your argument on length void, also, maybe we should not base a
language change decision on typing extra
48 matches
Mail list logo
