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
Hi,
On Thu, May 27, 2010 at 09:45, Arvids Godjuks arvids.godj...@gmail.com 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);
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
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
On Thu, May 27, 2010 at 10:34, Arvids Godjuks arvids.godj...@gmail.com 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
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. Because we get
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 the
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,
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
On Thu, May 27, 2010 at 10:53, Arvids Godjuks arvids.godj...@gmail.com 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 and
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 魏世江 shiji...@staff.sina.com.cn:
Hi .
I think there is no need to argue on it any more.
Good programmers have the ability to manipulate the variables'
On Thu, May 27, 2010 at 11:05, 魏世江 shiji...@staff.sina.com.cn 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
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 dimension
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']);
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
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
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 i...@prohost.org:
Zeev,
Auto-conversion does not validate input to the function/method, it merely
obfuscates the wrong input
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-conversion
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
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
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
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 is
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 value. I must
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=revisionrevision=299707
Ah that's great news, thanks!
Evert
--
PHP Internals - PHP Runtime
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 desired
On 27 May 2010 12:14, Zeev Suraski z...@zend.com 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
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.
In
On Thu, 27 May 2010, Richard Quadling wrote:
On 27 May 2010 12:14, Zeev Suraski z...@zend.com 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
At 15:31 27/05/2010, Richard Quadling wrote:
On 27 May 2010 12:14, Zeev Suraski z...@zend.com 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
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
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
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
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
On 2010-05-27, Zeev Suraski z...@zend.com 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
+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 -
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
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
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't
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 May 27 11:22 AM, David Soria Parra wrote:
On 2010-05-27, Zeev Suraski z...@zend.com 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
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
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
Please give Fitz mongo doc permissions.
On Thu, May 27, 2010 at 3:33 PM, Fitz Agard fhag...@lightcube.us 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
On Thu, May 27, 2010 at 5:47 PM, Lukas Kahwe Smith m...@pooteeweet.orgwrote:
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
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
On May 27, 2010, at 12:15 PM, Kristina Chodorow wrote:
On Thu, May 27, 2010 at 3:33 PM, Fitz Agard fhag...@lightcube.us 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
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
47 matches
Mail list logo
