Re: [PHP-DEV] [RFC] Reflection annotations reader

[guilhermebla...@gmail.com]

But I can add more.

Filtering
Validation
Form declaration
Database mapping
Joinpoint definitions (AOP)
Service Injection (look at FLOW3)
Testing
etc

Basically everything can define constraints or usage of an element,
behavior, process or nature of an element.
Let me give some individual examples:

Constraints: @MinLength, @NotNull
Behavior: @Transactional, @Inject
Process: @Column, @XmlElement, @OneToOne
Nature: @Entity, @Table, @WebService, @TestCase

Makes more sense now?


On Wed, Jan 9, 2013 at 1:01 AM, Mike van Riel wrote:

> On 09.01.2013 02:38, Rasmus Schultz wrote:
>
>> A native implementation of PHP-DOC block parser for run-time purposes
>> (annotation libraries) is already available in the Reflection API,
>>
>
> There is no DocBlock parser in the Reflection API; you can merely
> retrieve the T_DOC_COMMENT token.
>
>
>  and
>> already goes as deep as it needs to - going beyond simply finding and
>> extracting the docblocks would make little sense, as every annotation
>> library has it's own individual syntax, behaviors and features.
>>
>
> There are other types of project that benefit from the parsing of the
> actual DocBlock without any support for Annotations. Examples follow below.
>
>
>  There may
>> be a some libraries that could use a native implementation if it happens
>> to
>> fit their needs, but they most likely won't use it, because (A) they won't
>> win anything by doing so, and (B) these libraries would become
>> incompatible
>> with anything other than bleeding-edge PHP.
>>
>
> I disagree with this,
>
> A) Said applications and libraries win in the terms of performance and
>standardization; this will offer a baseline for IDEs to offer proper
>support for descriptions and tags and even more advanced features.
> B) This issue arises with _any_ new feature that substitutes or empowers
>a userland functionality and I thus consider it a non-argument.
>I am Lead Developer of phpDocumentor and I promise you, I'd use this.
>
>
>  A native implementation of PHP-DOC parser for offline purposes
>> (documentation generators) is already available in userland, does the job
>> fine, and does not rely on the Reflection API (as someone mentioned)
>> because loading every class in a large codebase is not feasible. If you
>> provide a separate PHP-DOC parser, these projects most likely won't use
>> it,
>> because (A) see above and (B) see above.
>>
>
> Performance is key with documentation generators. Since DocBlocks are the
> most prevalent thing in a code base they could win with a core
> implementation.
> Also, as provided earlier, would standardization benefit the whole
> community
> that consumes DocBlocks and IDE vendors.
>
>
>  Who else would need to parse PHP-DOC blocks and why?
>>
>
> * WSDL Generators to extract descriptions and type information
> * REST API documentation generators for the same reason
> * HATEOAS libraries could benefit from the reading of the @uses tag
> * Command Line Application frameworks could use the Command class'
> description
>   for their help screen.
>
> And more uses that I cannot think of within a few seconds.
>
>
>
> --
> 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] [RFC] Reflection annotations reader

[Mike van Riel]

On 09.01.2013 02:38, Rasmus Schultz wrote:

A native implementation of PHP-DOC block parser for run-time purposes
(annotation libraries) is already available in the Reflection API,


There is no DocBlock parser in the Reflection API; you can merely
retrieve the T_DOC_COMMENT token.


and
already goes as deep as it needs to - going beyond simply finding and
extracting the docblocks would make little sense, as every annotation
library has it's own individual syntax, behaviors and features.


There are other types of project that benefit from the parsing of the
actual DocBlock without any support for Annotations. Examples follow 
below.



There may
be a some libraries that could use a native implementation if it 
happens to
fit their needs, but they most likely won't use it, because (A) they 
won't
win anything by doing so, and (B) these libraries would become 
incompatible

with anything other than bleeding-edge PHP.


I disagree with this,

A) Said applications and libraries win in the terms of performance and
   standardization; this will offer a baseline for IDEs to offer proper
   support for descriptions and tags and even more advanced features.
B) This issue arises with _any_ new feature that substitutes or 
empowers

   a userland functionality and I thus consider it a non-argument.
   I am Lead Developer of phpDocumentor and I promise you, I'd use 
this.



A native implementation of PHP-DOC parser for offline purposes
(documentation generators) is already available in userland, does the 
job

fine, and does not rely on the Reflection API (as someone mentioned)
because loading every class in a large codebase is not feasible. If 
you
provide a separate PHP-DOC parser, these projects most likely won't 
use it,

because (A) see above and (B) see above.


Performance is key with documentation generators. Since DocBlocks are 
the
most prevalent thing in a code base they could win with a core 
implementation.
Also, as provided earlier, would standardization benefit the whole 
community

that consumes DocBlocks and IDE vendors.


Who else would need to parse PHP-DOC blocks and why?


* WSDL Generators to extract descriptions and type information
* REST API documentation generators for the same reason
* HATEOAS libraries could benefit from the reading of the @uses tag
* Command Line Application frameworks could use the Command class' 
description

  for their help screen.

And more uses that I cannot think of within a few seconds.


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

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Pierrick Charron]

Unfortunately [] is still not usable because it will introduce syntax
ambiguity with short array syntax. The patch we've done for
annotations would require some small change to work on the new master
version but I can take some time to do it if I see some interest in
the proposal. If someone want to try it how everything would work, a
patched version of the old master (from may) can be founded here :
https://github.com/adoy/php-src/tree/annotations-v3 (tests are in
tests/annotations).

Pierrick

On 8 January 2013 21:10, guilhermebla...@gmail.com
 wrote:
> Hi,
>
> At the time Pierrick and I worked on annotations patch, we couldn't use
> some of the operators due to many different reasons:
> @ = error supressing
> [] = short array syntax
> {} = scopr creation
> : = all sorts of problems you can imagine
> & = array referencing
>
> We actually found that <> was allowed, so we used this one.
> Now that short array syntax has evolved a lot from original patch, maybe []
> is supported again.
>
>
> On Tue, Jan 8, 2013 at 8:08 PM, Rasmus Schultz  wrote:
>
>> I've started working on a new proposal, but I'm getting hung up on the
>> syntax - if we can't use angle brackets anymore, what can we use? Virtually
>> every symbol on a standard US keyword is an operator of some sort, does
>> that mean those are all out of the question?
>>
>> e.g. thinking of concrete possible basic syntax, neither of the following
>> delimiters would work:
>>
>> [Foo('bar')]
>>
>> 
>>
>> {Foo('bar')}
>>
>> And presumably none of the following would work either:
>>
>> ~Foo('bar')
>> @Foo('bar')
>> ^Foo('bar')
>> *Foo('bar')
>> &Foo('bar')
>> :Foo('bar')
>>
>> Can you think of anything that would work?
>>
>>
>> On Tue, Jan 8, 2013 at 3:57 AM, Vladislav Veselinov
>> wrote:
>>
>> > Assume that you have this class with your proposed syntax:
>> >
>> > [SomeAnnotation('somevalue')]
>> > class Test {
>> >
>> > }
>> >
>> > This conflicts with the short array syntax. It looks like an array
>> > containing the result of the function 'SomeAnnotation' invoked with
>> > the parameter 'somevalue'.
>> > The only difference is the missing ";" but relying on this to
>> > determine whether this is an annotation or not would be insane.
>> > I'd support such a decision but with other syntax.
>> >
>> > I like Guilherme's RFC. I just don't think that the syntax is very
>> PHPish.
>> >
>> >
>>
>
>
>
> --
> Guilherme Blanco
> MSN: guilhermebla...@hotmail.com
> GTalk: guilhermeblanco
> Toronto - ON/Canada

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

Re: [PHP-DEV] [RFC] Reflection annotations reader

[guilhermebla...@gmail.com]

Hi,

At the time Pierrick and I worked on annotations patch, we couldn't use
some of the operators due to many different reasons:
@ = error supressing
[] = short array syntax
{} = scopr creation
: = all sorts of problems you can imagine
& = array referencing

We actually found that <> was allowed, so we used this one.
Now that short array syntax has evolved a lot from original patch, maybe []
is supported again.


On Tue, Jan 8, 2013 at 8:08 PM, Rasmus Schultz  wrote:

> I've started working on a new proposal, but I'm getting hung up on the
> syntax - if we can't use angle brackets anymore, what can we use? Virtually
> every symbol on a standard US keyword is an operator of some sort, does
> that mean those are all out of the question?
>
> e.g. thinking of concrete possible basic syntax, neither of the following
> delimiters would work:
>
> [Foo('bar')]
>
> 
>
> {Foo('bar')}
>
> And presumably none of the following would work either:
>
> ~Foo('bar')
> @Foo('bar')
> ^Foo('bar')
> *Foo('bar')
> &Foo('bar')
> :Foo('bar')
>
> Can you think of anything that would work?
>
>
> On Tue, Jan 8, 2013 at 3:57 AM, Vladislav Veselinov
> wrote:
>
> > Assume that you have this class with your proposed syntax:
> >
> > [SomeAnnotation('somevalue')]
> > class Test {
> >
> > }
> >
> > This conflicts with the short array syntax. It looks like an array
> > containing the result of the function 'SomeAnnotation' invoked with
> > the parameter 'somevalue'.
> > The only difference is the missing ";" but relying on this to
> > determine whether this is an annotation or not would be insane.
> > I'd support such a decision but with other syntax.
> >
> > I like Guilherme's RFC. I just don't think that the syntax is very
> PHPish.
> >
> >
>



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

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Clint Priest]

If we had true annotations, its certainly something the engine could put to 
use...  See my previous post in this thread.

-Clint

On Jan 8, 2013, at 7:38 PM, Rasmus Schultz  wrote:

> To summarize:
> 
> A native implementation of PHP-DOC block parser for run-time purposes
> (annotation libraries) is already available in the Reflection API, and
> already goes as deep as it needs to - going beyond simply finding and
> extracting the docblocks would make little sense, as every annotation
> library has it's own individual syntax, behaviors and features. There may
> be a some libraries that could use a native implementation if it happens to
> fit their needs, but they most likely won't use it, because (A) they won't
> win anything by doing so, and (B) these libraries would become incompatible
> with anything other than bleeding-edge PHP.
> 
> A native implementation of PHP-DOC parser for offline purposes
> (documentation generators) is already available in userland, does the job
> fine, and does not rely on the Reflection API (as someone mentioned)
> because loading every class in a large codebase is not feasible. If you
> provide a separate PHP-DOC parser, these projects most likely won't use it,
> because (A) see above and (B) see above.
> 
> Who else would need to parse PHP-DOC blocks and why?
> 
> Bottom line, who is this feature for, what will they do with it, and most
> importantly, why would they use it?
> 
> 
> On Tue, Jan 8, 2013 at 3:55 AM, Stas Malyshev wrote:
> 
>> Hi!
>> 
>>> First of all, there are already plenty of established userland
>>> implementations - so there is really no need for this.
>> 
>> On the contrary, plenty of implementations means there's a need in this
>> functionality, and it might be a good idea to have one standard
>> implementation if it can cover like 80% of use cases.
>> 
>>> 
>>> Whatever you decide on in terms of syntax, most likely won't satisfy
>> every
>>> the needs of every userland annotation library, so at least some of them
>>> most likely won't use it. You'd be creating more work for the maintainers
>>> of these frameworks, and they don't standard to gain anything from that
>>> work.
>> 
>> Since when "it does not satisfy all needs of all users, and some of them
>> may end up not using it" is an argument for not including functionality?
>> And how it's more work for maintainers if they just won't use it?
>> 
>>> On the other hand, I would be interested in having support for actual
>>> annotation syntax (not docblocks) added to PHP. Real annotation syntax
>> 
>> Can we please not hijack the topic? We discussed annotations many times
>> already, if you have better proposal than current RFCs please create
>> your own RFC (or ask one of the current RFC authors for collaboration)
>> and start a new topic
>> 
>> --
>> Stanislav Malyshev, Software Architect
>> SugarCRM: http://www.sugarcrm.com/
>> (408)454-6900 ext. 227
>> 

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

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Rasmus Schultz]

To summarize:

A native implementation of PHP-DOC block parser for run-time purposes
(annotation libraries) is already available in the Reflection API, and
already goes as deep as it needs to - going beyond simply finding and
extracting the docblocks would make little sense, as every annotation
library has it's own individual syntax, behaviors and features. There may
be a some libraries that could use a native implementation if it happens to
fit their needs, but they most likely won't use it, because (A) they won't
win anything by doing so, and (B) these libraries would become incompatible
with anything other than bleeding-edge PHP.

A native implementation of PHP-DOC parser for offline purposes
(documentation generators) is already available in userland, does the job
fine, and does not rely on the Reflection API (as someone mentioned)
because loading every class in a large codebase is not feasible. If you
provide a separate PHP-DOC parser, these projects most likely won't use it,
because (A) see above and (B) see above.

Who else would need to parse PHP-DOC blocks and why?

Bottom line, who is this feature for, what will they do with it, and most
importantly, why would they use it?


On Tue, Jan 8, 2013 at 3:55 AM, Stas Malyshev wrote:

> Hi!
>
> > First of all, there are already plenty of established userland
> > implementations - so there is really no need for this.
>
> On the contrary, plenty of implementations means there's a need in this
> functionality, and it might be a good idea to have one standard
> implementation if it can cover like 80% of use cases.
>
> >
> > Whatever you decide on in terms of syntax, most likely won't satisfy
> every
> > the needs of every userland annotation library, so at least some of them
> > most likely won't use it. You'd be creating more work for the maintainers
> > of these frameworks, and they don't standard to gain anything from that
> > work.
>
> Since when "it does not satisfy all needs of all users, and some of them
> may end up not using it" is an argument for not including functionality?
> And how it's more work for maintainers if they just won't use it?
>
> > On the other hand, I would be interested in having support for actual
> > annotation syntax (not docblocks) added to PHP. Real annotation syntax
>
> Can we please not hijack the topic? We discussed annotations many times
> already, if you have better proposal than current RFCs please create
> your own RFC (or ask one of the current RFC authors for collaboration)
> and start a new topic
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Rasmus Schultz]

I've started working on a new proposal, but I'm getting hung up on the
syntax - if we can't use angle brackets anymore, what can we use? Virtually
every symbol on a standard US keyword is an operator of some sort, does
that mean those are all out of the question?

e.g. thinking of concrete possible basic syntax, neither of the following
delimiters would work:

[Foo('bar')]



{Foo('bar')}

And presumably none of the following would work either:

~Foo('bar')
@Foo('bar')
^Foo('bar')
*Foo('bar')
&Foo('bar')
:Foo('bar')

Can you think of anything that would work?


On Tue, Jan 8, 2013 at 3:57 AM, Vladislav Veselinov
wrote:

> Assume that you have this class with your proposed syntax:
>
> [SomeAnnotation('somevalue')]
> class Test {
>
> }
>
> This conflicts with the short array syntax. It looks like an array
> containing the result of the function 'SomeAnnotation' invoked with
> the parameter 'somevalue'.
> The only difference is the missing ";" but relying on this to
> determine whether this is an annotation or not would be insane.
> I'd support such a decision but with other syntax.
>
> I like Guilherme's RFC. I just don't think that the syntax is very PHPish.
>
>

Re: [PHP-DEV] [RFC] Reflection annotations reader

[guilhermebla...@gmail.com]

Hi internals,

Just like before, people are confusing documentation support with
behavioral support.
No matter what people say, documentation is documentation and code still
behaves the same with and without the comment docblock. When talking about
behavioral marks, removing that piece makes your code crash.

While creating Doctrine Common Annotations, I was forced to add them in the
docblock because there was no way in the language to not place it there.
This is not an excuse to tell everyone now that only because different
tools used docblocks (because of the lack of support), this is now the
standard. It is a hack using the documentation support to add behavioral
support, point made.

Of course it does not invalidate the documentation. Docblocks should still
have a way to be parsed, but that information is static.

I really pushed hard annotations in the past, mainly because I was
foreseeing that many tools would start adopting behavioral support.
Behaviors can be declared by other ways, like XML, YAML or even PHP. But
the fact of bringing things together under different perspectives (read as
aspects) turns a certain piece of code more powerful and informative than
ever.
I wanted to use the term aspects on purpose because that is another subject
that people normally bring in about highly coupled classes. This is
conceptually wrong because if I only want to populate class properties, I
don't even touch other aspects like validation and filtering, so there's no
coupling, since code is used/dependent elsewhere.

Another point that got mentioned in the past was the lack of
standardization of annotations, which would lead different projects a good
portion of time to refactor to accommodate possible new support. Currently,
the status is quite different from 2010.
Now, except phpunit, almost all major projects are pointing to Doctrine
Common Annotations. Some examples are Doctrine itself, Symfony, Zend
Framework, Drupal, PPI, Flow3 and many others that I can bring here. It
does seem to me that language requires this functionality like 2 years ago,
and everyone is paying the price by using a hacked solution that now people
claim it's the standard. No, it's not the standard and it will never be.
What happened is that annotations indeed became a standard in PHP using a
hack due to the lack of support in core and it seems more and more we delay
the inclusion it will get worse to remove this hack because of this
"standardization". I wonder if that was the idea back in 2010, or maybe if
it was due to the lack of knowledge, interest or willingness.
For those still wondering how it could be applied, here are some links:
http://drupal.org/node/1882526
http://docs.doctrine-project.org/projects/doctrine-common/en/latest/reference/annotations.html
https://packages.zendframework.com/docs/latest/manual/en/modules/zend.form.quick-start.html#using-annotations
http://symfony.com/doc/master/book/validation.html

I think we should split this discussion to 2 points. One that details
Annotations support for the language and a second one, as a PECL extension
that add Docblock parsong support.

For Annotations, I recommend that you guys that a look at RFC I created
back in 2010: https://wiki.php.net/rfc/annotations
The docblock one (https://wiki.php.net/rfc/annotations-in-docblock) was
abandoned because I faced different problems that couldn't fix without
requiring a more powerful solution.

So, do you guys wanna discuss again this possible inclusion?



On Tue, Jan 8, 2013 at 5:42 PM, Yahav Gindi Bar  wrote:

> > If I read this thread correctly then almost everyone agrees that PHPUnit,
> > Symfony, ZF, Doctrine, etc, all use annotations in the DocBlock because
> > there
> > is no available alternative that enables them to use annotations.
> >
>
> Yes, I understood that too.
>
>
> As far as I am concerned I'd separate this topic into a DocBlock parser
> (that
> might take into account the current state of affairs with DocBlock
> Annotations)
> and actual Annotation support.
>
> I agree.
>
>
> I disagree with the above, documentation generators are _unable_ to use the
> > Reflection library of PHP due to issues with Dynamic Reflection and the
> > processing of a large amount of files (report on request) with it.
> >
> > To phpDocumentor and related projects it would be imperative that a
> > DocBlock parser is available without having to use the Reflection
> > extension.
> >
>
> Even so, I think that a pointer to that function should be present in the
> Reflection, so even if we got SPL parser, one could access it using
> Reflection since it's the obvious way he/she would look for that.
>
>
>
>
> On Tue, Jan 8, 2013 at 11:51 PM, Rafael Dohms  >wrote:
>
> > On Tue, Jan 8, 2013 at 10:37 PM, Stas Malyshev  > >wrote:
> >
> > > Hi!
> > >
> > > > Everyone I talked to who implemented annotations in docblocks did it
> > > > as hack because there is no native support. This is not something
> that
> > > > belongs to docblocks. It would be nice 

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Stas Malyshev]

Hi!

> This functionality parses doccomments and doccomments can be obtained
> through various ways. Reflection is only one. Docblocks can just as well
> come from parsing the files. If this would be tightly bound to the

You can also get functions, classes, etc. from parsing the files. But
from inside PHP you usually do not, you use Reflection.

> reflection mechanisms then it would become useless for many
> applications, e.g. phpDocumentor et al couldn't use this (if I'm not
> much mistaken).

phpDocumentor is using custom PHP parser anyway, so whatever we do in
core is not very relevant for it, at least in its current state.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

Re: [PHP-DEV] File-Paths exceeding MAX_PATH on Windows

[Pierre Joye]

On Tue, Jan 8, 2013 at 10:06 PM, Nicolai Scheer
 wrote:
> Hi again!
>
>
> On 8 January 2013 14:56, Nicolai Scheer  wrote:
>>
>>
>> Do you have any advice how I can move lill' pandora to an extension? Of
>> course I might copy the complete simple_file_wrapper, but I'd rather not do
>> it that way... I did not find any "add standard stream context option"-stuff
>> in the API...
>>
>
> I did finish to write a small extension this evening, which does what I want
> :)
>
> I just saved a copy of the php_plain_files_wrapper struct, deregistered the
> file wrapper during my MINIT, injected my own functions into the struct and
> registered it again.
> My own functions just wrap the original ones (using the saved original
> function pointers), adjust STREAM_ASSUME_REALPATH and add the prefix if
> necessary.
>
> Adjustments only kick in for paths exceeding MAX_PATH, so if all paths are
> within the usually allowed bounds, everything is back to original.
>
> Quick and dirty, but it works very well and is a feasible way for our
> project... until there's a better way :)

nice :) that's exactly what I meant earlier, much easier than
implementing a wrapper and safer than allowing special paths. Now be
sure to do not mess with the libs :)

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Yahav Gindi Bar]

> If I read this thread correctly then almost everyone agrees that PHPUnit,
> Symfony, ZF, Doctrine, etc, all use annotations in the DocBlock because
> there
> is no available alternative that enables them to use annotations.
>

Yes, I understood that too.


As far as I am concerned I'd separate this topic into a DocBlock parser
(that
might take into account the current state of affairs with DocBlock
Annotations)
and actual Annotation support.

I agree.


I disagree with the above, documentation generators are _unable_ to use the
> Reflection library of PHP due to issues with Dynamic Reflection and the
> processing of a large amount of files (report on request) with it.
>
> To phpDocumentor and related projects it would be imperative that a
> DocBlock parser is available without having to use the Reflection
> extension.
>

Even so, I think that a pointer to that function should be present in the
Reflection, so even if we got SPL parser, one could access it using
Reflection since it's the obvious way he/she would look for that.




On Tue, Jan 8, 2013 at 11:51 PM, Rafael Dohms wrote:

> On Tue, Jan 8, 2013 at 10:37 PM, Stas Malyshev  >wrote:
>
> > Hi!
> >
> > > Everyone I talked to who implemented annotations in docblocks did it
> > > as hack because there is no native support. This is not something that
> > > belongs to docblocks. It would be nice if you could take a look at the
> > > c# doc, there are really good concepts there.
> >
> > I know why they did it, and we already discussed that stuff in the last
> > annotation discussion. What I mean here is that presenting it as if the
> > notion of meaningful comments is completely unheard of in PHP and nobody
> > expects it is just wrong. Maybe it was so years ago, but it is
> > definitely not true now - de-facto meaningful comments *are* the
> > standard now, and have a lot of use, and nobody with any experience is
> > surprised by them. Regardless of *why* is it so, it is a fact.
> >
> > Stas,
>
> That still does not make it the right place. Annotations went into
> docblocks
> because it was the only place reflection could provide the needed
> information at
> runtime. Just because we now treat docblocks as 1st class citizens does not
> mean annotations should be there.
>
> Does that mean that annotations should be in docblocks and not in core
> for the reason of "we all know docblocks exist". I would seriously expect
> at the very least a stronger reason. These were some of the ones i heard
> before:
>
> 1. The syntax is crap: this is solvable, let's find the right syntax
> 2. PHP does not need it: i think we have proven the use already, every
> major FW has a
> implementation of this, there is clearly demand.
>
> So if we are going to get anywhere with this discussion I suggest getting
> back to
> the original RFC and working on solving the issues instead of discussing
> developer folklore.
>
> --
> Rafael Dohms
> PHP Evangelist and Community Leader
> http://doh.ms
> http://wwwamsterdamphp.nl
>

I, too, think that we should re-consider using Annotation. This feature
proved itself as usable
My opinion is that we should separate this discussion into two fields which
will get their own RFC:
- We should recreate / reconsider the Annotation feature. It proved itself
as something that developers wish to get, and they mix between abilities
(the ability to write documentation in userland) just to achieve that
because we didn't provided that.
- A doc-block parser (in SPL, core or whatever) that can analyze the
doc-comment and separate it. I think that we should still implement this
even if we'll have Annotation because this is a usable feature in PHP that
can give information for writing API's and such. However, in case
Annotations will be implemented - I understand that you may say that my
argument is weak.

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Pierre Joye]

On Tue, Jan 8, 2013 at 10:37 PM, Stas Malyshev  wrote:
> Hi!
>
>> Everyone I talked to who implemented annotations in docblocks did it
>> as hack because there is no native support. This is not something that
>> belongs to docblocks. It would be nice if you could take a look at the
>> c# doc, there are really good concepts there.
>
> I know why they did it, and we already discussed that stuff in the last
> annotation discussion. What I mean here is that presenting it as if the
> notion of meaningful comments is completely unheard of in PHP and nobody
> expects it is just wrong. Maybe it was so years ago, but it is
> definitely not true now - de-facto meaningful comments *are* the
> standard now, and have a lot of use, and nobody with any experience is
> surprised by them. Regardless of *why* is it so, it is a fact.

Just like any feature not implemented and created using php scripts.
That does not mean we have to use the same hacks to provide native
annotations support. Really not.


--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Rafael Dohms]

On Tue, Jan 8, 2013 at 10:37 PM, Stas Malyshev wrote:

> Hi!
>
> > Everyone I talked to who implemented annotations in docblocks did it
> > as hack because there is no native support. This is not something that
> > belongs to docblocks. It would be nice if you could take a look at the
> > c# doc, there are really good concepts there.
>
> I know why they did it, and we already discussed that stuff in the last
> annotation discussion. What I mean here is that presenting it as if the
> notion of meaningful comments is completely unheard of in PHP and nobody
> expects it is just wrong. Maybe it was so years ago, but it is
> definitely not true now - de-facto meaningful comments *are* the
> standard now, and have a lot of use, and nobody with any experience is
> surprised by them. Regardless of *why* is it so, it is a fact.
>
> Stas,

That still does not make it the right place. Annotations went into docblocks
because it was the only place reflection could provide the needed
information at
runtime. Just because we now treat docblocks as 1st class citizens does not
mean annotations should be there.

Does that mean that annotations should be in docblocks and not in core
for the reason of "we all know docblocks exist". I would seriously expect
at the very least a stronger reason. These were some of the ones i heard
before:

1. The syntax is crap: this is solvable, let's find the right syntax
2. PHP does not need it: i think we have proven the use already, every
major FW has a
implementation of this, there is clearly demand.

So if we are going to get anywhere with this discussion I suggest getting
back to
the original RFC and working on solving the issues instead of discussing
developer folklore.

-- 
Rafael Dohms
PHP Evangelist and Community Leader
http://doh.ms
http://wwwamsterdamphp.nl

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Stas Malyshev]

Hi!

> Everyone I talked to who implemented annotations in docblocks did it
> as hack because there is no native support. This is not something that
> belongs to docblocks. It would be nice if you could take a look at the
> c# doc, there are really good concepts there.

I know why they did it, and we already discussed that stuff in the last
annotation discussion. What I mean here is that presenting it as if the
notion of meaningful comments is completely unheard of in PHP and nobody
expects it is just wrong. Maybe it was so years ago, but it is
definitely not true now - de-facto meaningful comments *are* the
standard now, and have a lot of use, and nobody with any experience is
surprised by them. Regardless of *why* is it so, it is a fact.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Mike van Riel]

On 08.01.2013 18:19, Yahav Gindi Bar wrote:
That's true. But I wish to state my opinion now: the current 
annotations
that Doctorine etc. use is a hack. They took the original doc-block 
style
comments and use them for storing metadata. that's the reason I think 
that

in case we'll implement some sort of a parser - it should support the
documentation.


If I read this thread correctly then almost everyone agrees that 
PHPUnit,
Symfony, ZF, Doctrine, etc, all use annotations in the DocBlock because 
there

is no available alternative that enables them to use annotations.

As far as I am concerned I'd separate this topic into a DocBlock parser 
(that
might take into account the current state of affairs with DocBlock 
Annotations)

and actual Annotation support.

Which ever way the annotation discussion goes; fact is that a lot of 
libraries
already use a form of annotations and I believe a DocBlock parser 
should at

least take this into account to facilitate existing projects.


Yahav and all,
Why does this need to be part of Reflection? Seems a rather odd 
place for
it IMHO, since it basically hard-codes the functionality into part 
of the
core that's not trivially extendable (at least $class->getMethods() 
is hard

to override)...

Instead, what about adding a SPL class to parse the comment. 
Something like


class SplAnnotationParser {
const PARSE_DEFAULT = 1;
const PARSE_FUNCTION = 2;
public function __construct($rules = self::PARSE_DEFAULT);

/**
 * @param string $comment The comment to parse
 * @returns array An array of parsed annotations, pursuant to 
the

ruleset used
public function parseAnnotations($comment);
}

That way, you'd do:

$parser = new 
SplAnnotationParser(SplAnnotationParser::PARE_FUNCTION);

foreach ($class->getMethods() as $method) {
$annotations = 
$parser->parseAnnotations($method->getDocComment());

}

It decouples the implementation, and allows for people to 
polymorphically

substitute different parsers for different needs.

Thoughts?



I don't think it should be implemented as SPL feature since it uses 
the
doc-comment of a specific function. Since we got getDocComment() in 
the

Reflection extension, it just feel obvious for me that I'd have the
annotations accessors in the related classes too. In addition, in 
order to
parse a doc-block you should have either the doc-block as string or 
the

class/method/function etc. In case you wish to perform it from the
class/method etc. - the logic is already well-known for users that 
they can
reflect their classes using Reflection, so I don't see the reason to 
add
another layer. In case you wish to use the doc-comment - it's 
possible ,
but the user most likely need to initialize a Reflection object 
anyway to

get this doc-comment string...


I disagree with the above, documentation generators are _unable_ to use 
the

Reflection library of PHP due to issues with Dynamic Reflection and the
processing of a large amount of files (report on request) with it.

To phpDocumentor and related projects it would be imperative that a
DocBlock parser is available without having to use the Reflection 
extension.



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

Re: [PHP-DEV] File-Paths exceeding MAX_PATH on Windows

[Nicolai Scheer]

Hi again!

On 8 January 2013 14:56, Nicolai Scheer  wrote:

>
> Do you have any advice how I can move lill' pandora to an extension? Of
> course I might copy the complete simple_file_wrapper, but I'd rather not do
> it that way... I did not find any "add standard stream context
> option"-stuff in the API...
>
>
I did finish to write a small extension this evening, which does what I
want :)

I just saved a copy of the php_plain_files_wrapper struct, deregistered the
file wrapper during my MINIT, injected my own functions into the struct and
registered it again.
My own functions just wrap the original ones (using the saved original
function pointers), adjust STREAM_ASSUME_REALPATH and add the prefix if
necessary.

Adjustments only kick in for paths exceeding MAX_PATH, so if all paths are
within the usually allowed bounds, everything is back to original.

Quick and dirty, but it works very well and is a feasible way for our
project... until there's a better way :)

Greetings

Nico

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Benjamin Eberlei]

I agree with this very much.

In Doctrine we used Docblocks only because its the only means of
implementing something that closely resembles native annotation support. I
would be happy if we would have a Docblock parser in SPL, so that all
libraries can agree on using its syntax, however ultimately its just
missing the point that language level annotations would still be very handy.

greetings,
Benjamin


On Tue, Jan 8, 2013 at 2:46 PM, Pierrick Charron wrote:

> On 8 January 2013 03:55, Stas Malyshev  wrote:
> > On the contrary, plenty of implementations means there's a need in this
> > functionality, and it might be a good idea to have one standard
> > implementation if it can cover like 80% of use cases.
>
> I agree, there is a need in this functionality, but all those userland
> implementations were at the first place made because this
> functionality was not part of the language. I think docblocks is not
> the solution, doc blocks are just comments, and I would expect any
> code to work the same way if I remove my comments.
>
> Pierrick
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] Re: Reflection annotations reader

[Vladislav Veselinov]

Exactly. Annotations just don't belong there. Short syntax for arrays got
shut a few times but it finally made it to core. I hope native support will
be revisited at some point.

On Tuesday, January 8, 2013, Pierre Joye wrote:

> hi Stas,
>
> On Tue, Jan 8, 2013 at 7:28 PM, Stas Malyshev 
> >
> wrote:
> > Hi!
> >
> >> I agree, there is a need in this functionality, but all those userland
> >> implementations were at the first place made because this
> >> functionality was not part of the language. I think docblocks is not
> >> the solution, doc blocks are just comments, and I would expect any
> >> code to work the same way if I remove my comments.
> >
> > So you never used PHPUnit and never will in the future, right? Maybe so,
> > but thousands of other people do, and have no problem with directives in
> > the comments. I think it is time to lay this red herring to rest -
> > nobody who had any encounter with any of the most popular PHP tools
> > really expects it.
>
>
> Everyone I talked to who implemented annotations in docblocks did it
> as hack because there is no native support. This is not something that
> belongs to docblocks. It would be nice if you could take a look at the
> c# doc, there are really good concepts there.
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Pierre Joye]

hi Stas,

On Tue, Jan 8, 2013 at 7:28 PM, Stas Malyshev  wrote:
> Hi!
>
>> I agree, there is a need in this functionality, but all those userland
>> implementations were at the first place made because this
>> functionality was not part of the language. I think docblocks is not
>> the solution, doc blocks are just comments, and I would expect any
>> code to work the same way if I remove my comments.
>
> So you never used PHPUnit and never will in the future, right? Maybe so,
> but thousands of other people do, and have no problem with directives in
> the comments. I think it is time to lay this red herring to rest -
> nobody who had any encounter with any of the most popular PHP tools
> really expects it.


Everyone I talked to who implemented annotations in docblocks did it
as hack because there is no native support. This is not something that
belongs to docblocks. It would be nice if you could take a look at the
c# doc, there are really good concepts there.

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Pierrick Charron]

I do use PHP Unit and also Doctrine which uses annotations. And I know
that today because there is no native annotations, the implementation
use docblocks so I can not remove them :) But still if I did not know
anything about PHP and that someone was talking to me about comments,
I would expect my code to work even without them.

Pierrick

On 8 January 2013 13:28, Stas Malyshev  wrote:
> Hi!
>
>> I agree, there is a need in this functionality, but all those userland
>> implementations were at the first place made because this
>> functionality was not part of the language. I think docblocks is not
>> the solution, doc blocks are just comments, and I would expect any
>> code to work the same way if I remove my comments.
>
> So you never used PHPUnit and never will in the future, right? Maybe so,
> but thousands of other people do, and have no problem with directives in
> the comments. I think it is time to lay this red herring to rest -
> nobody who had any encounter with any of the most popular PHP tools
> really expects it.
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227

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

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Stas Malyshev]

Hi!

> I agree, there is a need in this functionality, but all those userland
> implementations were at the first place made because this
> functionality was not part of the language. I think docblocks is not
> the solution, doc blocks are just comments, and I would expect any
> code to work the same way if I remove my comments.

So you never used PHPUnit and never will in the future, right? Maybe so,
but thousands of other people do, and have no problem with directives in
the comments. I think it is time to lay this red herring to rest -
nobody who had any encounter with any of the most popular PHP tools
really expects it.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors

[Nikita Popov]

On Tue, Jan 8, 2013 at 7:03 PM, Steve Clay  wrote:

> On 1/8/13 2:56 AM, Christian Stoller wrote:
>
>> But the way 'nullable' properties are defined is not very intuitive and
>> unclean, in my opinion. Stas has already mentioned that.
>> `public DateTime $date = NULL;` // this looks like the property is
>> initialized with null, but it does not show that the property is 'nullable'
>>
>
> Much agreed. After instantiation, these shouldn't behave differently:
>
> public $foo = null;
> public Foo $foo = null;
>
> Sure, method signatures have special behavior based on a default value,
> but IMO:
> 1. those semantics aren't entirely intuitive to begin with
> 2. property initializers aren't method sigs
> 3. the semantics would apply only to some properties
>
>   public DateTime? $date;
>>
>> In C# the question mark after a type is a short hand for a generic
>> Nullable type.
>>
>
> I like that it's an established practice of doing exactly what we're
> trying to do.
>
> Could we not just make it obvious?:
>
> public Foo|null $foo;
>

I'm not going to argue whether or not determining nullability via = null is
a good or bad idea, but it's the way things currently work in PHP. Adding
other mechanisms for nullability (or multiple typehints, like it is your
suggestion) is something that may be considered, but it is outside the
scope of this RFC. Those things apply to typehints in general, not just to
property typehints. If you want pursue this further, then I would ask you
to create a separate RFC (or just a separate internals discussion maybe).

Thanks,
Nikita

Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors

[Steve Clay]

On 1/8/13 2:56 AM, Christian Stoller wrote:

But the way 'nullable' properties are defined is not very intuitive and 
unclean, in my opinion. Stas has already mentioned that.
`public DateTime $date = NULL;` // this looks like the property is initialized 
with null, but it does not show that the property is 'nullable'


Much agreed. After instantiation, these shouldn't behave differently:

public $foo = null;
public Foo $foo = null;

Sure, method signatures have special behavior based on a default value, but IMO:
1. those semantics aren't entirely intuitive to begin with
2. property initializers aren't method sigs
3. the semantics would apply only to some properties



 public DateTime? $date;

In C# the question mark after a type is a short hand for a generic Nullable 
type.


I like that it's an established practice of doing exactly what we're trying to 
do.

Could we not just make it obvious?:

public Foo|null $foo;


Steve Clay
--
http://www.mrclay.org/

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

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Yahav Gindi Bar]

Hi,
Firstly - many apologizes for not follwoing along, couldn't be near my mail
yesterday (university...). Many apologizes for the long response too ;).


> .
> There is already a similar RFC here :) Maybe it could be good to start
> from this one so that we don't have any duplicated RFC ?
>
> https://wiki.php.net/rfc/annotations-in-docblock


Didn't saw this RFC, it's describes better the idea, yeah. I think that we
should collect the argument we've said in this discussion and merge between
these RFC's. I can do that, in case you dont mind :).



At phpDocumentor we have been working on formalizing the PHPDoc Standard for
> quite some time now and I would ask you to take a look at that and use it
> as
> basis for the parsing of DocBlocks.
>
> You can find the document here:
> https://github.com/phpDocumentor/phpDocumentor2/blob/develop/docs/PSR.md
>
Personally, I think that a built-in parser should cover that. (I'll state
my opinion in this mail).

What about repeated keys? i.e:
>
> @param int $a
> @param string $b
>

> Let's make this clear immediately: an associative array as output is not
> useful.
> That would make it impossible to nest annotations. For example, something
> like following wouldn't work if the output is just arrays:
>

You right, so we can use the ReflectionAnnotation class proposed in the
other RFC (that I missed), which contains key and value. Even sounds more
OO for me.


Annotations have nothing to do with user land documentation, please
> don't go down this discussion again as it will be of no help for this
> topic.
>

That's true. But I wish to state my opinion now: the current annotations
that Doctorine etc. use is a hack. They took the original doc-block style
comments and use them for storing metadata. that's the reason I think that
in case we'll implement some sort of a parser - it should support the
documentation.

Yahav and all,
> Why does this need to be part of Reflection? Seems a rather odd place for
> it IMHO, since it basically hard-codes the functionality into part of the
> core that's not trivially extendable (at least $class->getMethods() is hard
> to override)...
>
> Instead, what about adding a SPL class to parse the comment. Something like
>
> class SplAnnotationParser {
> const PARSE_DEFAULT = 1;
> const PARSE_FUNCTION = 2;
> public function __construct($rules = self::PARSE_DEFAULT);
>
> /**
>  * @param string $comment The comment to parse
>  * @returns array An array of parsed annotations, pursuant to the
> ruleset used
> public function parseAnnotations($comment);
> }
>
> That way, you'd do:
>
> $parser = new SplAnnotationParser(SplAnnotationParser::PARE_FUNCTION);
> foreach ($class->getMethods() as $method) {
> $annotations = $parser->parseAnnotations($method->getDocComment());
> }
>
> It decouples the implementation, and allows for people to polymorphically
> substitute different parsers for different needs.
>
> Thoughts?


I don't think it should be implemented as SPL feature since it uses the
doc-comment of a specific function. Since we got getDocComment() in the
Reflection extension, it just feel obvious for me that I'd have the
annotations accessors in the related classes too. In addition, in order to
parse a doc-block you should have either the doc-block as string or the
class/method/function etc. In case you wish to perform it from the
class/method etc. - the logic is already well-known for users that they can
reflect their classes using Reflection, so I don't see the reason to add
another layer. In case you wish to use the doc-comment - it's possible ,
but the user most likely need to initialize a Reflection object anyway to
get this doc-comment string...


Hey everybody,
>
> I've been following this list for a while (1-2 years) and this is the
> first message I'm sending.
> In my oppinion, annotations in docblocks are a bit(a lot) hacky and
> making it even worse by adding them to core is not the best idea.
>
> This is how I think annotations have to look like if implemented in
> core (I've taken on of the annotation classes in Doctrine and
> transformed it).
>
> Declaration:
>
> namespace Doctrine\ORM\Mapping;
>
> use SplAnnotation, SplAnnotationInterface;
>
> @Target({'PROPERTY', 'ANNOTATION'})
> class JoinColumn implements SplAnnotation
> {
> @SplAnnotation\String
> private $name;
>
> @SplAnnotation\Boolean
> private $unique;
>
> @SplAnnotation\Mixed
> private $onDelete;
>
> @SplAnnotation\String
> private $referencedColumn = 'id';
> }
>
> Usage:
>
> 
> use Lib\Mapping\ORM as ORM;
>
> @ORM\Table()
> @ORM\Entity()
> class User {
>
> @ORM\Column(name="name", type="string")
> private $name;
>
> @ORM\OneToMany(targetEntity="
> Group", mappedBy="user")
> @ORM\JoinColumn(onDelete="CASCADE")
> private $groups;
> }
>
> Of course the syntax and interfaces are just an example for you to get
> the concept.
>

[PHP-DEV] Date timezone performance/cleanup [PATCH]

[Paul Taulborg]

https://bugs.php.net/bug.php?id=63941

Per discussion with Nuno Lopes and Christopher Jones, I have created
another patch to simplify guess_timezone() in ext/date/php_date.c

Internals summary: removes the newly patched in int value that caches
whether a timezone was previously checked or not, as well as reduces
complexity by only using timezone for the stored (and checked)
timezone value. default_timezone is still used locally for ini_set()
calls, but is copied to timezone when checked as valid. Does give a
slight performance increase due to less compiled ops.

If anyone has any feedback, let me know.

Thanks in advance!

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

Re: [PHP-DEV] 'Documentation'

[Paul Dragoonis]

On Tue, Jan 8, 2013 at 2:27 PM, Pierre Joye  wrote:

> On Tue, Jan 8, 2013 at 3:22 PM, Lester Caine  wrote:
>
> > Reflection/Annotations are just another way of 'documenting' classes -
> > aren't they?
>
> No.
>
> Annotations are used to affect behaviors, define services, etc. Check
> out the c# implementation for example.
>

Also, Doctrine uses them for defining relationships between entities.


>
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] 'Documentation'

[Marco Pivetta]

Heya,

Actually, annotations became a form of configuration, very powerful when
dealing with AOP and metadata. Very useful when your classes are tightly
coupled with config. If you never came to use them or never felt the need
to use them, fine.

But I wouldn't call it "further complexity without a real need" :)

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/


On 8 January 2013 15:22, Lester Caine  wrote:

> Having been using 'docblock' elements to document classes in PHP for many
> years, their use by PHPEclipse and PDE to provide type-hinting and via
> phpdocumentor to build developer documentation for classes, I simply
> haven't seen any need for some of the more recent developments.
>
> Reflection/Annotations are just another way of 'documenting' classes -
> aren't they? It's not a level of complexity that I have seen a need for, in
> the same way that 'Accessors' just seem to be further complexity without a
> real need for many users.
>
> By using established practices and developing them as extensions that can
> be disabled if not required, then we can all work with the level of
> complexity that we are comfortable with? 'docblock' comments make the code
> readable, and can be stripped in much the same way as javascript is
> 'packed' for running code, but using the same standard as the basis for
> other extensions information that can be parsed/compiled as required does
> have some sort of logic? The information required is on the whole the same
> for the IDE and documentation and currently a large swath of code already
> has all of the core comments already? Surely the starting point is to
> ensure that the basic docblock standards work with all of the 'new'
> features, and then everything else builds on top of that?
>
> --
> 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] 'Documentation'

[Pierre Joye]

On Tue, Jan 8, 2013 at 3:22 PM, Lester Caine  wrote:

> Reflection/Annotations are just another way of 'documenting' classes -
> aren't they?

No.

Annotations are used to affect behaviors, define services, etc. Check
out the c# implementation for example.

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

[PHP-DEV] 'Documentation'

[Lester Caine]

Having been using 'docblock' elements to document classes in PHP for many years, 
their use by PHPEclipse and PDE to provide type-hinting and via phpdocumentor to 
build developer documentation for classes, I simply haven't seen any need for 
some of the more recent developments.


Reflection/Annotations are just another way of 'documenting' classes - aren't 
they? It's not a level of complexity that I have seen a need for, in the same 
way that 'Accessors' just seem to be further complexity without a real need for 
many users.


By using established practices and developing them as extensions that can be 
disabled if not required, then we can all work with the level of complexity that 
we are comfortable with? 'docblock' comments make the code readable, and can be 
stripped in much the same way as javascript is 'packed' for running code, but 
using the same standard as the basis for other extensions information that can 
be parsed/compiled as required does have some sort of logic? The information 
required is on the whole the same for the IDE and documentation and currently a 
large swath of code already has all of the core comments already? Surely the 
starting point is to ensure that the basic docblock standards work with all of 
the 'new' features, and then everything else builds on top of that?


--
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] File-Paths exceeding MAX_PATH on Windows

[Nicolai Scheer]

Hi!


On 8 January 2013 14:40, Pierre Joye  wrote:

> On Tue, Jan 8, 2013 at 2:38 PM, Nicolai Scheer 
> wrote:
>
> > I agree, but what about pandora and the other file functions like
> unlink()
> > etc.? :)
> > They currently do not prevent such long and prefixed paths...
>
> A bug then, should be fixed. Yes, you don't want to hear that but... :-)
>

Could have guessed the answer ;)



>
> > And to my mind it is ok to let the user open the box (a little?) when he
> is
> > doing so on purpose.
> >
> > Unfortunately mouting directories is too unflexible for our use case...
>
> How so? can be easily automated for shared hosts and the likes.
>

We're developing a file system indexer. There's a huge folder structure and
we scan folders in parallel. The users mountpoints are way down the
structure (subfolder for department, team etc.). If the users reach
MAX_PATH, the scanner, using the whole path from root, exceeds MAX_PATH.
We'd need to adjust a lot of code in order to be able to work on mounts
instead of the direct path, and it's not trivial to parallelize this. Of
course it could be done, but I searched for an easier way...

Do you have any advice how I can move lill' pandora to an extension? Of
course I might copy the complete simple_file_wrapper, but I'd rather not do
it that way... I did not find any "add standard stream context
option"-stuff in the API...

Thanks!

Greetings

Nico

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Pierrick Charron]

On 8 January 2013 03:55, Stas Malyshev  wrote:
> On the contrary, plenty of implementations means there's a need in this
> functionality, and it might be a good idea to have one standard
> implementation if it can cover like 80% of use cases.

I agree, there is a need in this functionality, but all those userland
implementations were at the first place made because this
functionality was not part of the language. I think docblocks is not
the solution, doc blocks are just comments, and I would expect any
code to work the same way if I remove my comments.

Pierrick

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

Re: [PHP-DEV] File-Paths exceeding MAX_PATH on Windows

[Pierre Joye]

On Tue, Jan 8, 2013 at 2:38 PM, Nicolai Scheer  wrote:

> I agree, but what about pandora and the other file functions like unlink()
> etc.? :)
> They currently do not prevent such long and prefixed paths...

A bug then, should be fixed. Yes, you don't want to hear that but... :-)

> And to my mind it is ok to let the user open the box (a little?) when he is
> doing so on purpose.
>
> Unfortunately mouting directories is too unflexible for our use case...

How so? can be easily automated for shared hosts and the likes.

> Furthermore we only need to read files, and that's the only function
> currently not allowing the prefix workaround :(


--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] [RFC][discussion] 5.3 EOL

[Pierre Joye]

On Tue, Jan 8, 2013 at 2:36 PM, Johannes Schlüter
 wrote:

> One thing is to change from "single vote" to "approval voting" (one can
> "aaprove" any of those, sum up, done, one of the best voting systems for
> "winner takes it all" things
> http://en.wikipedia.org/wiki/Approval_voting)

Multiple choices? Don't see the point :)

> and the other way is to at
> least get rid of either "With the next PHP 5.3 release" or "Right after
> the end of this vote" if we stick to our about monthly release schedule
> that makes a difference of maybe two weeks, which is barely relevant ...

good point, done.

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Nikita Popov]

On Tue, Jan 8, 2013 at 10:17 AM, Stas Malyshev wrote:

> Hi!
>
> > Why does this need to be part of Reflection? Seems a rather odd place for
> > it IMHO, since it basically hard-codes the functionality into part of the
>
> Reflection is an odd place for functionality that describes attributes
> of classes, methods, properties, etc.? ITYM "natural place" - that's
> exactly what Reflection does.
>

This functionality parses doccomments and doccomments can be obtained
through various ways. Reflection is only one. Docblocks can just as well
come from parsing the files. If this would be tightly bound to the
reflection mechanisms then it would become useless for many applications,
e.g. phpDocumentor et al couldn't use this (if I'm not much mistaken).

Nikita

Re: [PHP-DEV] File-Paths exceeding MAX_PATH on Windows

[Nicolai Scheer]

Hi!


On 8 January 2013 14:27, Pierre Joye  wrote:

> hi,
>
> On Tue, Jan 8, 2013 at 2:24 PM, Nicolai Scheer 
> wrote:
>
> > What do you think?
>
> As I stated earlier, doing so is like opening the pandora box. I would
> rather go with mounted directory and the likes to reduce the length of
> the path, as long as it is possible.
>

I agree, but what about pandora and the other file functions like unlink()
etc.? :)
They currently do not prevent such long and prefixed paths...
And to my mind it is ok to let the user open the box (a little?) when he is
doing so on purpose.

Unfortunately mouting directories is too unflexible for our use case...
Furthermore we only need to read files, and that's the only function
currently not allowing the prefix workaround :(

Greetings

Nico

Re: [PHP-DEV] [RFC][discussion] 5.3 EOL

[Johannes Schlüter]

On Tue, 2013-01-08 at 14:25 +0100, Pierre Joye wrote:
> > Whereas 50%-1 vote for "Two years, one normal fixes and one security
> > fixes only" and "With the PHP 5.5 final release"
> >
> > Then the winner will be "One year with security fixes only" and "With
> > the PHP 5.5 final release" which probably wasn't intended by the
> > majority.
> 
> Good point but not sure how to do it without clutter the 1st part... I
> thought that 1st choosing which option and then when to begin (that
> does not change the 1st option but when one thinks it is a good time
> to announce&begin it).

One thing is to change from "single vote" to "approval voting" (one can
"aaprove" any of those, sum up, done, one of the best voting systems for
"winner takes it all" things
http://en.wikipedia.org/wiki/Approval_voting) and the other way is to at
least get rid of either "With the next PHP 5.3 release" or "Right after
the end of this vote" if we stick to our about monthly release schedule
that makes a difference of maybe two weeks, which is barely relevant ...

johannes


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

Re: [PHP-DEV] File-Paths exceeding MAX_PATH on Windows

[Pierre Joye]

hi,

On Tue, Jan 8, 2013 at 2:24 PM, Nicolai Scheer  wrote:

> What do you think?

As I stated earlier, doing so is like opening the pandora box. I would
rather go with mounted directory and the likes to reduce the length of
the path, as long as it is possible.

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] [RFC][discussion] 5.3 EOL

[Pierre Joye]

On Tue, Jan 8, 2013 at 2:18 PM, Johannes Schlüter
 wrote:

> Separating the two questions is "strange" and can lead to unintended
> results. They should be combined into one. Example assumption: 50%+1
> vote for "One year with security fixes only" but are split between "With
> the next PHP 5.3 release" and "Right after the end of this vote"

Not sure to see where is the issue here. One is about how long we want
to support 5.3 and how, and the other is when this phase will begin.

> Whereas 50%-1 vote for "Two years, one normal fixes and one security
> fixes only" and "With the PHP 5.5 final release"
>
> Then the winner will be "One year with security fixes only" and "With
> the PHP 5.5 final release" which probably wasn't intended by the
> majority.

Good point but not sure how to do it without clutter the 1st part... I
thought that 1st choosing which option and then when to begin (that
does not change the 1st option but when one thinks it is a good time
to announce&begin it).

> Aside from that: I don't think we need "the PHP Security team" to review
> all things, sometimes individual developers can make the choice, too.

It is not what it said, but if the security team defines something as
a security issue.

> And in my opinion this should be more "fluent" where the bar for
> "criticalness" is set higher and higher, instead of suddenly basically
> stopping.

Right, common sense applies here. We both know that.

> In the end we have to deal with two things: On the one side we have
> users, they want a stable platform, they can rely on, without functional
> changes. Many people I talk to don't care much about small bugs with
> easy workarounds, but they care for simple risk-free updates for
> security things (which btw. is a reason why many use distribution
> packages not php.net's)

Same here.

> On the other side are developers, who nowadays have to test 4 branches
> for each essentially trivial fix. This makes the process to verify a
> patch more annoying than it should be. Given that most here are
> volunteers the barrier shouldn't be set too high.

If sec only option is chosen, we should not see too many releases but
every 2-3 months.

> But we've been through this and the both of us won't come to agreement.

We do, but we are not alone. I am for one for two years sec only.

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] File-Paths exceeding MAX_PATH on Windows

[Nicolai Scheer]

Hi!

On 8 January 2013 06:48, Pierre Joye  wrote:

> hi,
>
> On Mon, Jan 7, 2013 at 10:22 PM, Ferenc Kovacs  wrote:
>
> > is this about allowing the user to shot him/herself in the foot, or
> adding
> > this feature could potentially break some existing functionality (eg. new
> > trick to bypass open_basedir, etc.)?
>
> All of them, as the paths are passed right to the kernel APIs, without
> any system checks like in the higher level APIs (posix or win32).
>

I justed checked that without any modification the userspace functions

unlink()
mkdir()
rmdir()
rename()

do work with "\\?\" prefixed paths, because there is no call to
expand_filepath() i.e. paths are passed directly.

So the only function we needed to modify is php_plain_files_stream_opener...

What do you think about adding:

zval **ctx_opt = NULL;

...
// basedir checks
...

if (context) {
  if ( SUCCESS == php_stream_context_get_option(context, "file",
"assume_realpath", &ctx_opt) && Z_TYPE_PP(ctx_opt) == IS_BOOL &&
Z_LVAL_PP(ctx_opt) == 1) {
options = options | STREAM_ASSUME_REALPATH;
  }
}


Usually STREAM_ASSUME_REALPATH is set by _php_stream_open_wrapper_ex when
USE_PATH is set and the path was resolved successfully. Unfortunately, the
following zend_resolve_path fails as before, because of the '?' in the path.

With the context option above, I could do the following:

 array( "assume_realpath" => true ) );
$ctx = stream_context_create( $options );

$fh = fopen( $path, "r", false, $ctx );

Which works without the need to touch MAXPATHLEN by just using the already
implemented skip of expand_filepath().

Don't get me wrong, I'm not trying to bend php to allow the usage of this
ugly workaround. But as this is quite well documented, and supported on
windows, I just like to ask if adding the above context option is a
feasable way to prevent php with interfering with the prefix.

As of now, there don't seem to be any stream context options for file://.
Question here is, if it is ok to expose a stream option telling php "do not
interfere with my paths, I'm doing this myself". To my mind, since it
already works for anything not involving php_plain_files_stream_opener,
this could be ok.

There are already a lot of stream context options for other wrappers. And
most of them do very lowlevel adjustments...

Yes, there are better ways of doing this, but these future implementations
will take a lot of time and will not be available within the next months.
Of course I'm trying to prevent finding myself compiling php for production
use incorporating just such a little change...
I currently don't see a way how I could introduce the mentioned context
option inside an extension without duplicating a lot of code. Any pointers
are welcome...

What do you think?

Greeting

Nico

Re: [PHP-DEV] [RFC][discussion] 5.3 EOL

[Johannes Schlüter]

On Tue, 2013-01-08 at 12:39 +0100, Pierre Joye wrote:
> On Tue, Jan 8, 2013 at 12:25 PM, Clint Priest  wrote:
> 
> > Would this 1 or 2 year period begin from release date of 5.3 or as of 
> > around now/vote?
> 
> See "When should start the EOL period and when should it be announced?"

I don't understand why we have to go through this again, but anyways, if
we do this:


Separating the two questions is "strange" and can lead to unintended
results. They should be combined into one. Example assumption: 50%+1
vote for "One year with security fixes only" but are split between "With
the next PHP 5.3 release" and "Right after the end of this vote"

Whereas 50%-1 vote for "Two years, one normal fixes and one security
fixes only" and "With the PHP 5.5 final release"

Then the winner will be "One year with security fixes only" and "With
the PHP 5.5 final release" which probably wasn't intended by the
majority.



Aside from that: I don't think we need "the PHP Security team" to review
all things, sometimes individual developers can make the choice, too.
And in my opinion this should be more "fluent" where the bar for
"criticalness" is set higher and higher, instead of suddenly basically
stopping.



In the end we have to deal with two things: On the one side we have
users, they want a stable platform, they can rely on, without functional
changes. Many people I talk to don't care much about small bugs with
easy workarounds, but they care for simple risk-free updates for
security things (which btw. is a reason why many use distribution
packages not php.net's)

On the other side are developers, who nowadays have to test 4 branches
for each essentially trivial fix. This makes the process to verify a
patch more annoying than it should be. Given that most here are
volunteers the barrier shouldn't be set too high.

By reducing the pressure to merge everything, in my opinion, we serve
both - users have less risk updating (yes, with 5.3.18 and 5.3.19 we
changed the behavior slightly, users have to always test this) and
maintainers are a bit freer in their work.


But we've been through this and the both of us won't come to agreement.

johannes




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

Re: [PHP-DEV] [RFC][discussion] 5.3 EOL

[Kris Craig]

On Tue, Jan 8, 2013 at 2:00 AM, Pierre Joye  wrote:

> On Tue, Jan 8, 2013 at 10:48 AM, Kris Craig  wrote:
>
> > Would a voting option to tie it to the release of a future PHP version,
> > rather than a fixed time interval, be appropriate?
>
>
> Like in end it when 5.x is released?


Actually, I was thinking more like 6.0.  That occurred to me when you
mentioned that it's still the most widely-used branch and that numerous
projects still rely on it.  I'd hypothesize that it's less likely that most
of these folks will bother to upgrade if it's still in the 5.x branch.  I'm
thinking this version-specific cutoff would only apply to security fixes.
 I'm not sure if it's a good idea or not, but I figured it was worth
mentioning.  Unless it's just me, it might be worthwhile to add that as a
voting option.

--Kris

Re: [PHP-DEV] [RFC][discussion] 5.3 EOL

[Pierre Joye]

On Tue, Jan 8, 2013 at 12:25 PM, Clint Priest  wrote:

> Would this 1 or 2 year period begin from release date of 5.3 or as of around 
> now/vote?

See "When should start the EOL period and when should it be announced?"

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] [RFC][discussion] 5.3 EOL

[Clint Priest]

Would this 1 or 2 year period begin from release date of 5.3 or as of around 
now/vote?

-Clint

On Jan 8, 2013, at 4:00 AM, Pierre Joye  wrote:

> On Tue, Jan 8, 2013 at 10:48 AM, Kris Craig  wrote:
> 
>> Would a voting option to tie it to the release of a future PHP version,
>> rather than a fixed time interval, be appropriate?
> 
> 
> Like in end it when 5.x is released? Not sure it helps in anyway, but
> that's possible already if we choose to begin the EOL cycle with the
> release of 5.5 (yearly release).
> 
> Cheers,
> --
> Pierre
> 
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

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

[PHP-DEV] VCS Account Rejected: heavenfactory rejected by bjori

[PHP Group]

Nuked heavenfactory


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

[PHP-DEV] VCS Account Rejected: demoking8 rejected by bjori

[PHP Group]

Nuked demoking8


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

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Rafael Dohms]

On Tue, Jan 8, 2013 at 11:05 AM, Pierre Joye  wrote:

> On Tue, Jan 8, 2013 at 10:57 AM, Derick Rethans  wrote:
>
> > This belongs in an extension, just like last time we've discussed
> > annotations.
>
> Last time we discussed this area, we discussed almost everything about
> docblock and the likes but actual annotation. However I do not get
> your reasoning, annotations are part of languages features, how could
> it fit in an extension? That makes no sense.
>
> I also agree it is core due to its nature.
But also, given the large amount of frameworks that support the use of
annotations and the nature of
hosting providers and extensions, I really think this is a core feature.

-- 
Rafael Dohms
PHP Evangelist and Community Leader
http://doh.ms
http://wwwamsterdamphp.nl

Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors

[Lazare Inepologlou]

2013/1/8 Lars Schultz 

> Am 08.01.2013 10:03, schrieb Lazare Inepologlou:
>
>> The fact is that the existing syntax for nullable type hinting has its own
>> problems. For example, this is not possible:
>> function foo( Bar $bar = null , $mandatory ) { ... }
>>
>
> Sure it's possible;) I did not get a syntax error for that...I even use
> that case many times in my code exactly for that purpose, to allow $bar to
> be null but require $mandatory to be defined explicitly.
>

Seems you are right. Sorry.


>
>  I would love to have the question mark syntax for both properties and
>> argument type hinting.
>>
>
> Introducing a BC-Break and/or yet another syntax? Is that worth it?
>
>  This does not apply in all cases. Here is an example of a property that is
>> guaranteed not to be null:
>>
>> class Foo {
>>private $_date;
>>public DateTime $date {
>>  get {
>>return is_null($date) ? new DateTime() : $this->date;
>>  }
>>  set {
>>$this->date = $value;
>>  }
>>}
>> }
>>
>
> The property is still null;) Only the return value of the getter will not
> be null. But that's not the issue, is it? I am not arguing the case of NOT
> allowing null, Stas wanted to always allow null because of this reason and
> not have a special syntax to declare this.
>
>
>
No, the field $_date can be null. The property $date is not null, cannot be
set to null and cannot return null. Furthermore, it cannot be unset (should
fail with an error) and isset always returns true.


Lazare INEPOLOGLOU
Ingénieur Logiciel

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Pierre Joye]

On Tue, Jan 8, 2013 at 10:57 AM, Derick Rethans  wrote:

> This belongs in an extension, just like last time we've discussed
> annotations.

Last time we discussed this area, we discussed almost everything about
docblock and the likes but actual annotation. However I do not get
your reasoning, annotations are part of languages features, how could
it fit in an extension? That makes no sense.

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] [RFC][discussion] 5.3 EOL

[Pierre Joye]

On Tue, Jan 8, 2013 at 10:48 AM, Kris Craig  wrote:

> Would a voting option to tie it to the release of a future PHP version,
> rather than a fixed time interval, be appropriate?


Like in end it when 5.x is released? Not sure it helps in anyway, but
that's possible already if we choose to begin the EOL cycle with the
release of 5.5 (yearly release).

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Derick Rethans]

On Sun, 6 Jan 2013, Yahav Gindi Bar wrote:

> In one of the discussions (about the "deprecated" keyword, to be specific),
> it was been said that adding ability to read doc-comment annotation could
> be handy. Personally, I really think it can be great.
> 
> So, I've created an RFC that propose to improve the Reflection extension by
> adding the ability to read annotations decorated in the doc-comment.
> 
> https://wiki.php.net/rfc/reflection_doccomment_annotations
> 
> What is your opinion about this?

This belongs in an extension, just like last time we've discussed 
annotations.

Cheers,
Derick

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

Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors

[Lars Schultz]

Am 08.01.2013 10:03, schrieb Lazare Inepologlou:

The fact is that the existing syntax for nullable type hinting has its own
problems. For example, this is not possible:
function foo( Bar $bar = null , $mandatory ) { ... }


Sure it's possible;) I did not get a syntax error for that...I even use 
that case many times in my code exactly for that purpose, to allow $bar 
to be null but require $mandatory to be defined explicitly.



I would love to have the question mark syntax for both properties and
argument type hinting.


Introducing a BC-Break and/or yet another syntax? Is that worth it?


This does not apply in all cases. Here is an example of a property that is
guaranteed not to be null:

class Foo {
   private $_date;
   public DateTime $date {
 get {
   return is_null($date) ? new DateTime() : $this->date;
 }
 set {
   $this->date = $value;
 }
   }
}


The property is still null;) Only the return value of the getter will 
not be null. But that's not the issue, is it? I am not arguing the case 
of NOT allowing null, Stas wanted to always allow null because of this 
reason and not have a special syntax to declare this.



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

Re: [PHP-DEV] [RFC][discussion] 5.3 EOL

[Kris Craig]

On Tue, Jan 8, 2013 at 1:36 AM, Pierre Joye  wrote:

> hi,
>
> While the 5.3 RM already unilaterally published some announce about
> 5.3 status with the last release, we still have to clearly and openly
> decide what is the best road to take.
>
> Here is the last version of the rfc:
>
> https://wiki.php.net/rfc/php53eol
>
> If anyone has any other additional options to add, please raise your
> voice. I plan to go for the votes tonight.
>
> ps: pls do not hijack this post to ask to do not end support at all or
> any other unrelated topic, refer to the numerous previous threads if
> you need to refresh your mind, thanks for your understanding.
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Would a voting option to tie it to the release of a future PHP version,
rather than a fixed time interval, be appropriate?

--Kris

[PHP-DEV] [RFC][discussion] 5.3 EOL

[Pierre Joye]

hi,

While the 5.3 RM already unilaterally published some announce about
5.3 status with the last release, we still have to clearly and openly
decide what is the best road to take.

Here is the last version of the rfc:

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

If anyone has any other additional options to add, please raise your
voice. I plan to go for the votes tonight.

ps: pls do not hijack this post to ask to do not end support at all or
any other unrelated topic, refer to the numerous previous threads if
you need to refresh your mind, thanks for your understanding.

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] [RFC] Fixing insecure cURL file uploading

[Stas Malyshev]

Hi!

> Looks good to me, just it could be great to add a new cURL option at
> the same time to disable the '@' usage so that someone working with
> the new ext/curl version can disable it and therefore send values
> starting by @

That is a good suggestion, I'll add CURL_SAFE_POSTFIELDS which would
disable the @ option.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Stas Malyshev]

Hi!

> Why does this need to be part of Reflection? Seems a rather odd place for
> it IMHO, since it basically hard-codes the functionality into part of the

Reflection is an odd place for functionality that describes attributes
of classes, methods, properties, etc.? ITYM "natural place" - that's
exactly what Reflection does.

> core that's not trivially extendable (at least $class->getMethods() is hard
> to override)...

Why you need to override getMethods in Reflection?
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Pierre Joye]

hi,

On Sun, Jan 6, 2013 at 10:58 PM, Yahav Gindi Bar  wrote:
> Hi internals!
>
> In one of the discussions (about the "deprecated" keyword, to be specific),
> it was been said that adding ability to read doc-comment annotation could
> be handy. Personally, I really think it can be great.
>
> So, I've created an RFC that propose to improve the Reflection extension by
> adding the ability to read annotations decorated in the doc-comment.
>
> https://wiki.php.net/rfc/reflection_doccomment_annotations
>
> What is your opinion about this?

Using docblock for annotations is a hack in userland because there is
no other way to do it nicely using php scripts. That's why I strongly
opposed to implement it this way in core, or in SPL. It has to be part
of the parser and generated at compile time.

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Mike van Riel]

On 08.01.2013 09:55, Stas Malyshev wrote:

First of all, there are already plenty of established userland
implementations - so there is really no need for this.


On the contrary, plenty of implementations means there's a need in 
this

functionality, and it might be a good idea to have one standard
implementation if it can cover like 80% of use cases.


I agree with Stas on this one; I have noticed that there is a real need 
to
parse the meta-data from a DocBlock (not just tags, descriptions as 
well).
phpDocumentor is an example but other projects benefit from this as 
well.




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

Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors

[Lazare Inepologlou]

> It takes up the syntax php has been using for method-definitions.

The fact is that the existing syntax for nullable type hinting has its own
problems. For example, this is not possible:

function foo( Bar $bar = null , $mandatory ) { ... }

I would love to have the question mark syntax for both properties and
argument type hinting.

> Although, as Stas has pointed out, *not* allowing NULL for a property
will not prevent it from being NULL...depending on wether it has been
initalized.

This does not apply in all cases. Here is an example of a property that is
guaranteed not to be null:

class Foo {
  private $_date;
  public DateTime $date {
get {
  return is_null($date) ? new DateTime() : $this->date;
}
set {
  $this->date = $value;
}
  }
}



Lazare INEPOLOGLOU
Ingénieur Logiciel


2013/1/8 Lars Schultz 

> Am 08.01.2013 08:56, schrieb Christian Stoller:
>
>> But the way 'nullable' properties are defined is not very intuitive and
>> unclean, in my opinion. Stas has already mentioned that.
>> `public DateTime $date = NULL;` // this looks like the property is
>> initialized with null, but it does not show that the property is 'nullable'
>>
>
> To me this makes perfect sense. It takes up the syntax php has been using
> for method-definitions. A syntax we would be using to create a classic
> setter method if there wasn't a fancy new one.
>
> public function setDate(DateTime $date = NULL) {
> $this->date = $date;
> }
>
> Anything other than this would result in an inconsistency. Having accepted
> that syntax previously and now introducing yet another one, would be
> confusing and unnecessary.
>
> Although, as Stas has pointed out, *not* allowing NULL for a property will
> not prevent it from being NULL...depending on wether it has been initalized.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] File-Paths exceeding MAX_PATH on Windows

[Ferenc Kovacs]

2013.01.08. 6:48, "Pierre Joye"  ezt írta:
>
> hi,
>
> On Mon, Jan 7, 2013 at 10:22 PM, Ferenc Kovacs  wrote:
>
> > is this about allowing the user to shot him/herself in the foot, or
adding
> > this feature could potentially break some existing functionality (eg.
new
> > trick to bypass open_basedir, etc.)?
>
> All of them, as the paths are passed right to the kernel APIs, without
> any system checks like in the higher level APIs (posix or win32).
>
> >> A better solution I work on for previous php version (incl. 5.5 as I
> >> won't make it in time) is an extension which would override existing
> >> functions. Next major version (6) will support unicode filenames,
> >> which will solve the 255 chars horrible limitation.
> >
> >
> > by 6.0 you mean php next after 5.5, or adding this to the core would
require
> > a major version for some reason?
>
> I mean 6 as the changes are rather big. It could be possible in 5.6
> but I rather prefer to target the next major.

thanks for the clarification.

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Stas Malyshev]

Hi!

> First of all, there are already plenty of established userland
> implementations - so there is really no need for this.

On the contrary, plenty of implementations means there's a need in this
functionality, and it might be a good idea to have one standard
implementation if it can cover like 80% of use cases.

> 
> Whatever you decide on in terms of syntax, most likely won't satisfy every
> the needs of every userland annotation library, so at least some of them
> most likely won't use it. You'd be creating more work for the maintainers
> of these frameworks, and they don't standard to gain anything from that
> work.

Since when "it does not satisfy all needs of all users, and some of them
may end up not using it" is an argument for not including functionality?
And how it's more work for maintainers if they just won't use it?

> On the other hand, I would be interested in having support for actual
> annotation syntax (not docblocks) added to PHP. Real annotation syntax

Can we please not hijack the topic? We discussed annotations many times
already, if you have better proposal than current RFCs please create
your own RFC (or ask one of the current RFC authors for collaboration)
and start a new topic

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Rafael Dohms]

I agree with Rasmus on this one.

Userland solutions are enough to support a in-docblock solution today, the
performance gains from making it SPL are too little to matter.
However docblocks are a compromise, and not where these should be.

I do suggest we revive Guilherme's RFC and try once more to arrive at a
"acceptable" syntax. A lot has happened since the last discussion, maybe
this time the usefulness of annotations can be further moved along and we
can get this patch into core.

That would be: https://wiki.php.net/rfc/annotations

Maybe moving more towards the implementation described by Rasmus Schultz.

On Tue, Jan 8, 2013 at 4:42 AM, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:

> Cof... cof...
>
> https://wiki.php.net/rfc/annotations
>
> Good luck convincing php-src folks.
> You'd be my hero.
>
>
> On Mon, Jan 7, 2013 at 9:50 PM, Rasmus Schultz  wrote:
>
> > On parsing annotations in docblocks: please don't.
> >
> > First of all, there are already plenty of established userland
> > implementations - so there is really no need for this.
> >
> > Whatever you decide on in terms of syntax, most likely won't satisfy
> every
> > the needs of every userland annotation library, so at least some of them
> > most likely won't use it. You'd be creating more work for the maintainers
> > of these frameworks, and they don't standard to gain anything from that
> > work.
> >
> > In terms of performance, there is nothing significant to gain here - any
> > good annotation engine/framework already caches parsed annotations.
> >
> > On the other hand, I would be interested in having support for actual
> > annotation syntax (not docblocks) added to PHP. Real annotation syntax
> > could have benefits over parsing docblocks, starting with the fact that
> > most of what's currently in docblocks is documentation, and thus not very
> > interesting at run-time for anything other than documentation generators.
> > (again, documentation generators already have working parsers, and don't
> > stand to gain anything significant from switching to a native docblock
> > parser.) - also mind the fact that docblocks are a loose standard with
> many
> > more variations since annotation libraries came around.
> >
> > The only real downside (in terms of run-time) to adding custom syntax, is
> > that existing useful annotations (such as @var for property-types) would
> > not be useful - but in another sense, that's a good thing, because (for
> the
> > most part) in existing codebases, these were written as documentation,
> not
> > intended for run-time consumption. IDEs and documentation tools can add
> > support for  new annotation syntax, and treat these consistently and
> code,
> > which itself can be documented using phpdoc blocks.
> >
> > I would support and encourage a C# style syntax and behavior, e.g.:
> >
> > use my\lib\DataType;
> >
> > [DataType('datetime')]
> > public $published_date;
> >
> > In other words, DataType is a class, implementing an interface for
> > initialization - everything between the parentheses is interpreted
> > basically the same way as in an array() statement, and is passed to the
> > annotation instance after construction via an initialization method
> defined
> > by the interface.
> >
> > I could elaborate tons more on this subject, as it's something I have
> spent
> > a lot of time researching in different languages, prior to writing my own
> > annotation library.
> >
> > It may strike you as odd that someone who implemented an annotation
> library
> > based on docblocks is actually against annotations in docblocks - I
> mainly
> > chose that option because it was the best option at the time. I'm not a C
> > programmer, and I do believe that docblocks are the best approach for a
> > native PHP implementation. For a native implementation, I'd prefer to
> see a
> > clear separation between non-functional documentation metadata and
> > functional annotation objects. While there is some overlap between the
> two,
> > much of what is currently written as documentation (for example @var
> > annotations) could be written as functional annotations when these have a
> > meaningful purpose. After all, existing code with phpdoc-annotations most
> > likely was not written with the intent of consuming that metadata at
> > runtime, unless written for use with an annotation library.
> >
> > I would be happy to involve myself deeper in this, if others agree and
> > would like to work on a new RFC.
> >
> > - Rasmus Schultz
> >
>
>
>
> --
> Guilherme Blanco
> MSN: guilhermebla...@hotmail.com
> GTalk: guilhermeblanco
> Toronto - ON/Canada
>



-- 
Rafael Dohms
PHP Evangelist and Community Leader
http://doh.ms
http://wwwamsterdamphp.nl

Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors

[Lars Schultz]

Am 08.01.2013 08:56, schrieb Christian Stoller:

But the way 'nullable' properties are defined is not very intuitive and 
unclean, in my opinion. Stas has already mentioned that.
`public DateTime $date = NULL;` // this looks like the property is initialized 
with null, but it does not show that the property is 'nullable'


To me this makes perfect sense. It takes up the syntax php has been 
using for method-definitions. A syntax we would be using to create a 
classic setter method if there wasn't a fancy new one.


public function setDate(DateTime $date = NULL) {
$this->date = $date;
}

Anything other than this would result in an inconsistency. Having 
accepted that syntax previously and now introducing yet another one, 
would be confusing and unnecessary.


Although, as Stas has pointed out, *not* allowing NULL for a property 
will not prevent it from being NULL...depending on wether it has been 
initalized.



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