On 05/28/2010 03:06 AM, Felipe Pena wrote:
Hello devs,
I've updated the patch that backports the Mike's work, which was previously
created and applied by Jani on branches/PHP_5_3 (and reverted...) based on
the old trunk, to be applied against the new trunk.
At 08:28 28/05/2010, Tjerk Anne Meesters wrote:
On the other hand, auto-casting used to be my favourite until I
glanced over the conversion table; it's not just regular casting, it
has different rules. I wouldn't want to be the one going over that
table when writing code against a certain API, I
On Friday 28 May 2010 01:54:55 am Zeev Suraski wrote:
At 08:28 28/05/2010, Tjerk Anne Meesters wrote:
On the other hand, auto-casting used to be my favourite until I
glanced over the conversion table; it's not just regular casting, it
has different rules. I wouldn't want to be the one going
As man from userland, I totally agree with Larry. I see completely no sense
in raising error when a safe conversion can be done. And I don't like
current implementation at all. It is completely not-php-way.
2010/5/28 Larry Garfield la...@garfieldtech.com
On Friday 28 May 2010 01:54:55 am Zeev
I'd say that I agree on this, I would like to see the conversion rules
cleaned up and made more clear. The idea of emitting e_warning or
e_strict on conversions with data loss throughout the language is very
appealing. Maybe we really need to do that so conversion rules and
type hinting rules to
On 28.05.2010, at 10:57, Arvids Godjuks wrote:
I'd say that I agree on this, I would like to see the conversion rules
cleaned up and made more clear. The idea of emitting e_warning or
e_strict on conversions with data loss throughout the language is very
appealing. Maybe we really need to do
Hi,
Apparently, the discussion is not looking like it will end up in a
general agreement. I'd suggest the following:
1) Since it seems that there is concerns about the current
auto-casting RFC (inconsistencies, when/what errors, etc..), I believe
it's authors should refine the RFC to propose
On Fri, May 28, 2010 at 11:04, Lukas Kahwe Smith m...@pooteeweet.org wrote:
In the weak type hinting RFC the conversion rules are pretty clear to me,
anything that converts without data loss goes through, anything else does not
convert silently (or even fails if we want to be so strict,
Lukas, Etienne, Hannes:
You all pointed out the issues and enhansments that can be done.
Basic thing I want to say that type hinting and data casting should be
done in tandem and work the same way. So generally there is a need to
rething how type casting works and implement enhansments with
Am 27.05.2010 12:59, schrieb Ilia Alshanetsky:
As far as your example goes consider a function that expects a boolean, but
instead gets an int/string/float, which in nearly all cases will result in
TRUE. Which is not the desired outcome.
Which is why, for instance, PHPUnit today is full of
Am 27.05.2010 00:30, schrieb Derick Rethans:
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
Hey,
I know type hints are more fun to discuss but anyways: In trunk
ChangeLog lists entries up till 2005 (when 5.2 was branched of, from
which 5.3 was branched from which the current trunk was branched of) In
the old trunk the file lasts until 2009-07-08 (when we switched from CVS
to svn)
Is
2010/5/28 Johannes Schlüter johan...@schlueters.de:
Hey,
I know type hints are more fun to discuss but anyways: In trunk
ChangeLog lists entries up till 2005 (when 5.2 was branched of, from
which 5.3 was branched from which the current trunk was branched of) In
the old trunk the file lasts
2010/5/28 Michael Wallner m...@php.net
On 05/28/2010 03:06 AM, Felipe Pena wrote:
Hello devs,
I've updated the patch that backports the Mike's work, which was
previously
created and applied by Jani on branches/PHP_5_3 (and reverted...) based on
the old trunk, to be applied against the new
2010/5/28 Johannes Schlüter johan...@schlueters.de:
Is anybody using this file? If this is thee case could somebody then
make sure it's being updated (and maybe take care of
ChangeLog-200[6-9].gz being created) else I'd suggest dropping them. An
outdated file might be confusing for users
Hi!
Currently if you pass int(42) to an array type hint it will fail. For
the weak type hint it will cast it to whatever was hinted.
This makes sense. 42 doesn't have array representation. We might
introduce a rule that if anything passed to a function that requires
array gets converted to
Hi!
I think that's a brilliant plan. We won't ever agree on whether we want
either strict type hinting, or casting typehinting and this provides
both possibilities with the following pros:
For the record, I think having both is even worse than having one of
them. That makes the language into
Hi!
Which is why, for instance, PHPUnit today is full of code like this
public function foo($flag)
{
if (!is_bool($flag)) {
throw new InvalidArgumentException(/* ... */);
}
}
This is the type of code that I want to get rid off using scalar
Am 28.05.2010 19:45, schrieb Stas Malyshev:
The question here is does it make sense somewhere outside PHPUnit?
I have seen boilerplate [1] code like this in other Open Source projects
as well as closed-source applications.
--
[1] boilerplate as is code I need to write because the language
Hi!
I have seen boilerplate [1] code like this in other Open Source projects
as well as closed-source applications.
I've seen all kinds of code, whether making sense or not. The question
is not if somebody somewhere is doing it but if it's the right thing to
recommend to do. I think
hi Johannes,
2010/5/28 Johannes Schlüter johan...@schlueters.de:
Is anybody using this file? If this is thee case could somebody then
make sure it's being updated (and maybe take care of
ChangeLog-200[6-9].gz being created) else I'd suggest dropping them. An
outdated file might be confusing
On Fri, 28 May 2010, Pierre Joye wrote:
2010/5/28 Johannes Schlüter johan...@schlueters.de:
Is anybody using this file? If this is thee case could somebody then
make sure it's being updated (and maybe take care of
ChangeLog-200[6-9].gz being created) else I'd suggest dropping them. An
2010/5/29 Derick Rethans der...@php.net:
On Fri, 28 May 2010, Pierre Joye wrote:
2010/5/28 Johannes Schlüter johan...@schlueters.de:
Is anybody using this file? If this is thee case could somebody then
make sure it's being updated (and maybe take care of
ChangeLog-200[6-9].gz being
23 matches
Mail list logo
