> 1. PHP already has its reserved namespace, the global one *\*.
> 2. Is it *\PHP* or *\Php*? This opens a huge can of worms.
We've technically only reserved PHP and php but it is case insensitive
anyway. PHP *does not* reserve the global namespace. At least that's
not what it says in the docs.
-
Results for project PHP master, build date 2016-03-17 06:31:11+02:00
commit: fc49f1c
previous commit:4165ae1
revision date: 2016-03-17 03:53:01+01:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
On Wed, Mar 16, 2016 at 2:58 PM, Stanislav Malyshev wrote:
>> Pretty basic RFC: There's new methods in ICU 52, wrap 'em up and make
>> 'em available.
>> Note that despite these APIs being windows focused, they are in fact
>> available on Linux.
>> They're just a database lookup, essentially.
>> ht
> At least that's not what it says in the docs.
I meant: at least according to the docs:
http://php.net/manual/en/language.namespaces.rationale.php
> Namespace names PHP and php, and compound names starting with these names
> (like PHP\Classes) are reserved for internal language use and should
On Friday, March 18, 2016, Larry Garfield wrote:
> On 03/18/2016 03:49 PM, Fleshgrinder wrote:
>
>> First a general note on the complete nullability first: It is not up to
>> us as language designers to decide whether it is good practice to use
>> nullable properties or not. It is supported by ma
class SomeStruct{ public int $a; }
class Joe
{
public SomeStruct $struct;
function test1() : SomeStruct{
return new SomeStruct();// TypeError: can't return
a type whose fields' type declarations aren't fulfilled
}
function test2(SomeStruct $struct){
On 3/17/2016 4:04 AM, Yasuo Ohgaki wrote:
> The only problem with this is "It looks inconsistent with existing
> module functions". We may consider how we are going to use namespaces
> for extensions in general. I like the idea
>
> \ModuleName\function_name
>
> for all extension functions, indeed
Den 2016-03-16 kl. 17:36, skrev Phil Sturgeon:
Hello everyone,
I have completed the draft for an RFC, to add Typed Properties. The
patch has been written by the one and only Joe Watkins.
https://wiki.php.net/rfc/typed-properties
I would really appreciate constructive feedback on this RFC, with
On Wed, Mar 16, 2016 at 6:17 PM, Andrey Andreev wrote:
> On Thu, Mar 17, 2016 at 12:00 AM, Larry Garfield
> wrote:
>
>> On 3/16/16 2:30 PM, Andrey Andreev wrote:
>>
>>> Also, a LOT of code would end up with e.g. a default value of 0 for an
>>> integer property, still having to check if it was pro
On Wed, Mar 16, 2016 at 3:20 PM, Larry Garfield wrote:
> If it works on Linux just fine, why is it called Windows? Is that really
> what the ICU spec says to call them, rather than something meaningful?
> (That would be sad making if so.)
>
Because there's no "spec" as such for the names that Win
On 03/18/2016 03:49 PM, Fleshgrinder wrote:
First a general note on the complete nullability first: It is not up to
us as language designers to decide whether it is good practice to use
nullable properties or not. It is supported by many systems since ages
(e.g. SQL where nullable fields are also
Results for project PHP master, build date 2016-03-18 06:28:14+02:00
commit: 48e3459
previous commit:fc49f1c
revision date: 2016-03-17 22:44:23+03:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
Hi Phil,
On 16 March 2016 at 17:36, Phil Sturgeon wrote:
> Hello everyone,
>
> I have completed the draft for an RFC, to add Typed Properties. The
> patch has been written by the one and only Joe Watkins.
>
> https://wiki.php.net/rfc/typed-properties
>
> I would really appreciate constructive fe
On Wed, Mar 16, 2016 at 12:50 PM, Larry Garfield
wrote:
> On 3/16/16 11:36 AM, Phil Sturgeon wrote:
>
>>
>> 2. This whole temporary nullability situation, where unset properties
>> will error on attempted usage if not set. Should they instead error
>> after the constructor has been called if they
Hi all,
Am 16.03.2016 um 21:29 schrieb Fleshgrinder:
> Another more complicated user case would be *mysqli_fetch_object* that
> populates the properties with values from a storage but values that
> should become something specific and strict at some point but are
> initially populated as strings.
> -Original Message-
> From: Andone, Bogdan [mailto:bogdan.and...@intel.com]
> Sent: Wednesday, March 09, 2016 9:33 AM
> To: 'Nikita Popov'
> Cc: internals@lists.php.net
> Subject: RE: [PHP-DEV] Lazy keys comparison during hash lookups
>
>
>
> > -Original Message-
> > From: Andon
16 matches
Mail list logo
