Re: [PHP-DEV] Native Annotation Syntax

[Larry Garfield]

On 11/25/15 10:31 AM, Pedro Cordeiro wrote:

2015-11-25 13:47 GMT-02:00 Lester Caine :


Any new system would require
every third party tool to be adapted to use it


That's not true at all. A new syntax would in no way invalidate parsing
annotations from docblocks.

The only legacy code that is supported by IDEs (if they are, PHPStorm will
not hint/autocomplete, nor will eclipse/netbeans) would be
Symfony2/Doctrine2. There are tons of other tools that with custom
annotations (JMSSerializer as an example) that do not have any support at
all.

This argument is so flawed that you didn't consider that there are many
parsers with many different syntaxes (
https://github.com/jan-swiecki/php-simple-annotations,
https://github.com/nette/neon) and that ANY implementation, be it through
docblocks or with a native syntax would require a rewrite anyway for many
projects if those tools want to support the new native feature.

Also, doing it through an extension is a nice way to delay adoption,
because shared hosts rarely give the option to install new extensions.

I don't have a vote here, but if I had, I'd strongly oppose any
docblock-based implementation.


When Drupal adopted annotations, the absolute #1 objection people had 
was "but docblocks aren't code, you moron!"  There's no value in 
language-native annotations being in the docblock, other than BC with 
*some* existing implementations.  However, doing so would make static 
checking more difficult; If annotations become a language-native 
feature, they should be a first-class citizen to make it easier for IDEs 
to handle.


I'm also not super picky on what the tokens are, however I do think 
mapping them to actual classes, like Doctrine does, would be the most 
flexible.  Structured data all the things.  That also means annotations 
can be namespaced, be affected by use statements, and so forth.  In a 
sense, they become isomorphic to:


class Foo {
  public static function getAnnotations() {
return [
  new OneToMany('a', 'b', 'c'),
  new Stuff('d', 4);
];
  }
}

Except they can be applied to anything reflectable rather than just 
classes.  (Functions, methods, classes, object properties.)


Sara's suggestion of making them legal within a // comment line for BC 
reasons is interesting, but we don't do that for any other new syntax 
AFAIK.  Plus, it means it's harder to comment out an annotation 
temporarily for debugging.  There's still /* */, but it's one more quirk 
to have to think about.


--
--Larry Garfield


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

Re: [PHP-DEV] Native Annotation Syntax

[Rowan Collins]

Pedro Cordeiro wrote on 25/11/2015 16:53:
Rowan, even if they are not harder, there is no reason to keep this 
feature in docblocks.


Well, I can think of one reason: backwards compatibility. I don't mean 
with current frameworks - as you say, these are not currently 
standardised, so some will need to be adapted whatever is implemented in 
core - but with older versions of PHP.


If we invent new syntax, then any code using that feature must *require* 
the version of PHP that introduces that syntax, because previous 
versions will simply throw a syntax error. There are a few ways around 
this, such as:


- allowing the annotation to be preceded by // as Sara suggested (or 
maybe #, to make it look like a C pre-processor directive)
- using some other syntax that is currently a no-op, like ECMAScript's 
wacky "use strict"


But ultimately, these end up having the same disadvantages you're 
claiming for docblocks - they look like things you can delete, or which 
has some other purpose, but are actually vital to the operation of the 
code.#


I don't feel that strongly in favour of docblocks, but I don't think the 
reasons given against are particularly strong.


Regards,
--
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] Native Annotation Syntax

[Rowan Collins]

Pedro Cordeiro wrote on 25/11/2015 11:04:
I'd really like to see something outside the docblock. Comment 
annotations are a workaround for the lack of native annotations.


This is true, but they are now a very widely used workaround, and any 
native support for them could be polyfilled using the kind of userland 
libraries that already exist.


It makes the environment hard to learn ("What does @param do? And what 
does @ManyToMany do?")


I'm not sure how this is made any easier by moving the annotations out 
of the docblock. I suppose it's a little confusing that, within the 
docblock, code annotations and documentation annotations share the same 
syntax; maybe we could use a different prefix, like "@@" instead of "@"? 
This would also give a chance for projects to transition to the new 
standard syntax, rather than having to break compatibility if their old 
implementation doesn't quite match.


it makes it impossible for IDEs to hint/autocomplete without 
project-specific plugins


That's a good argument for standardisation, but doesn't require moving 
out of the docblock; in fact, it doesn't even require any action from 
this list, as PHP-FIG could simply agree a PSR, and IDEs like PHPStorm 
would use that as an implementation guide.


and adds this odd notion that removing some comment blocks might break 
an app (which is just awful).


If it helps, just think of /** ... */ as not being a comment, but 
already a first-class piece of syntax. Note that the parser already 
thinks so - hence we can have functions like 
ReflectionMethod::getDocComment. IDEs also parse docblocks already, and 
most syntax highlighting editors can probably style them differently 
from comments so that you don't delete them by mistake.


Now, if annotations were being implemented as something brand new to 
PHP, like say Traits were, I'd agree that we should look to languages 
like Java and C# for syntax ideas. But since a lot of people have 
already invented annotations using docblocks, and since docblocks are 
already supported by the reflection classes, I'm not convinced of why we 
shouldn't just carry on down that route.


Regards,
--
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] Native Annotation Syntax

[Lester Caine]

On 25/11/15 16:53, Rowan Collins wrote:
> Now, if annotations were being implemented as something brand new to
> PHP, like say Traits were, I'd agree that we should look to languages
> like Java and C# for syntax ideas. But since a lot of people have
> already invented annotations using docblocks, and since docblocks are
> already supported by the reflection classes, I'm not convinced of why we
> shouldn't just carry on down that route.

Thanks Rowan ... that just about sums it up better than I did ...

-- 
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] Native Annotation Syntax

[Pedro Cordeiro]

2015-11-25 13:47 GMT-02:00 Lester Caine :

> Any new system would require
> every third party tool to be adapted to use it
>

That's not true at all. A new syntax would in no way invalidate parsing
annotations from docblocks.

The only legacy code that is supported by IDEs (if they are, PHPStorm will
not hint/autocomplete, nor will eclipse/netbeans) would be
Symfony2/Doctrine2. There are tons of other tools that with custom
annotations (JMSSerializer as an example) that do not have any support at
all.

This argument is so flawed that you didn't consider that there are many
parsers with many different syntaxes (
https://github.com/jan-swiecki/php-simple-annotations,
https://github.com/nette/neon) and that ANY implementation, be it through
docblocks or with a native syntax would require a rewrite anyway for many
projects if those tools want to support the new native feature.

Also, doing it through an extension is a nice way to delay adoption,
because shared hosts rarely give the option to install new extensions.

I don't have a vote here, but if I had, I'd strongly oppose any
docblock-based implementation.

Re: [PHP-DEV] Native Annotation Syntax

[Rowan Collins]

Larry Garfield wrote on 25/11/2015 17:06:
Too, it means that a given annotation directive may have spurious * 
characters inside its string, if it's multi-line.  Sure, that can be 
filtered out (Doctrine already does), but that's one more complication 
to have to consider. 


I would expect that behaviour would be part of the standard definition, 
and the core implementation, so don't really see it as a big deal. The 
same thing happens with leading whitespace in many syntaxes anyway.


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

Re: [PHP-DEV] Native Annotation Syntax

[Lester Caine]

On 25/11/15 11:04, Pedro Cordeiro wrote:
> I feel like this is a major feature that's missing, and people are using it
> in a suboptimal way (docblocks), so I thought I'd reopen the discussion and
> see if someone more familiar with the internals feels like implementing it

In previous discussions it was pointed out that a substantial amount of
legacy code already uses docblock style annotation, and that is well
supported by IDE's and other tools, so there is no reason not it
continue to support that substantial base. Any new system would require
every third party tool to be adapted to use it was there any reason to
load the code base with something which will only have a limited uptake.
Adding an extension to provide an alternative would be the correct way
forward, and then if that gains traction, look to it's status then.

-- 
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] Native Annotation Syntax

[Pedro Cordeiro]

Rowan, even if they are not harder, there is no reason to keep this feature
in docblocks. Even the argument "compatibility with current
implementations" is flawed, because there are many different
implementations (not only doctrine's) with different syntaxes, so any
native option would break SOME implementations.

Docblocks are Documentation Blocks, which is meant for documentation only.

Mixing documentation (@param) with runtime stuff (@manyToMany) is
counter-intuitive and makes the ecosystem harder to learn.

It's also weird that removing comment blocks break an app.

2015-11-25 14:47 GMT-02:00 Rowan Collins :

> Larry Garfield wrote on 25/11/2015 16:42:
>
>> However, doing so would make static checking more difficult; If
>> annotations become a language-native feature, they should be a first-class
>> citizen to make it easier for IDEs to handle.
>>
>
> Could you explain why docblocks are harder to parse than text outside
> docblocks? As far as I know, IDEs *already* parse docblocks, e.g. using
> @param and @return for type analysis, so I don't really see why
> generalising that would be a big problem.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Native Annotation Syntax

[Rowan Collins]

Larry Garfield wrote on 25/11/2015 17:06:
For me, the "sometimes it's code and sometimes it's not, even though 
it looks the same" argument is sufficient to reject docblocks as a 
location for annotations. 


Annotations aren't code, they're metadata, and docblocks already contain 
metadata; it's just that originally, that metadata was targeted at 
generating documentation, rather than generating code, or affecting 
run-time behaviour.


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

Re: [PHP-DEV] Native Annotation Syntax

[Larry Garfield]

On 11/25/15 10:47 AM, Rowan Collins wrote:

Larry Garfield wrote on 25/11/2015 16:42:
However, doing so would make static checking more difficult; If 
annotations become a language-native feature, they should be a 
first-class citizen to make it easier for IDEs to handle. 


Could you explain why docblocks are harder to parse than text outside 
docblocks? As far as I know, IDEs *already* parse docblocks, e.g. 
using @param and @return for type analysis, so I don't really see why 
generalising that would be a big problem.


Not being an IDE author I cannot say for certain, so perhaps it's easier 
than I imagine.  However, speaking as a user I would want a robust level 
of static syntax validation of my annotations.  Having robust syntax 
validation show up in *some* parts of my docblock but not others is 
confusing for me as a user; I hypothesize that it would similarly be 
more difficult to selectively treat bits and pieces of the docblock as 
code but not others.  (My current IDE, PHPStorm, parses a docblock to 
validate that it matches the method signature but all it does is tell me 
if the whole thing is valid or not, and if I'm using a "used" class 
name.  It's actually very unhelpful when dealing with complex Doctrine 
annotations like Drupal uses.)


Too, it means that a given annotation directive may have spurious * 
characters inside its string, if it's multi-line.  Sure, that can be 
filtered out (Doctrine already does), but that's one more complication 
to have to consider.


For me, the "sometimes it's code and sometimes it's not, even though it 
looks the same" argument is sufficient to reject docblocks as a location 
for annotations.


--
--Larry Garfield


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

Re: [PHP-DEV] Native Annotation Syntax

[Rowan Collins]

Pedro Cordeiro wrote on 25/11/2015 17:04:


2015-11-25 14:53 GMT-02:00 Rowan Collins >:


If it helps, just think of /** ... */ as not being a comment, but
already a first-class piece of syntax.


Except that it won't parse some stuff while parsing some other stuff. 
There was a topic on reddit some time ago with a rant I wrote about 
it, and the community seemed to support the notion that comment 
annotations are bad: 
https://www.reddit.com/r/PHP/comments/1ztstd/rant_it_baffles_me_that_people_think_using/


A very quick response to that rant:

> 1) Some php bytecode compilers (for example, facebook's hiphop) will 
strip your comments. STRIPPING COMMENTS SHOULD NEVER BREAK YOUR APP.


So, let's make sure we treat these as first-class entities not comments, 
and mention it in the language standard (drafted by Facebook, so that 
they can make HHVM maximally conformant) that these MUST NOT be stripped 
by compilers or pre-processors.


> 2) No IDE hints, no IDE syntax checking because, you know, THEY ARE 
COMMENTS. If you think I should download a specific IDE plugin to work 
with Doctrine and another one to work with Symfony and yet another one 
to work in your specific project with your custom annotations, you can 
go F@#$ yourself.


Total strawman: IDEs parse all sorts of information out of docblocks. 
They may not parse annotations *because they're not standardised*, but 
if there were a PSR defining them, I bet the plugin for parsing that 
syntax would soon be bundled with any IDE with decent PHP support.


> 3) Coupling, separation of concerns, encapsulation: having 
@Route("/something") in a controller class is AWFUL.


This appears to be a rant about annotations in general, not the syntax 
used for them.


> 4) Dude, what does "@ManyToMany" do? Oh, ok, and what does "@param" 
do...? HOW THE HELL AM I SUPPOSED TO TELL SOMEONE "oh, this part over 
here is metadata, but this one is just a comment"? How do I distinguish 
between the two of them?


Well, no, they're both metadata, just with different targets - @param is 
targeted at IDEs and documentation generators, @ManyToMany is targeted 
at a run-time hook, or maybe a code-generation one, or, well, anything 
that wants metadata about something.



I'll stop there, because you probably already had this discussion at the 
time, but since you linked...


Regards,
--
Rowan Collins
[IMSoP]

Re: [PHP-DEV] Native Annotation Syntax

[Rowan Collins]

Larry Garfield wrote on 25/11/2015 16:42:
However, doing so would make static checking more difficult; If 
annotations become a language-native feature, they should be a 
first-class citizen to make it easier for IDEs to handle. 


Could you explain why docblocks are harder to parse than text outside 
docblocks? As far as I know, IDEs *already* parse docblocks, e.g. using 
@param and @return for type analysis, so I don't really see why 
generalising that would be a big problem.


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

Re: [PHP-DEV] Native Annotation Syntax

[guilhermebla...@gmail.com]

Hi,

I'm the co-author of RFC of Annotations, co-author of Annotations in
docblock which I abandoned for being conceptually wrong and co-author of
Doctrine Annotations.

Comments such as the one from Lester Caine "In previous discussions it was
pointed out that a substantial amount of legacy code already uses docblock
style annotation, and that is well supported by IDE's and other tools, so
there is no reason not it continue to support that substantial base." makes
me very sad, specially because these claimed legacy code using docblocks
were only written that way in first place because Annotations RFC got
"declined".

Yes, I quoted because it actually acquired a lot of positive votes (over
50% of overall voters) even when there was no 2/3, 50% +1, etc criteria,
but that's the feedback I received after bothering a lot of people about
patch's resolution: the majority of long period contributors of PHP voted
against the patch considering it was too complex, with several
modifications to Zend Engine, which lead them to reject as it was. I also
got suggested to implement this support outside of core through a PECL
extension parsing docblock annotations.

If ever any "long term contributor" decided to discuss about potentially
introducing Annotations into PHP core, I'll be the first one to help. Until
them, anything userland guys ask here IMHO is irrelevant.


Regards,


On Wed, Nov 25, 2015 at 12:00 PM, Rowan Collins 
wrote:

> Pedro Cordeiro wrote on 25/11/2015 16:53:
>
>> Rowan, even if they are not harder, there is no reason to keep this
>> feature in docblocks.
>>
>
> Well, I can think of one reason: backwards compatibility. I don't mean
> with current frameworks - as you say, these are not currently standardised,
> so some will need to be adapted whatever is implemented in core - but with
> older versions of PHP.
>
> If we invent new syntax, then any code using that feature must *require*
> the version of PHP that introduces that syntax, because previous versions
> will simply throw a syntax error. There are a few ways around this, such as:
>
> - allowing the annotation to be preceded by // as Sara suggested (or maybe
> #, to make it look like a C pre-processor directive)
> - using some other syntax that is currently a no-op, like ECMAScript's
> wacky "use strict"
>
> But ultimately, these end up having the same disadvantages you're claiming
> for docblocks - they look like things you can delete, or which has some
> other purpose, but are actually vital to the operation of the code.#
>
> I don't feel that strongly in favour of docblocks, but I don't think the
> reasons given against are particularly strong.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

[PHP-DEV] RE: [INTERNALS-WIN] Re: [PHP-DEV] Windows (Visual Studio) compiler stuff

[Anatol Belski]

Hi Matt,

> -Original Message-
> From: Matt Wilmas [mailto:php_li...@realplain.com]
> Sent: Monday, November 23, 2015 8:15 AM
> To: Anatol Belski ; internals@lists.php.net;
internals-
> w...@lists.php.net
> Cc: 'Dmitry Stogov' ; 'Pierre Joye'

> Subject: Re: [INTERNALS-WIN] Re: [PHP-DEV] Windows (Visual Studio)
compiler
> stuff
> 
> Hi Anatol, all,
> 
> - Original Message -
> From: "Anatol Belski"
> Sent: Monday, November 16, 2015
> 
> > Hi Matt,
> >
> >> -Original Message-
> >> From: Matt Wilmas [mailto:php_li...@realplain.com]
> >> Sent: Monday, November 16, 2015 2:59 PM
> >> To: Anatol Belski ; internals@lists.php.net;
> > internals-
> >> w...@lists.php.net
> >> Cc: 'Dmitry Stogov' ; 'Pierre Joye'
> > 
> >> Subject: [INTERNALS-WIN] Re: [PHP-DEV] Windows (Visual Studio)
> >> compiler stuff
> >>
> >> > According to the docs __declspec(noinline) is specific to C++. Also
> >> > with VS it's always much more tedious to inline something than the
> >> > opposite. These are the main two reasons it's disregarded ATM. We
> >> > can add it for compliance with C++, but it'll in best case have no
> >> > effect in the PHP core. Should be tested before, though.
> >>
> >> Yeah, I know what the docs imply ("member function"), which is why I
> > tested it.
> >> I guess you missed my "works as expected" part. :-P
> >>
> >> A test function that just returns a number was automatically inlined
> > (plain C).
> >> Using __declspec(noinline) it was call'ed instead.
> >>
> >> Not sure if any of the "zend_never_inline" PHP stuff is getting
> >> inlined
> > when it's
> >> desired not to be -- I'll compile PHP in a bit and see what it looks
> >> like
> > with
> >> "noinline."
> >>
> > Yeah, I knew it could work, just that it's undocumented so preferred
> > not even to start with it because I haven't expect much gain from it.
> > The functions I've seen with zend_never_inline are rather big and
> > wouldn't get inlined even when forced.
> 
> noinline did have an effect -- 12 KB smaller php7.dll.  So, obviously it's
> preventing those zend_never_inline functions from being inlined when they
> currently are.  Dmitry surely had reason to make them that way --
cache-related,
> I assume.  Any difference, however "minor," is the same as other
compilers, so
> it's nice to know this can be used, with so many of the other GCC/Clang
"tricks"
> missing...
> 
I wasn't telling it wouldn't work. We should check for possible
implications. If there's nothing negative, so we can add this into master.
It always depends, smaller image size vs. function call.

> BTW, something "big" not getting inlined even when forced?  I know the
"rules"
> about what can't be [force] inlined (basically same as GCC) and size isn't
one of
> them. :-)  (I hope not.)  As I've mentioned a bit, to be seen soon, my
"compile-
> time" param parsing optimization will have the "hugest"
> inline function, but it compiles down to literally nothing, which I
finally got to
> work with MSVC as well.  That's why I wasn't liking the idea of a
standalone copy
> of that stuff adding several KB to each module...
> 
Size is one of the factors, the concrete code and usage, too. Despite that,
any compiler doc says that inline is just a suggestion.

> >> > I'd ask you for some concrete case for this, as I'm not sure to
> >> > understand exactly what you mean. The only case where an extra code
> >> > would be generated is with "__declspec(export) inline", but that's
> >> > not the case anywhere within PHP.
> >>
> >> My concrete case is checking tons of generated code! ;-)
> >>
> >> It's simple: useless standalone functions are created for every
> >> "static __forceinline" definition...  Not having static makes it act
> >> like
> > GCC/Clang.
> >>
> > I guess I've understood what you're talking about - abut unreferenced
> > COMDATs (or maybe also duplicated COMDATs). There is a variety of
> > situations for that, not possibly only inlining. Fixing it is done in
> > PHP when building with --enable-debug-pack, that is on in release
> > builds. In your experiments, if you add /Zi CFLAG (or explicitly /Gy)
> > and /OPT:REF,ICF LDFLAG - that will solve it for yur other project.
> > You can read more about COMDAT on MSDN.
> 
> Yeah, I know about the COMDAT stuff.  And I thought I had tried the
/OPT:REF,
> etc. on a standalone test a while ago and it didn't do anything...
> 
> I just now tried --enable-debug-pack, and as I was thinking, it had no
effect.
> 
What do you mean with "no effect"? Don't reduce size? The compiler/linker
options I've mentioned are about removing identical or unreferenced COMDATS,
and they do that. BTW how do you check it? I would like you to be more
precise at this point, please. Did you use link /map or disasm?

> I don't need to solve anything on the other project since I didn't use
static there.
> :-P
> 
> > Hm, probably 

RE: [PHP-DEV] Windows (Visual Studio) compiler stuff

[Anatol Belski]

Hi Matt,

I wonder really how much research you do :)

> -Original Message-
> From: Matt Wilmas [mailto:php_li...@realplain.com]
> Sent: Monday, November 23, 2015 2:28 AM
> To: internals@lists.php.net; internals-...@lists.php.net
> Cc: Dmitry Stogov ; Anatol Belski
;
> Pierre Joye ; Matt Tait ;
Nikita
> Popov 
> Subject: Re: [PHP-DEV] Windows (Visual Studio) compiler stuff
> 
> Hi Anatol, Dmitry, all,
> 
> Will reply about the original subject issues soon, but this is about new
stuff I
> noticed the other day...  Adding Matt Tait and Nikita because of PR
> #1418 and comments.
> 
> Anyway, the new Control Flow Guard (/guard:cf) is causing a big slowdown
on
> bench.php. :-(  14% on a Yorkfield (Q9400) and 19% on a Sandy Bridge
(Celeron
> G530).  Ouch.  Did anyone else check the performance impact?  Is this
> acceptable?  On any other platform...?
> 
> I'll definitely remove that from my builds (Elephpant Sanctuary, coming
> soon) since it's useless on all but the latest Windows versions anyway.
> 
> But if that "feature" must remain enabled otherwise, I think we can
eliminate
> most of the performance hit.  As Nikita wondered about, I first wanted to
look
> at the indirect calls to the opcode handlers.  I tried
> separating out zend_execute.c in the Makefile and added /guard:cf-
Bingo!
> That restored about 98% of the speed on bench.php.  It reduced the
--disable-all
> NTS DLL by 13.5 KB (of the 67 KB added by full CFG).
> 
> Or could maybe change back to the old SWITCH executor?  I didn't try that.
> 
> 
> It seems like it would be a good "rule" to not use any MS stuff that isn't
done on
> other compilers/platforms. :-)
> 
> /GS [1] is another that is/was starting to get annoying (function
prolog/epilog);
> luckily I was able to suppress it in most cases with changes I'm making.
It's
> enabled by default, of course, although I see it's
> commented out in a line (old?) of confutils.js.  /GS-   ;-)   I really
hope
> there aren't places where we are not doing range checks, etc. ourselves
(that
> the compiler can't see).  So, either /GS is a waste, or it's only a matter
of time
> with other compilers?!
> 
> [1]
> http://stackoverflow.com/questions/6607410/understanding-buffer-security-
> check-gs-compiler-option-in-msvc
> 
We're unlikely to remove the security options in favor of performance. But
that's for one.

/guard:cf is documented to have possible performance impact on systems that
don't support it. However no such side effects was noticed even on win7.
There was also no bug reports in this regard. We definitely can't test any
possible HW, but it's more about OS, not HW. Is win7 your case? Then just
upgrade :)

With /GS is basically same. It's not supposed to fix the programmer
mistakes, but to add protection against exploits. Stability and
compatibility matters more than a performance trade off.

Another thing is that just one synthetic test is unlikely to reveal the big
picture. You should probably also test on some real apps, that will bring
more realistic results.

Thanks for your work.

Regards

Anatol


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

Re: [PHP-DEV] Native Annotation Syntax

[Rowan Collins]

guilhermebla...@gmail.com wrote on 25/11/2015 17:58:

I can give you a good argument.

opcache.save_comments=0

Make it work.


Simple: remove that configuration variable, and always save doc blocks. 
As mentioned, my view would be that these should no longer be considered 
"comments", but "metadata", and that documentation and core features 
would be altered to reflect this.


Did you think that was a killer argument, or just another thought to 
bring to the discussion? Because I absolutely welcome people adding to 
the list of pros and cons *on either side*, but I object to any attempt 
to shut down the discussion just because people have already made their 
mind up based on some gut feeling.


Regards,
--
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] Native Annotation Syntax

[guilhermebla...@gmail.com]

Hi Rowan,

If you're in a shared hosting, you can't "simply" remove the configuration
variable.
Relying on extensions or configuration flags to support core language
features is very bad. We don't have flags that can turn IF support off for
example, why we would have that for annotations?
I can bring more cons if you want... like how/when to parse "use" calls in
a docblock? I mainly want to address the need of this class:
https://github.com/doctrine/annotations/blob/master/lib/Doctrine/Common/Annotations/TokenParser.php

I've exhausted to death pros and cons of every single part. The biggest
problem of not realizing this is a core feature and pushing so hard to
docblock is that as soon as this is blinded to some people, others will say
"oh, so that doesn't need to be in core and can be a PECL extension". Now
re-read my email from the beginning about shared hosting, you just entered
in an infinite loop.

On Wed, Nov 25, 2015 at 1:50 PM, Pedro Cordeiro 
wrote:

> On top of it, it'd break obfuscators like Zend Guard.
>
> 2015-11-25 15:58 GMT-02:00 guilhermebla...@gmail.com <
> guilhermebla...@gmail.com>:
>
>> I can give you a good argument.
>>
>> opcache.save_comments=0
>>
>> Make it work.
>>
>> On Wed, Nov 25, 2015 at 12:48 PM, Rowan Collins 
>> wrote:
>>
>> > Larry Garfield wrote on 25/11/2015 17:39:
>> >
>> >> On 11/25/15 11:00 AM, Rowan Collins wrote:
>> >>
>> >>> I don't feel that strongly in favour of docblocks, but I don't think
>> the
>> >>> reasons given against are particularly strong.
>> >>>
>> >>> Regards,
>> >>>
>> >>
>> >> If you don't feel strongly in favor of them, why are you trying to
>> make a
>> >> case for them so strongly?  Just for kicks?  We don't need a "devil's
>> >> advocate" at this point in the discussion...
>> >>
>> >>
>> > Hi Larry,
>> >
>> > I don't *feel* strongly in favour or against them, but can see
>> advantages
>> > and disadvantages on both sides. Feeling strongly is not the same as
>> having
>> > a strong argument for your point of view, so just because some people
>> have
>> > expressed strong opinions against, I don't see why I shouldn't challenge
>> > their reasoning, even if that does mean playing devil's advocate.
>> >
>> > Which is better: basing the decision on the gut feeling of a handful of
>> > people who happen to be here now, or basing it on sound reasoning after
>> > thinking through the implications?
>> >
>> > Regards,
>> > --
>> > Rowan Collins
>> > [IMSoP]
>> >
>> > --
>> > PHP Internals - PHP Runtime Development Mailing List
>> > To unsubscribe, visit: http://www.php.net/unsub.php
>> >
>> >
>>
>>
>> --
>> Guilherme Blanco
>> MSN: guilhermebla...@hotmail.com
>> GTalk: guilhermeblanco
>> Toronto - ON/Canada
>>
>
>


-- 
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

RE: [PHP-DEV] Re: Scalar Type Declaration Syntax Weirdness

[Anatol Belski]

Hi Andrea,

> -Original Message-
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Wednesday, November 25, 2015 9:00 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: Scalar Type Declaration Syntax Weirdness
> 
> Hi,
> 
> Anatol Belski wrote:
> > that's my point as well. There is a clear documentation about type hints, 
> > usage
> of an undocumented way is out of scope of BC. Using \int means there were a
> "class int{}" which is prohibited. Of course it is a bug after all, which 
> will be
> addressed.
> 
> It may not be documented, but that doesn't put it outside the scope of BC.
> People will unintentionally rely on bugs.
> 
What is the reason to use \int if "class \int{}" is prohibited? A typo :) ? 

If the patch is fine within RC8 period, it is going to be applied in 7.0.1 
which is soon enough to avoid creating bad habits. Applying a couple of hours 
old patch to the bug with such severity seems not appropriate, anyway.

Regards

Anatol


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

RE: [PHP-DEV] Re: Scalar Type Declaration Syntax Weirdness

[Anatol Belski]

Hi Andrea,

> -Original Message-
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Thursday, November 26, 2015 12:47 AM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: Scalar Type Declaration Syntax Weirdness
> 
> Hi Anatol,
> 
> Anatol Belski wrote:
> >>
> >> It may not be documented, but that doesn't put it outside the scope of BC.
> >> People will unintentionally rely on bugs.
> >>
> > What is the reason to use \int if "class \int{}" is prohibited? A typo :) ?
> 
> It might be used deliberately since some IDEs (PHPStorm in particular) can't
> handle PHP 7's scalar type hints properly in namespaces yet.
> 
Hm, but then it's a bug in PHPStorm for PHP7 support, not in PHP? Particularly 
I've found this amusing thread https://devnet.jetbrains.com/message/5507875 . 
Even PHPStorm would insert \int, it'll then complain that there's no such 
class, and it'll complain about the doc blocks, and passing int instead of \int 
object. So an IDE will really need to be PHP 7 compatible.

Also, the basic situation is even worse, any code ported to PHP7 and using type 
hints is potentially already broken. With this patch available on the day zero, 
those codes won't work. We know that this fix is necessary and can't be 
avoided, so putting it into somewhere after day zero - the broken PHP codes 
will work with .0 and there will be a gap to fix them till next PHP release.

Regards

Anatol 


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

Re: [PHP-DEV] Re: Scalar Type Declaration Syntax Weirdness

[Andrea Faulds]

Hi Anatol,

Anatol Belski wrote:


It may not be documented, but that doesn't put it outside the scope of BC.
People will unintentionally rely on bugs.


What is the reason to use \int if "class \int{}" is prohibited? A typo :) ?


It might be used deliberately since some IDEs (PHPStorm in particular) 
can't handle PHP 7's scalar type hints properly in namespaces yet.


Thanks.

--
Andrea Faulds
http://ajf.me/

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

Re: [PHP-DEV] Re: Scalar Type Declaration Syntax Weirdness

[Stanislav Malyshev]

Hi!

> It may not be documented, but that doesn't put it outside the scope of
> BC. People will unintentionally rely on bugs.

People might, but we are under no obligation to keep bugs around for
these people.

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

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

Re: [PHP-DEV] Native Annotation Syntax

[guilhermebla...@gmail.com]

Ok, so I'll explain why it's not "the same way" as you imagine.

I've heard this many times already so I'll save you keystrokes.
- "Sure, we can do that on docblocks"
- "Based on that, it doesn't need to be part of core and can safely be
implemented as a PECL extension"

IMHO, internals need to stop considering that PECL is a space for beta
testing features, 95% of userland doesn't even know what PECL is.

Now back to business. At parsing level, PHP has its own parser which we
could take advantage of, and though PECL extension would have to create
one. Clearly not the same way.

The closest stage we can start with this at parsed and resolved AST level
(or enter on the dark side of PHP rewriting stuff like xdebug does).
At that stage, we'd already have resolved classnames, but not for those
annotations in docblock, which is a simple block of text so far. We'd also
have to introspect the AST before it pushes to zend_compile, where use
states are vanished and all classes are already string-resolved into their
corresponding FQCN. And we still have to resolve the class names in the
docblocks using USE statements at AST level, we don't even have the
zend_class_entry instances done at that point, because they're only built
later. Not the same way, again.

Considering I've resolved these problems, it starts wit managing these data
structures. At AST level, we don't have the zend_class_entries, but I'd
already be forced to create instances of specific annotation instances. And
also I need to manage keeping my own data structures, cache them through
opcode and also implement/override Reflection data structures to enable
access to specific annotated elements. Still not the same thing.

Now let's enter on logistics of parsing the docblock text. It's multi-lined
and parsing strings like the one I sent you as an example that you ignored
to answer me back replying "it's just the same way" of parsing now need to
be away of line and column location and carefully remove pieces of text
(remember the " * " I commented?), leading to unexpected behavior and
potentially removing user's text, while re2c would already have done for
us. Again, not the same way.

I can't even imagine how can you bindly say the implementation would be the
same or act the same way as a docblock implementation. It's incredibly
complex, error prone and unreliable to be ensured present (well, it'd be an
optional extension, right?) for such an intrinsic to the language data
structure. We didn't make namespaces a PECL extension, we didn't make
traits part of docblocks. I'd argue traits is not widely used too and the
introduced complexity to core was very big. It could easily be solved by
"using traits" through docblocks and general classes too. Why your argument
is applicable to one thing and not the other?


If anyone is really willing to actually discuss true annotations
implementation and behavior in core, I'm here to help. Until then, I'll
keep watching the list.
Ah, and please stop saying "it should be in docblock". This argument is
just bull... to suppress the actual people interested to see this natively
available and just exposes your lack of interest into language improvement.


Regards,

On Wed, Nov 25, 2015 at 5:03 PM, Rowan Collins 
wrote:

> On 25 November 2015 19:02:37 GMT, "guilhermebla...@gmail.com" <
> guilhermebla...@gmail.com> wrote:
> >Hi Rowan,
> >
> >If you're in a shared hosting, you can't "simply" remove the
> >configuration
> >variable.
> >Relying on extensions or configuration flags to support core language
> >features is very bad. We don't have flags that can turn IF support off
> >for
> >example, why we would have that for annotations?
>
> I think you misunderstood: I didn't mean that users would need to turn
> that feature off, I meant that that feature would be removed, and docblocks
> would always be saved.
>
>
> >I can bring more cons if you want... like how/when to parse "use" calls
> >in
> >a docblock
>
> In exactly the same place you'd parse them outside a docblock.
>
> I really don't understand all these arguments about the parsing being
> harder. The only difference is that you're parsing /** @Foo */ instead of
> <> or whatever other syntax anyone comes up with.
>
> Really the only difference is that a docblock means sharing with other
> metadata (directives for generating documentation). Which has the advantage
> of being polyfillable from older versions of PHP, but the disadvantage of
> not being as clearly separated as a new type of syntax. Oh, and the
> perception, right or wrong, that docblocks are "just comments", rather than
> metadata containers, which Drupal's experience may demonstrate is more
> important than a purely rational analysis would suggest.
>
> All the other details about how this or that tool will adapt, how
> whitespace and multiline values should be handled, etc, are going to need
> just as much thought whatever the syntax looks like.
>
> Regards,
>
> --
> Rowan Collins

Re: [PHP-DEV] Native Annotation Syntax

[guilhermebla...@gmail.com]

Hi Rowan,

I'm avoiding drilling down as much as I can to explain every single
decision motivation of the 2010's patch, which hints every time why
docblocks are bad.
Maybe another example may help you to illustrate the problem; all I want is
to add a multi-lined text in an annotation (using your docblock approach):

/**
 * @Documentation\Description("This
 * is
 * multi-lined.")
 */

Or:

/**
 * @Documentation\Description(<<
wrote:

> On 11/25/15 11:48 AM, Rowan Collins wrote:
>
>> Larry Garfield wrote on 25/11/2015 17:39:
>>
>>> On 11/25/15 11:00 AM, Rowan Collins wrote:
>>>
 I don't feel that strongly in favour of docblocks, but I don't think
 the reasons given against are particularly strong.

 Regards,

>>>
>>> If you don't feel strongly in favor of them, why are you trying to make
>>> a case for them so strongly?  Just for kicks?  We don't need a "devil's
>>> advocate" at this point in the discussion...
>>>
>>>
>> Hi Larry,
>>
>> I don't *feel* strongly in favour or against them, but can see advantages
>> and disadvantages on both sides. Feeling strongly is not the same as having
>> a strong argument for your point of view, so just because some people have
>> expressed strong opinions against, I don't see why I shouldn't challenge
>> their reasoning, even if that does mean playing devil's advocate.
>>
>> Which is better: basing the decision on the gut feeling of a handful of
>> people who happen to be here now, or basing it on sound reasoning after
>> thinking through the implications?
>>
>> Regards,
>>
>
> So far, the only argument FOR them is BC with existing practices.
> Everything else I've seen is, I think, ways around the issues that raises.
> However, as has been noted the BC is spurious as it would only be BC with
> one implementation out of several, and we've never polyfiled other
> syntax-level features that I can recall.  (We've polyfilled new functions,
> but that's easy.)
>
> By the same argument, we should have used docblocks for scalar types, too,
> so that they could be polyfilled and be BC with existing practices, and
> those would have even been fairly standardized already.  Someone even made
> that point, IIRC, and it was quickly rejected.
>
> Whereas as a stand-alone syntax, it offers a much better distinction
> between "metadata that affects code execution" and "stuff for humans to
> read" (both for parsers and for humans).  It gives us much more flexibility
> to implement a meaningful API.  It completely avoids the "but comments
> shouldn't be code" question (which is a bigger deal than you'd think; it
> was one of the drivers behind the Backdrop fork of Drupal. I'm not kidding.)
>
> That one of the lead authors of the most widely used comment-based
> annotation system in PHP is arguing what a terrible idea a comment-based
> annotation system is should carry a great deal of weight.
>
> --
> --Larry Garfield
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

Re: [PHP-DEV] Re: Scalar Type Declaration Syntax Weirdness

[Andrea Faulds]

Hi,

Anatol Belski wrote:

that's my point as well. There is a clear documentation about type hints, usage of an 
undocumented way is out of scope of BC. Using \int means there were a "class 
int{}" which is prohibited. Of course it is a bug after all, which will be 
addressed.  


It may not be documented, but that doesn't put it outside the scope of 
BC. People will unintentionally rely on bugs.


Thanks.

--
Andrea Faulds
http://ajf.me/

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

Re: [PHP-DEV] Native Annotation Syntax

[guilhermebla...@gmail.com]

I can give you a good argument.

opcache.save_comments=0

Make it work.

On Wed, Nov 25, 2015 at 12:48 PM, Rowan Collins 
wrote:

> Larry Garfield wrote on 25/11/2015 17:39:
>
>> On 11/25/15 11:00 AM, Rowan Collins wrote:
>>
>>> I don't feel that strongly in favour of docblocks, but I don't think the
>>> reasons given against are particularly strong.
>>>
>>> Regards,
>>>
>>
>> If you don't feel strongly in favor of them, why are you trying to make a
>> case for them so strongly?  Just for kicks?  We don't need a "devil's
>> advocate" at this point in the discussion...
>>
>>
> Hi Larry,
>
> I don't *feel* strongly in favour or against them, but can see advantages
> and disadvantages on both sides. Feeling strongly is not the same as having
> a strong argument for your point of view, so just because some people have
> expressed strong opinions against, I don't see why I shouldn't challenge
> their reasoning, even if that does mean playing devil's advocate.
>
> Which is better: basing the decision on the gut feeling of a handful of
> people who happen to be here now, or basing it on sound reasoning after
> thinking through the implications?
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

Re: [PHP-DEV] Native Annotation Syntax

[Larry Garfield]

On 11/25/15 11:48 AM, Rowan Collins wrote:

Larry Garfield wrote on 25/11/2015 17:39:

On 11/25/15 11:00 AM, Rowan Collins wrote:
I don't feel that strongly in favour of docblocks, but I don't think 
the reasons given against are particularly strong.


Regards,


If you don't feel strongly in favor of them, why are you trying to 
make a case for them so strongly?  Just for kicks?  We don't need a 
"devil's advocate" at this point in the discussion...




Hi Larry,

I don't *feel* strongly in favour or against them, but can see 
advantages and disadvantages on both sides. Feeling strongly is not 
the same as having a strong argument for your point of view, so just 
because some people have expressed strong opinions against, I don't 
see why I shouldn't challenge their reasoning, even if that does mean 
playing devil's advocate.


Which is better: basing the decision on the gut feeling of a handful 
of people who happen to be here now, or basing it on sound reasoning 
after thinking through the implications?


Regards,


So far, the only argument FOR them is BC with existing practices. 
Everything else I've seen is, I think, ways around the issues that 
raises.  However, as has been noted the BC is spurious as it would only 
be BC with one implementation out of several, and we've never polyfiled 
other syntax-level features that I can recall.  (We've polyfilled new 
functions, but that's easy.)


By the same argument, we should have used docblocks for scalar types, 
too, so that they could be polyfilled and be BC with existing practices, 
and those would have even been fairly standardized already.  Someone 
even made that point, IIRC, and it was quickly rejected.


Whereas as a stand-alone syntax, it offers a much better distinction 
between "metadata that affects code execution" and "stuff for humans to 
read" (both for parsers and for humans).  It gives us much more 
flexibility to implement a meaningful API.  It completely avoids the 
"but comments shouldn't be code" question (which is a bigger deal than 
you'd think; it was one of the drivers behind the Backdrop fork of 
Drupal. I'm not kidding.)


That one of the lead authors of the most widely used comment-based 
annotation system in PHP is arguing what a terrible idea a comment-based 
annotation system is should carry a great deal of weight.


--
--Larry Garfield


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

Re: [PHP-DEV] Native Annotation Syntax

[Rowan Collins]

Rowan Collins wrote on 25/11/2015 18:47:

Simple: remove that configuration variable, and always save doc blocks.


Thinking about it, you don't even need to do that, just add a structure 
in the opcache memory layout for the parsed annotations, allowing you to 
accelerate access to those. (Something you'd have to do anyway if the 
syntax was outside the docblock.)


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

Re: [PHP-DEV] Native Annotation Syntax

[Larry Garfield]

On 11/25/15 11:00 AM, Rowan Collins wrote:
I don't feel that strongly in favour of docblocks, but I don't think 
the reasons given against are particularly strong.


Regards,


If you don't feel strongly in favor of them, why are you trying to make 
a case for them so strongly?  Just for kicks?  We don't need a "devil's 
advocate" at this point in the discussion...


--
--Larry Garfield


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

Re: [PHP-DEV] Native Annotation Syntax

[Pedro Cordeiro]

On top of it, it'd break obfuscators like Zend Guard.

2015-11-25 15:58 GMT-02:00 guilhermebla...@gmail.com <
guilhermebla...@gmail.com>:

> I can give you a good argument.
>
> opcache.save_comments=0
>
> Make it work.
>
> On Wed, Nov 25, 2015 at 12:48 PM, Rowan Collins 
> wrote:
>
> > Larry Garfield wrote on 25/11/2015 17:39:
> >
> >> On 11/25/15 11:00 AM, Rowan Collins wrote:
> >>
> >>> I don't feel that strongly in favour of docblocks, but I don't think
> the
> >>> reasons given against are particularly strong.
> >>>
> >>> Regards,
> >>>
> >>
> >> If you don't feel strongly in favor of them, why are you trying to make
> a
> >> case for them so strongly?  Just for kicks?  We don't need a "devil's
> >> advocate" at this point in the discussion...
> >>
> >>
> > Hi Larry,
> >
> > I don't *feel* strongly in favour or against them, but can see advantages
> > and disadvantages on both sides. Feeling strongly is not the same as
> having
> > a strong argument for your point of view, so just because some people
> have
> > expressed strong opinions against, I don't see why I shouldn't challenge
> > their reasoning, even if that does mean playing devil's advocate.
> >
> > Which is better: basing the decision on the gut feeling of a handful of
> > people who happen to be here now, or basing it on sound reasoning after
> > thinking through the implications?
> >
> > Regards,
> > --
> > Rowan Collins
> > [IMSoP]
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
>
> --
> Guilherme Blanco
> MSN: guilhermebla...@hotmail.com
> GTalk: guilhermeblanco
> Toronto - ON/Canada
>

Re: [PHP-DEV] Native Annotation Syntax

[Rowan Collins]

Larry Garfield wrote on 25/11/2015 17:39:

On 11/25/15 11:00 AM, Rowan Collins wrote:
I don't feel that strongly in favour of docblocks, but I don't think 
the reasons given against are particularly strong.


Regards,


If you don't feel strongly in favor of them, why are you trying to 
make a case for them so strongly?  Just for kicks?  We don't need a 
"devil's advocate" at this point in the discussion...




Hi Larry,

I don't *feel* strongly in favour or against them, but can see 
advantages and disadvantages on both sides. Feeling strongly is not the 
same as having a strong argument for your point of view, so just because 
some people have expressed strong opinions against, I don't see why I 
shouldn't challenge their reasoning, even if that does mean playing 
devil's advocate.


Which is better: basing the decision on the gut feeling of a handful of 
people who happen to be here now, or basing it on sound reasoning after 
thinking through the implications?


Regards,
--
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] Scalar Type Declaration Syntax Weirdness

[Andrea Faulds]

Hi,

Xinchen Hui wrote:

Hey:

On Wed, Nov 25, 2015 at 5:57 PM, Nikita Popov  wrote:



Imho this additional change is not necessary, it only makes the parser
more complicated.

However something missing from the original patch is handling of relative
names like namespace\int. Instead of checking for ast->attr == ZEND_NAME_FQ
it should check for ast->attr != ZEND_NAME_NOT_FQ.



PS: However, namespace\int will result error while checking valid
classname, as int is reserved keywords.

so I think check for == ZEND_NAME_FQ is enough here.



This is how I feel as well. You can't make a class with that name anyway 
(at least for now), so we don't need to prohibit it. \int was a problem 
because it was interpreted the same as 'int'.


Thanks.

--
Andrea Faulds
http://ajf.me/

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

Re: [PHP-DEV] Native Annotation Syntax

[Rowan Collins]

On 25 November 2015 19:02:37 GMT, "guilhermebla...@gmail.com" 
 wrote:
>Hi Rowan,
>
>If you're in a shared hosting, you can't "simply" remove the
>configuration
>variable.
>Relying on extensions or configuration flags to support core language
>features is very bad. We don't have flags that can turn IF support off
>for
>example, why we would have that for annotations?

I think you misunderstood: I didn't mean that users would need to turn that 
feature off, I meant that that feature would be removed, and docblocks would 
always be saved. 


>I can bring more cons if you want... like how/when to parse "use" calls
>in
>a docblock

In exactly the same place you'd parse them outside a docblock.

I really don't understand all these arguments about the parsing being harder. 
The only difference is that you're parsing /** @Foo */ instead of <> or 
whatever other syntax anyone comes up with.

Really the only difference is that a docblock means sharing with other metadata 
(directives for generating documentation). Which has the advantage of being 
polyfillable from older versions of PHP, but the disadvantage of not being as 
clearly separated as a new type of syntax. Oh, and the perception, right or 
wrong, that docblocks are "just comments", rather than metadata containers, 
which Drupal's experience may demonstrate is more important than a purely 
rational analysis would suggest.

All the other details about how this or that tool will adapt, how whitespace 
and multiline values should be handled, etc, are going to need just as much 
thought whatever the syntax looks like.

Regards,

-- 
Rowan Collins
[IMSoP]

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

[PHP-DEV] Re: [PHP-CVS] tag php-src: create tag php-7.0.0RC8

[Sebastian Bergmann]

On 11/25/2015 04:10 AM, Anatol Belski wrote:

Tag php-7.0.0RC8 in php-src.git was created
Tag: 4db85e9fedda7d177737cbfeb1cf3096cb4d3bc4
Tagger:  Anatol Belski Wed Nov 25 04:10:51 2015 +0100
Log:
Tag for 7.0.0RC8


 Why were 569763cb1ac67f56e7743062ca8b3b7c650c1254 and
 00865ae22f2c5fdee9e500ce79d442467e0a0899 not merged into PHP-7.0.0 and
 thus not part of 7.0.0RC8?

 The consensus on the mailinglist seemed to me that the "scalar type
 declaration syntax weirdness" that I brought to the list's attention
 must not make it into PHP 7.0.0.

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

RE: [PHP-DEV] Re: Scalar Type Declaration Syntax Weirdness

[Anatol Belski]

Hi Stas,

> -Original Message-
> From: Stanislav Malyshev [mailto:smalys...@gmail.com]
> Sent: Tuesday, November 24, 2015 6:28 PM
> To: Andrea Faulds ; internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: Scalar Type Declaration Syntax Weirdness
> 
> Hi!
> 
> > It can't wait for 7.0.1, because banning this would be a
> > backwards-compatibility break with 7.0.0. We have to fix it in 7.0.0
> > or not fix it ever.
> 
> In theory, yes. In practice, if somebody starts using 7.0.0 and immediately 
> jumps
> to using \int, I don't feel too bad for breaking that code. We can put a note 
> in
> release notes for this is needed. But the risk of changing syntax parts on the
> brink of GA IMHO is much larger than the risk of somebody using \int in 7.0.0
> and getting breakage in 7.0.1. Especially if it's clearly described as a bug 
> we
> intend to fix.
> 
that's my point as well. There is a clear documentation about type hints, usage 
of an undocumented way is out of scope of BC. Using \int means there were a 
"class int{}" which is prohibited. Of course it is a bug after all, which will 
be addressed.

Regards

Anatol


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

[PHP-DEV] RE: [PHP-CVS] tag php-src: create tag php-7.0.0RC8

[ab]

Hi Sebastian,

> -Original Message-
> From: Sebastian Bergmann [mailto:sebast...@php.net]
> Sent: Wednesday, November 25, 2015 10:18 AM
> To: Anatol Belsk 
> Cc: internals@lists.php.net
> Subject: Re: [PHP-CVS] tag php-src: create tag php-7.0.0RC8
> 
> On 11/25/2015 04:10 AM, Anatol Belski wrote:
> > Tag php-7.0.0RC8 in php-src.git was created
> > Tag: 4db85e9fedda7d177737cbfeb1cf3096cb4d3bc4
> > Tagger:  Anatol Belski Wed Nov 25 04:10:51 2015 
> > +0100
> > Log:
> > Tag for 7.0.0RC8
> 
>   Why were 569763cb1ac67f56e7743062ca8b3b7c650c1254 and
>   00865ae22f2c5fdee9e500ce79d442467e0a0899 not merged into PHP-7.0.0
> and
>   thus not part of 7.0.0RC8?
> 
>   The consensus on the mailinglist seemed to me that the "scalar type
>   declaration syntax weirdness" that I brought to the list's attention
>   must not make it into PHP 7.0.0.
Yes, because I didn't want to go with 569763cb1ac67f56e7743062ca8b3b7c650c1254 
without a proper review. And for GA it doesn't seem to be critical enough, 
please see also my reply in that thread.

Regards

Anatol


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

Re: [PHP-DEV] Scalar Type Declaration Syntax Weirdness

[Nikita Popov]

On Wed, Nov 25, 2015 at 4:47 AM, Xinchen Hui  wrote:

> Hey:
>
>
>
> On Wed, Nov 25, 2015 at 4:49 AM, Bob Weinand  wrote:
>
> > > Am 24.11.2015 um 20:30 schrieb Matteo Beccati :
> > >
> > > On 24/11/2015 18:50, Andrea Faulds wrote:
> > >> There's no syntax change. We'd be adding another fatal error to
> > >> zend_compile.c triggered by a flag on the token. No messing around
> with
> > >> the parser.
> > >>
> > >> I understand your concern about the risk, but it's the kind of change
> > >> that wouldn't break anything without it being tremendously obvious.
> > >
> > > I agree and we should be still in time for RC8.
> > >
> > >
> > > Cheers
> > > --
> > > Matteo Beccati
> >
> > Hey,
> >
> > I fixed the issue via
> >
> http://git.php.net/?p=php-src.git;a=commitdiff;h=569763cb1ac67f56e7743062ca8b3b7c650c1254
> >
> > I think too this should go into PHP 7.0.0 as it is some type of a
> language
> > related change (even if not directly failing in parser...)
> >
> >
> I've made a improvement to the fix(
>
> https://github.com/php/php-src/commit/00865ae22f2c5fdee9e500ce79d442467e0a0899
> )
> ,
>
> before this, \array will result a syntax , but \int result a compiler
> error, which seems a little in-consistent.
>

Imho this additional change is not necessary, it only makes the parser more
complicated.

However something missing from the original patch is handling of relative
names like namespace\int. Instead of checking for ast->attr == ZEND_NAME_FQ
it should check for ast->attr != ZEND_NAME_NOT_FQ.

Nikita

Re: [PHP-DEV] Scalar Type Declaration Syntax Weirdness

[Xinchen Hui]

Hey:

On Wed, Nov 25, 2015 at 5:57 PM, Nikita Popov  wrote:

> On Wed, Nov 25, 2015 at 4:47 AM, Xinchen Hui  wrote:
>
>> Hey:
>>
>>
>>
>> On Wed, Nov 25, 2015 at 4:49 AM, Bob Weinand  wrote:
>>
>> > > Am 24.11.2015 um 20:30 schrieb Matteo Beccati :
>> > >
>> > > On 24/11/2015 18:50, Andrea Faulds wrote:
>> > >> There's no syntax change. We'd be adding another fatal error to
>> > >> zend_compile.c triggered by a flag on the token. No messing around
>> with
>> > >> the parser.
>> > >>
>> > >> I understand your concern about the risk, but it's the kind of change
>> > >> that wouldn't break anything without it being tremendously obvious.
>> > >
>> > > I agree and we should be still in time for RC8.
>> > >
>> > >
>> > > Cheers
>> > > --
>> > > Matteo Beccati
>> >
>> > Hey,
>> >
>> > I fixed the issue via
>> >
>> http://git.php.net/?p=php-src.git;a=commitdiff;h=569763cb1ac67f56e7743062ca8b3b7c650c1254
>> >
>> > I think too this should go into PHP 7.0.0 as it is some type of a
>> language
>> > related change (even if not directly failing in parser...)
>> >
>> >
>> I've made a improvement to the fix(
>>
>> https://github.com/php/php-src/commit/00865ae22f2c5fdee9e500ce79d442467e0a0899
>> )
>> ,
>>
>> before this, \array will result a syntax , but \int result a compiler
>> error, which seems a little in-consistent.
>>
>
> Imho this additional change is not necessary, it only makes the parser
> more complicated.
>
> However something missing from the original patch is handling of relative
> names like namespace\int. Instead of checking for ast->attr == ZEND_NAME_FQ
> it should check for ast->attr != ZEND_NAME_NOT_FQ.
>

PS: However, namespace\int will result error while checking valid
classname, as int is reserved keywords.

so I think check for == ZEND_NAME_FQ is enough here.

thanks

>
>

>
> Nikita
>



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

Re: [PHP-DEV] 7.0.0 release

[Ferenc Kovacs]

On Tue, Nov 24, 2015 at 5:07 PM, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:

> +1 on (a)
>
> It's perfectly normal to have issues fixed between last RC and GA.
>
> []s,


it's not a clear cut.
you can get away with doing that but the point of the RCs is that allow the
general public to test and spot problems before the GA release.
if your GA isn't made from the last RC there is a chance that those changes
introduced since the last RC have problems which the general public did not
have a chance to find and report.
for the php project we prefer having the GA releases done from the RC and
we usually more strict about this when preparing the .0 release.
(for the record this is also how golden master originally was defined:
http://techterms.com/definition/goldenmaster )


-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Native Annotation Syntax

[Pedro Cordeiro]

I'd really like to see something outside the docblock. Comment annotations
are a workaround for the lack of native annotations. It makes the
environment hard to learn ("What does @param do? And what does @ManyToMany
do?"), it makes it impossible for IDEs to hint/autocomplete without
project-specific plugins, and adds this odd notion that removing some
comment blocks might break an app (which is just awful).

@beberlei, I had searched through the archives already and couldn't find
the vote. I found the discussion (in which many people advocated for
docblock annotations), but didn't find the vote.

I feel like this is a major feature that's missing, and people are using it
in a suboptimal way (docblocks), so I thought I'd reopen the discussion and
see if someone more familiar with the internals feels like implementing it
(I don't feel confident enough since I've never tried messing with into the
internals).

2015-11-24 22:31 GMT-02:00 Sara Golemon :

> On Tue, Nov 24, 2015 at 11:05 AM, Rowan Collins 
> wrote:
> > At first sight, these seem like details which could be tweaked later, but
> > they make a difference to what syntax to standardise: is the annotation
> name
> > just a string, or a valid class name? is the value of the annotation
> just a
> > string, or a parseable PHP expression? is it more useful to use the de
> facto
> > existing syntax in DocBlocks, or to add a new keyword or operator? etc
> >
> If we're going to use something in the docblock, then I wouldn't want
> it parsed on compilation, but rather have it be an on-demand parse
> while reflecting.  The reason being that there are plenty of
> docblock'd PHP libraries out there using invalid annotations because
> they're not running it through tools to tell them what they got wrong.
> Waiting till they've actually tried to examine it through reflection
> lets us throw an exception on code that cares about it rather than
> preventing code which ignores reflection from running.
>
> I, for one, am a fan of Java style annotations which allow a string
> name plus optional metadata.
>
> @@foo
> class Bar {
>   @@Baz("something", 123, [ 'a', 'b', ''c'])
>   public function qux() { ... }
> }
>
> Though the formality of having to define the annotation as an
> interface is a bit overkill for PHP, the same rules Hack uses would be
> clear and simple enough:
>
> <>
> class Bar {
>   <>
>   public function qux() { ... }
> }
>
> And no, I'm not picky about the parser symbol used...  In fact,
> allowing an optional '//' prefix to annotations might be nice for
> compatibility.
>
> -Sara
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Scalar Type Declaration Syntax Weirdness

[Xinchen Hui]

Hey:


On Wed, Nov 25, 2015 at 5:57 PM, Nikita Popov  wrote:

> On Wed, Nov 25, 2015 at 4:47 AM, Xinchen Hui  wrote:
>
>> Hey:
>>
>>
>>
>> On Wed, Nov 25, 2015 at 4:49 AM, Bob Weinand  wrote:
>>
>> > > Am 24.11.2015 um 20:30 schrieb Matteo Beccati :
>> > >
>> > > On 24/11/2015 18:50, Andrea Faulds wrote:
>> > >> There's no syntax change. We'd be adding another fatal error to
>> > >> zend_compile.c triggered by a flag on the token. No messing around
>> with
>> > >> the parser.
>> > >>
>> > >> I understand your concern about the risk, but it's the kind of change
>> > >> that wouldn't break anything without it being tremendously obvious.
>> > >
>> > > I agree and we should be still in time for RC8.
>> > >
>> > >
>> > > Cheers
>> > > --
>> > > Matteo Beccati
>> >
>> > Hey,
>> >
>> > I fixed the issue via
>> >
>> http://git.php.net/?p=php-src.git;a=commitdiff;h=569763cb1ac67f56e7743062ca8b3b7c650c1254
>> >
>> > I think too this should go into PHP 7.0.0 as it is some type of a
>> language
>> > related change (even if not directly failing in parser...)
>> >
>> >
>> I've made a improvement to the fix(
>>
>> https://github.com/php/php-src/commit/00865ae22f2c5fdee9e500ce79d442467e0a0899
>> )
>> ,
>>
>> before this, \array will result a syntax , but \int result a compiler
>> error, which seems a little in-consistent.
>>
>
> Imho this additional change is not necessary, it only makes the parser
> more complicated.
>
> However something missing from the original patch is handling of relative
> names like namespace\int. Instead of checking for ast->attr == ZEND_NAME_FQ
> it should check for ast->attr != ZEND_NAME_NOT_FQ.
>
> yeah, you are right,  namespace\array still behavior difference from
namespace\int.

I am going to revert my part.

thanks

> Nikita
>



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

[PHP-DEV] Benchmark Results for PHP Master 2015-11-25

[lp_benchmark_robot]

Results for project PHP master, build date 2015-11-25 05:26:40+02:00
commit: 283e9ea21bb980513d86c5273bebc01b5eb2b52c
revision date:  2015-11-25 03:40:55+01: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.0beta3, with hash
1674bd9b151ff389fb8c9fc223bc6aafdd49ff2c from 2015-08-05 04:56:40+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.49% -0.78%  2.00%  
  7.95%
:-|   Drupal 7.36 cgi -T1  1.59% -0.02% -0.10%  
  5.04%
:-)   MediaWiki 1.23.9 cgi -T5000  0.37% -0.29%  1.57%  
  4.37%
:-( bench.php cgi -T1  0.10% -1.42%  1.27%  
  7.03%
:-)   micro_bench.php cgi -T1  0.01%  1.45%  1.84%  
  4.59%
:-(mandelbrot.php cgi -T1  0.12% -1.34% -0.48%  
  8.48%
---
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.
* Relative Standard Deviation (Standard Deviation/Average)

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

[PHP-DEV] Re: libtool builds CLI/CGI php from PIC object files

[Dmitry Stogov]

hi,

On Wed, Nov 25, 2015 at 3:43 PM, Andone, Bogdan 
wrote:

> Hi Dmitry,
>
>
>
> Here is a PR trying to solve the problem:
> https://github.com/php/php-src/pull/1650
>
> Let me know if I missed something.
>

Yeah. This approach should work.

Using non-PIC object files instead of PIC for linking executable programs
make it about 2% faster on Linux x86_64.
I have no idea about disadvantages. May be ASLR.
For some reason libtool always use PIC objects, and even don't provide a
simple way to switch to non-PIC.

Nikita, are you familiar with libtool hacking?
May be we have some experts on @internals?

Thanks. Dmitry.


>
>
> Kind Regards,
>
> Bogdan
>
>
>
> *From:* Andone, Bogdan
> *Sent:* Tuesday, November 24, 2015 1:29 PM
> *To:* 'Dmitry Stogov'
> *Cc:* jit-project
> *Subject:* RE: libtool builds CLI/CGI php from PIC object files
>
>
>
> *From:* Dmitry Stogov [mailto:dmi...@zend.com ]
> *Sent:* Tuesday, November 24, 2015 1:00 PM
> *To:* Andone, Bogdan
> *Cc:* jit-project
> *Subject:* Re: libtool builds CLI/CGI php from PIC object files
>
>
>
>
>
>
>
> On Tue, Nov 24, 2015 at 12:16 PM, Andone, Bogdan 
> wrote:
>
> Hi Dmitry,
>
>
>
> I spent some time for understanding how auto tools work on PHP and I have
> some ideas on how to tweak libtool and Makefile for using static objects on
> x86 executables builds on linux.
>
>
>
> It seems it should be quite easy to switch to non-PIC objects modifying
> sapi/cli/config.m4.
>
> "darwin" already uses non-PIC objects and we may creae similar case for
> X86_64.
>
> But I don't know if this is 100% safe.
>
>
>
> *[BA] *The solution I was thinking involves two parts:
>
> -Tweak acinclude.m4 for not inhibiting anymore static object
> compiling with libtool (as libtool compiles by default both PIC and non PIC
> versions); in this way we get both shared and static objects; shared
> objects will always be needed for linking libphp7, I think.
>
> -Rework the Makefile for using .o instead of .lo objects for
> php-fpm, php-cgi and php-cli (this will touch config.m4 files and also
> configure.in)
>
>
>
> Kind Regards,
>
> Bogdan
>
> My current concerns are related to the fact that I am not sure how these
> tweaks will impact the diversity of possible PHP configurations on the
> multitude of platforms.
>
>
>
> I tried to get some feedback on the topic on the internals discussion list
> but I didn’t get any reply; I assume people are highly focused on releasing
> PHP7 and low energy for unrelated subjects.
>
>
> I afraid, nobody in PHP community know this.
>
> This is more a question to "libtool" developers.
>
> It tried to find information in Internet (why they use PIC objects to
> build executables, and even don't provide an option to use non-PIC ones),
> but without success. :(
>
>
>
> Thanks. Dmitry.
>
>
>
>
> It would be good to have a contact person knowing the history of
> libtool/autoconf. Otherwise, I will probably use the trial and error hard
> way: provide a proposal and see who reacts J.
>
>
>
> Thanks,
>
> Bogdan
>
>
>
> *From:* Dmitry Stogov [mailto:dmi...@zend.com]
> *Sent:* Monday, November 23, 2015 11:23 PM
> *To:* Andone, Bogdan; jit-project
> *Subject:* libtool builds CLI/CGI php from PIC object files
>
>
>
> Hi,
>
> I just verified Bogdan's research related to CLI/CGI build on x86_64.
>
> libtools really builds programs from PIC object files.
>
> I tried to manually rebuild them using non-PIC objects for Zend/* files
> and got 2% improvement on bench.php and Wordpress.
>
> BTW I didn't find a standard way to tell "libtools" not to use PIC files.
>
> On x86 it's possible to use '--without-pic' configure option, but it can't
> work on x86_64 if we build any shared libraries.
>
>
>
> Thanks. Dmitry.
>
>
>
>
>