On Jan 5, 2008 1:52 AM, Jani Taskinen <[EMAIL PROTECTED]> kirjoitti:
> Anyway, who dropped the word "OPTIONAL" from the subject? I think that was
> quite
> essential part of this whole debate? As I'm +1 for OPTIONAL scalar-type
> hinting.
+1 on scalar-type-hinting (not to be confused with type-c
Hello Gregory,
Saturday, January 5, 2008, 4:25:00 AM, you wrote:
> Index: run-tests.php
> ===
> RCS file: /repository/php-src/run-tests.php,v
> retrieving revision 1.226.2.37.2.35.2.10
> diff -u -r1.226.2.37.2.35.2.10 run-tests.php
>
On Saturday 05 January 2008, Hannes Magnusson wrote:
> On Jan 5, 2008 1:52 AM, Jani Taskinen <[EMAIL PROTECTED]> kirjoitti:
> > Anyway, who dropped the word "OPTIONAL" from the subject? I think that was
> > quite
> > essential part of this whole debate? As I'm +1 for OPTIONAL scalar-type
> > hint
Magnus Määttä wrote:
>> +1 on scalar-type-hinting (not to be confused with type-casting)
> I'm also +1 for optional scalar-type hinting FWIW.
Same here.
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B
Hi,
I was wondering if there are any plans to introduce the ability of array
functions to work with
"array objects".
More specifically I was thinking of starting with adding an SPL interface
called ArraySearchable,
and modifying php_search_array in ext/standard/array.c to accept an object that
PHP is first and foremost a Web scripting language. Everything we do
and every decision is based on that. For every feature the first
question you need to ask yourselves is:
Will this make it easier or harder for the average PHP user to
build a web app? And if it makes it harder, is the
On Sat, Jan 05, 2008 at 09:46:34AM -0800, Rasmus Lerdorf wrote:
> PHP is first and foremost a Web scripting language. Everything we do
> and every decision is based on that. For every feature the first
> question you need to ask yourselves is:
>
> Will this make it easier or harder for the a
On Sat, Jan 05, 2008 at 09:48:37PM +0100, Stefan Esser wrote:
> Hello,
> >> typing into PHP, even if it is optional. Passing $_REQUEST['age'] to a
> >>
> > that $_REQUEST['age'] has been checked for numeric before the functio
>
> would you please not use $_REQUEST in any of your examples? $
> Be conservative in what you do; be liberal in what you accept from
> others.
You hopefully realise that this is exactly the opposite of your earlier
opinion that ext/filter should be used to block everything and let only
harmless data through. And only have raw data on demand...
I really do
Hello,
>> typing into PHP, even if it is optional. Passing $_REQUEST['age'] to a
>>
> that $_REQUEST['age'] has been checked for numeric before the functio
would you please not use $_REQUEST in any of your examples? $_REQUEST is
one of the biggest design weaknesses in PHP. Every application
Stefan Esser wrote:
Be conservative in what you do; be liberal in what you accept from
others.
You hopefully realise that this is exactly the opposite of your earlier
opinion that ext/filter should be used to block everything and let only
harmless data through. And only have raw data on dema
>> opinion) reason why type hinting should NOT be introduced. BTW accepting
>> the string '1' where an (int) type hint is placed would be the next
>> stupid design decision.
>>
>
> Why
Because type hinting is supposed to limit what kind of variable type is
allowed for a parameter. When you m
On Sat, Jan 05, 2008 at 10:13:29PM +0100, Stefan Esser wrote:
>
> >> opinion) reason why type hinting should NOT be introduced. BTW accepting
> >> the string '1' where an (int) type hint is placed would be the next
> >> stupid design decision.
> >>
> >
> > Why
> Because type hinting is suppo
Also,
function foo(SomeClass $obj) would error out if passed something other
than a SomeClass instance, while
function foo(int $number) would just cast $number to int.
Not really intuitive and not really consistent.
Regards,
Vlad Bosinceanu
Stefan Esser wrote:
Hello,
typing into PHP, eve
On Jan 5, 2008 3:48 PM, Stefan Esser <[EMAIL PROTECTED]> wrote:
> Hello,
> >> typing into PHP, even if it is optional. Passing $_REQUEST['age'] to a
> >>
> > that $_REQUEST['age'] has been checked for numeric before the functio
>
> would you please not use $_REQUEST in any of your examples? $_REQU
> Because type hinting is supposed to limit what kind of variable type
> is
> allowed for a parameter. When you magically convert you kill the whole
> idea of type hints and replace it with some magical function parameter
> auto type conversion, which would be another hard to understand magic
> fea
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Mike Lively wrote:
| in the neck to use effectively. If you start using 'int' type checks for
| functions you are going to want to be passing data from _GET, _POST, etc
| to, you will have to do is_numeric checks or something similar, so
| instea
On Sun, 2008-01-06 at 01:11 +0200, Vlad Bosinceanu wrote:
> Also,
>
> function foo(SomeClass $obj) would error out if passed something other
> than a SomeClass instance, while
> function foo(int $number) would just cast $number to int.
>
> Not really intuitive and not really consistent.
My patc
On Sat, 2008-01-05 at 15:59 -0800, Mike Lively wrote:
> > Because type hinting is supposed to limit what kind of variable type
> > is
> > allowed for a parameter. When you magically convert you kill the whole
> > idea of type hints and replace it with some magical function parameter
> > auto type c
On Sat, 2008-01-05 at 21:35 -0500, Sam Barrow wrote:
> On Sat, 2008-01-05 at 15:59 -0800, Mike Lively wrote:
> > > Because type hinting is supposed to limit what kind of variable type
> > > is
> > > allowed for a parameter. When you magically convert you kill the whole
> > > idea of type hints and
Mike Lively wrote:
> That being said I still do agree with Stefan that changing the type of a
> variable would be aweful. I do know that for any purpose I have for
> additional type hinting would actually be solved by just introducing
> type hints for 'scalar' (read string or int) and 'resource'.
21 matches
Mail list logo
