At 00:28 27/05/2010, Davey Shafik wrote:
You could just as easily say to do:
function foo($bar) {
$bar = (int) $bar;
}
as:
function foo($bar) {
if (!is_int($bar)) {
// error
}
}
Why bother with either if that's the case?
I don't think there's any argu
Hi!
Let's call this proposal what it is -- strict typing. The auto-cast is (1)
mere fog in this discussion and (2) useless.
(1) fog
function foo( (int) $bar) {}
foo($bar);
is exactly the same, with strict typing, as
function foo(int $bar) { }
foo( (int) $bar);
No it is not the same. There'
On Wed, 26 May 2010 23:30:27 +0100, Derick Rethans wrote:
On Wed, 26 May 2010, Davey Shafik wrote:
Would it be possible to support two syntaxes:
function foo( (int) $bar) { } // auto-cast to int
function foo(int $bar) { } // require int
I think that's a brilliant plan. We won't ever
>
> On May 26, 2010, at 5:20 PM, Zeev Suraski wrote:
>
> > At 23:44 26/05/2010, Davey Shafik wrote:
> >
> >> On May 26, 2010, at 3:08 PM, Zeev Suraski wrote:
> >>
> >> > At 21:12 26/05/2010, Pierre Joye wrote:
> >> >> As PHP's type system is seen as a big plus,
> >> >> I have to say that many u
Hi,
On Thu, May 27, 2010 at 00:30, Derick Rethans wrote:
> On Wed, 26 May 2010, Davey Shafik wrote:
>
>> Would it be possible to support two syntaxes:
>>
>> function foo( (int) $bar) { } // auto-cast to int
>> function foo(int $bar) { } // require int
>
> I think that's a brilliant plan. We
On Wed, 26 May 2010, Davey Shafik wrote:
> Would it be possible to support two syntaxes:
>
> function foo( (int) $bar) { } // auto-cast to int
> function foo(int $bar) { } // require int
I think that's a brilliant plan. We won't ever agree on whether we want
either strict type hinting, or
I like the idea of type hinting a lot. (See:
http://marc.info/?l=zend-engine2&m=102421231114377&w=2) I suggested it
in 2001 when ZE2 was being designed. Somehow my idea was bastardized
into only classes and arrays. Guess it was the mad OOP craze of the time.
Anyhow, I would like to use it. And
Hi!
You could just as easily say to do:
function foo($bar) {
$bar = (int) $bar;
}
/.../
Why bother with either if that's the case? Why not add support for something
like:
Indeed, why bother? Only reason I heard so far is documentation. Which
applies to both cases, but as you not
On May 26, 2010, at 5:20 PM, Zeev Suraski wrote:
> At 23:44 26/05/2010, Davey Shafik wrote:
>
>> On May 26, 2010, at 3:08 PM, Zeev Suraski wrote:
>>
>> > At 21:12 26/05/2010, Pierre Joye wrote:
>> >> As PHP's type system is seen as a big plus,
>> >> I have to say that many users consider it as
At 23:44 26/05/2010, Davey Shafik wrote:
On May 26, 2010, at 3:08 PM, Zeev Suraski wrote:
> At 21:12 26/05/2010, Pierre Joye wrote:
>> As PHP's type system is seen as a big plus,
>> I have to say that many users consider it as a plus in the
>> implementation of a given method function or method
Davey Shafik wrote:
Do you propose to have a warning when the types are a mis-match, similar to the
array->scalar conversion example from Gustavo? (strtoupper(array('ABC')))
If you have a warning or notice, that warns of potential loss of data accuracy,
then
I think I'd be OK with auto-converti
On May 26, 2010, at 3:08 PM, Zeev Suraski wrote:
> At 21:12 26/05/2010, Pierre Joye wrote:
>> As PHP's type system is seen as a big plus,
>> I have to say that many users consider it as a plus in the
>> implementation of a given method function or method. But the same
>> users ask to have somethi
On Wed, May 26, 2010 at 9:08 PM, Zeev Suraski wrote:
> At 21:12 26/05/2010, Pierre Joye wrote:
>>
>> As PHP's type system is seen as a big plus,
>> I have to say that many users consider it as a plus in the
>> implementation of a given method function or method. But the same
>> users ask to have s
At 21:12 26/05/2010, Pierre Joye wrote:
As PHP's type system is seen as a big plus,
I have to say that many users consider it as a plus in the
implementation of a given method function or method. But the same
users ask to have something more strict for the methods signature. I
think it is a valid
hi Zeev,
On Wed, May 26, 2010 at 8:05 PM, Zeev Suraski wrote:
>> I'd say: the type-juggling is not the *big plus* of PHP. BTW: if I read
>> some "PHP is so enterprise-ready" articles, I never read about the
>> advantages
>> of weak types. (I'd even liked it, if there would be an optional(!)
>> p
At 15:05 25/05/2010, you wrote:
I don't know if I have a full understanding about zval.type on internal
C-level. But in my code I always use strict type checking in comparisons and
in functions like in_array that offer that possibility. That's because I
learned the hard way how much debugging tim
On 05/25/10 13:05, Thomas Nunninger wrote:
> - If you don't want to distinguish beetween strict and weak hints, create
> some
> ini setting that influences the behavior. (I'm not a fan of that.)
>
My £0.02 as a user: ini settings should NEVER influence the way the core
language works, as they
On Wed, May 26, 2010 at 3:37 AM, Wez Furlong wrote:
> I confess to being busy, but I don't recall any conversation where
> this capability was revoked or otherwise called out as wrong.
Now you have examples of such discussions :)
More seriously, the current situation has to be discussed. For on
18 matches
Mail list logo
