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
At 03:57 28/05/2010, Philip Olson wrote:
- We want both options, can we accept this and focus on making it happen?
There's definitely no consensus for having both options. I've said
countless times this is the worst option, many seem to agree.
Zeev
--
PHP Internals - PHP Runtime Developme
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.
http://felipe.ath.cx/diff/mike-new-out
Having seen both options, I would vote neither for the following reasons:
With strict "hinting", give it about a year when some major frameworks
would have adopted this, and not just for the functions that would
actually require it; they would go all the way in the name of
consistency. When that h
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.
http://felipe.ath.cx/diff/mike-new-output-api.diff
Mike/Jani feel free to commit i
This thread needed post #100 so here goes:
- We want both options, can we accept this and focus on making it happen?
- I love using === but am okay with others ab^H^Husing ==
- The strict type hinting patch now includes 'numeric' and 'scalar' type hints
Regards,
Philip
--
PHP Internals - PHP R
On May 27, 2010, at 12:15 PM, Kristina Chodorow wrote:
>
> On Thu, May 27, 2010 at 3:33 PM, Fitz Agard wrote:
>
>> The existing SVN account holder "kristina" suggested that I get an account
>> specifically to help maintain /phpdoc/en/trunk/reference/mongo/
> Please give Fitz mongo doc permissi
Hi,
I have only recently started listening in on this list and I usually
find it quite interesting. This one especially so.
But I think it's going nowhere...forgive me for saying so. I believe
that those of you, who'll have a say in this decision, have already made
their minds up and they ca
On Thu, May 27, 2010 at 5:47 PM, Lukas Kahwe Smith wrote:
>
> well most people do not use that since its just as tedious to use as having
> to cast your results. of course if we did have strict typing it would
> probably become more widely used, not that having to add those lines of code
> are som
Please give Fitz mongo doc permissions.
On Thu, May 27, 2010 at 3:33 PM, Fitz Agard wrote:
> The existing SVN account holder "kristina" suggested that I get an account
> specifically to help maintain /phpdoc/en/trunk/reference/mongo/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
The existing SVN account holder "kristina" suggested that I get an account
specifically to help maintain /phpdoc/en/trunk/reference/mongo/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!
No, your app doesn't need to be. Only if you interact with a library
that employs it in the API. A library provides APIs. API developers that
want you to follow strict types now, will force you to do so anyway, but
What would be a legitimate reasons for API developers to care about zval
t
On Thu May 27 11:22 AM, David Soria Parra wrote:
> On 2010-05-27, Zeev Suraski wrote:
> +1 from me for this. I think two solutions is not the right way and we
> +should
> try to make the type system consistent for the user. Therefore +1 for
> auto-converting.
I still feel the debate of the "rig
On 27.05.2010, at 17:40, Derick Rethans wrote:
> On Thu, 27 May 2010, Arvids Godjuks wrote:
>
>> Please read more carefully - what I mean that is we deal mostly with
>> numbers witch are represented as strings, because all data that comes
>> from external sources are STRING regardless of actual
On Thu, 27 May 2010, Arvids Godjuks wrote:
> Please read more carefully - what I mean that is we deal mostly with
> numbers witch are represented as strings, because all data that comes
> from external sources are STRING regardless of actual contents - be
> that integer or float - no matter. I don
On Thu, 27 May 2010, la...@garfieldtech.com wrote:
> The problem is that, as was pointed out, strict typing is not
> optional. The minute I am using one library that is built with strict
> typing, all of my interaction with it from my code must be strict.
> That means either:
>
> 1) My appli
The problem is that, as was pointed out, strict typing is not optional.
The minute I am using one library that is built with strict typing,
all of my interaction with it from my code must be strict. That means
either:
1) My application needs to be strictly typed throughout (assuming I even
+1 vote for weak typing.
I myself often (but not always) do take care about types, so for me
personally strict typing won't hurt that much. However, I beleive this will
be an overcomplicated aspect to many. As we know, there are tons of
webmasters who dont know any programming language in deep - b
On 2010-05-27, Zeev Suraski wrote:
> I'm strictly against having two solutions. It's the worst outcome we
> could reach IMHO - it means we're unable to decide which is better,
> so we support both (kind of like a hi-tech version of
> http://bit.ly/9I8dHw). I think it's the one solution that's
I have posted a topic on main Russian site for IT. Soon we will have a
result on what the Russian community thinks on this matter.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!
*We* don't force anybody. API developers *could potentionally* force
their consumers to take care about their types.
Which is IMO bad idea. Having dynamic language means you care about the
data, but not its internal representation. Now you are stepping back and
telling them "you need not
Hi!
It's exactly correct. Function declarations are a contract, just like
interface specifications. Not a "let's pass some random stuff past
customs to see if it works". Having this, in combination with the
Yes, it's exactly how PHP functions and operators always worked - "let's
accept everyt
Hi!
What we are talking about here is an **optional** feature for user-land
function that allow the author to implement really cheap input-validation to
facilitate ensuring that the correct input is supplied. Additionally it also
It's not really "optional" - if you use a library that does stri
At 15:31 27/05/2010, Richard Quadling wrote:
On 27 May 2010 12:14, Zeev Suraski wrote:
> BTW - even if strict type checking was implemented, do you truly think
> people won't simply cast their inputs to make PHP shutup about "42" not
> being a valid int? Â Let me assure you, they
would. Â You'd
On Thu, 27 May 2010, Richard Quadling wrote:
> On 27 May 2010 12:14, Zeev Suraski wrote:
> > BTW - even if strict type checking was implemented, do you truly think
> > people won't simply cast their inputs to make PHP shutup about "42" not
> > being a valid int? Let me assure you, they would. Y
On 27.05.2010, at 14:31, Richard Quadling wrote:
> In any decent course regarding defensive programming, we are told to
> filter input and escape output. One easy way of filtering input is to
> cast and verify.
>
> Once cast and verified we know we've got the right type and acceptable values.
>
On 27 May 2010 12:14, Zeev Suraski wrote:
> BTW - even if strict type checking was implemented, do you truly think
> people won't simply cast their inputs to make PHP shutup about "42" not
> being a valid int? Let me assure you, they would. You'd gain nothing - as
> a matter of fact you'd lose o
On Thu, 27 May 2010, Johannes Schlüter wrote:
> On Thu, 2010-05-27 at 06:59 -0400, Ilia Alshanetsky wrote:
> > 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 desir
>>
>> Is a 'scalar' typehint still being considered? It doesn't seem to suffer
>> from the conversion vs. typechecking argument.
>
> Currently, it's available in trunk:
> http://svn.php.net/viewvc?view=revision&revision=299707
Ah that's great news, thanks!
Evert
--
PHP Internals - PHP Runtime
On Thu, May 27, 2010 at 13:43, Evert | Filemobile wrote:
>
> On 2010-05-27, at 8:14 PM, Zeev Suraski wrote:
>
>> At 13:59 27/05/2010, Ilia Alshanetsky wrote:
>>> Zeev,
>>>
>>> Auto-conversion does not validate input to the function/method, it merely
>>> obfuscates the "wrong" input by converting
On 2010-05-27, at 8:14 PM, Zeev Suraski wrote:
> At 13:59 27/05/2010, Ilia Alshanetsky wrote:
>> Zeev,
>>
>> Auto-conversion does not validate input to the function/method, it merely
>> obfuscates the "wrong" input by converting it to desired type resulting in a
>> potentially un-expected valu
On Thu, 2010-05-27 at 06:59 -0400, Ilia Alshanetsky wrote:
> 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.
Especially the int to boolean conversion i
At 14:09 27/05/2010, Ilia Alshanetsky wrote:
Because auto-conversion is magic and like any magic causes
in-consistent behaviour and what I like to call WTF factor, which
means the developer is not quite certain what is going on. With
strict type hints the behaviour is consistent every-time and
At 13:59 27/05/2010, Ilia Alshanetsky wrote:
Zeev,
Auto-conversion does not validate input to the function/method, it
merely obfuscates the "wrong" input by converting it to desired type
resulting in a potentially un-expected value. I must say I am
completely against the auto-conversion hint
Because auto-conversion is magic and like any magic causes in-consistent
behaviour and what I like to call WTF factor, which means the developer is
not quite certain what is going on. With strict type hints the behaviour is
consistent every-time and there is no ambiguity of function.
On Thu, May 2
On 27.05.2010, at 12:59, Ilia Alshanetsky wrote:
> Zeev,
>
> Auto-conversion does not validate input to the function/method, it merely
> obfuscates the "wrong" input by converting it to desired type resulting in a
> potentially un-expected value. I must say I am completely against the
> auto-con
Why not do the check and let auto converting for int => float, int =>
string, string => int, string => float when it doesn't loose any
precision.
2010/5/27 Ilia Alshanetsky :
> Zeev,
>
> Auto-conversion does not validate input to the function/method, it merely
> obfuscates the "wrong" input by con
Brian,
What we are talking about here is an **optional** feature for user-land
function that allow the author to implement really cheap input-validation to
facilitate ensuring that the correct input is supplied. Additionally it also
allows for better language interrogation for auto-generation of t
Zeev,
Auto-conversion does not validate input to the function/method, it merely
obfuscates the "wrong" input by converting it to desired type resulting in a
potentially un-expected value. I must say I am completely against the
auto-conversion hint idea.
As far as your example goes consider a func
Lest not touch the validation topic - it's obvious and we are not
talking about it.
As for the DB - I don't want to write code like this.
// Select from DB
// Start the loop fetch the data
settype('integer', $row['id']);
settype('float', $row['price']);
settype('int', $row['amount']);
settype('in
On 27.05.2010, at 11:05, 魏世江 wrote:
> But I think it's the icing on the cake if we give the PHP programmer the
> choice of whether use explicit types.
> For examlpe, we may add a switch in php.ini, let's say, explict_types=On/Off.
heh .. you are giving the question "cake or death" a new dimen
On Thu, May 27, 2010 at 11:05, 魏世江 wrote:
> Hi .
> I think there is no need to argue on it any more.
> Good programmers have the ability to manipulate the variables' types.
> But I think it's the icing on the cake if we give the PHP programmer the
> choice of whether use explicit types.
> For ex
No .ini switches. Forget it. Developers of PHP said it clearly - NO
.ini values that change the behaviour of PHP! Ever! Topic closed.
2010/5/27 魏世江 :
> Hi .
> I think there is no need to argue on it any more.
> Good programmers have the ability to manipulate the variables' types.
> But I think it
On Thu, May 27, 2010 at 10:53, Arvids Godjuks wrote:
> Heh... Please do a DB select and make a var_dump on the rows from
> database. You will see things like:
>
> array(3) {
> ["id"]=>
> string(1) "1"
> ["ref_id"]=>
> string(2) "15"
> ["name"]=>
> string(7) "Bla bla"
> }
>
> string, string a
Exactly.
Yes, we check data coming from POST/GET/COOKIE and other really
external resources. But doing the same for data coming from database
is kinda an overkill. And most projects do select their data mostly
from databases. And I'm 100% sure that people will not use type
hinting if they have to
Hi .
I think there is no need to argue on it any more.
Good programmers have the ability to manipulate the variables' types.
But I think it's the icing on the cake if we give the PHP programmer the choice
of whether use explicit types.
For examlpe, we may add a switch in php.ini, let's say, expl
On 27.05.2010, at 10:45, Daniel Egeberg wrote:
> If you don't know whether the user/database provided information you
> have is correct before you pass it along to something else, I would
> say that the code indeed is bad. Unless you regard "123abc" as a valid
> value from your user, don't allow
Heh... Please do a DB select and make a var_dump on the rows from
database. You will see things like:
array(3) {
["id"]=>
string(1) "1"
["ref_id"]=>
string(2) "15"
["name"]=>
string(7) "Bla bla"
}
string, string and string again.
And that breaks the concept of strict type hinting. Be
On Thu, May 27, 2010 at 10:34, Arvids Godjuks wrote:
> Please read more carefully - what I mean that is we deal mostly with
> numbers witch are represented as strings, because all data that comes
> from external sources are STRING regardless of actual contents - be
> that integer or float - no mat
Hi,
if it comes to auto-converting (that's different from existing type-juggling):
wouldn't it be nice, to change type-juggling as well?
I know about BC breaks here, thus it would need till PHP 7 or so to become the
default behavior. But I think, BC breaks mainly occur in the cases where
type-
Please read more carefully - what I mean that is we deal mostly with
numbers witch are represented as strings, because all data that comes
from external sources are STRING regardless of actual contents - be
that integer or float - no matter. I don't want to make my code look
like this:
function do
Hi,
On Thu, May 27, 2010 at 09:45, Arvids Godjuks wrote:
> Just wanted to remind everyone that option #3 proposed earlier doesn't
> include auto-casting when data loss is happening.
>
> That means:
>
> function hintMe(int $number) {
> }
>
> hintMe(1);
> hintMe("1");
> hintMe("1.0");
> hintMe(arra
Just wanted to remind everyone that option #3 proposed earlier doesn't
include auto-casting when data loss is happening.
That means:
function hintMe(int $number) {
}
hintMe(1);
hintMe("1");
hintMe("1.0");
hintMe(array(1)); - Error or notice, no array -> int conversions
hintMe(1.25); - Error or n
53 matches
Mail list logo
