Re: [PHP-DEV] Opcache::get($key), set($key, $value) to shared memory, is planned in PHP 7.1?

[Xinchen Hui]

Hey:



On Mon, Apr 25, 2016 at 10:09 PM, S.A.N  wrote:

> In userland  lacks the ability to store data in the shared memory
> modules, do not use pecl modules, it would be very nice to have a
> function:
>
> opcache_get($key);
> opcache_set($key, $value);
>
> Is planned in PHP 7.1?
>
you could try https://github.com/laruence/yac

it's a  "A fast shared memory user data cache for PHP "

thanks

> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

[PHP-DEV] [RFC] Patch for Union and Intersection Types

[Levi Morrison]

Internals,

Joe Watkins and Bob Weinand have worked out a [proof-of-concept patch
for union types][1]. Please go download it and experiment with it.

A few things to note:

  * This patch includes intersection types. However, a type expression
must be either a union type or an intersection type; it doesn't
support both such as `Array | (Countable & Traversable)`.
  * This patch adds `null`, `true` and `false` for type declarations.
  * This patch includes conversion rules for weak types.
  * It does not have short-hand for unions with null (`?Foo` being `Foo | Null`)

These features (or omitted ones) are not necessarily what will be
voted on. Rather this patch allows us to experiment with these
features in code. This experience should be helpful for us to solidify
how we actually feel about these features.

I especially would like people to try out the conversion rules for
scalar types as it has been a point of discussion.

  [1]: https://github.com/php/php-src/pull/1887

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Opcache::get($key), set($key, $value) to shared memory, is planned in PHP 7.1?

[S.A.N]

> Meanwhile, you haven't addressed the point being made as a reason not to
> bundle, which is that this is not a universally-useful solution, and there
> needs to be some reason why this needs to be incorporated - under whatever
> name - any more urgently than a memcache driver, or a redis driver, or
> igbinary serialisation, or any one of dozens of other extensions.

Redis, Memcached - single threaded and network latency.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] PHP Attributes

[Fleshgrinder]

On 4/25/2016 10:04 PM, Rowan Collins wrote:
> On 25/04/2016 19:37, Stanislav Malyshev wrote:
>> Hi!
>>
>>> @attr() - is a valid "silenced" call to function named "attr".
>>> This syntax can't be reused.
>> Not valid if it's in the middle of class definition, and not valid in
>> form of:
>>
>> @attr() function foo() { ... }
>>
>> This is not a valid PHP syntax now. So I'm not sure why it can't be
>> used. << is an operator too and so is >> .
>>
> 
> No, but this is valid:
> 
> @atrr(); function foo() { ... }
> 
> That's perhaps a little too close for comfort...?
> 
> Regards,
> 

Actually I agree with Stanislav (in pretty much every point he made so
far) on the syntax discussion, however, I already said that the brackets
are the main problem and it seems as it nobody sees it but your example
illustrates it perfectly.

@fopen('file', 'r'); function foo(){}

@deprecated function foo(){}

@throws InvalidArgumentException function foo(){}

@route ['name' => 'foo'] function foo(){}

Leaving out the brackets makes it very clear. I am in an extreme rush
and will read more in the thread the next days, sorry.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] PHP Attributes

[Stanislav Malyshev]

Hi!

> No, but this is valid:
> 
> @atrr(); function foo() { ... }
> 
> That's perhaps a little too close for comfort...?

That's different syntax. If you put ; in the middle of statement, it can
change - "$c = $a + $b;" is not the same as "$c = $a; + $b;" - but
nobody thinks + can not be used because of that. As I said, << and >>
are existing operators too, so if you are creative enough, I'm sure you
can find cases like that too.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Opcache::get($key), set($key, $value) to shared memory, is planned in PHP 7.1?

[Rowan Collins]

On 25/04/2016 19:07, S.A.N wrote:

I am not against third-party libraries, I want to have this
functionality out of the box, it seems to me correct to make these
functions in OPCache, instead of adding  Apcu to PHP core, IMHO...


Literally the only difference between including APCu in core and adding 
this to OpCache is the name of the resulting functions. The result 
either way is that you would have the functionality out of the box, and 
the PHP core devs would need to maintain it.


Meanwhile, you haven't addressed the point being made as a reason not to 
bundle, which is that this is not a universally-useful solution, and 
there needs to be some reason why this needs to be incorporated - under 
whatever name - any more urgently than a memcache driver, or a redis 
driver, or igbinary serialisation, or any one of dozens of other extensions.


Regards,

--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Opcache::get($key), set($key, $value) to shared memory, is planned in PHP 7.1?

[Arvids Godjuks]

On Mon, 25 Apr 2016, 21:07 S.A.N,  wrote:

> 2016-04-25 20:56 GMT+03:00 Rowan Collins :
> > S.A.N wrote on 25/04/2016 18:49:
> >>>
> >>> There's not really a huge connection between opcode caching and
> >>> optimization
> >>> >(OpCache) and shared memory data caches (APCu, memcached, etc), so I
> >>> > don't
> >>> >think there's any particular logic to calling such functions
> "opcache".
> >>> >
> >>> >So I guess the question becomes: "should APCu be made part of core?"
> I'm
> >>> > not
> >>> >aware of anyone having proposed that, so don't know if there are
> strong
> >>> >feelings for or against such a thing.
> >>
> >> Yes, there are a lot of libraries to work with shared memory, but why
> >> should they if there OPcache in core PHP?
> >> Functions get, set key values will be useful and in demand.
> >
> >
> > Because different situations call for different functionality. If the
> only
> > reason not to use APCu was the need to install a PECL extension, then
> nobody
> > would have implemented a PECL extension for Memcache, or Redis, etc.
> >
> > Storing data in PHP's shared memory has several downsides - for instance,
> > inability to share with CLI / services built in other languages,
> > non-persistent across server restarts, not shareable across instances,
> etc.
> > For you, these may not be an issue, but to say that "if APCu
> functionality
> > was in core, nobody would need any other memory cache" is somewhat naive.
>
> I am not against third-party libraries, I want to have this
> functionality out of the box, it seems to me correct to make these
> functions in OPCache, instead of adding  Apcu to PHP core, IMHO...
>

A little history lesson - combining an opcode cache and data storage is one
of the reasons APC died - it got too complex and too convoluted in the end.
Yes, there were other reasons too, but this one was one of the big one.

Getting that functionality into the core is not bad idea, but never ever
ever mix it with the opcode cache. Keep them separate.

>

Re: [PHP-DEV] [RFC] PHP Attributes

[Rowan Collins]

On 25/04/2016 19:37, Stanislav Malyshev wrote:

Hi!


@attr() - is a valid "silenced" call to function named "attr".
This syntax can't be reused.

Not valid if it's in the middle of class definition, and not valid in
form of:

@attr() function foo() { ... }

This is not a valid PHP syntax now. So I'm not sure why it can't be
used. << is an operator too and so is >> .



No, but this is valid:

@atrr(); function foo() { ... }

That's perhaps a little too close for comfort...?

Regards,

--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] PHP Attributes

[Rasmus Schultz]

Check here to see what we did for php-annotations:

https://github.com/php-annotations/php-annotations/blob/master/docs/CustomAnnotations.rst#usageannotation

It's somewhat similar to how C# does it, and it has worked quite nicely.


On Mon, Apr 25, 2016 at 8:40 PM, Stanislav Malyshev 
wrote:

> Hi!
>
> > a class/property/method that has annotations, it NOT inherit
> > annotations/attributes by default. However, by adding an annotation of
> >
> > <<__inherit>>
> >
> > (Or some other internal-reserved keyword, I don't have strong feelings
> > on what it is) then the engine will automatically give you all the
> > annotations off of the parent, and union them with whatever additional
> > ones you add.
>
> Then it makes no sense to ban repeating annotations - because that's
> what we effectively are doing here. Also, this assumes all annotations
> are either of inheritable kind or not, and these two categories can
> never be combined.
>
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Opcache::get($key), set($key, $value) to shared memory, is planned in PHP 7.1?

[Lester Caine]

On 25/04/16 19:07, S.A.N wrote:
> I am not against third-party libraries, I want to have this
> functionality out of the box, it seems to me correct to make these
> functions in OPCache, instead of adding  Apcu to PHP core, IMHO...

So how do you then manage the data when the PHP servers are spread
across multiple machines? Shared data needs to exist across space as
well as time, and the increasing use of virtual services needs
persistent data that is not reliant on the same memory storing that
data? This is not something that can easily be added unless all the
restrictions are fully understood.

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] PHP Attributes

[Stanislav Malyshev]

Hi!

> a class/property/method that has annotations, it NOT inherit
> annotations/attributes by default. However, by adding an annotation of
> 
> <<__inherit>>
> 
> (Or some other internal-reserved keyword, I don't have strong feelings
> on what it is) then the engine will automatically give you all the
> annotations off of the parent, and union them with whatever additional
> ones you add.

Then it makes no sense to ban repeating annotations - because that's
what we effectively are doing here. Also, this assumes all annotations
are either of inheritable kind or not, and these two categories can
never be combined.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] PHP Attributes

[Stanislav Malyshev]

Hi!

> @attr() - is a valid "silenced" call to function named "attr".
> This syntax can't be reused.

Not valid if it's in the middle of class definition, and not valid in
form of:

@attr() function foo() { ... }

This is not a valid PHP syntax now. So I'm not sure why it can't be
used. << is an operator too and so is >> .

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] PHP Attributes

[Stanislav Malyshev]

Hi!

> The proposed by you "@..." syntax just won't fit into PHP grammar,
> because @ used as silence operator.

Not sure why it is a problem more than << and >> being shift operators.
Since you said it can't be applied to anonymous functions/classes
anyway, parser with the help of AST should be able to figure out which
one is meant - I don't see a case where it's ambiguous.

> Attribute, syntax is taken from HHVM. I don't see a big reason to
> introduce more fragmentation into PHP world.

I don't think this is a good argument. It effectively means we now give
our language design to Facebook Hack team - whatever they do in Hack, we
then must follow, since otherwise it would be "more fragmentation". I
don't think it is a good position on our side.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Opcache::get($key), set($key, $value) to shared memory, is planned in PHP 7.1?

[Marco Pivetta]

On 25 April 2016 at 20:07, S.A.N  wrote:

> 2016-04-25 20:56 GMT+03:00 Rowan Collins :
> > S.A.N wrote on 25/04/2016 18:49:
> >>>
> >>> There's not really a huge connection between opcode caching and
> >>> optimization
> >>> >(OpCache) and shared memory data caches (APCu, memcached, etc), so I
> >>> > don't
> >>> >think there's any particular logic to calling such functions
> "opcache".
> >>> >
> >>> >So I guess the question becomes: "should APCu be made part of core?"
> I'm
> >>> > not
> >>> >aware of anyone having proposed that, so don't know if there are
> strong
> >>> >feelings for or against such a thing.
> >>
> >> Yes, there are a lot of libraries to work with shared memory, but why
> >> should they if there OPcache in core PHP?
> >> Functions get, set key values will be useful and in demand.
> >
> >
> > Because different situations call for different functionality. If the
> only
> > reason not to use APCu was the need to install a PECL extension, then
> nobody
> > would have implemented a PECL extension for Memcache, or Redis, etc.
> >
> > Storing data in PHP's shared memory has several downsides - for instance,
> > inability to share with CLI / services built in other languages,
> > non-persistent across server restarts, not shareable across instances,
> etc.
> > For you, these may not be an issue, but to say that "if APCu
> functionality
> > was in core, nobody would need any other memory cache" is somewhat naive.
>
> I am not against third-party libraries, I want to have this
> functionality out of the box, it seems to me correct to make these
> functions in OPCache, instead of adding  Apcu to PHP core, IMHO...
>

You are still asking for a tool that does a very precise and single thing
to be re-purposed into a completely different scope.

Use the right tool for the right job: including APCu would be much
clearer/simpler than making OpCache an all-purpose shared memory space for
userland.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] Opcache::get($key), set($key, $value) to shared memory, is planned in PHP 7.1?

[S.A.N]

2016-04-25 20:56 GMT+03:00 Rowan Collins :
> S.A.N wrote on 25/04/2016 18:49:
>>>
>>> There's not really a huge connection between opcode caching and
>>> optimization
>>> >(OpCache) and shared memory data caches (APCu, memcached, etc), so I
>>> > don't
>>> >think there's any particular logic to calling such functions "opcache".
>>> >
>>> >So I guess the question becomes: "should APCu be made part of core?" I'm
>>> > not
>>> >aware of anyone having proposed that, so don't know if there are strong
>>> >feelings for or against such a thing.
>>
>> Yes, there are a lot of libraries to work with shared memory, but why
>> should they if there OPcache in core PHP?
>> Functions get, set key values will be useful and in demand.
>
>
> Because different situations call for different functionality. If the only
> reason not to use APCu was the need to install a PECL extension, then nobody
> would have implemented a PECL extension for Memcache, or Redis, etc.
>
> Storing data in PHP's shared memory has several downsides - for instance,
> inability to share with CLI / services built in other languages,
> non-persistent across server restarts, not shareable across instances, etc.
> For you, these may not be an issue, but to say that "if APCu functionality
> was in core, nobody would need any other memory cache" is somewhat naive.

I am not against third-party libraries, I want to have this
functionality out of the box, it seems to me correct to make these
functions in OPCache, instead of adding  Apcu to PHP core, IMHO...

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Opcache::get($key), set($key, $value) to shared memory, is planned in PHP 7.1?

[Rowan Collins]

S.A.N wrote on 25/04/2016 18:49:

There's not really a huge connection between opcode caching and optimization
>(OpCache) and shared memory data caches (APCu, memcached, etc), so I don't
>think there's any particular logic to calling such functions "opcache".
>
>So I guess the question becomes: "should APCu be made part of core?" I'm not
>aware of anyone having proposed that, so don't know if there are strong
>feelings for or against such a thing.

Yes, there are a lot of libraries to work with shared memory, but why
should they if there OPcache in core PHP?
Functions get, set key values will be useful and in demand.


Because different situations call for different functionality. If the 
only reason not to use APCu was the need to install a PECL extension, 
then nobody would have implemented a PECL extension for Memcache, or 
Redis, etc.


Storing data in PHP's shared memory has several downsides - for 
instance, inability to share with CLI / services built in other 
languages, non-persistent across server restarts, not shareable across 
instances, etc. For you, these may not be an issue, but to say that "if 
APCu functionality was in core, nobody would need any other memory 
cache" is somewhat naive.


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Opcache::get($key), set($key, $value) to shared memory, is planned in PHP 7.1?

[Marco Pivetta]

This seems to mix the concerns of an opcode cache (saves opcodes) with a
user-cache (saves mixed data).

You should just use APCu for that.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

On 25 April 2016 at 19:49, S.A.N  wrote:

> 2016-04-25 17:36 GMT+03:00 Rowan Collins :
> > S.A.N wrote on 25/04/2016 15:09:
> >>
> >> In userland  lacks the ability to store data in the shared memory
> >> modules, do not use pecl modules, it would be very nice to have a
> >> function:
> >>
> >> opcache_get($key);
> >> opcache_set($key, $value);
> >>
> >> Is planned in PHP 7.1?
> >>
> >
> > This was identified as a difference between APC and OpCache when the
> latter
> > was added to core several releases ago, and that's exactly why APCu
> exists:
> > http://php.net/apcu
> >
> > There's not really a huge connection between opcode caching and
> optimization
> > (OpCache) and shared memory data caches (APCu, memcached, etc), so I
> don't
> > think there's any particular logic to calling such functions "opcache".
> >
> > So I guess the question becomes: "should APCu be made part of core?" I'm
> not
> > aware of anyone having proposed that, so don't know if there are strong
> > feelings for or against such a thing.
>
> Yes, there are a lot of libraries to work with shared memory, but why
> should they if there OPcache in core PHP?
> Functions get, set key values will be useful and in demand.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Opcache::get($key), set($key, $value) to shared memory, is planned in PHP 7.1?

[S.A.N]

2016-04-25 17:36 GMT+03:00 Rowan Collins :
> S.A.N wrote on 25/04/2016 15:09:
>>
>> In userland  lacks the ability to store data in the shared memory
>> modules, do not use pecl modules, it would be very nice to have a
>> function:
>>
>> opcache_get($key);
>> opcache_set($key, $value);
>>
>> Is planned in PHP 7.1?
>>
>
> This was identified as a difference between APC and OpCache when the latter
> was added to core several releases ago, and that's exactly why APCu exists:
> http://php.net/apcu
>
> There's not really a huge connection between opcode caching and optimization
> (OpCache) and shared memory data caches (APCu, memcached, etc), so I don't
> think there's any particular logic to calling such functions "opcache".
>
> So I guess the question becomes: "should APCu be made part of core?" I'm not
> aware of anyone having proposed that, so don't know if there are strong
> feelings for or against such a thing.

Yes, there are a lot of libraries to work with shared memory, but why
should they if there OPcache in core PHP?
Functions get, set key values will be useful and in demand.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] PHP Attributes

[Benjamin Eberlei]

On Mon, Apr 25, 2016 at 7:11 PM, Rowan Collins 
wrote:

> guilhermebla...@gmail.com wrote on 25/04/2016 15:22:
>
>> Another thing that looks odd to me i that every time you call new
>> ReflectionClass, a new reflection_object gets created.
>> Isn't there a way to get this "cached" somehow in zend_class_entry?
>>
>
> I recently came upon a package that exists solely to work around this:
> https://packagist.org/packages/fsi/reflection
>
> I am reminded of the fact that people often say "reflection is slow, use
> it with care". Is this still the case? Does this limit the usability of
> attributes as proposed?


No its not slow, if you don't create Reflection* instances all the time. In
Doctrine we cache this per class and only do it once.

Guilherme came up with the why the object references are not reused on IRC,
because setAccessible could otherwise produce side effects to other
instances. So this actually makes sense.

>
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] PHP Attributes

[Rowan Collins]

guilhermebla...@gmail.com wrote on 25/04/2016 15:22:

Another thing that looks odd to me i that every time you call new
ReflectionClass, a new reflection_object gets created.
Isn't there a way to get this "cached" somehow in zend_class_entry?


I recently came upon a package that exists solely to work around this: 
https://packagist.org/packages/fsi/reflection


I am reminded of the fact that people often say "reflection is slow, use 
it with care". Is this still the case? Does this limit the usability of 
attributes as proposed?


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Opcache::get($key), set($key, $value) to shared memory, is planned in PHP 7.1?

[Rowan Collins]

André Rømcke wrote on 25/04/2016 18:00:

>So I guess the question becomes: "should APCu be made part of core?" I'm not 
aware of anyone having proposed that, so don't know if there are strong feelings for or 
against such a thing.

As long as it’s cache is not shared among processes, rather not.
A user cache needs to be able to be shared between cli and web process to cover 
the main use cases imo.



Yeah, there are many key-value, document-based, and NoSQL stores these 
days (memcached, redis, couchbase, mongo, etc), and while APCu might be 
the best in some circumstances, I'm inclined to say it doesn't deserve 
special privilege within default builds.


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] PHP Attributes

[Benjamin Eberlei]

On Mon, Apr 25, 2016 at 6:49 PM, Larry Garfield 
wrote:

> On 04/25/2016 10:20 AM, Dmitry Stogov wrote:
>
>>
>> This leads to some serious copy/paste, highly error prone... =(
>>>
>>
>> If we had a theoretical approach for attribute inheritance, I would
>> implement it.
>> But I wouldn't invite any theory, because anyone is going to depend on
>> use-case.
>>
>
> Realistically, I see only 3 possible approaches to consider:
>
> 1) An overridden class/property/method always inherits its parent's
> annotations/attributes, and you can add to them.
> 2) An overridden class/property/method never inherits its parent's
> annotations/attributes, but you can repeat them.
> 3) Give users a syntactic toggle.


Why do we talk about inheritance at all? ReflectionClass/Method/Property
already have a well defined way of accessing the inherited data. Why should
it work differently for ReflectionAttribute:

Demonstration of how to get access to overwritten doc comments in case of
overwritting a base class:

https://3v4l.org/6fRdn

Attributes should just work exactly the same and we are done.

>
>
> As I said earlier, if you do a call based approach, we could create
>>> @Inherit or @Override, which would not only make us safe from support, but
>>> also gives more power to developers.
>>>
>>
>> If we implement built-in @Inherit and/or @Override, it's not a big
>> problem to copy attributes from parent.
>>
>
> If I understand you correctly, that would be option 3.  I would support
> that as well, as it's consistent with how methods work: By default, they
> override the parent method but you can call parent::whatever() to toggle
> the parent behavior back on.  Thus, I would suggest that when overriding a
> class/property/method that has annotations, it NOT inherit
> annotations/attributes by default. However, by adding an annotation of
>
> <<__inherit>>
>
> (Or some other internal-reserved keyword, I don't have strong feelings on
> what it is) then the engine will automatically give you all the annotations
> off of the parent, and union them with whatever additional ones you add.
>
> That of course raises interesting questions around interfaces and traits,
> and how annotations on those comingle.  Should annotations on interfaces
> auto-apply to their implementations or should they require an explicit
> <<__inherit>>?  I'm undecided.
>
> --Larry Garfield
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Opcache::get($key), set($key, $value) to shared memory, is planned in PHP 7.1?

[André Rømcke]

> On 25 Apr 2016, at 16:36 , Rowan Collins  wrote:
> 
> S.A.N wrote on 25/04/2016 15:09:
>> In userland  lacks the ability to store data in the shared memory
>> modules, do not use pecl modules, it would be very nice to have a
>> function:
>> 
>> opcache_get($key);
>> opcache_set($key, $value);
>> 
>> Is planned in PHP 7.1?
>> 
> 
> This was identified as a difference between APC and OpCache when the latter 
> was added to core several releases ago, and that's exactly why APCu exists: 
> http://php.net/apcu
> 
> There's not really a huge connection between opcode caching and optimization 
> (OpCache) and shared memory data caches (APCu, memcached, etc), so I don't 
> think there's any particular logic to calling such functions "opcache".
> 
> So I guess the question becomes: "should APCu be made part of core?" I'm not 
> aware of anyone having proposed that, so don't know if there are strong 
> feelings for or against such a thing.


As long as it’s cache is not shared among processes, rather not.
A user cache needs to be able to be shared between cli and web process to cover 
the main use cases imo.

Re: [PHP-DEV] [RFC] PHP Attributes

[Larry Garfield]

On 04/25/2016 10:20 AM, Dmitry Stogov wrote:



This leads to some serious copy/paste, highly error prone... =(


If we had a theoretical approach for attribute inheritance, I would 
implement it.
But I wouldn't invite any theory, because anyone is going to depend on 
use-case.


Realistically, I see only 3 possible approaches to consider:

1) An overridden class/property/method always inherits its parent's 
annotations/attributes, and you can add to them.
2) An overridden class/property/method never inherits its parent's 
annotations/attributes, but you can repeat them.

3) Give users a syntactic toggle.

As I said earlier, if you do a call based approach, we could create 
@Inherit or @Override, which would not only make us safe from 
support, but also gives more power to developers.


If we implement built-in @Inherit and/or @Override, it's not a big 
problem to copy attributes from parent.


If I understand you correctly, that would be option 3.  I would support 
that as well, as it's consistent with how methods work: By default, they 
override the parent method but you can call parent::whatever() to toggle 
the parent behavior back on.  Thus, I would suggest that when overriding 
a class/property/method that has annotations, it NOT inherit 
annotations/attributes by default. However, by adding an annotation of


<<__inherit>>

(Or some other internal-reserved keyword, I don't have strong feelings 
on what it is) then the engine will automatically give you all the 
annotations off of the parent, and union them with whatever additional 
ones you add.


That of course raises interesting questions around interfaces and 
traits, and how annotations on those comingle.  Should annotations on 
interfaces auto-apply to their implementations or should they require an 
explicit <<__inherit>>?  I'm undecided.


--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC:generics]

[Rasmus Schultz]

> I really don't like 'as' in this context, even if Hack uses it, as it
> doesn't reflect in English terms what the code is doing. As others
> have already said, it reads as if 'T' is being aliased to 'Bar'.

I second that.

I hear the concerns about adding another reserved word "is" though,
so I'd like to suggest simply using a ":" ... as in:

class A { ... }

Consistent with return type-hints, it should feel like home?

For sure nobody wants to type out "instanceof", and (as pointed out
in the RFC) the instanceof operator checks the type of an object,
which is *not* what this is doing - a type argument is not an "instance
of" anything. The ":" is more neutral in that regard maybe?


On Thu, Apr 21, 2016 at 10:32 AM, Josh Di Fabio  wrote:
> On Wed, Apr 20, 2016 at 8:17 PM, Dominic Grostate
>  wrote:
>> Thanks for you're input everyone.
>>
>> So far, we have read some ideas for handling upper bounds, or multiple there
>> of.
>> The preferred keywords appear to be either "as" or "instanceof".
>>
>> class Foo {}
>> class Foo {}
>>
>> We would like to know for sure then if everyone is largely against the
>> addition of an "is" keyword, in favour of one of the other two.
>>
>
> I really don't like 'as' in this context, even if Hack uses it, as it
> doesn't reflect in English terms what the code is doing. As others
> have already said, it reads as if 'T' is being aliased to 'Bar'.
>
> On Wed, Apr 20, 2016 at 8:17 PM, Dominic Grostate
>  wrote:
>> Thanks for you're input everyone.
>>
>> So far, we have read some ideas for handling upper bounds, or multiple there
>> of.
>> The preferred keywords appear to be either "as" or "instanceof".
>>
>> class Foo {}
>> class Foo {}
>>
>> We would like to know for sure then if everyone is largely against the
>> addition of an "is" keyword, in favour of one of the other two.
>>
>> 
>>
>> There is also a desire to include unions and intersections.
>> Presently though, this feature feels tied in with
>> https://wiki.php.net/rfc/union_types meaning if union types are approved,
>> then generics would have to support them as well.  Likewise if this feature
>> becomes approved in generics, it would make sense to support them in regular
>> type hints as well.
>>
>> 
>>
>> The RFC makes a reference to generic closures, which may look something like
>> this:
>>
>> function my_function(callable $func) {
>>
>> }
>>
>> However, an RFC already exists which is very similar to this feature at
>> https://wiki.php.net/rfc/callable-types
>> As it currently standards these RFCs appear incompatible with each other
>> (please correct me if I am wrong).
>>
>> My question about this is would you prefer the generics RFC exclude this
>> part in favour of a separate or later RFC.
>> Initially the proposal included generic arrays "array".  However to
>> ease the implementation it was decided that should be a separate feature.
>> So we'd like to find out if everyone else feels the same way about callable
>> types.
>>
>> 
>>
>> This RFC currently doesn't specify in detail how reflection would work.  We
>> have attempted a few API designs, but due to generic classes being ...
>> generic, it is difficult to find a suitable way to glean information about a
>> class in a backwards compatible manner.  So we will need some help on this
>> one.
>>
>> -
>>
>> Aside from these top issues on our own list, however does everyone feel
>> about the proposal in general?
>> As the RFC is still in draft, we will continue to make changes to it as more
>> popular idea pop up, so please continue.
>>
>> Thanks.
>>
>> PS: I wasn't properly subscribed to the mailing list, so I missed a few
>> important messages that were mailed directly to internals, but hopefully
>> I've managed to fix that now.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

This is another reason to use PHP layer on top on base attribute functionality.

Implementing caching would take just 3 additional lines of PHP code.


From: guilhermebla...@gmail.com 
Sent: Monday, April 25, 2016 17:22
To: Dmitry Stogov
Cc: Dominic Grostate; PHP internals
Subject: Re: [PHP-DEV] [RFC] PHP Attributes

Another thing that looks odd to me i that every time you call new 
ReflectionClass, a new reflection_object gets created.
Isn't there a way to get this "cached" somehow in zend_class_entry?

On Mon, Apr 25, 2016 at 10:11 AM, 
guilhermebla...@gmail.com 
> wrote:


On Mon, Apr 25, 2016 at 3:42 AM, Dmitry Stogov 
> wrote:


On 04/22/2016 06:39 PM, 
guilhermebla...@gmail.com wrote:

On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov 
> wrote:


On 04/22/2016 04:05 AM,  
guilhermebla...@gmail.com wrote:
Hi Dmitry,

As a previous suggester of metadata information built-in into PHP, and also one 
of developers of the most used metadata library written in PHP, I understand 
this feature implementation requires several design decisions and also a good 
understanding of specific situations users may require.

While I am a strong supporter of a more robust solution, this is already a good 
start.
A few things I'd like to ask for my own understanding and also suggestions too:

1- I understand you took a minimalistic approach towards a "dumb" 
implementation for attributes (when I mean "dumb", the idea here is towards a 
non-OO approach). Can you explain your motivations towards this approach?

I see two distinct approaches of implementation for this feature. Both of them 
have some common demands, like lazy initialization of metadata. Here they are:

- Simplistic approach, which lets consumers of the feature do all the work 
related to validation, assertion of valid keys, values, etc
This does not invalidate the ability to leverage of some features that a more 
robust implementation demands.

- Robust approach: language takes the burden of instantiating complex 
structures, validating, assertion of valid keys, values, if this complex 
structure is allowed to be instantiated in that given class, method, etc.

I didn't exactly understand what do you suggest.
If you are talking about Attribute objects initialization during compilation - 
this is just not possible from implementation point of view.
Now attributes may be stored in opcache SHM and relive request boundary.
Objects can't relive requests.


I know that object instances are not cross-requests. Explicitly, I mentioned 
that both approaches require lazy-initialization (which means, whenever you 
call getAttributes() or getAttribute()).

What I mentioning is that your approach is basically a new key/value syntax 
that are used specifically for Attributes. We could easily turn this into a 
more robust approach if instead of defining key/value pairs, we instantiate 
objects or call functions. You already demonstrated interest to support 
<> reusing the imports (which is our biggest headache in Doctrine 
Annotations), so why not issue constructor or function calls there? That would 
simplify the work needed for consumers and also add room for later improvements.

So basically in this example:

use Doctrine\ORM;

<>
class User {}

$reflClass = new \ReflectionClass("User");
var_dump($reflClass->getAttributes());

We'd be changing from this:

array(1) {
  ["Doctrine\ORM\Entity"]=>
  array(1) {
[0]=>
string(4) "user"
  }
}

Into this:

array(1) {
  ["Doctrine\ORM\Entity"]=>
  object(Doctrine\ORM\Entity)#1 (1) {
["tableName"]=>
string(4) "user"
  }
}

As I showed already, it's very easy to do this transformation at higher layer.

$reflClass = new \ReflectionClass("User");
$attributes = $reflClass->getAttributes()
foreach ($attributes as $key => &$val) {
$val = new $key(...$val);
}
var_dump($attributes);

Construction objects directly in Reflection*::getAttributes() method, doesn't 
make significant benefits and even makes limitation.

Sorry, but I don't see how limitations are added. If you call a function, 
static method or constructor, you actually add whole new level of 
possibilities, and I fail to see which limitations are added. Could you provide 
me one?

Calling the function/constructor/static method, not only helps to better 
segregate userland code, but it also adds subsequents extensibility. I can 
highlight examples:

- Support for Inheritance and overrides, through @Inherit, @Override, etc. 
While you might not see how it could be used now, other developers might be 
weirdly creative.
- Targeting of annotations, such as limiting its scope to be only class, method 
or 

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/25/2016 05:11 PM, guilhermebla...@gmail.com wrote:



On Mon, Apr 25, 2016 at 3:42 AM, Dmitry Stogov > wrote:




On 04/22/2016 06:39 PM, guilhermebla...@gmail.com
 wrote:


On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov > wrote:



On 04/22/2016 04:05 AM, guilhermebla...@gmail.com
 wrote:

Hi Dmitry,

As a previous suggester of metadata information built-in
into PHP, and also one of developers of the most used
metadata library written in PHP, I understand this feature
implementation requires several design decisions and also a
good understanding of specific situations users may require.

While I am a strong supporter of a more robust solution,
this is already a good start.
A few things I'd like to ask for my own understanding and
also suggestions too:

1- I understand you took a minimalistic approach towards a
"dumb" implementation for attributes (when I mean "dumb",
the idea here is towards a non-OO approach). Can you explain
your motivations towards this approach?

I see two distinct approaches of implementation for this
feature. Both of them have some common demands, like lazy
initialization of metadata. Here they are:

- Simplistic approach, which lets consumers of the feature
do all the work related to validation, assertion of valid
keys, values, etc
This does not invalidate the ability to leverage of some
features that a more robust implementation demands.

- Robust approach: language takes the burden of
instantiating complex structures, validating, assertion of
valid keys, values, if this complex structure is allowed to
be instantiated in that given class, method, etc.


I didn't exactly understand what do you suggest.
If you are talking about Attribute objects initialization
during compilation - this is just not possible from
implementation point of view.
Now attributes may be stored in opcache SHM and relive
request boundary.
Objects can't relive requests.



I know that object instances are not cross-requests. Explicitly,
I mentioned that both approaches require lazy-initialization
(which means, whenever you call getAttributes() or getAttribute()).

What I mentioning is that your approach is basically a new
key/value syntax that are used specifically for Attributes. We
could easily turn this into a more robust approach if instead of
defining key/value pairs, we instantiate objects or call
functions. You already demonstrated interest to support
<> reusing the imports (which is our biggest headache
in Doctrine Annotations), so why not issue constructor or
function calls there? That would simplify the work needed for
consumers and also add room for later improvements.
So basically in this example:

use Doctrine\ORM;

<>
class User {}

$reflClass = new \ReflectionClass("User");
var_dump($reflClass->getAttributes());

We'd be changing from this:

array(1) {
["Doctrine\ORM\Entity"]=>
array(1) {
[0]=>
string(4) "user"
  }
}

Into this:

array(1) {
["Doctrine\ORM\Entity"]=>
object(Doctrine\ORM\Entity)#1 (1) {
["tableName"]=>
string(4) "user"
  }
}


As I showed already, it's very easy to do this transformation at
higher layer.

$reflClass = new \ReflectionClass("User");
$attributes = $reflClass->getAttributes()
foreach ($attributes as $key => &$val) {
$val = new $key(...$val);
}
var_dump($attributes);

Construction objects directly in Reflection*::getAttributes()
method, doesn't make significant benefits and even makes limitation.


Sorry, but I don't see how limitations are added. If you call a 
function, static method or constructor, you actually add whole new 
level of possibilities, and I fail to see which limitations are added. 
Could you provide me one?


For example, I like to check an attribute existence, and I don't need to 
construct any objects.


Calling the function/constructor/static method, not only helps to 
better segregate userland code, but it also adds subsequents 
extensibility. I can highlight examples:


- Support for Inheritance and overrides, through @Inherit, @Override, 
etc. While you might not see how it could be used now, other 
developers might be weirdly creative.
- Targeting of annotations, such as limiting its scope to be only 
class, method or property. We use this extensively in Doctrine, where 
you cannot define Doctrine\ODM\Entity over a property.
- Separating what can be considered as an annotation and what 

[PHP-DEV] BAD Benchmark Results for PHP Master 2016-04-25

[lp_benchmark_robot]

Results for project PHP master, build date 2016-04-25 06:28:35+03:00
commit: 434e0fb
previous commit:304e5ae
revision date:  2016-04-24 21:46:20+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, 
stepping 2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0, with hash 60fffd2 from
2015-12-01 04:16:47+00:00

---
benchmark   relative   change since   change since  
current rev run
std_dev*   last run   baseline  
   with PGO
---
:-|   Wordpress 4.2.2 cgi -T1  0.15%  0.14%  0.80%  
  7.17%
:-|   Drupal 7.36 cgi -T1  0.21%  0.16%  0.41%  
  3.58%
:-|   MediaWiki 1.23.9 cgi -T5000  0.09%  0.22%  1.53%  
  3.33%
:-|   bench.php cgi -T100  0.03% -0.14% 24.95%  
  0.15%
:-|  micro_bench.php cgi -T10  0.01%  0.04%  6.38%  
  2.12%
:-(  mandelbrot.php cgi -T100  0.30% -2.10% 29.89%  
  5.24%
---
* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/bad-benchmark-results-for-php-master-2016-04-25/

Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at: 
https://01.org/lp/documentation/php-environment-setup.

Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload


Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Opcache::get($key), set($key, $value) to shared memory, is planned in PHP 7.1?

[Rowan Collins]

S.A.N wrote on 25/04/2016 15:09:

In userland  lacks the ability to store data in the shared memory
modules, do not use pecl modules, it would be very nice to have a
function:

opcache_get($key);
opcache_set($key, $value);

Is planned in PHP 7.1?



This was identified as a difference between APC and OpCache when the 
latter was added to core several releases ago, and that's exactly why 
APCu exists: http://php.net/apcu


There's not really a huge connection between opcode caching and 
optimization (OpCache) and shared memory data caches (APCu, memcached, 
etc), so I don't think there's any particular logic to calling such 
functions "opcache".


So I guess the question becomes: "should APCu be made part of core?" I'm 
not aware of anyone having proposed that, so don't know if there are 
strong feelings for or against such a thing.


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] PHP Attributes

[guilhermebla...@gmail.com]

Another thing that looks odd to me i that every time you call new
ReflectionClass, a new reflection_object gets created.
Isn't there a way to get this "cached" somehow in zend_class_entry?

On Mon, Apr 25, 2016 at 10:11 AM, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:

>
>
> On Mon, Apr 25, 2016 at 3:42 AM, Dmitry Stogov  wrote:
>
>>
>>
>> On 04/22/2016 06:39 PM, guilhermebla...@gmail.com wrote:
>>
>>
>> On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov  wrote:
>>
>>>
>>>
>>> On 04/22/2016 04:05 AM, 
>>> guilhermebla...@gmail.com wrote:
>>>
>>> Hi Dmitry,
>>>
>>> As a previous suggester of metadata information built-in into PHP, and
>>> also one of developers of the most used metadata library written in PHP, I
>>> understand this feature implementation requires several design decisions
>>> and also a good understanding of specific situations users may require.
>>>
>>> While I am a strong supporter of a more robust solution, this is already
>>> a good start.
>>> A few things I'd like to ask for my own understanding and also
>>> suggestions too:
>>>
>>> 1- I understand you took a minimalistic approach towards a "dumb"
>>> implementation for attributes (when I mean "dumb", the idea here is towards
>>> a non-OO approach). Can you explain your motivations towards this approach?
>>>
>>> I see two distinct approaches of implementation for this feature. Both
>>> of them have some common demands, like lazy initialization of metadata.
>>> Here they are:
>>>
>>> - Simplistic approach, which lets consumers of the feature do all the
>>> work related to validation, assertion of valid keys, values, etc
>>> This does not invalidate the ability to leverage of some features that a
>>> more robust implementation demands.
>>>
>>> - Robust approach: language takes the burden of instantiating complex
>>> structures, validating, assertion of valid keys, values, if this complex
>>> structure is allowed to be instantiated in that given class, method, etc.
>>>
>>>
>>> I didn't exactly understand what do you suggest.
>>> If you are talking about Attribute objects initialization during
>>> compilation - this is just not possible from implementation point of view.
>>> Now attributes may be stored in opcache SHM and relive request boundary.
>>> Objects can't relive requests.
>>>
>>
>>
>> I know that object instances are not cross-requests. Explicitly, I
>> mentioned that both approaches require lazy-initialization (which means,
>> whenever you call getAttributes() or getAttribute()).
>>
>> What I mentioning is that your approach is basically a new key/value
>> syntax that are used specifically for Attributes. We could easily turn this
>> into a more robust approach if instead of defining key/value pairs, we
>> instantiate objects or call functions. You already demonstrated interest to
>> support <> reusing the imports (which is our biggest headache
>> in Doctrine Annotations), so why not issue constructor or function calls
>> there? That would simplify the work needed for consumers and also add room
>> for later improvements.
>>
>> So basically in this example:
>>
>> use Doctrine\ORM;
>>
>> <>
>> class User {}
>>
>> $reflClass = new \ReflectionClass("User");
>> var_dump($reflClass->getAttributes());
>>
>> We'd be changing from this:
>>
>> array(1) {
>>   ["Doctrine\ORM\Entity"]=>
>>   array(1) {
>> [0]=>
>> string(4) "user"
>>   }
>> }
>>
>> Into this:
>>
>> array(1) {
>>   ["Doctrine\ORM\Entity"]=>
>>   object(Doctrine\ORM\Entity)#1 (1) {
>> ["tableName"]=>
>> string(4) "user"
>>   }
>> }
>>
>>
>> As I showed already, it's very easy to do this transformation at higher
>> layer.
>>
>> $reflClass = new \ReflectionClass("User");
>> $attributes = $reflClass->getAttributes()
>> foreach ($attributes as $key => &$val) {
>> $val = new $key(...$val);
>> }
>> var_dump($attributes);
>>
>> Construction objects directly in Reflection*::getAttributes() method,
>> doesn't make significant benefits and even makes limitation.
>>
>
> Sorry, but I don't see how limitations are added. If you call a function,
> static method or constructor, you actually add whole new level of
> possibilities, and I fail to see which limitations are added. Could you
> provide me one?
>
> Calling the function/constructor/static method, not only helps to better
> segregate userland code, but it also adds subsequents extensibility. I can
> highlight examples:
>
> - Support for Inheritance and overrides, through @Inherit, @Override, etc.
> While you might not see how it could be used now, other developers might be
> weirdly creative.
> - Targeting of annotations, such as limiting its scope to be only class,
> method or property. We use this extensively in Doctrine, where you cannot
> define Doctrine\ODM\Entity over a property.
> - Separating what can be considered as an annotation and what cannot.
> Built-in @Annotation as a marker would differentiate 

Re: [PHP-DEV] [RFC] PHP Attributes

[guilhermebla...@gmail.com]

On Mon, Apr 25, 2016 at 3:42 AM, Dmitry Stogov  wrote:

>
>
> On 04/22/2016 06:39 PM, guilhermebla...@gmail.com wrote:
>
>
> On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov  wrote:
>
>>
>>
>> On 04/22/2016 04:05 AM, 
>> guilhermebla...@gmail.com wrote:
>>
>> Hi Dmitry,
>>
>> As a previous suggester of metadata information built-in into PHP, and
>> also one of developers of the most used metadata library written in PHP, I
>> understand this feature implementation requires several design decisions
>> and also a good understanding of specific situations users may require.
>>
>> While I am a strong supporter of a more robust solution, this is already
>> a good start.
>> A few things I'd like to ask for my own understanding and also
>> suggestions too:
>>
>> 1- I understand you took a minimalistic approach towards a "dumb"
>> implementation for attributes (when I mean "dumb", the idea here is towards
>> a non-OO approach). Can you explain your motivations towards this approach?
>>
>> I see two distinct approaches of implementation for this feature. Both of
>> them have some common demands, like lazy initialization of metadata. Here
>> they are:
>>
>> - Simplistic approach, which lets consumers of the feature do all the
>> work related to validation, assertion of valid keys, values, etc
>> This does not invalidate the ability to leverage of some features that a
>> more robust implementation demands.
>>
>> - Robust approach: language takes the burden of instantiating complex
>> structures, validating, assertion of valid keys, values, if this complex
>> structure is allowed to be instantiated in that given class, method, etc.
>>
>>
>> I didn't exactly understand what do you suggest.
>> If you are talking about Attribute objects initialization during
>> compilation - this is just not possible from implementation point of view.
>> Now attributes may be stored in opcache SHM and relive request boundary.
>> Objects can't relive requests.
>>
>
>
> I know that object instances are not cross-requests. Explicitly, I
> mentioned that both approaches require lazy-initialization (which means,
> whenever you call getAttributes() or getAttribute()).
>
> What I mentioning is that your approach is basically a new key/value
> syntax that are used specifically for Attributes. We could easily turn this
> into a more robust approach if instead of defining key/value pairs, we
> instantiate objects or call functions. You already demonstrated interest to
> support <> reusing the imports (which is our biggest headache
> in Doctrine Annotations), so why not issue constructor or function calls
> there? That would simplify the work needed for consumers and also add room
> for later improvements.
>
> So basically in this example:
>
> use Doctrine\ORM;
>
> <>
> class User {}
>
> $reflClass = new \ReflectionClass("User");
> var_dump($reflClass->getAttributes());
>
> We'd be changing from this:
>
> array(1) {
>   ["Doctrine\ORM\Entity"]=>
>   array(1) {
> [0]=>
> string(4) "user"
>   }
> }
>
> Into this:
>
> array(1) {
>   ["Doctrine\ORM\Entity"]=>
>   object(Doctrine\ORM\Entity)#1 (1) {
> ["tableName"]=>
> string(4) "user"
>   }
> }
>
>
> As I showed already, it's very easy to do this transformation at higher
> layer.
>
> $reflClass = new \ReflectionClass("User");
> $attributes = $reflClass->getAttributes()
> foreach ($attributes as $key => &$val) {
> $val = new $key(...$val);
> }
> var_dump($attributes);
>
> Construction objects directly in Reflection*::getAttributes() method,
> doesn't make significant benefits and even makes limitation.
>

Sorry, but I don't see how limitations are added. If you call a function,
static method or constructor, you actually add whole new level of
possibilities, and I fail to see which limitations are added. Could you
provide me one?

Calling the function/constructor/static method, not only helps to better
segregate userland code, but it also adds subsequents extensibility. I can
highlight examples:

- Support for Inheritance and overrides, through @Inherit, @Override, etc.
While you might not see how it could be used now, other developers might be
weirdly creative.
- Targeting of annotations, such as limiting its scope to be only class,
method or property. We use this extensively in Doctrine, where you cannot
define Doctrine\ODM\Entity over a property.
- Separating what can be considered as an annotation and what cannot.
Built-in @Annotation as a marker would differentiate that I can do call
Doctrine\ORM\Entity and not Doctrine\ORM\UnitOfWork.
- Make it easier to support an AOP extension, where it could detect
annotations being used and override DO_FCALL to call before, after or
around through the implementation of interfaces.
- If we ever decide to support named parameters, taking advantage of that
would become natural, like: < "user")>>



>
>
>
>
>>
>> 1- Your approach is 

[PHP-DEV] Opcache::get($key), set($key, $value) to shared memory, is planned in PHP 7.1?

[S.A.N]

In userland  lacks the ability to store data in the shared memory
modules, do not use pecl modules, it would be very nice to have a
function:

opcache_get($key);
opcache_set($key, $value);

Is planned in PHP 7.1?

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] PHP Attributes

[Rowan Collins]

Dan Ackroyd wrote on 24/04/2016 21:45:

The point
I was trying to make is that it explicitly says that "this is a
userland attribute", rather than using the generic <<...>> syntax,
which we might want to use for non-userland attributes at some point.


I think framing the problem as "engine vs userland" is misleading; what 
you are actually saying is "how do we avoid name collisions?"


There's currently no difference in syntax between userland and engine 
functions and classes, and *that is a good thing*, because it means you 
can transparently apply polyfills, create C / Zephir extensions to 
replace performance-sensitive functions, etc. The same could be done for 
annotations - if it's possible to create a userland DBC library, then 
why shouldn't it be able to polyfill the same syntax as an engine one?


As mentioned elsewhere, in an OO implementation of annotations, the 
existing namespace hierarchy could be used (which includes the \php\ 
reservation, which we've never taken advantage of). If it's not, we are 
left with naming conventions.


I would suggest that even if we don't have objects representing the 
annotations, "\" should be allowed, and encouraged, in their names. 
Thus, *by convention*, attributes would be prefixed with at least a 
vendor name ("<>", etc).


PHP could reserve "__" and "php\" for future internal use, but also 
semi-reserve the global namespace, as described here: 
http://php.net/manual/en/userlandnaming.rules.php


> PHP owns the top-level namespace but tries to find decent descriptive 
names and avoid any obvious clashes.


If somebody creates a userland library that uses <>, 
it's up to them to deal with the consequences if PHP later implements an 
incompatible version, just as it would be if they wrote a function 
called dbc_require(), or DBC::require().


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/25/2016 02:28 PM, Joe Watkins wrote:

Morning internals,

This morning I attempted to prototype a dbc extension.

In my opinion, the patch, or internals, are not fit for the 
intended purpose.


At the moment, the *only* way to perform meta programming is going 
to be in userland. This is going to make it prohibitively slow, and 
rather pointless.


why? It's quite easy to use attributes in C extension.

if (op_array->attributes) {
zval *val = zend_hash_find_str(op_array->attributes, "requires", 
sizeof("requires")-1_;

if (val && Z_TYPE_P(val) == IS_ARRAY) {
  HashTable *ht = Z_ARRVAL_P(val);
  ZEND_HASH_FORECH_VAL(ht, val) {
...
  ZEND_HASH_FOREACH_END();
   }
}




None of the compiler API is exported: This means that AST is 
almost useless to internals unless it's a constant expression.

Do you mean C or PHP API?
What exactly do you like to be exported? zend_compile_expr()? It's not a 
problem to export it in 7.1.




There is a problem with zend extensions and fcall handlers, which 
we are not sure how to fix.


This is completely unrelated historical problem  :)


Working with AST is easy, working with opcodes directly is not.

Before we can have this, we must work on the AST API and allow 
extensions to transform AST with much better hooks than we have at the 
moment.
This is related to user extendable parser, that is definitely not a 
subject of this RFC.




I was excited to start working with this .. at the moment, I'm -1.


I got you.
Attributes are not especially for DbC and user extendable parser, and 
they are not a magic wand.

They may be an underlying layer for many things (including DbC).
But to reach what you want, you'll have to start from something anyway.

Thanks. Dmitry.


Cheers
Joe

PS. If anyone is interested http://github.com/krakjoe/dbc was my first 
attempt at interacting with the patch.





On Mon, Apr 25, 2016 at 11:08 AM, Dmitry Stogov > wrote:




On 04/25/2016 12:44 PM, Pierre Joye wrote:

hi Dmitry,

Awesome work! Thanks.

I do like you keep what was discussed last time. Make the basics
available and leave the rest to the applications (doctrine or
other).

I feel too that how the apps will interact with may need some more
discussions but other commented on it so I won't interfer here :).

I've collected the most interesting feedback at
https://wiki.php.net/rfc/attributes#open_issues
And I'm going to correct RFC and implementation rethinking these
questions.

Thanks. Dmitry.



On Mon, Apr 25, 2016 at 3:17 PM, Dmitry Stogov
> wrote:

The proposed by you "@..." syntax just won't fit into PHP
grammar, because @
used as silence operator.

Attribute, syntax is taken from HHVM. I don't see a big
reason to introduce
more fragmentation into PHP world.

Also see https://docs.hhvm.com/hack/attributes/syntax and I fully
agree with Dmitry here. It makes no sense now to go with our own
syntax.

If any of the hhvm developers are around, we may get some
feedbacks
about their current APIs (using getAttributes) and if they
would like
to change one thing or another. That could (or must) part of
the PHP
specifications.

Cheers,



-- 
PHP Internals - PHP Runtime Development Mailing List

To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] PHP Attributes

[Lester Caine]

On 25/04/16 09:42, Dmitry Stogov wrote:
> I know, any syntax is going to be loved by ones and hated by others...
> It's not possible to satisfy everyone.

If one takes a step back, current well used annotation IS provided but
not cleanly documented in the docbloc material that is a major element
of legacy code. There is clearly a case for improving the usage of this
style of working, and adding 'attributes' to the rest of the rest of
this annotation seems to me to be the best way forward for a STOCK PHP
install. Every current IDE I've seen will correctly display docbloc
annotation and has the option to disable tags in that code if required.

I'm looking at the > then imples that 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: ext/curl update

[Leigh]

On Sun, 24 Apr 2016 at 01:25 Davey Shafik  wrote:

> Hi Pierrick,
>
> This should be in master for 7.1, alongside my RFC'ed patch for server push
> support.


I don't see why the additional constants that don't have a direct
dependency on your server push patch can't be committed to 7.0 as well. The
patch is pretty non-invasive.

The patch should hit in 7.1 but it has been requested that tests be added —
> and we can't add tests with a server push supporting HTTP/2 server against
> which to push.
>

The only new logic seems to be around CURLMOPT_PIPELINING_*_BL
and CURLOPT_STREAM_DEPENDS(_E). I don't know what these do, are they
related to server push? Is it possible to add deterministic tests for them?

Maybe in 7.1 we could bump the minimum version of cURL required too. #ifdef
version checks going back over 12 years seems unnecessary :)

Fwd: [PHP-DEV] [RFC] PHP Attributes

[Joe Watkins]

Forwarded, sorry for top post :(

-- Forwarded message --
From: Joe Watkins 
Date: Mon, Apr 25, 2016 at 12:28 PM
Subject: Re: [PHP-DEV] [RFC] PHP Attributes
To: Dmitry Stogov 
Cc: Pierre Joye , PHP internals <
internals@lists.php.net>, Benjamin Eberlei , Sara
Golemon 


Morning internals,

This morning I attempted to prototype a dbc extension.

In my opinion, the patch, or internals, are not fit for the intended
purpose.

At the moment, the *only* way to perform meta programming is going to
be in userland. This is going to make it prohibitively slow, and rather
pointless.

None of the compiler API is exported: This means that AST is almost
useless to internals unless it's a constant expression.

There is a problem with zend extensions and fcall handlers, which we
are not sure how to fix.

Working with AST is easy, working with opcodes directly is not.

Before we can have this, we must work on the AST API and allow
extensions to transform AST with much better hooks than we have at the
moment.

I was excited to start working with this .. at the moment, I'm -1.

Cheers
Joe

PS. If anyone is interested http://github.com/krakjoe/dbc was my first
attempt at interacting with the patch.




On Mon, Apr 25, 2016 at 11:08 AM, Dmitry Stogov  wrote:

>
>
> On 04/25/2016 12:44 PM, Pierre Joye wrote:
>
>> hi Dmitry,
>>
>> Awesome work! Thanks.
>>
>> I do like you keep what was discussed last time. Make the basics
>> available and leave the rest to the applications (doctrine or other).
>>
>> I feel too that how the apps will interact with may need some more
>> discussions but other commented on it so I won't interfer here :).
>>
> I've collected the most interesting feedback at
> https://wiki.php.net/rfc/attributes#open_issues
> And I'm going to correct RFC and implementation rethinking these questions.
>
> Thanks. Dmitry.
>
>
>>
>> On Mon, Apr 25, 2016 at 3:17 PM, Dmitry Stogov  wrote:
>>
>>> The proposed by you "@..." syntax just won't fit into PHP grammar,
>>> because @
>>> used as silence operator.
>>>
>>> Attribute, syntax is taken from HHVM. I don't see a big reason to
>>> introduce
>>> more fragmentation into PHP world.
>>>
>> Also see https://docs.hhvm.com/hack/attributes/syntax and I fully
>> agree with Dmitry here. It makes no sense now to go with our own
>> syntax.
>>
>> If any of the hhvm developers are around, we may get some feedbacks
>> about their current APIs (using getAttributes) and if they would like
>> to change one thing or another. That could (or must) part of the PHP
>> specifications.
>>
>> Cheers,
>>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] PHP Attributes

[Joe Watkins]

Morning internals,

This morning I attempted to prototype a dbc extension.

In my opinion, the patch, or internals, are not fit for the intended
purpose.

At the moment, the *only* way to perform meta programming is going to
be in userland. This is going to make it prohibitively slow, and rather
pointless.

None of the compiler API is exported: This means that AST is almost
useless to internals unless it's a constant expression.

There is a problem with zend extensions and fcall handlers, which we
are not sure how to fix.

Working with AST is easy, working with opcodes directly is not.

Before we can have this, we must work on the AST API and allow
extensions to transform AST with much better hooks than we have at the
moment.

I was excited to start working with this .. at the moment, I'm -1.

Cheers
Joe

PS. If anyone is interested http://github.com/krakjoe/dbc was my first
attempt at interacting with the patch.




On Mon, Apr 25, 2016 at 11:08 AM, Dmitry Stogov  wrote:

>
>
> On 04/25/2016 12:44 PM, Pierre Joye wrote:
>
>> hi Dmitry,
>>
>> Awesome work! Thanks.
>>
>> I do like you keep what was discussed last time. Make the basics
>> available and leave the rest to the applications (doctrine or other).
>>
>> I feel too that how the apps will interact with may need some more
>> discussions but other commented on it so I won't interfer here :).
>>
> I've collected the most interesting feedback at
> https://wiki.php.net/rfc/attributes#open_issues
> And I'm going to correct RFC and implementation rethinking these questions.
>
> Thanks. Dmitry.
>
>
>>
>> On Mon, Apr 25, 2016 at 3:17 PM, Dmitry Stogov  wrote:
>>
>>> The proposed by you "@..." syntax just won't fit into PHP grammar,
>>> because @
>>> used as silence operator.
>>>
>>> Attribute, syntax is taken from HHVM. I don't see a big reason to
>>> introduce
>>> more fragmentation into PHP world.
>>>
>> Also see https://docs.hhvm.com/hack/attributes/syntax and I fully
>> agree with Dmitry here. It makes no sense now to go with our own
>> syntax.
>>
>> If any of the hhvm developers are around, we may get some feedbacks
>> about their current APIs (using getAttributes) and if they would like
>> to change one thing or another. That could (or must) part of the PHP
>> specifications.
>>
>> Cheers,
>>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/25/2016 12:44 PM, Pierre Joye wrote:

hi Dmitry,

Awesome work! Thanks.

I do like you keep what was discussed last time. Make the basics
available and leave the rest to the applications (doctrine or other).

I feel too that how the apps will interact with may need some more
discussions but other commented on it so I won't interfer here :).
I've collected the most interesting feedback at 
https://wiki.php.net/rfc/attributes#open_issues

And I'm going to correct RFC and implementation rethinking these questions.

Thanks. Dmitry.




On Mon, Apr 25, 2016 at 3:17 PM, Dmitry Stogov  wrote:

The proposed by you "@..." syntax just won't fit into PHP grammar, because @
used as silence operator.

Attribute, syntax is taken from HHVM. I don't see a big reason to introduce
more fragmentation into PHP world.

Also see https://docs.hhvm.com/hack/attributes/syntax and I fully
agree with Dmitry here. It makes no sense now to go with our own
syntax.

If any of the hhvm developers are around, we may get some feedbacks
about their current APIs (using getAttributes) and if they would like
to change one thing or another. That could (or must) part of the PHP
specifications.

Cheers,



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

[Rowan Collins]

Patrick ALLAERT wrote on 24/04/2016 14:18:

There is just nothing more repeatable or common cases than "resource not
found", "method not allowed", "access denied",... They are all non
exceptional cases better handled without exceptions and with clean APIs
reflecting the business logic of the application.


I think part of the problem may be that non-trivial examples require 
rather a lot of context. An example that comes to my mind is if an 
application is combining a bunch of different libraries, and calling 
them all in sequence:


try
{
$fooService->doStuff($data);
$barService->doMoreStuff($data);
$bazService->doDifferentStuff($data);
}
catch ( FooException | BarException | BazException $e )
{
// We don't care which library threw the exception, the action is always 
the same
throw new AppException($e); // Hide which libraries we're using to 
implement the function

}

Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] PHP Attributes

[Pierre Joye]

hi Dmitry,

Awesome work! Thanks.

I do like you keep what was discussed last time. Make the basics
available and leave the rest to the applications (doctrine or other).

I feel too that how the apps will interact with may need some more
discussions but other commented on it so I won't interfer here :).


On Mon, Apr 25, 2016 at 3:17 PM, Dmitry Stogov  wrote:
> The proposed by you "@..." syntax just won't fit into PHP grammar, because @
> used as silence operator.
>
> Attribute, syntax is taken from HHVM. I don't see a big reason to introduce
> more fragmentation into PHP world.

Also see https://docs.hhvm.com/hack/attributes/syntax and I fully
agree with Dmitry here. It makes no sense now to go with our own
syntax.

If any of the hhvm developers are around, we may get some feedbacks
about their current APIs (using getAttributes) and if they would like
to change one thing or another. That could (or must) part of the PHP
specifications.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/24/2016 02:09 AM, Thomas Bley wrote:

The <<>> syntax comes with the problem that previous versions cannot ignore it 
on parsing.
So poeple write new frameworks for 7.0 which cannot be parsed in 5.x, then they 
write new frameworks for 7.1 which cannot be parsed with 7.0 and 5.x and so on.
For companies staying on Linux distributions with long term support on 7.0, 
this is rather a nightmare for both users and framework maintainers.
When choosing <<>> or any other non-backward compatible syntax for 7.1, there 
should be a patch for 7.0 to ignore the new syntax without parse errors.
Good point, but any syntax proposed for native attributes would break 
forward-compatibility as well.

The only choice to stay with doc-comments and do all the work at user level.

Thanks. Dmitry.



Regards
Thomas

Fleshgrinder wrote on 23.04.2016 17:29:


+1 for the basic idea, however, I have various remarks.

The RFC text is hard to read and contains many grammatical mistakes. How
could one help you here?

I think that the Hack name attributes is unintelligible and annotations
would be much clearer to any audience. Simply because the name is very
well known.

I do not see the need for multi-annotation nor multi-value support. It
just creates multiple ways to achieve the exact same thing for no good
reason.

I do not like the <<>> syntax. It requires many key strokes, is hard to
read, and looks ugly. Why not simply @ and be done with it. I am not so
sure about the bracket requirement, is it somehow required for the
parsing? Otherwise I would leave it off. I guess it might be hard to
find the end of an annotation but have you considered to use the
semicolon for that? Would align nicely with existing PHP syntax. The
following would be the ABNF for my proposal:

ANNOTATION= "@" NAME [ " " VALUE ]
NAME  = STRING
VALUE = QUOTED-STRING / PHP-CONSTANT / EXPRESSION
QUOTED-STRING = ( "'" / DQUOTE ) STRING ( "'" / DQUOTE )
EXPRESSION= PHP-CODE ";"

A semicolon would only be required if it is not a single quoted string
(see following example) or constant. A question that I see unanswered is
how embedding of variables in quoted strings should be dealt with. I see
no need for this but people might assume it is supported because PHP
supports it everywhere else.

"
class A {}

<")>>
class B {}

?>

Requiring PHP code to be terminated with a semicolon should also ensure
that people do not start to write fully-fledged programs in annotations.
Since that is not what they are intended for. An alternative approach I
see here would be to go for the brackets but then again only for PHP code:

EXPRESSION = "(" PHP-CODE ")"

Then again, it looks similar to a function call and this is imho not
good. Unless of course new annotations can be defined as special
functions directly in userland, e.g. with an `annotation function`
and/or `annotation class`. However, this would require more thought.

Another question that is unanswered for me is: how to go about adding
annotations to a complete file as is currently possible with PhpDoc and
its file-level doc block:

'
@copyright '2016 Richard Fussenegger'
@license 'MIT'

declare(strict_types=1);

namespace Fleshgrinder\PhpInternals;

@description 'True annotation support could be a very good thing.'
@invariant $this->balance >= self::MIN_BALANCE;
class Account {

  private const int MIN_BALANCE = 0;

  private int $balance;

  private Person $owner;

  @require $sum >= 0;
  @ensure $this->balance === (old::$balance + $sum);
  public function deposit(int $sum): void {
$this->balance += $sum;
  }

  @require $sum >= 0;
  @require $sum <= $this->balance - self::MIN_BALANCE;
  @ensure $this->balance === (old::$balance - $sum);
  public function withdraw(int $sum): void {
$this->balance -= $sum;
  }

  @deprecated 'for various reasons'
  public function setOwner(Person $wner): void {
$this->owner = $owner;
  }

}

@inheritDoc
class OverdraftAccount extends Account {

  private const int MIN_BALANCE = -1000;

}

?>

We also need to make sure to add something regarding coding standards
for annotation names. I would propose to go for camelCase (same as for
method names) since this is what PhpDoc used to use for many years now.

We also need to define how people can avoid to collide with internal
annotations. The typical double-underscore prefix approach that we have
for magic methods creates a lot of visual clutter and looks weird if
spread among all kinds of places. A namespace approach as we have it
already for userland code could help here.

 'user',
  'unique_constraints' => [
'name' => 'user_unique',
'columns' => [ 'username' ],
  ],
  'indexes' => [
'name' => 'user_idx',
'clumns' => [ 'email' ],
  ],
  'schema' => 'schema_name',
];
class User {}

?>

--
Richard "Fleshgrinder" Fussenegger





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/25/2016 06:23 AM, Stanislav Malyshev wrote:

Hi!


https://wiki.php.net/rfc/attributes

I've read the proposal and I like the idea of reviving the attributes
idea and the simplicity of the approach.

I have the following questions for it:

- Namespacing. Since the attribute names are not processed in any way
according to spec, it may be rather hard to ensure attribute
requirements from different domains do not conflict, and we do not get
into the same problem we've got into with class names before we
implemented namespaces. How it is planned to address the issue?


I'm going to extend RFC with namespace support.
Attribute name is going to be qualified string.


- The expressions support is nice, however I'm not sure I understand
what PHP application is supposed to do with syntax trees? I.e. taking
the example in the RFC, if I got AST\Node representing <
0)>>, how do I use it? Would I implement mini-PHP-engine in PHP to
evaluate such an expression? Am I supposed to use some other
functionality to do it? It is unclear.
I don't think promoting reimplementing PHP expressions in a myriad of
different ways (which all would be subtly different and distinct from
how PHP understands such expressions) is not good, and if we expose
those trees we should also provide means to work with them. Otherwise
any advanced usage of the feature would mean basically reimplementing
PHP engine in PHP.

AST is going to be processed and evaluated using php-ast extension.
Nikita was going to propose including it into core distribution.

As a side note, my personal opinion is that for about 90% of use cases
expressions are not needed. For 90% of those which are needed, string +
some form of eval would cover it's use case since all the'd be doing is
evaluating the expression and checking the resulting value.


This is a question. We may use AST expression or just strings.
In second case we miss syntax verification at compile time.
I'm going to describe the problem in RFC and set an additional voting 
question.


- As far as I can see, AST extension has no documentation except for
initial README. If it is going to end up in core, this needs to be
fixed. Preferably before it is merged into core.

- I would also consider moving AST namespace under \PHP since we have
this one reserved (unlike \AST which we did not reserve).

For me AST is the best choice here.



- Are attributes also allowed to apply to anonymous classes/functions?
Would the syntax still work in that case?


No. At least now.


_ I also think <<...>> syntax is ugly and @attribute syntax would be
much better (and also is used in Java attributes and Python decorators).
That's my personal opinion though.


@ is reserved for silence operator.

Thanks. Dmitry.


Thanks,



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] PHP Attributes

[Niklas Keller]

>
> I think that the Hack name attributes is unintelligible and annotations
>> would be much clearer to any audience. Simply because the name is very
>> well known.
>>
>
> Different languages names this differently.
> I may add an additional voting question - "annotation vs attributes?".


The description on https://wiki.php.net/rfc even uses "annotation" to
explain what "PHP Attributes" is,
so I think "annotation"is the right naming choice.

PHP Attributes
> Native support for annotation (Discussion began 2016-04-22)


Annotation is well known and unambiguous.

Regards, Niklas.

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/24/2016 07:57 PM, Levi Morrison wrote:

On Sun, Apr 24, 2016 at 10:03 AM, Dan Ackroyd  wrote:

On 21 April 2016 at 22:13, Dmitry Stogov  wrote:

Hi,


I would like to present an RFC proposing support for native annotation.


Hi Dmitry,

Although everyone will have an opinion about the syntax, I think there
is one criticism that should be thought about; the chosen syntax isn't
future expandable to other concerns.

People have talked about "design by contract" RFCs where annotation
like data is readable by the engine. The current proposed syntax
_could_ be used to store DBC data, but it would not be clear what
would be annotation data to read by the application, and what was DBC
data to be read by the engine.

Changing the proposed syntax to be something like @attr(...) would
allow it to be expanded in the future by adding a @contract(...)
construct:

@attr(test($a + $b > 0))   // This is attribute data read by userland code
@contract(require($a + $b > 0, 'InvalidFooArgsException'))  // This is
DBC data read by the engine.
function foo($a, $b) {
 ...
}

Making features be compatible with future features would avoid a lot
of potential pain down the road.

Genuine question[1]: how is @attr() different than `<>`? Also,
isn't `@attr()` 100% valid user-land code today that can precede
function or constant declarations?

@attr() - is a valid "silenced" call to function named "attr".
This syntax can't be reused.

Thanks. Dmitry.




   [1] I don't like that I have to make that explicit but it is what it is.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/24/2016 07:03 PM, Dan Ackroyd wrote:

On 21 April 2016 at 22:13, Dmitry Stogov  wrote:

Hi,


I would like to present an RFC proposing support for native annotation.


Hi Dmitry,

Although everyone will have an opinion about the syntax, I think there
is one criticism that should be thought about; the chosen syntax isn't
future expandable to other concerns.

People have talked about "design by contract" RFCs where annotation
like data is readable by the engine. The current proposed syntax
_could_ be used to store DBC data, but it would not be clear what
would be annotation data to read by the application, and what was DBC
data to be read by the engine.

Changing the proposed syntax to be something like @attr(...) would
allow it to be expanded in the future by adding a @contract(...)
construct:

@attr(test($a + $b > 0))   // This is attribute data read by userland code
@contract(require($a + $b > 0, 'InvalidFooArgsException'))  // This is
DBC data read by the engine.
function foo($a, $b) {
 ...
}

Making features be compatible with future features would avoid a lot
of potential pain down the road.

cheers
Dan

"@..." syntax can't work. @ - is a silence operator.

< 0, 'InvalidFooArgsException')>> - this is 
not really worse than your example.


I know, any syntax is going to be loved by ones and hated by others...
It's not possible to satisfy everyone.

Thanks. Dmitry.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/24/2016 12:34 AM, Yasuo Ohgaki wrote:

Hi Dimitry,

On Fri, Apr 22, 2016 at 6:13 AM, Dmitry Stogov  wrote:

I would like to present an RFC proposing support for native annotation.

The naming, syntax and behavior are mostly influenced by HHVM Hack, but not 
exactly the same.

The most interesting difference is an ability to use arbitrary PHP expressions 
as attribute values.

These expressions are not evaluated, but stored as Abstract Syntax Trees, and later may 
be accessed (node by node) in PHP extensions, preprocessors and PHP scripts their selves. 
I think this ability may be useful for "Design By Contract", other formal 
verification systems, Aspect Oriented Programming, etc


https://wiki.php.net/rfc/attributes


Note that this approach is going to be native, in contrast to doc-comment 
approach that uses not well defined syntax, and even not parsed by PHP itself.


Additional ideas, endorsement and criticism are welcome.

Nice RFC!
Attributes are always evaluated, right? i.e. No INI switch nor declare
to control behavior.
Just making sure.

Attributes are always parsed together with PHP script and stored internally.
Then you may access them through Reflection*::getAttributes() or in C 
extensions through native API.


AST in attribute values is not evaluated.

Thanks. Dmitry.



Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/23/2016 06:29 PM, Fleshgrinder wrote:

+1 for the basic idea, however, I have various remarks.

The RFC text is hard to read and contains many grammatical mistakes. How
could one help you here?

I would need a co-author :)



I think that the Hack name attributes is unintelligible and annotations
would be much clearer to any audience. Simply because the name is very
well known.


Different languages names this differently.
I may add an additional voting question - "annotation vs attributes?".



I do not see the need for multi-annotation nor multi-value support. It
just creates multiple ways to achieve the exact same thing for no good
reason.

completely disagree.
Each value in multi-value attribute may have its own meaning. e.g. 
<>




I do not like the <<>> syntax. It requires many key strokes, is hard to
read, and looks ugly. Why not simply @ and be done with it. I am not so
sure about the bracket requirement, is it somehow required for the
parsing? Otherwise I would leave it off. I guess it might be hard to
find the end of an annotation but have you considered to use the
semicolon for that? Would align nicely with existing PHP syntax. The
following would be the ABNF for my proposal:

ANNOTATION= "@" NAME [ " " VALUE ]
NAME  = STRING
VALUE = QUOTED-STRING / PHP-CONSTANT / EXPRESSION
QUOTED-STRING = ( "'" / DQUOTE ) STRING ( "'" / DQUOTE )
EXPRESSION= PHP-CODE ";"

A semicolon would only be required if it is not a single quoted string
(see following example) or constant. A question that I see unanswered is
how embedding of variables in quoted strings should be dealt with. I see
no need for this but people might assume it is supported because PHP
supports it everywhere else.

"
class A {}

<")>>
class B {}

?>

Requiring PHP code to be terminated with a semicolon should also ensure
that people do not start to write fully-fledged programs in annotations.
Since that is not what they are intended for. An alternative approach I
see here would be to go for the brackets but then again only for PHP code:

EXPRESSION = "(" PHP-CODE ")"

Then again, it looks similar to a function call and this is imho not
good. Unless of course new annotations can be defined as special
functions directly in userland, e.g. with an `annotation function`
and/or `annotation class`. However, this would require more thought.

Another question that is unanswered for me is: how to go about adding
annotations to a complete file as is currently possible with PhpDoc and
its file-level doc block:

'
@copyright '2016 Richard Fussenegger'
@license 'MIT'

declare(strict_types=1);

namespace Fleshgrinder\PhpInternals;

@description 'True annotation support could be a very good thing.'
@invariant $this->balance >= self::MIN_BALANCE;
class Account {

   private const int MIN_BALANCE = 0;

   private int $balance;

   private Person $owner;

   @require $sum >= 0;
   @ensure $this->balance === (old::$balance + $sum);
   public function deposit(int $sum): void {
 $this->balance += $sum;
   }

   @require $sum >= 0;
   @require $sum <= $this->balance - self::MIN_BALANCE;
   @ensure $this->balance === (old::$balance - $sum);
   public function withdraw(int $sum): void {
 $this->balance -= $sum;
   }

   @deprecated 'for various reasons'
   public function setOwner(Person $wner): void {
 $this->owner = $owner;
   }

}

@inheritDoc
class OverdraftAccount extends Account {

   private const int MIN_BALANCE = -1000;

}

?>

You should try to implement this syntax to understand the problem.
It leads to parse conflicts.


We also need to make sure to add something regarding coding standards
for annotation names. I would propose to go for camelCase (same as for
method names) since this is what PhpDoc used to use for many years now.


This RFC is not going to propose coding standards.


We also need to define how people can avoid to collide with internal
annotations. The typical double-underscore prefix approach that we have
for magic methods creates a lot of visual clutter and looks weird if
spread among all kinds of places. A namespace approach as we have it
already for userland code could help here.

 'user',
   'unique_constraints' => [
 'name' => 'user_unique',
 'columns' => [ 'username' ],
   ],
   'indexes' => [
 'name' => 'user_idx',
 'clumns' => [ 'email' ],
   ],
   'schema' => 'schema_name',
];
class User {}

?>


Agree. Namespaces looks better than "__" prefixes.

Thanks. Dmitry.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/24/2016 05:02 PM, Thomas Punt wrote:

Hi!


From: dmi...@zend.com

On 04/22/2016 02:46 PM, Thomas Punt wrote:
Hi Dmitry!

Just a couple of comments on this:

1. I'd definitely reuse the php-ast extension for parsing the code into an
AST. It performs a number of transformations on PHP's underlying AST
that make it much nicer to use (namely better consistency). It is also
less fragile by having the abstraction between PHP's internal AST and
the AST that is exposed to userland (enabling for internal AST changes
without impacting the AST exposed to userland).

I'm not sure. Both approaches make sense.

Whilst fragility is a concern, a bigger problem with not reusing
ast\parse_code() is that the AST produced will be different in even the
simplest of cases. For example, take the following simple expression:

$a> 2

With your attributes branch, this will produce an AST of:

object(ast\Node)#2 (4) {
 ["kind"]=> int(521) // ZEND_AST_GREATER
 ["flags"]=> int(0)
 ["lineno"]=> int(1)
 ["children"]=> [...]
}

Whereas with ast\parse_code(), the following AST will be produced:

object(ast\Node)#2 (4) {
 ["kind"]=> int(520) // AST_BINARY_OP
 ["flags"]=> int(256) // BINARY_IS_GREATER
 ["lineno"]=> int(1)
 ["children"]=> [...]
}

The php-ast extension transforms the special node types for>,>=, <, <=
into AST_BINARY_OP nodes with different flags set. This is just one
difference of many between the internal AST and the AST produced by
the php-ast extension.


This is initial implementation details, and they are going to be fixed.
If we decide to use AST in attributes, getAttributes() outout are going 
to be 100% compatible with php-ast.





2. You mentioned about moving some of the php-ast extension into core.
I wonder if it would be better to just move the whole extension into the
core first, and then enable this functionality if the php-ast extension is
enabled.

Even if we move php-ast into core (I think we will do it), it's going to
be optional.
However attributes should always work.

If we're going to reuse ast\parse_code(), then we will need the whole php-ast
extension in the core. It could therefore be made similar to the pcre, date,
Reflection, SPL, etc extensions, where it cannot be disabled.


Right,  but this is out of scope of this RFC.
Nikita was going to propose moving php-ast into core soon.

Thanks. Dmitry.




Also, slightly tangential, but the RFC says attributes are supported on
class constants, yet doc comments (IIRC) are not. I wonder if support
for doc comments should be added for class constants?

it is already implemented.

Oh right, my mistake. It does not seem to be exposed through php-ast or
reflection then.


Thanks. Dmitry.

Thanks,
Tom

-Tom



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/24/2016 03:33 PM, Fleshgrinder wrote:

I am not arguing against the RFC nor the feature itself, on the
contrary, I like it. I just do not like certain aspects and design
decisions of it; that is all.

Configuration and AOP are the best usecases for annotations and those
should be stressed in the RFC. They are not mentioned at all!

Another usecase that I am missing completely is the usage of it for
documentation and static code analysis. I already mentioned the /throws/
annotation, this could help e.g. IDEs to warn you better about uncatched
exceptions form methods you call.

DbC is a possible usecase but better implemented at language level. The
RFC could mention the possibility of it. However, right now it is the
sole usecase beside the not very PHP applicable `<>` and
`<>` examples.

You see, this is more a problem of the RFC text and not of the feature. ;)

Another think I complained about is the proposed syntax because it makes
annotations look like function calls, which they simply are not and will
not be. The syntax is misleading and a possible built-in functionality
of reactive annotations (not saying we need them) at the language level
for userland is blocked. I know I just repeated myself.

The extension you mentioned works just fine without the brackets.

   @invariant CONDITION;
   class A {

 @ensure CONDITION;
 @require CONDITION;
 function f(){}

   }

The proposed by you "@..." syntax just won't fit into PHP grammar, 
because @ used as silence operator.


Attribute, syntax is taken from HHVM. I don't see a big reason to 
introduce more fragmentation into PHP world.


Personally I don't see "foo(a,b,c)" as a function, I see this as a 
predicate.


It's possible to extend RFC with additional use-cases, but the longer 
the RFC the less people read it.


Thanks. Dmitry.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/24/2016 11:24 AM, Fleshgrinder wrote:

The invariant could also be added as an additional branch to the class
instead of a method, since it would not work like a method.

   class A {} invariant {}

   function f() {} require {} ensure {}

This would also align nicely with closures and anonymous classes, which
is kind a problematic with annotations.

   $A = new class {} invariant {};

   $f = function () {} require {} ensure {};

The only thing that remains that might be of interest to both is
`@throws` but that was not discussed at all as of yet.

   use Ns\SomeException;

   @throws SomeException
   function f() {

   }

This is at least how one would expect it to work and it is something
that should be covered by annotations and not as part of the language.
The ABNF should account for that:

ANNOTATION= "@" NAME [ " " VALUE ]
NAME  = STRING
VALUE = QUOTED-STRING / PHP-REFERENCE / EXPRESSION
QUOTED-STRING = ( "'" / DQUOTE ) STRING ( "'" / DQUOTE )
EXPRESSION= PHP-CODE ";"

Where PHP references are any of the already possible ones:

   use F\Q\C\N;

   @annotation \F\Q\C\N
   @annotation N
   @annotation \F\Q\C\N::CONSTANT
   @annotation N::CONSTANT
   @annotation \F\Q\C\N::function()
   @annotation N::function()
   @annotation \F\Q\C\N::$variable
   @annotation N::$variable

I also though some more about function support for annotations and this
would actually be a nice thing for userland.

   annotation deprecated(Reflection $element, string $message = '') {
 @trigger_error($message, E_USER_DEPRECATED);
   }

   @deprecated('because')
   function x() {}

   @deprecated
   function y() {}

This would allow users to implement simple and easy reactive annotations
in userland. Even if this could or should be an extension of the feature
in the future, it should be thought about know. Simply because the
brackets make sense if such a feature is to be implemented. ;)

Looks interesting, but try to think where the "annotation deprecated" 
should be declared,to be visible in every compiled script, when the 
corresponding code should be called (in what context), what if we need 
to do something at compile-time? Single answers to these question are 
going to be great for "deprecated" use case, however they will limit 
usability for other cases.


Thanks. Dmitry.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/22/2016 06:56 PM, Larry Garfield wrote:

On 4/22/16 10:39 AM, guilhermebla...@gmail.com wrote:

On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov  wrote:




3- Did you put any thought on inheritance? What I mentioned in 
comment #1

is even smaller than what you implemented in RFC.
Assuming you keep the RFC approach, did you consider support overrides,
inherit, etc?


In my opinion, attributes don't have to be inherited.
If you think differently - please explain your point.


Of source I can.
A simple case would be to increate visibility of the inherited 
property. It
was declared in a parent class as protected, but now you want public, 
and

you still want to keep all parent defined Attributes.
Another example is like we do in Doctrine. We support a callback system
which we named as lifetime callbacks. Pre-persist is one of them, 
which is

called every time a given Entity is about to be persisted into DB. When
you're dealing with inheritance, you can potentially override the method
content and you still want to trigger the same operation as if it was
untouched. Example:

use Doctrine\ORM;

trait Timestampable {
 protected $created;
 protected $updated;

 <>
 public function prePersist() {
 $this->created = $this->updated = new \DateTime("now");
 }

 <>
 public function preUpdate() {
 $this->updated = new \DateTime("now");
 }
}

<>
class User {
 use Timestampable;

 public function prePersist() {
 // Add my custom logic
 }
}

The implication is that through a simplistic approach, inheriting (or
overriding) is not clear and I can't figure it out an easy way to 
achieve

that.
Now if we go towards calling a function or class constructor like I
mentioned before, then we could easily build structures like __Inherit,
__Override, etc.



Here's another example from a Doctrine-using project I built a while 
back.  (Not the exact code, but the same concept; I've adapted it to 
PHP 7 types as well):


interface Ownable {
  public function getOwner() : string;
  public function setOwner(string $u);
  public function isUnowned() : bool;
}

trait OwnableTrait {

  /** @ORM\String **/
  private $owner = '';

  public getOwner() : string {
return $this->owner;
  }

  public setOwner(string $u) {
$this->owner = $owner;
  }

  public function isUnowned() : bool {
return $this->owner == '';
  }
}

/** @ORM\Entity */
class Product implements Ownable {
  use OwnableTrait;

  // ...
}

class Widget extends Product {
// ...
}

For annotations to work for this use case, reflecting on the 
properties of Widget would need to include $owner, and it would need 
to include the ORM\String annotation.  (True regardless of whether 
annotations are array or object based.)


In your example you don't override the property, so you'll able to see 
attributes of your property.


>
protected $x;
}
class Foo {
use T;
}
$r = new ReflectionClass("Foo");
$prop = $r->getProperty("x");
var_dump($prop->getAttributes());
?>

$ sapi/cli/php attr7.php
array(1) {
  ["test"]=>
  bool(true)
}

Works fine.

Thanks. Dmitry.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/22/2016 06:39 PM, guilhermebla...@gmail.com wrote:


On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov > wrote:




On 04/22/2016 04:05 AM, guilhermebla...@gmail.com
 wrote:

Hi Dmitry,

As a previous suggester of metadata information built-in into
PHP, and also one of developers of the most used metadata library
written in PHP, I understand this feature implementation requires
several design decisions and also a good understanding of
specific situations users may require.

While I am a strong supporter of a more robust solution, this is
already a good start.
A few things I'd like to ask for my own understanding and also
suggestions too:

1- I understand you took a minimalistic approach towards a "dumb"
implementation for attributes (when I mean "dumb", the idea here
is towards a non-OO approach). Can you explain your motivations
towards this approach?

I see two distinct approaches of implementation for this feature.
Both of them have some common demands, like lazy initialization
of metadata. Here they are:

- Simplistic approach, which lets consumers of the feature do all
the work related to validation, assertion of valid keys, values, etc
This does not invalidate the ability to leverage of some features
that a more robust implementation demands.

- Robust approach: language takes the burden of instantiating
complex structures, validating, assertion of valid keys, values,
if this complex structure is allowed to be instantiated in that
given class, method, etc.


I didn't exactly understand what do you suggest.
If you are talking about Attribute objects initialization during
compilation - this is just not possible from implementation point
of view.
Now attributes may be stored in opcache SHM and relive request
boundary.
Objects can't relive requests.



I know that object instances are not cross-requests. Explicitly, I 
mentioned that both approaches require lazy-initialization (which 
means, whenever you call getAttributes() or getAttribute()).


What I mentioning is that your approach is basically a new key/value 
syntax that are used specifically for Attributes. We could easily turn 
this into a more robust approach if instead of defining key/value 
pairs, we instantiate objects or call functions. You already 
demonstrated interest to support <> reusing the imports 
(which is our biggest headache in Doctrine Annotations), so why not 
issue constructor or function calls there? That would simplify the 
work needed for consumers and also add room for later improvements.

So basically in this example:

use Doctrine\ORM;

<>
class User {}

$reflClass = new \ReflectionClass("User");
var_dump($reflClass->getAttributes());

We'd be changing from this:

array(1) {
["Doctrine\ORM\Entity"]=>
  array(1) {
[0]=>
string(4) "user"
  }
}

Into this:

array(1) {
["Doctrine\ORM\Entity"]=>
object(Doctrine\ORM\Entity)#1 (1) {
["tableName"]=>
string(4) "user"
  }
}


As I showed already, it's very easy to do this transformation at higher 
layer.


$reflClass = new \ReflectionClass("User");
$attributes = $reflClass->getAttributes()
foreach ($attributes as $key => &$val) {
$val = new $key(...$val);
}
var_dump($attributes);

Construction objects directly in Reflection*::getAttributes() method, 
doesn't make significant benefits and even makes limitation.







1- Your approach is basically defining an array. Could you
explain your line of thinking on why you didn't consider a syntax
like the one below?

<["key" => "value"]>
class Foo {}

I didn't try to invite new syntax. Just completely took it from HHVM.


My idea was based on your current proposal, which is basically a way 
to define key/value pairs.
If you decide to go minimalistic, that is probably my best line of 
thinking.






2- I see that you added support over functions, classes,
constants and properties. According to the RFC, getAttributes()
was added over ReflectionFunction. Is there a reason why support
was not added to methods (ReflectionMethod extends
ReflectionFunctionAbstract, which was not mentioned on RFC)? Any
reason to not support it in function/method parameters?

ReflectionMethod is a child of ReflectinFunction, so it's supported.

Attributes are allowed for the same entities as doc-comments (they
are not allowed for parameters)


I was asking if there was a purpose to not support Attributes over 
ReflectionParameter. Example:


class Foo {
public function bar(<> Bar $bar) : bool {
// ...
}
}

$reflClass = new \ReflectionClas("Foo");
$reflMethod = $reflClass->getMethod("bar");
$reflParameter = $reflMethod->getParameters()[0];

var_dump($reflParameter->getAttributes());


I understood, we may add this ability 

RE: [PHP-DEV] Lazy keys comparison during hash lookups

[Andone, Bogdan]

> -Original Message-
> From: Andone, Bogdan [mailto:bogdan.and...@intel.com]
> Sent: Friday, March 18, 2016 11:58 AM
> To: 'Nikita Popov' 
> Cc: internals@lists.php.net
> Subject: RE: [PHP-DEV] Lazy keys comparison during hash lookups
> 
> > -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: Andone, Bogdan [mailto:bogdan.and...@intel.com]
> > > Sent: Tuesday, March 08, 2016 4:19 PM
> > > To: 'Nikita Popov'
> > > Cc: internals@lists.php.net
> > > Subject: RE: [PHP-DEV] Lazy keys comparison during hash lookups
> > >
> > > > From: Nikita Popov [mailto:nikita@gmail.com]
> > > > Sent: Tuesday, March 08, 2016 3:43 PM
> > > > To: Andone, Bogdan
> > > > Cc: internals@lists.php.net
> > > > Subject: Re: [PHP-DEV] Lazy keys comparison during hash lookups
> > > > >On Tue, Mar 8, 2016 at 2:18 PM, Nikita Popov
> > > > >
> > > wrote:
> > > > >> On Tue, Mar 8, 2016 at 2:01 PM, Andone, Bogdan
> > > >  wrote:
> > > > >> Hi Guys,
> > > > >>
> > > > >> I would like to propose a small change into the DJBX33A hash
> > > function
> > > > algorithm which will make easier the key matching validations in
> > hash
> > > > lookup functions.
> > > > >>
> > > > >> The change addresses the modulo 8 tailing bytes of the key. For
> > > these
> > > > bytes we can use an 8 bit shift instead of a 5 bit shift; we also
> > need
> > > > to replace the ADD by XOR, in order to avoid byte level overflows.
> > > This
> > > > change ensures the uniqueness of the hash function transformation
> > for
> > > > the tailing bytes: supposing two strings have same partial hash
> > value
> > > > for the first Nx8 bytes, different combinations of tailing
> > characters
> > > > (with the same tail size) will always generate different keys.
> > > > >> We have the following consequences:
> > > > >> If two strings have:
> > > > >> - same hash value,
> > > > >> - same length,
> > > > >> - same bytes for the first Nx8 positions, then they are equal,
> > > > >> and the tailing bytes can be skipped during
> > > > comparison.
> > > > >>
> > > > >> There is a visible performance gain if we apply this approach
> > > > >> as
> > we
> > > > can use a lightweight memcmp() implementation based on longs
> > > comparison
> > > > and completely free of the complexity incurred by tailing bytes.
> > > > For Mediawiki I have a 1.7%  performance gain while Wordpress
> > > > reports
> > 1.2%
> > > > speedup on Haswell-EP.
> > > > >>
> > > > >> Let’s take a small example:
> > > > >> Suppose we have a key=”this_is_a_key_value”.
> > > > >> The hash function for the  first N x 8 byes are computed in the
> > > > original way; suppose “this_is_a_key_va” (16bytes) will return a
> > > partial
> > > > hash value h1; the final hash value will be computed by the
> > following
> > > > sequence:
> > > > >> h = ((h1<<8) ^ h1) ^ ‘l’;
> > > > >> h = ((h<<8) ^ h) ^ ‘u’;
> > > > >> h = ((h<<8) ^ h) ^ ‘e’;
> > > > >> or, in only one operation:
> > > > >> h = (h1<<24) ^ (h1<<16) ^ (h1<<8) ^ h1 ^ (‘l’<<16) ^
> > ((‘l’^‘u’)<<8)
> > > ^
> > > > (‘l’^’u’^‘e’)
> > > > >> We can see that ht=(‘l’<<16) ^ ((‘l’^‘u’)<<8) ^
> > > (‘l’^’u’^‘e’)  cannot
> > > > be obtained by any other 3 characters long tail. The statement is
> > not
> > > > true if we use ADD instead of XOR, as extended ASCII characters
> > might
> > > > generate overflows affecting the LSB of the higher byte in the
> > > > hash value.
> > > > >>
> > > > >> I pushed a pull request here: https://github.com/php/php-
> > > > src/pull/1793. Unfortunately it does not pass the travis tests
> > because
> > > > “htmlspecialchars etc use a generated table that assumes the
> > > > current hash function” as noticed by Nikita.
> > > > >>
> > > > >> Let me know your thoughts on this idea.
> > > > >
> > > > > Hey Bogdan,
> > > > > This looks like an interesting idea! I'm somewhat apprehensive
> > about
> > > > coupling this to a change of the hash function, for two reasons:
> > > > > a) This will make it more problematic if we want to change the
> > hash
> > > > function in the future, e.g. if we want to switch to SipHash.
> > > > > b) The quality of the new hash distribution is not immediately
> > > clear,
> > > > but likely non-trivially weaker.
> > > > > So I'm wondering if we can keep the concept of using a
> > > > > zend_ulong
> > > > aligned memcmp while leaving the hash function alone: The
> > zend_string
> > > > allocation policy already allocates the string data aligned and
> > padded
> > > > to zend_ulong boundaries. If we were to additionally explicitly
> > > > zero
> > > out
> > > > the last byte (to avoid valgrind warnings) we should be able to
> > > compare
> > > > the character data of two zend_strings using a 

Re: [PHP-DEV] [RFC] Nullable Types

[Jesse Schalken]

On Sun, Apr 24, 2016 at 2:58 AM, Levi Morrison  wrote:

> On Sat, Apr 23, 2016 at 10:40 AM, Quim Calpe  wrote:
>
> Option is no better than a union type with null[1]. If a language
> requires an option to be unwrapped then it can do the same with some
> type or null. This is what Swift does. These things are exactly
> equivalent.
>

I don't think that's strictly true. Option (or Maybe) types that must
be unwrapped can usually be safely nested as Option>. This is
important if you have a generic class Foo that uses Option internally
and Foo is instantiated as Foo (using string as an
example), causing an Option to occur inside Foo. If
Option meant string|null, the Option would become
string|null|null and the real "null" at runtime would become ambiguous.

Nonetheless, nesting is very rarely needed, but it is something to keep in
mind when using generics in combination with union with null for
nullability.



> However in PHP we do not have generics, which means a nullable type is
> actually better because we can express the type that participates with
> null. With an Option type we cannot.
>
>   [1] At least with the behaviors here. If Option is a Traverable that
> returns 0 or 1 items then we can use that behavior to our advantage.
> Of course, we lose the ability to express the underlying option type.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>