Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

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

Re: [PHP-DEV] Let's discuss enums!

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

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

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

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

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

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

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

Re: [PHP-DEV] Let's discuss enums!

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

[PHP-DEV] Re: Let's discuss enums!

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

[PHP-DEV] Benchmark Results for PHP Master 2015-09-18

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

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

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

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

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

Re: [PHP-DEV] Let's discuss enums!

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: >

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

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

Re: [PHP-DEV] Let's discuss enums!

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

Re: [PHP-DEV] Let's discuss enums!

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) -

Re: [PHP-DEV] Let's discuss enums!

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

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] More precise float value

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

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

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

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] More precise float value

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

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

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

[PHP-DEV] Re: [RFC] [DISCUSSION] More precise float value

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

Re: [PHP-DEV] Let's discuss enums!

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

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

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

Re: [PHP-DEV] Re: Let's discuss enums!

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? >

Re: [PHP-DEV] Let's discuss enums!

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,

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

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

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

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

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

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

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

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

Re: [PHP-DEV] Let's discuss enums!

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

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

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

Re: [PHP-DEV] Let's discuss enums!

> 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

Re: [PHP-DEV] Let's discuss enums!

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

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

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 >

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

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

Re: [PHP-DEV] LDAP module requirements?

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

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

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

Re: [PHP-DEV] Let's discuss enums!

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

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

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

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

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!

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

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) ) {

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

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,

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

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

Re: [PHP-DEV] Let's discuss enums!

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 |

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

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

Re: [PHP-DEV] Let's discuss enums! <pajou...@gmail.com>

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

Re: [PHP-DEV] Let's discuss enums!

(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,

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

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

Re: [PHP-DEV] Let's discuss enums!

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

Re: [PHP-DEV] Let's discuss enums!

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

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

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

Re: [PHP-DEV] Let's discuss enums!

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

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

> 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