Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:92020 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 10247 invoked from network); 30 Mar 2016 10:24:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 30 Mar 2016 10:24:08 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.214 mail4-2.serversure.net Linux 2.6 Received: from [217.147.176.214] ([217.147.176.214:50852] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C3/54-24137-649ABF65 for ; Wed, 30 Mar 2016 05:24:07 -0500 Received: (qmail 27669 invoked by uid 89); 30 Mar 2016 10:24:03 -0000 Received: by simscan 1.3.1 ppid: 27662, pid: 27665, t: 0.0714s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.7?) (lester@rainbowdigitalmedia.org.uk@81.155.186.161) by mail4.serversure.net with ESMTPA; 30 Mar 2016 10:24:03 -0000 To: internals@lists.php.net References: <56FB7096.9090602@zend.com> <56FB8EFA.5020108@zend.com> Message-ID: <56FBA943.808@lsces.co.uk> Date: Wed, 30 Mar 2016 11:24:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <56FB8EFA.5020108@zend.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties From: lester@lsces.co.uk (Lester Caine) On 30/03/16 09:31, Dmitry Stogov wrote: >> >> I hope this makes some of these decisions clearer ... > > One more thought about implicit initialization values. (int(0) for int > instead of IS_UNDEF). > I'm not sure if this RFC is going to be accepted yet, but lets think we > will also implement type hinting for arrays. > e.g. "array $a[40];" would create a packed array of integers > with 40 elements. > I would prefer to have all elements initialized by int(0) instead of > IS_UNDEF. > In this case we won't have to use zvals (and Buckets) for elements at > all, and will able to narrow this type to native C array "long a[40];" > This would safe 3/4 of memory required for array, and improve data > locality. > > Actually, this is exactly the same for properties. This is defining a new packed array ... one that is not a PHP array? I can understand the desire to compact data, but the place for that is in code not in normal scripts. But my main objection is that making the 'new' default some type related value rather than 'NULL' is taking things too far. The creation of a 'variable' precedes the initialization, and the processing of an array of variables to then populating from a database read or some other data source can be completed by a step that identifies any 'uninitialised' data and actions that appropriately ... or simply left as NULL. OK I may be a dinosaur, but in my model of object orientated processing, I create an object or array of objects and populate them or not as required. Empty objects simply return that they are just that, and NULL is the natural response converted to false as appropriate rather than having to interpret '0' as different to some other integer ID. NOT creating a container until there is something to put in it is a completely different method of working, but that seems to be what is being pushed as the 'proper way of doing things'? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk