Hi!
> would tell you that accessing an uninitialized variable triggers an
> error. You can argue that a 'notice' is not an error but, in practice,
> everybody considers it this way. Nobody will tell you : 'Oh, that's just
> a notice, just disable E_NOTICE in your php.ini'.
In fact, that's exactly
Hi Rowan,
Le 18/09/2015 22:32, Rowan Collins a écrit :
It's the other way around - null doesn't mean uninitialized, but an
uninitialized variable has the implicit value null. It's also a reasonably
likely sign that there's a bug in your code, so PHP gives you a notice
suggesting you set it e
On 18/09/15 21:32, Rowan Collins wrote:
> It would not be a replacement for is_null, nor for isset(), but a way of
> writing a completely new type of code, which examined not a variable's value,
> but its state within the Engine.
Rowan ... why is using is_null() and isset() after using
array_ke
Hi Yasuo
2015-09-18 23:28 GMT+02:00 Yasuo Ohgaki :
> It's been 2 weeks and no comment for this.
> I'll start voting.
I'm sorry I have not caught this any earlier, but even without
consulting with Anatol, I'm not keen on adding this into 7.0, we are
in RC stage, and I want us to focus on a stable
Hi Yasuo,
- Original Message -
From: "Yasuo Ohgaki"
Sent: Friday, September 18, 2015
Hi all,
On Fri, Sep 4, 2015 at 9:41 AM, Yasuo Ohgaki wrote:
IEEE 754 double cannot express exact float values. That said,
float values expressed by json/serialize/var_export/echo/print
are not precis
On 18 September 2015 01:49:35 BST, John Bafford wrote:
>an important benefit to providing a value for enums would be to allow for
>changing or deprecating enums. So you might want to say something like:
>
>enum FormEvents {
> PRE_SUBMIT,
> PRE_BIND = PRE_SUBMIT, //deprecated name, pr
On 18 September 2015 18:31:55 BST, Lester Caine wrote:
>On 18/09/15 00:06, Rowan Collins wrote:
>> So, what are anyone's thoughts? Am I rambling on too much as usual?
>;)
>
>What happens when you need to switch language?
Yes, the names of enum members should be considered labels, not descriptions
On 18 September 2015 15:42:44 BST, Anthony Ferrara wrote:
>As far as enums, I wonder if they would be necessary if we supported
>algebraic types, since you could define an "enum" as a virtual type:
>
>const MONDAY = 0;
>const TUESDAY = 1;
>const WEDNESDAY = 2;
>const THURSDAY = 3;
>const FRIDAY =
Hi all,
On Fri, Sep 4, 2015 at 9:41 AM, Yasuo Ohgaki wrote:
> IEEE 754 double cannot express exact float values. That said,
> float values expressed by json/serialize/var_export/echo/print
> are not precise enough in many cases.
>
> Issues:
> - json_encode() uses EG(precision)=14 that truncates
On 18 September 2015 08:05:11 BST, "Pavel Kouřil" wrote:
>personally, I feel that you should be able to assign numeric value to
>each element (and have them implicit if not specified).
>
>This is imho better for serialization (but it can be done with names
>as well, yeah) - but more importantly, i
On 18 September 2015 03:58:57 BST, Stephen Coakley
wrote:
>On 09/17/2015 06:06 PM, Rowan Collins wrote:
>> member THURSDAY, FRIDAY, SATURDAY, SUNDAY; // don't force people
>to
>> write each entry on its own line; maybe even the "member" keyword is
>too
>> much?
>
>Member is even a little too
On 18 September 2015 20:37:07 BST, Benoit Schildknecht
wrote:
>So there is a bug regarding variables and null. Because I don't get any
>
>notice if I use a variable with "null" as a value. If "null" means
>"uninitialized", how come there are no notices ?
It's the other way around - null doesn
On 18/09/15 20:37, Benoit Schildknecht wrote:
> You have a lot of people who use isset() against null elements in an
> array. null elements happen a lot when interacting with an SQL server
> (for instance). I personally use array_key_exists(), but most people
> won't do the same at all. Because the
On 18/09/15 19:38, Rowan Collins wrote:
> The examples Lester and Robert have come up with make sense in
> themselves, but are not architectures I would choose precisely because
> they are opaque (you have to remember what unset() and null mean) and
> hard to extend (there's no way to introduce a 4
Le Fri, 18 Sep 2015 20:38:12 +0200, Rowan Collins
a écrit:
Benoit Schildknecht wrote on 18/09/2015 19:24:
I agree. exists() would allow PHP devs to make more secure, cleaner and
lighter code. It fills a gap and would be useful to a lot of devs.
On the contrary, I think code using exists()
On 09/18/2015 02:29 PM, Rowan Collins wrote:
Jefferson Gonzalez wrote on 18/09/2015 19:25:
I also believe the rfc should include type hinting of enums as has
been mentioned on this discussion. That would make enumerations more
useful and the rfc more complete.
It already mentions that:
> Enu
Benoit Schildknecht wrote on 18/09/2015 19:24:
I agree. exists() would allow PHP devs to make more secure, cleaner
and lighter code. It fills a gap and would be useful to a lot of devs.
On the contrary, I think code using exists() would be extremely fragile,
because it's highly resistant to r
Jefferson Gonzalez wrote on 18/09/2015 19:25:
I also believe the rfc should include type hinting of enums as has
been mentioned on this discussion. That would make enumerations more
useful and the rfc more complete.
It already mentions that:
> Enums are strongly typed and can be used as param
Robert Williams wrote on 18/09/2015 18:40:
Exactly, there’s clearly a gap here. Further, enough people want it
that a few have shown up on this list, which means there are probably
many, many thousands, or even millions, of people out in the wild that
want it.
The problem is that a lot of th
On 09/18/2015 01:21 PM, Levi Morrison wrote:
On Fri, Sep 18, 2015 at 11:18 AM, Rowan Collins wrote:
Levi Morrison wrote on 18/09/2015 18:04:
Anything else is trying to add value in some way – in your case you
are adding a primitive value that the language will automatically map
for you. I'm n
Le Fri, 18 Sep 2015 19:40:50 +0200, Robert Williams
a écrit:
On Sep 18, 2015, at 10:27, Lester Caine wrote:
All I am saying is that 'exists()' is simply part of the toolkit that
goes WITH extract(). There is a suitable tool in arrays and in objects
so why not complete the toolkit in straigh
> On Sep 18, 2015, at 10:27, Lester Caine wrote:
>
> All I am saying is that 'exists()' is simply part of the toolkit that
> goes WITH extract(). There is a suitable tool in arrays and in objects
> so why not complete the toolkit in straight variables. The names are a
> mess between the three for
On 18/09/15 00:06, Rowan Collins wrote:
> So, what are anyone's thoughts? Am I rambling on too much as usual? ;)
What happens when you need to switch language?
This is one area where a well formatted database system fills many
holes. Simply selecting a subset of entries from a table allows a user
On 18/09/15 18:11, Rowan Collins wrote:
>> You don't want to disable expand() so the next step is handling the
>> results of importing variables for which null is a valid state but
>> equally their NOT having been created is equally valid.
>
> Sure, extract() allows you to do half the trick you wa
On Fri, Sep 18, 2015 at 11:18 AM, Rowan Collins wrote:
> Levi Morrison wrote on 18/09/2015 18:04:
>>
>> Anything else is trying to add value in some way – in your case you
>> are adding a primitive value that the language will automatically map
>> for you. I'm not saying that is a bad thing but I
Levi Morrison wrote on 18/09/2015 18:04:
Anything else is trying to add value in some way – in your case you
are adding a primitive value that the language will automatically map
for you. I'm not saying that is a bad thing but I hope you can at
least recognize that it is an addition and not the b
Lester Caine wrote on 18/09/2015 17:20:
On 18/09/15 17:01, Rowan Collins wrote:
Right, so stop talking about Notices. Ignoring Notices does not get you
any closer to that goal.
And stop lecturing me about Nulls. The is_null($foo) part of that is the
part that already works fine.
ONLY if $foo a
(CC'ing internals as it was apparently dropped by Jeff)
On Fri, Sep 18, 2015 at 11:03 AM, Levi Morrison wrote:
> On Fri, Sep 18, 2015 at 9:59 AM, Jefferson Gonzalez wrote:
>> On 09/18/2015 10:21 AM, Levi Morrison wrote:
>>>
>>> On Fri, Sep 18, 2015 at 1:05 AM, Pavel Kouřil wrote:
On F
On 18/09/15 17:01, Rowan Collins wrote:
>
> Right, so stop talking about Notices. Ignoring Notices does not get you
> any closer to that goal.
>
> And stop lecturing me about Nulls. The is_null($foo) part of that is the
> part that already works fine.
ONLY if $foo actually exists!
My point here
Lester Caine wrote on 18/09/2015 16:55:
On 18/09/15 16:35, Rowan Collins wrote:
If what you want to write is "if ( ! exists($foo) || is_null($foo) ) {
... }" then that is exactly what "if ( isset($foo) )" will give you,
without any notices whatsoever.
NO what I want is
if ( exists($foo) ) {
Lester Caine wrote on 18/09/2015 16:17:
You don't do much real database coding do you ...
NULL is returned for fields that have no entry on a secondary table, so
the result set NATURALLY returns NULL.
Why do you keep going on about null? We're talking about non-existent
variables, not null!
On 09/18/2015 10:21 AM, Levi Morrison wrote:
On Fri, Sep 18, 2015 at 1:05 AM, Pavel Kouřil wrote:
On Fri, Sep 18, 2015 at 1:06 AM, Rowan Collins wrote:
Hi All,
This has come up in passing a few times recently, but I'm not sure there's
ever been a dedicated discussion of it: would it be usefu
On Fri, Sep 18, 2015 at 9:35 AM, Rowan Collins
wrote:
>
>
> If what you want to write is "if ( ! exists($foo) || is_null($foo) ) { ...
> }" then that is exactly what "if ( isset($foo) )" will give you, without
> any notices whatsoever.
Conversely, if what you want to write is "if ( exists($foo)
On 18/09/15 16:35, Rowan Collins wrote:
>> exists() has a place in SOME coding
>> styles which does not require to find the 'NULL' some other way to avoid
>> the potential notice!
>
> exists() would not be a way of avoiding the notice. exists() would be a
> way of distinguishing an extra state, qu
On 09/18/2015 10:42 AM, Anthony Ferrara wrote:
As far as enums, I wonder if they would be necessary if we supported
algebraic types, since you could define an "enum" as a virtual type:
const MONDAY = 0;
const TUESDAY = 1;
const WEDNESDAY = 2;
const THURSDAY = 3;
const FRIDAY = 4;
use MONDAY | TU
On 18/09/15 15:54, Rowan Collins wrote:
>> On 18/09/15 15:06, Rowan Collins wrote:
>>> A PHP variable can have all sorts of states, because you can take
>>> advantage of loose typing:
>>>
>>> $date = new DateTime();
>>> $date = null;
>>> $date = 'TODAY';
>>> $date = -1;
>>> $date = M_PI;
>> And iss
Lester Caine wrote on 18/09/2015 15:39:
On 18/09/15 15:06, Rowan Collins wrote:
A PHP variable can have all sorts of states, because you can take
advantage of loose typing:
$date = new DateTime();
$date = null;
$date = 'TODAY';
$date = -1;
$date = M_PI;
And isset() returns true for every one b
Bob Weinand wrote on 18/09/2015 15:23:
Well, I think we should*either* have an ordinal*or* a name.
But not both.
Currently, after thinking about it, I'm in favor of just a name. And no ordinal.
Having both is, I think, unnecessary.
Yeah, that was my instinct. It's a bit like surrogate keys o
Levi et al,
On Fri, Sep 18, 2015 at 10:11 AM, Levi Morrison wrote:
> On Thu, Sep 17, 2015 at 5:52 PM, John Bafford wrote:
>> On Sep 17, 2015, at 19:16, Bob Weinand wrote:
>>>
Am 18.09.2015 um 01:06 schrieb Rowan Collins :
This has come up in passing a few times recently, but I'm
On 18/09/15 15:06, Rowan Collins wrote:
> A PHP variable can have all sorts of states, because you can take
> advantage of loose typing:
>
> $date = new DateTime();
> $date = null;
> $date = 'TODAY';
> $date = -1;
> $date = M_PI;
And isset() returns true for every one but 'null' so how do I ident
> Am 18.09.2015 um 10:42 schrieb Rowan Collins :
>
> On 18 September 2015 01:15:43 BST, Bob Weinand wrote:
>> The reason it is not an associative array is that the names are not
>> important.
> ...
>> You never should *rely* on the ordinal value of the enum for anything.
>
> I feel like I'm miss
On Fri, Sep 18, 2015 at 1:05 AM, Pavel Kouřil wrote:
> On Fri, Sep 18, 2015 at 1:06 AM, Rowan Collins
> wrote:
>> Hi All,
>>
>> This has come up in passing a few times recently, but I'm not sure there's
>> ever been a dedicated discussion of it: would it be useful for PHP to have a
>> built-in E
On Thu, Sep 17, 2015 at 5:52 PM, John Bafford wrote:
> On Sep 17, 2015, at 19:16, Bob Weinand wrote:
>>
>>> Am 18.09.2015 um 01:06 schrieb Rowan Collins :
>>>
>>> This has come up in passing a few times recently, but I'm not sure there's
>>> ever been a dedicated discussion of it: would it be us
Lester Caine wrote on 18/09/2015 12:38:
For SQL data coming from any decent database each variable can either
have a value in, ( which may be an empty string ) or be NULL. The NUMBER
of fields returned does not matter, a query returning a single record
can have a variable
Again, I know what NUL
Stig Bakken wrote on 18/09/2015 14:44:
What lesson can we learn from that? Short and sweet names sometimes
lead to problems, if they do not precisely convey the actual
semantics.
I would much rather see a function called something like
is_variable_defined(), to avoid running into the same trap w
On Wed, Aug 26, 2015 at 5:09 AM, Scott Arciszewski wrote:
> Hi everybody,
>
> Would anyone be interested in adding another helper like
> isset()/empty() simply called exists() which would return true if the
> variable is defined in the current scope (i.e. without raising an
> E_NOTICE)?
>
> It sho
I checked the latest 5.6 release and it looks fine to me. Thanks for
incorporating the patch!
Rainer
Am 13.08.2015 um 17:32 schrieb Andreas Heigl:
Hi Rainer.
Am 13.08.15 um 16:39 schrieb Rainer Jung:
Am 12.08.2015 um 13:17 schrieb Andreas Heigl:
Hi Rainer.
Am 12.08.2015 um 13:00 schrieb R
On 18/09/15 12:38, Lester Caine wrote:
> Forget enum and more than three values in a variable ...
>
> For SQL data coming from any decent database each variable can either
> have a value in, ( which may be an empty string ) or be NULL. The NUMBER
> of fields returned does not matter, a query retur
On 18/09/15 12:15, Rowan Collins wrote:
>> But the whole problem here is that isset does NOT identify that the
>> result set has fields that are NULL.
>
> My point was that if you use isset() in place of is_null(), you don't
> have to switch off any errors. That's the only difference between the
>
Lester Caine wrote on 18/09/2015 01:32:
On 18/09/15 00:14, Rowan Collins wrote:
I'm confused - do you mean that some rows in the result set from the
database have columns "missing", rather than just set to NULL? That's
not something I've ever come across before.
While it would be better SQL p
Jefferson Gonzalez wrote on 18/09/2015 03:20:
On 09/17/2015 08:05 PM, Rowan Collins wrote:
I don't think serializing to a name is particularly more inefficient
than serializing to an integer - depending on the internal
implementation, of course. Or do you mean efficiency in terms of the
length o
Results for project php-src-nightly, build date 2015-09-18 05:00:00+03:00
commit: df29df7ec40cf7950a98f36bfa99ef19f0950309
revision_date: 2015-09-17 19:17:57+03:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping
2, LLC 45 MB
On 18 September 2015 01:15:43 BST, Bob Weinand wrote:
>The reason it is not an associative array is that the names are not
>important.
...
>You never should *rely* on the ordinal value of the enum for anything.
I feel like I'm missing something here. In my mind, the only absolute universal
about
On Fri, Sep 18, 2015 at 1:06 AM, Rowan Collins wrote:
> Hi All,
>
> This has come up in passing a few times recently, but I'm not sure there's
> ever been a dedicated discussion of it: would it be useful for PHP to have a
> built-in Enumeration type, and if so, how should it look?
>
> Many other l
54 matches
Mail list logo