> On Sep 16, 2015, at 14:57, Stanislav Malyshev wrote:
>
>> I’ll refer again to the above documentation:
>>
>> "A variable is considered to be null if […] it has been unset().”
>
> You are confusing two things.
>
> 1. The variable has value of null.
> 2. The variable does not exist, so when yo
On Sep 16, 2015, at 14:09, Rowan Collins wrote:
> I can certainly sympathise with wanting to run without any notices - they are
> generally hints for writing better code. In the vast majority of cases,
> though, that means working out *why* the variable is undefined, otherwise you
> might as we
Yasuo Ohgaki wrote on 17.09.2015 00:10:
> Hi all,
>
> PHP 7 has strict_types mode for function parameters/return values and
> these are binded to certain type strictly.
> https://wiki.php.net/rfc/scalar_type_hints_v5
>
> Why not make strict_types mode more strict?
> The idea is as follows:
>
>
On 17/09/15 00:09, Rowan Collins wrote:
>> That is better coding practice, but extract() is an equally
>> >valid practice currently being used and that needs a different way of
>> >handling if the elements exist.
> I'm still not entirely sure what it is you need to "handle".
>
> What is the behavi
Hi!
> PHP 7 has strict_types mode for function parameters/return values and
> these are binded to certain type strictly.
> https://wiki.php.net/rfc/scalar_type_hints_v5
>
> Why not make strict_types mode more strict?
What you are proposing is not making strict_mode more strict, it is full
variab
On 16 September 2015 23:10:55 BST, Yasuo Ohgaki wrote:
>The idea is as follows:
>
>declare(strict_types=1);
>
>function foo(int &$i) {
> $i = "string"; // Raise error
> $i = function_returns_string(); // Raise error
> $i = 1234.5678; // Raise error
> $i = function_returns_float(); // Raise err
Hi Yasuo,
Le 17/09/2015 00:10, Yasuo Ohgaki a écrit :
Hi all,
Assigning different type to already initialized variable is a bug most
likely. There may be cases that variable should have several types,
e.g. return INT for success and FALSE for failure, but programmers can
use different variable
On 16 September 2015 23:39:30 BST, Lester Caine wrote:
>On 16/09/15 22:23, Rowan Collins wrote:
>>> 'exists but I don't know what
>>> >as yet' is a logical state
>> It is indeed. "I know it's name but it doesn't exist", however, is
>generally not a valid state - if you've hard-coded the name (as i
On 16/09/15 22:23, Rowan Collins wrote:
>> 'exists but I don't know what
>> >as yet' is a logical state
> It is indeed. "I know it's name but it doesn't exist", however, is generally
> not a valid state - if you've hard-coded the name (as is the case with 99.9%
> of bare variables) then clearly y
Hi all,
PHP 7 has strict_types mode for function parameters/return values and
these are binded to certain type strictly.
https://wiki.php.net/rfc/scalar_type_hints_v5
Why not make strict_types mode more strict?
The idea is as follows:
Assigning different type to already initialized variable is
Hi!
> I’ll refer again to the above documentation:
>
> "A variable is considered to be null if […] it has been unset().”
You are confusing two things.
1. The variable has value of null.
2. The variable does not exist, so when you try to get its value,
there's nothing to give you, but we don't w
On 16 September 2015 at 14:36, Kalle Sommer Nielsen wrote:
> 2015-09-16 23:31 GMT+02:00 Anatol Belski :
>> While your observation is correct, I wouldn't see the matter as an alarming
>> issue. We're oriented to have less bugs in every next RC, thus RC2 will have
>> had its day soon anyway. So IM
2015-09-16 23:31 GMT+02:00 Anatol Belski :
> While your observation is correct, I wouldn't see the matter as an alarming
> issue. We're oriented to have less bugs in every next RC, thus RC2 will have
> had its day soon anyway. So IMHO this change is not quite nice at this stage,
> but still acce
On 16 September 2015 21:54:28 BST, Lester Caine wrote:
> 'exists but I don't know what
>as yet' is a logical state
It is indeed. "I know it's name but it doesn't exist", however, is generally
not a valid state - if you've hard-coded the name (as is the case with 99.9% of
bare variables) then cl
Hi Adam,
> -Original Message-
> From: a...@adamharvey.name [mailto:a...@adamharvey.name] On Behalf
> Of Adam Harvey
> Sent: Wednesday, September 16, 2015 3:08 AM
> To: Dmitry Stogov
> Cc: PHP internals ; Anatoliy Belsky ;
> Kalle
> Sommer Nielsen ; Ferenc Kovacs
> Subject: ABI break? (w
On 16 September 2015 21:03:42 BST, Robert Williams
wrote:
>looking at actual behavior of PHP, it’s clear that an undefined
>variable behaves differently from one assigned null. One can easily
>tell if a variable is null, but one can’t easily tell if a variable is
>just not defined.
This strikes
On 16 September 2015 20:56:22 BST, Robert Williams
wrote:
>On Sep 16, 2015, at 11:14, Rowan Collins
>wrote:
>>
>> Robert Williams wrote on 16/09/2015 18:37:
>>> If they were null, then PHP wouldn’t spit out errors about undefined
>variable accesses
>>
>> Once again - PHP does not spit out erro
On 16/09/15 21:03, Robert Williams wrote:
> "A variable is considered to be null if […] it has been unset().”
If the memory storing the variable has been destroyed by unset() then
there is nothing to 'consider' the variable does not exist?
If the variable has been created but as yet has not had a
On Sep 16, 2015, at 11:28, Stanislav Malyshev wrote:
>
>> 1 PHP defines null to include variables that have "not been set" 2
>
> No, not really, PHP does not define that.
It does according to the docs:
"A variable is considered to be null if […] it has not been set to any value
yet."
http://
On Sep 16, 2015, at 11:14, Rowan Collins wrote:
>
> Robert Williams wrote on 16/09/2015 18:37:
>> The docs suggest that uninitialized variables are null, and the above makes
>> it sound like that’s what you’re stating, too. But they’re not: they don’t
>> exist at all, they’re uninitialized.
>
Hi!
>> Taint is blacklisting.
>>
> Last time I checked marking all user input as tainted and requiring
> "untainting" before usage in sensitive functions is whitelisting and not
> blacklisting.
I would say it's neither - whitelisting is an explicit check (or fixing,
to ensure) that the input ma
Hi!
> Apologies, no offense intended, but you do realize that you
> essentially said that any programmer who doesn't agree with what you
> profess is the One True Way, is doing it wrong? This type of
> statement has been made several times in this thread, and it's
> annoyingly dismissive. Given ho
Robert Williams wrote on 16/09/2015 18:06:
As an example, go back to template systems that just define a bunch of
variables within the view’s scope: the view code needs to verify that
it actually got needed variables before it uses them so that it can
fail gracefully if it didn't.
At first si
Robert Williams wrote on 16/09/2015 18:27:
an even more common scenario is config files that are supposed to just
define a bunch of standalone variables, which is a very common
pattern. If you’re writing code that relies on those variables, or
you’re writing the code that’s supposed to pull tha
Robert Williams wrote on 16/09/2015 18:37:
The docs suggest that uninitialized variables are null, and the above
makes it sound like that’s what you’re stating, too. But they’re not:
they don’t exist at all, they’re uninitialized.
As soon as you access them, you will get the value null. You ca
On Sep 16, 2015, at 06:54, Rowan Collins wrote:
>
> I want to pull this out for a bit more attention: one of the crucial
> questions in this thread is whether the language is wrong, or just the
> documentation. There's one particularly wonky passage someone found in the
> manual that makes it
On Sep 16, 2015, at 06:44, Rowan Collins wrote:
>
> Can you give an example of code where you do not know this until the code
> runs - i.e. where "is this variable set?" is something you can hang business
> logic on?
>
> Somewhere where it would make sense to write something like this, if the
On Sep 16, 2015, at 06:00, Rowan Collins wrote:
>
> Absolutely. However, in order to need a dynamic check of variable existence,
> you must also be using non-existence as a second sentinel value. You must be
> saying "if the variable has never been assigned to, that means state X; if
> it's be
On 16/09/15 16:40, Rowan Collins wrote:
> If the extract() was being used to make the view code more readable in
> the first place, the exists() defeats rather than assists in that
> objective, in my opinion.
My own interface with it has been via templating, where the layout is
stored in a databas
Lester Caine wrote on 16/09/2015 16:48:
On 16/09/15 16:40, Rowan Collins wrote:
If the extract() was being used to make the view code more readable in
the first place, the exists() defeats rather than assists in that
objective, in my opinion.
My own interface with it has been via templating, wh
Lester Caine wrote on 16/09/2015 16:19:
Found the little gem I was trying to remember ... extract()
Import variables into the current symbol table from an array
THAT was the process I've seen used in libraries resulting in 'NULL'
Yes, extract(), like variable-variables ($$foo), can dynamically
On 16/09/15 14:30, Rowan Collins wrote:
> Yes, we can, and I repeatedly have. With the caveat that, like Perl, we
> raise an error if you try to use it on a plain variable rather than an
> array key or object property reference. My only remaining concern is
> that with that error in place, is "exis
Good morning,
> ==8<--
> Taint is blacklisting.
>
Last time I checked marking all user input as tainted and requiring
"untainting" before usage in sensitive functions is whitelisting and not
blacklisting.
Regards,
Stefan
--
SektionEins GmbHstefan.es...@sekti
On 9/15/2015 9:10 AM, Dennis Birkholz wrote:
Hi all,
Am 15.09.2015 um 17:09 schrieb Craig Francis:
2015-09-14 4:44 GMT+02:00 Christopher Owen :
Please consider making ‘taint’ a first-class feature/extension in PHP 7.0.
I would echo Kalle's suggestion of 7.1.
But I think you will find it har
Robert Williams wrote on 15/09/2015 10:38:
Okay, so to bring this home:
1 PHP defines null to include variables that have "not been set"
2 PHP also defines null to include variables that have been unset()
3 Variables can be explicitly set to null
All of these are null. And yet:
4 Calling isset
Robert Williams wrote on 15/09/2015 10:38:
variable existence is referenced throughout the docs along with null-ness (e.g., the docs for
isset() say it returns true if the variable, "is set and is not null" and if the
variable, "exists and has value other than null")
I want to pull this out f
Benoit Schildknecht wrote on 15/09/2015 18:04:
Every dev I've seen in my company use isset() as its name says it does
: "Is this variable set, whatever its value is ?". That's exactly how
we use it in the code.
Can you give an example of code where you do not know this until the
code runs -
François Laupretre wrote on 16/09/2015 14:26:
OK, but, as I already said, an exists() construct would probably be
used mostly for arrays elements and properties. Can't we accept this
as a more readable alternative to array_key_exists()/property_exists() ?
Yes, we can, and I repeatedly have. W
Le 16/09/2015 14:54, Rowan Collins a écrit :
The problem is that you're assigning meaning to a state that is
extremely hard to work with. For instance, you can't refactor code
which relies on dynamic variable existence into multiple functions,
because the input parameter of the new function wil
Robert Williams wrote on 14/09/2015 23:46:
Nonsense. It just means that one isn’t using null the way you do. You’re saying
people shouldn’t be programming to distinguish between
declared-but-defined-null and undeclared. But the fact is, from user land-POV,
null*is* a value, and it’s frequentl
Results for project php-src-nightly, build date 2015-09-16 05:00:00+03:00
commit: b6b1454c1ef4fd567f103f9306e69c2b1806e6a3
revision_date: 2015-09-15 08:59:01-07:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping
2, LLC 45 MB
Lester Caine wrote on 16/09/2015 13:37:
Since all of my data comes into
PHP as associative arrays, that is the way I handle them, and being SQL
data, NULL IS a valid state for an element.
Sure, and since you've got an array, you can use array_key_exists if you
need to.
Some people seem to
François Laupretre wrote on 16/09/2015 13:43:
Le 16/09/2015 14:23, Rowan Collins a écrit :
I would say encouraging devs to treat unset($foo) and $foo=null as
distinct states is an extremely bad idea.
I don't see it this way but, if unset and null states should
absolutely be considered the sam
Robert Williams wrote on 14/09/2015 21:17:
I really don’t understand the resistance to this type of change, other
than knowing that a fix will necessarily be messy.
The resistance is that not everyone agrees that there is a problem to be
fixed.
The fact is, PHP distinguishes between a varia
Le 16/09/2015 14:23, Rowan Collins a écrit :
I would say encouraging devs to treat unset($foo) and $foo=null as
distinct states is an extremely bad idea.
I don't see it this way but, if unset and null states should absolutely
be considered the same, why don't we add
array_key_isset()/property
On 16/09/15 13:23, Rowan Collins wrote:
> Possibly the same for property_exists(), since some people think
> stdClass objects look prettier than associative arrays, though I've
> never understood the attraction myself.
I think that may well be the point here. Since all of my data comes into
PHP as
François Laupretre wrote on 16/09/2015 12:36:.
I agree that it is not needed on local vars very often (maybe in some
template systems...).
I have yet to see, in this entire discussion, one single example.
The example Craig Francis gave of a template system worked 100%
correctly using the curr
Hi,
Le 15/09/2015 17:09, Craig Francis a écrit :
But I think you will find it hard to get support... I was pushing this
a few weeks ago (either the one from Wietse Venema, the one from Matt
Tait, or even my own suggestion), but it seems the developers are more
interested in features that make
Hi Rowan,
Le 16/09/2015 12:57, Rowan Collins a écrit :
However, I have still yet to see any use case where it would be
necessary or useful to detect - at runtime, rather than in static
analysis for debugging - that $i has never been initialised, vs it
having been initialised to null.
I agree
Lester Caine wrote on 16/09/2015 11:35:
If you are working with an array then fine, but we are talking about
variables here not arrays. isset($i) is a local variable so 'which array
is the variable is hiding in' applies?
No, it's not hiding in any array, and I agree that array_key_exists() is
On 16/09/15 11:03, Rowan Collins wrote:
> Lester Caine wrote on 15/09/2015 08:52:
>> Saying 'use the array_key_exists() assumes you also
>> know which array the variable is hiding in?
>
> Why would a variable ever be "hiding in" an array? If you're using an
> associative array, you should know whe
Lester Caine wrote on 15/09/2015 08:52:
Saying 'use the array_key_exists() assumes you also
know which array the variable is hiding in?
Why would a variable ever be "hiding in" an array? If you're using an
associative array, you should know where that array is; if you're not,
what exactly are
52 matches
Mail list logo
