Re: [PHP-DEV] Annotated PHP 5->7 extension diff

[guilhermebla...@gmail.com]

Hi Rasmus,

Thanks for the highlight.
My biggest concern about all this breakage done for NG could somehow be
minimized by providing possible alternate implementations that could work
both backwards compatible and forwards compatible?
I just don't want to work on extensions I support that would never be
usable in earlier versions once finished the update.

Maybe it would be interesting to have samples of before/after (like you
did) and also samples of of compatibility pieces for PHP 7- and PHP 7+.


Regards,

On Thu, Feb 5, 2015 at 5:28 PM, Rasmus Lerdorf  wrote:

> We have had quite a number of changes to the extension API and it
> worries me a little bit how long it will take everyone to get their
> extensions ported. We have UPGRADING.INTERNALS which still needs some
> love, but even if that covered everything it is sometimes hard to match
> a bullet point in a long list of changes to actual code.
>
> Having just finished porting php-memcached (with help from Xinchen) to
> PHP7 I was wondering if it wouldn't be worthwhile to annotate the diff
> and explain why each change was made. The extension is complicated
> enough to cover most of the changes the bulk of extension authors need
> to worry about.
>
> The diff is easy enough to grab:
>
>   git clone https://github.com/php-memcached-dev/php-memcached.git
>   cd php-memcached
>   git checkout php7
>   git diff master php7
>
> It looks like this:
>
>   https://gist.github.com/anonymous/15cbc9947edb4f0a71fd
>
> Any suggestions for how to handle annotating it? We could turn it into a
> fake PR and mark it up using github's PR comments. But is there
> something more suited for this out there?
>
> -Rasmus
>
>


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

Re: [PHP-DEV] Design by Contract

[guilhermebla...@gmail.com]

Hi all,

I already said before and I'm happy to say it again...
Whenever you feel ready to get true, complete Annotations into core, just
tell me and I'll be ready to work on previously suggested Annotations in
sync with current internals.

Cheers,

On Thu, Feb 5, 2015 at 11:00 PM, Pierre Joye  wrote:

> On Thu, Feb 5, 2015 at 11:36 PM, Dmitry Stogov  wrote:
> > phpdoc is annotation as well, but to split it into specific attributes we
> > have to write specialized parsers.
> > Other languages support annotation or attributes that may be used more
> > easily.
> >
> > http://docs.hhvm.com/manual/en/hack.attributes.php
>
> Exactly, phpdoc is used as annotation (or comments with some similar
> syntax) but is definitively not aimed to be annotations.
>
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org
>
> --
> 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] Design by Contract

[guilhermebla...@gmail.com]

Hi Pierre,

Sorry, but you don't. Proposing a simple syntax is the same as not
proposing it.
We can do whatever syntax is proposed, but we need to discuss on how to
handle inheritance, overriding, etc.
None ever discussed that. 2010's patch handled all that nicely. I do
remember however Dmitry had a suggestion to optimize the overall storage of
annotation values, but it got lost in time. I somehow remember he wanted to
store a cached version of reflection class into the class entry and expose
as Class::CLASS or something... I saw this written in another place too...
it got slightly changed over time and we now have it return only its FQCN.

[]s,


On Thu, Feb 5, 2015 at 11:10 PM, Pierre Joye  wrote:

> On Fri, Feb 6, 2015 at 11:08 AM, guilhermebla...@gmail.com
>  wrote:
> > Hi all,
> >
> > I already said before and I'm happy to say it again...
> > Whenever you feel ready to get true, complete Annotations into core, just
> > tell me and I'll be ready to work on previously suggested Annotations in
> > sync with current internals.
>
> We are, with the simplified syntax we discussed last time (have to dig
> the archive)
>
> > Cheers,
> >
> > On Thu, Feb 5, 2015 at 11:00 PM, Pierre Joye 
> wrote:
> >>
> >> On Thu, Feb 5, 2015 at 11:36 PM, Dmitry Stogov  wrote:
> >> > phpdoc is annotation as well, but to split it into specific attributes
> >> > we
> >> > have to write specialized parsers.
> >> > Other languages support annotation or attributes that may be used more
> >> > easily.
> >> >
> >> > http://docs.hhvm.com/manual/en/hack.attributes.php
> >>
> >> Exactly, phpdoc is used as annotation (or comments with some similar
> >> syntax) but is definitively not aimed to be annotations.
> >>
> >> --
> >> Pierre
> >>
> >> @pierrejoye | http://www.libgd.org
> >>
> >> --
> >> 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
>
>
>
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org
>



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

Re: [PHP-DEV] Design by Contract

[guilhermebla...@gmail.com]

Hi Dmitry,

Last time we discussed was this one: https://wiki.php.net/rfc/annotations
The ideal one was the version before:
https://wiki.php.net/rfc/annotations?rev=1300089833

To have this in core, we need to step back and re-evaluate how we could
achieve 80% minimum. My original proposal was trying 95%, too much.
We could get 80% by having a simpler implementation, something like this:

<[ new Foo() ]>
class Bar
{
}

And all it would be required is 2 new methods as part of Reflection classes.
The example could be translated into this:

$bar = new \ReflectionClass('Bar');
$bar->setMetadata([ new Foo() ]);

var_dump($bar->getMetadata());

array(1) {
[0] => object(Foo)
}

Does that sound reasonable? It would allow us to achieve "nested
annotations".
However, it would not achieve a bunch of other things, like named
parameters (you couldn't only do one or two as a constructor params...
Foo(null, null, 'value') would be seen everywhere).
We forget about inheritance, so metadata wouldn't be propagated to
inherited classes, methods or properties.
Also, if we implement in important Reflection structures, that would
incredibly improve its power, such as: ReflectionClass, ReflectionProperty,
ReflectionMethod, ReflectionParameter and ReflectionFunction.

I think this is more reasonable than my original proposal, addresses 80% of
use cases and still help all projects around.
Named parameters would be my next battle then... =D


[]s,

On Fri, Feb 6, 2015 at 9:17 AM, François Laupretre 
wrote:

> > De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo
> Ohgaki
>
> > Personally, backward compatibility is not too important.
> > PHP5 is dead by PHP 7.2 release... This is the reason why.
> > It's only 3 years later, only 2 years later after PHP 7.0 release.
>
> That's where we disagree, as I think it's most important.
>
> Thinking that PHP 5 is dead in 3 years is extremely naïve IMO. You
> probably didn't live the PHP 4/5 migration but I guess we won't have more
> than 30 % of production servers under PHP 7 in 2018, just due to the delays
> of distros, hosting companies, and others.
>
> Now, suppose you're distributing a library or a framework, like Symfony,
> Doctrine, etc. Someone tells you : "Here's the new DbC feature. You can use
> it but this implies splitting your code to two independent branches and
> maintain them in parallel until you have no PHP 5 customer anymore.". What
> do you think you'll do (or won't do) ?
>
> @Pierre,@Dmitry : you have a better vision than mine on the migration
> process. What's your opinion on forcing software developers to maintain two
> separate branches ?
>
> Once again, the conditions in @assert lines ARE PHP code. There's no new
> syntax. There is no real difference between writing 'assert()'
> and '@assert ', especially if the require/ensure blocks should
> contain 'assert' statements only.
>
> > What I believe is not important to you. I could be wrong.
>
> It is important. As I may be wrong too.
>
> Cheers
>
> François
>
>
> --
> 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] Design by Contract

[guilhermebla...@gmail.com]

Dmitry,

Doc comments are terrible. I really want you to spend some time looking at
what we had to do inside of Doctrine Annotations to make it work. We have
to token_get_all() the file to be processed and track for "use"s to allow
importing inside of doc blocks. We also had to build a top-down recursive
parser to make it work... don't you think it's too much? As one of the
library maintainers, I do, by heart.

We have until Mar 15 to work on something and propose. I can work on it
without any problems, but as an enthusiast of PHP, it's very frustrating
that I spend time to make PHP better and none even care to review PRs or
simply ignore messages on php-internals. If anyone compromise to review,
I'd do my best to get it ready yesterday if it was possible!

Thanks,

On Fri, Feb 6, 2015 at 9:40 AM, Dmitry Stogov  wrote:

> I see your point, and, of course, it makes sense, but it also means that no
> new PHP7 features might not be used in these frameworks and libraries for a
> long time. Should we stop add new features in major releases?
>
> As I said, according to DbC, I'm not sure if it should be defined on
> language level. Doc comments or annotations with external tools might be
> good enough.
>
> Thanks. Dmitry.
>
> On Fri, Feb 6, 2015 at 5:17 PM, François Laupretre 
> wrote:
>
> > > De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo
> > Ohgaki
> >
> > > Personally, backward compatibility is not too important.
> > > PHP5 is dead by PHP 7.2 release... This is the reason why.
> > > It's only 3 years later, only 2 years later after PHP 7.0 release.
> >
> > That's where we disagree, as I think it's most important.
> >
> > Thinking that PHP 5 is dead in 3 years is extremely naïve IMO. You
> > probably didn't live the PHP 4/5 migration but I guess we won't have more
> > than 30 % of production servers under PHP 7 in 2018, just due to the
> delays
> > of distros, hosting companies, and others.
> >
> > Now, suppose you're distributing a library or a framework, like Symfony,
> > Doctrine, etc. Someone tells you : "Here's the new DbC feature. You can
> use
> > it but this implies splitting your code to two independent branches and
> > maintain them in parallel until you have no PHP 5 customer anymore.".
> What
> > do you think you'll do (or won't do) ?
> >
> > @Pierre,@Dmitry : you have a better vision than mine on the migration
> > process. What's your opinion on forcing software developers to maintain
> two
> > separate branches ?
> >
> > Once again, the conditions in @assert lines ARE PHP code. There's no new
> > syntax. There is no real difference between writing 'assert()'
> > and '@assert ', especially if the require/ensure blocks should
> > contain 'assert' statements only.
> >
> > > What I believe is not important to you. I could be wrong.
> >
> > It is important. As I may be wrong too.
> >
> > Cheers
> >
> > François
> >
> >
>



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

Re: [PHP-DEV] Design by Contract

[guilhermebla...@gmail.com]

Hi Dmitry,

Actually the RFC was approved by 1 or 2 votes more than needed, but the
overall response from core maintainers was that it was overly complex,
adding features the language did not support until that point (named
parameters, short array syntax as examples), it was broken with the
proposed opcache merge (was not a trivial fix IIRC) and memory expensive.

I think a simpler approach could work now as I suggested in previous
messages. It does not add new features besides annotations itself.
We'd still have to discuss about the memory usage and where the metadata
class instances should be placed.

[]s,

On Fri, Feb 6, 2015 at 10:12 AM, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:

> Dmitry,
>
> Doc comments are terrible. I really want you to spend some time looking at
> what we had to do inside of Doctrine Annotations to make it work. We have
> to token_get_all() the file to be processed and track for "use"s to allow
> importing inside of doc blocks. We also had to build a top-down recursive
> parser to make it work... don't you think it's too much? As one of the
> library maintainers, I do, by heart.
>
> We have until Mar 15 to work on something and propose. I can work on it
> without any problems, but as an enthusiast of PHP, it's very frustrating
> that I spend time to make PHP better and none even care to review PRs or
> simply ignore messages on php-internals. If anyone compromise to review,
> I'd do my best to get it ready yesterday if it was possible!
>
> Thanks,
>
> On Fri, Feb 6, 2015 at 9:40 AM, Dmitry Stogov  wrote:
>
>> I see your point, and, of course, it makes sense, but it also means that
>> no
>> new PHP7 features might not be used in these frameworks and libraries for
>> a
>> long time. Should we stop add new features in major releases?
>>
>> As I said, according to DbC, I'm not sure if it should be defined on
>> language level. Doc comments or annotations with external tools might be
>> good enough.
>>
>> Thanks. Dmitry.
>>
>> On Fri, Feb 6, 2015 at 5:17 PM, François Laupretre 
>> wrote:
>>
>> > > De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo
>> > Ohgaki
>> >
>> > > Personally, backward compatibility is not too important.
>> > > PHP5 is dead by PHP 7.2 release... This is the reason why.
>> > > It's only 3 years later, only 2 years later after PHP 7.0 release.
>> >
>> > That's where we disagree, as I think it's most important.
>> >
>> > Thinking that PHP 5 is dead in 3 years is extremely naïve IMO. You
>> > probably didn't live the PHP 4/5 migration but I guess we won't have
>> more
>> > than 30 % of production servers under PHP 7 in 2018, just due to the
>> delays
>> > of distros, hosting companies, and others.
>> >
>> > Now, suppose you're distributing a library or a framework, like Symfony,
>> > Doctrine, etc. Someone tells you : "Here's the new DbC feature. You can
>> use
>> > it but this implies splitting your code to two independent branches and
>> > maintain them in parallel until you have no PHP 5 customer anymore.".
>> What
>> > do you think you'll do (or won't do) ?
>> >
>> > @Pierre,@Dmitry : you have a better vision than mine on the migration
>> > process. What's your opinion on forcing software developers to maintain
>> two
>> > separate branches ?
>> >
>> > Once again, the conditions in @assert lines ARE PHP code. There's no new
>> > syntax. There is no real difference between writing
>> 'assert()'
>> > and '@assert ', especially if the require/ensure blocks
>> should
>> > contain 'assert' statements only.
>> >
>> > > What I believe is not important to you. I could be wrong.
>> >
>> > It is important. As I may be wrong too.
>> >
>> > Cheers
>> >
>> > François
>> >
>> >
>>
>
>
>
> --
> Guilherme Blanco
> MSN: guilhermebla...@hotmail.com
> GTalk: guilhermeblanco
> Toronto - ON/Canada
>



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

Re: [PHP-DEV] Design by Contract

[guilhermebla...@gmail.com]

Hi Dmitry,

So, can we start drafting out some things?
Simple questions would help everybody to get this moving forward.
I'll compile a simple list of questions to answer that would drive the
direction on how it would be implemented.
Please ignore the formatting on HOW they are defined. Tokens can change.
Here it is:

1- Doc comments vs. outside?

2- Keep object instance creation the same? IE: @Foo vs new Foo()

3- Is constructor the only way to inject parameters?

4- What if we have optional arguments, like: @Foo("bar", null, null, "woo")?
Suppose that you wanna fix the optional arguments by declaring names (like
this: @Foo("bar", test="woo")), doesn't it collide with PHP interests of
not supporting parametrized arguments? How would parameter skipping
proposal address this in a nicer way?

5- How would you deal with inheritance? Should a method inherit the same
annotations from parent or not?
Should we add ability to flag to inherit or not? What about overrides?
Would they be allowed? Is there a vague idea on how this concept could be
achieved?

6- Would you be possible to change annotations value at runtime?

7- Would we validate annotation arguments at all? Consider as array?
Properties of objects?

8- In case we take the approach of properties of objects... how would we
flag that a given class can/cannot be used as annotation: another
annotation, interface, any other idea?

9- Would we and/or wow would we flag that a given class could be used only
in a class and not in a method?

10- How would it be the syntax to declare a new annotation?


I think we have a good start now... =)

[]s,


On Fri, Feb 6, 2015 at 12:53 PM, Dennis Birkholz 
wrote:

> > On the other hand you have a working solution.
> > You won't be able to use annotations for PHP5 projects anyway.
> > Except, if we put them into comments or doc-comments.
> >
> > /**[Attribute(Value)]*/
>
> Why not /**@ Attribute Value */ or /**@ Attribute(Value) */? No []
> required and @ looks more familiar with docblock annotations in use.
>
> --
> 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] Design by Contract

[guilhermebla...@gmail.com]

Hi Yasuo,

Design by Contract could be used at the top of Annotation if (and only if)
it also had support for Interceptors. Since it could potentially be a
nightmare for PHP, I don't think it's time to propose something at the top
of another thing that is still far from being reality.
It would follow somehow a similar approach of what Symfony validators do:
http://symfony.com/doc/current/book/validation.html but it would be called
at possible 3 times: pre-execution, in-execution (using around and bound to
an external class) and post-execution.
However, I keep myself asking if this is a good idea. It obviously brings a
certain level of AOP to PHP, but I'd rather take a simplistic approach such
as the one suggested by Stas but with a few adjustments.
His approach is more inline to C and C++, but I like a more customizable
Java style assertion support
http://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html
Example:

function foo($name) {
assert $name !== '': "Name must not be an empty value";
}

This would be similar to this:

function foo($name) {
if ($name === null) {
throw new AssertionError("Name must not be an empty value");
}
}

Basically, new grammar to be supported would be something like this:

assert_statement:
T_ASSERT expr ':' expr ';'
;

Where the first expr is a boolean expression and the second expr must
return a value (cannot be null).

This would be a good start for PHP, even though Java does not recommend to
use this for argument's method check (
http://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html#usage),
but I consider that since PHP is not a strict language, we do not have the
same privileges by automating this check form arguments itself.

That is my personal suggestion for DbC, which does not fully align with
what it was proposed, but since you asked... here it is.

[]s,


On Sun, Feb 8, 2015 at 8:22 PM, Yasuo Ohgaki  wrote:

> Hi Stas,
>
> On Mon, Feb 9, 2015 at 8:11 AM, Stanislav Malyshev 
> wrote:
>
> > > Following our conversation, I tried to imagine how DbC should look like
> > in
> > > PHP from user perspective. Finally, I was influenced by the semantic
> > > proposed in D, and syntax proposed for Java. So, these are my initial
> > > thoughts:
> > >
> > > For php it may look like the following:
> > >
> > > function foo()
> > > requre()
> > > ensure()
> > > {
> > >   ...
> > > }
> >
> > Why not do it simpler?
> >
> > function foo() {
> > // require
> > assert();
> > ...
> > // ensure
> > assert();
> > }
> >
> > I'm oversimplifying a bit, but in general, why we need more places to
> > have code in the function than the actual code of the function? It would
> > be harder to parse, to read, to maintain, to debug, to profile, etc. and
> > I'm not sure what exactly it provides that can't be done by plain
> > regular code inside the function.
> >
> > If we're concerned about the costs of assert, we could make special
> > provision in the compiler for zero-cost asserts. It doesn't require
> > moving code out of the function.
>
>
> Interesting idea. I like it.
> The only draw back I can see now is that this may make post/pre condition
> retrieving
> harder for automatic documentation.  We may think of solution for this.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>



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

Re: [PHP-DEV] Design by Contract

[guilhermebla...@gmail.com]

Hi Yasuo,

Class invariants could be done as this example:

class Foo {
private function isValidState() {
// Checks class's state and returns boolean
}

public function doSomething($args) {
// Some complex operation over Foo instance using $args
// then...

assert $this->isValidState(): $this; // it would call
Foo::__toString() for AssertionError message
}
}

Another example of pre and post conditions:

function foo($number) {
// pre-condition
assert is_numeric($number): '...';

// Some expensive operation creating $value as response

// post-condition
assert someCheckWith($value): '...';
return $value;
}

A good explanation about use-cases can be found here
http://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html#class-invariants

[]s,

On Sun, Feb 8, 2015 at 11:24 PM, Yasuo Ohgaki  wrote:

> Hi Guilherme,
>
> On Mon, Feb 9, 2015 at 11:58 AM, guilhermebla...@gmail.com <
> guilhermebla...@gmail.com> wrote:
>
>> Design by Contract could be used at the top of Annotation if (and only
>> if) it also had support for Interceptors. Since it could potentially be a
>> nightmare for PHP, I don't think it's time to propose something at the top
>> of another thing that is still far from being reality.
>> It would follow somehow a similar approach of what Symfony validators do:
>> http://symfony.com/doc/current/book/validation.html but it would be
>> called at possible 3 times: pre-execution, in-execution (using around and
>> bound to an external class) and post-execution.
>> However, I keep myself asking if this is a good idea. It obviously brings
>> a certain level of AOP to PHP, but I'd rather take a simplistic approach
>> such as the one suggested by Stas but with a few adjustments.
>> His approach is more inline to C and C++, but I like a more customizable
>> Java style assertion support
>> http://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html
>> Example:
>>
>> function foo($name) {
>> assert $name !== '': "Name must not be an empty value";
>> }
>>
>> This would be similar to this:
>>
>> function foo($name) {
>> if ($name === null) {
>> throw new AssertionError("Name must not be an empty value");
>> }
>> }
>>
>> Basically, new grammar to be supported would be something like this:
>>
>> assert_statement:
>> T_ASSERT expr ':' expr ';'
>> ;
>>
>> Where the first expr is a boolean expression and the second expr must
>> return a value (cannot be null).
>>
>> This would be a good start for PHP, even though Java does not recommend
>> to use this for argument's method check (
>> http://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html#usage),
>> but I consider that since PHP is not a strict language, we do not have the
>> same privileges by automating this check form arguments itself.
>>
>> That is my personal suggestion for DbC, which does not fully align with
>> what it was proposed, but since you asked... here it is.
>>
>
> Thank you.
> Since assert is going to have zero performance penalty, Stas proposal
> would work.
> We have to think of how invariants should be.
>
> Joe, could you add "Proposal" section to the RFC.
> https://wiki.php.net/rfc/expectations
> Currently, it does not have "Proposal" section and it's harder to
> understand what the
> RFC is. Then, could you start vote? New assert is valuable regardless of
> DbC.
>
> The RFC will encourage users to use assert(), my little concern with
> Stas's proposal
> is misuse/abuse of assert(). Stas's proposal is simplest, but I'm not sure
> if we should go
> for it or not.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>



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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

[guilhermebla...@gmail.com]

Hi,

I read again and again the RFC and I just decided to switch my vote.
Originally a "YES" voter, I'm now a "NO" voter. I still want strict types
to exist in PHP, and not only at the end-user level, but also at the
internals level (I can see so many optimizations around...).
However, I think it's not an INI setting or a per file operation. I
consider it should be (at the current PHP's pace) a heavily flexible
support. I tend to agree that if you put "string" in its definition, you
don't want a weak type, but strict type, the same way when you put MyClass
instead of nothing.

That's why I don't agree with the declare or "use strict" or  wrote:

> Hi,
>
> On Mon, Feb 9, 2015 at 7:22 PM, Jordi Boggiano  wrote:
> >
> > And that is exactly why this RFC is great, since it lets the
> > strict-proponents have their strict types in their files, but those
> > preferring weak ones can remain in the default weak mode, never see an
> ugly
> > declare(), and still call strict code in weak mode.
> >
> > That is why I don't quite understand the "no" votes coming from
> weak-hints
> > proponents. Unless of course you would prefer to pass weak-only v0.1 and
> > then shoot down any attempt at strict hints. That strikes me as quite
> > selfish though, given the strict-proponents isn't such a tiny group of
> > people.
> >
> > And then there are the people sitting somewhere in between the black and
> > white camps. Those that would like to use strict sometimes for some
> critical
> > code paths, and for them the proposed solution is quite good as well.
> >
>
> I am in the "between black and white" camp and this RFC doesn't give
> me what I want, nor did the 0.1 version of it.
> I would vote 'no' on both if I had voting privileges.
>
> Please, all, stop speculating and just let the votes count.
>
> Cheers,
> Andrey.
>
> --
> 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] [VOTE] Scalar Type Hints

[guilhermebla...@gmail.com]

Hi Andrea,

I totally see your viewpoint. That's why initially I voted "YES", because
your proposal somehow makes sense.
My when I thought over and use a weak/strict boolean type conversion on my
own brain, I came to the conclusion my real wish does not get fully
addressed with a "YES", leading me to switch my vote.
I really wanted to expose the motivation of my change here, so everyone is
aware that I do love strict typing, and I really want this in for PHP, but
not in this RFC way.

[]s,

On Mon, Feb 9, 2015 at 1:19 PM, Andrea Faulds  wrote:

> Hi Guilherme,
>
> > On 9 Feb 2015, at 18:12, guilhermebla...@gmail.com wrote:
> >
> > I read again and again the RFC and I just decided to switch my vote.
> > Originally a "YES" voter, I'm now a "NO" voter. I still want strict types
> > to exist in PHP, and not only at the end-user level, but also at the
> > internals level (I can see so many optimizations around...).
> > However, I think it's not an INI setting or a per file operation. I
> > consider it should be (at the current PHP's pace) a heavily flexible
> > support. I tend to agree that if you put "string" in its definition, you
> > don't want a weak type, but strict type, the same way when you put
> MyClass
> > instead of nothing.
> >
> > That's why I don't agree with the declare or "use strict" or  strict.
> > If I say "string $foo", I want a string, not a converted value. By
> > accepting this fact, makes easier in the future to make OO primitive
> types
> > if we wish, and also makes everything easier for everyone... if you have
> > foo(string $name), you expect strict type... if you want weak type,
> > foo($name). All code will work as is today, no BC breaks.
> >
> > That's my 2 cents... now time to update my vote in RFC.
>
> I can understand that viewpoint, but it’s not terribly kind on your users.
> You’re basically saying that you want to force people who’d prefer weak
> typing to use strict typing if they use your API. It’s doing this which
> this RFC is designed to prevent. I don’t think allowing people to force
> their way on their users is a good way to deal with the lack of weak or
> strict consensus in the community, no matter whether it’s nice for API
> design or not.
>
> Thanks.
>
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>


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

Re: [PHP-DEV] Annotations in PHP7

[guilhermebla...@gmail.com]

François,

Doctrine relies on nested annotations for a variety of mapping information.
One example:

http://doctrine-orm.readthedocs.org/en/latest/reference/association-mapping.html#one-to-many-unidirectional-with-join-table

[]s,

On Tue, Feb 17, 2015 at 4:33 PM, François Laupretre 
wrote:

> Hi Alexander,
>
> > De : Alexander Lisachenko [mailto:lisachenko...@gmail.com]
> >
> > This RFC consists of two parts: parsing API and parser extension API.
> Last
> > one can be rejected, however it can be perfectly connected with
> annotation
> > RFC (if AST will be used as values)
>
> Parser extension API is great. Go on with it. I have a lot of uses in mind.
>
> > As for annotations, general use-case is appreciated. This can be extended
> > later in future versions of PHP. Therefore, annotation syntax should
> allow
> > to define key and values. Value can be valid expression (AST? concrete
> > node? compiled value?) or can recursively contain nested annotations.
>
> Can you give a use case for nested annotations ? I don't see what they can
> be needed for.
>
> Thanks
>
> François
>
>
>
>


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

Re: [PHP-DEV] Annotations in PHP7

[guilhermebla...@gmail.com]

Hi Dmitry,

> Are you (and Doctrine team) interested in this annotation idea?

I'd say that Benjamin nailed in our possible usage:


class Foo {
}

Now I do feel we need to elaborate some sort of named parameters. Doctrine
tries to simplify a lot developer's life by using consistency in default
mapping and only if the user wants to override default behavior he needs to
override a given parameter. This means in a case where you're mapping a
JoinColumn (
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Mapping/JoinColumn.php
),
you may only want to specify the onDelete="CASCADE" operation instead of
name, referencedColumnName and many other parameters.
Trying to map this in your default parameter passing, we'd have something
like:


public $address;

As I said, named parameters make a lot of sense when mapping defaults.
Now by looking at this syntax, I still think we're closer to a simple array
implementation (ReflectionClass::getMetadata(string $name)) and having
something like:

<[
"orm" => [
new OneToOne("Address"),
new JoinColumn(default, default, default, default, "CASCADE")
]
]>
public $address;


PS: We haven't even started on talking about overrides yet... =\

Regards,

On Wed, Feb 18, 2015 at 12:04 PM, Dmitry Stogov  wrote:

>
>
> On Wed, Feb 18, 2015 at 6:14 PM, François Laupretre 
> wrote:
>
>> Hi Dmitry,
>>
>>
>>
>> Right. That’s what I got from your last reply. But my question was about
>> another post where you are talking about ‘compile time evaluation’ of
>> expressions, which is different from the bare key/value storage I
>> understood first, and poses the problem of compile time evaluation scope
>> (which also exists at runtime).
>>
>>
>>
>> If you just store the expression as a bare string or AST without
>> evaluating it, that’s fine and, even, much better from a performance point
>> of view. I just want to make it clear for me and everyone that there will
>> be no possibility of compile time evaluation. That’s all.
>>
>
> right.
>
> Again, sorry to insist ;).
>>
>
> no problem.
>
> Thaks. Dmitry.
>
>
>>
>>
>> François
>>
>>
>>
>> I answer the last time.
>> Annotations is just a key value storage, where value may be AST for php
>> expression.
>>
>> Your may do with it whatever you like (traverse, evaluate, compile), but
>> PHP core itself is not going to do anything.
>>
>> Thanks. Dmitry.
>>
>
>


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

[PHP-DEV] Getting function namespace at runtime

[guilhermebla...@gmail.com]

Hi internals,

I came really close to reach the final state of my to be proposed "private
class, interface and trait" support here.
However, I have a bug under this circumstance:
https://gist.github.com/guilhermeblanco/3392925014c9f8374acc

I'd love if someone could give me a hand on how could I get the currently
active namespace (which does not exist at runtime, only compile time) in
order to do the checks inside of VM.
The only way I somehow through that could work was through something like
EX(called_scope) or EX(func) or EX(call).

Would love if someone could give me a north to finish the patch and put the
finalized RFC for voting. =)

[]s,

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

Re: [PHP-DEV] [VOTE] Exceptions in the engine

[guilhermebla...@gmail.com]

+1 on Sebastian's suggestion. =)

I volunteer to either update the RFC or create a new one to resolve this
once "Exceptions in the engine" passes (which looks like a reality already
to me).

Just tell me which approach I should take and I'll happily write the RFC.

[]s,

On Fri, Feb 27, 2015 at 9:47 AM, Jordi Boggiano  wrote:

> On 27/02/2015 14:31, Sebastian Bergmann wrote:
>
>> Am 23.02.2015 um 19:15 schrieb Nikita Popov:
>>
>>> Voting on the engine exceptions RFC, which proposes to convert existing
>>> fatal and recoverable fatal errors into exceptions, has opened:
>>>
>>>  https://wiki.php.net/rfc/engine_exceptions_for_php7#vote
>>>
>>> The primary vote requires a 2/3 majority, as this is a language change.
>>>
>>> A second vote will decide whether to use a BaseException based
>>> inheritance
>>> hierarchy. This vote uses a simple majority.
>>>
>>
>>   I have voted yes on "Allow exceptions in the engine and conversion of
>>   existing fatals?" and no on "Introduce and use BaseException?" and
>>   would like to elaborate on the latter.
>>
>>   I am sorry that I was unable to raise this concern earlier (did not
>>   really become aware of the RFC before it was put to the vote), but I
>>   would prefer the following:
>>
>> * Introduce a Throwable interface
>> * Let Exception implement the Throwable interface
>> * Introduce an Error class that implements the Throwable interface
>> * Use Error class as base class for exceptions raised by the engine
>>
>>   This would be along the lines of what Java does.
>>
>
> +1 on that, and as it seems the BaseException is going to pass, it might
> be good to quickly draft another RFC to amend that part.
>
> It seems people in general favor the fact that catch(Exception $e) does
> not catch those new engine exceptions, but there hopefully would not be
> much resistance against a cleaner scheme than a BaseException class.
>
> Also the Error (and possibly Throwable) class/interface might be put in a
> PHP namespace and then we avoid any potential BC issues, but that's perhaps
> another voting point :)
>
> Cheers
>
>
>
>
> --
> 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] Consistent function names

[guilhermebla...@gmail.com]

@Rasmus:

I don't see what's the problem of aliasing functions for the next 1-2
majors, deprecate the inconsistent one in the following and remove later.

On Wed, Mar 4, 2015 at 10:33 AM, Trevor Suarez  wrote:

> ... well that's a constructive way of going about it. I don't think Yasuo
> did anything harmful or rude in making his proposal. Regardless of how
> realistic the idea may be, I don't think its ever appropriate or
> constructive to tell someone to simply "stop" because something "is just
> ridiculous".
>
> On Wed, Mar 4, 2015 at 10:24 AM Rasmus Lerdorf  wrote:
>
> > On 03/03/2015 07:34 PM, Yasuo Ohgaki wrote:
> > > Hi Michael,
> > >
> > > On Wed, Mar 4, 2015 at 12:15 PM, Michael Schuett <
> > michaeljs1...@gmail.com>
> > > wrote:
> > >
> > >> Your evaluation is pretty anecdotal. I agree with some points but you
> > need
> > >> some solid evidence if you are going to rate these languages. Also do
> > you
> > >> have a list of all the functions you would like to rename or is this a
> > >> sweeping lets just change everything so it matches and deprecate all
> the
> > >> old stuff. Your matrix is a very weak push to do so. If you want to
> make
> > >> these changes it would be better to choose a select set such as the
> > array
> > >> functions and try and push that through or see what that change might
> > look
> > >> like and if it's really beneficial to userland.
> > >
> > >
> > > I agree that my evaluation is subjective. For example, I rate PHP has
> "1"
> > > security only
> > > because PHP is very weak against script/file inclusions because it's
> > fatal
> > > and other
> > > languages apps do not have script/file inclusions as PHP apps do.
> Others
> > > might
> > > rate "2" or even "3" because it is too easy to fix it even if incident
> is
> > > fatal.
> > > (Security should be evaluated by "how difficult to make mistakes", not
> > "how
> > > easy to
> > > fix mistakes" generally. IMHO)
> > >
> > > I made list of rename candidates
> > > https://wiki.php.net/rfc/consistent_function_names#
> > list_of_functions_to_be_renamed
> > > If you have suggestions, I appreciate!
> >
> > Yasuo, please stop. This isn't going to happen. Changing strlen() to
> > str_len() is just ridiculous.
> >
> > -Rasmus
> >
> >
> >
>



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

[PHP-DEV] STH and the 3 RFCs

[guilhermebla...@gmail.com]

Hi internals,

I carefully read all 3 proposed RFCs related to scalar type hints.
As an end user and enthusiast of the language, I want PHP to always
improve. STH is *the* major inclusion for PHP 7 and no matter how many
people say about phpng performance, STH is the one that will impact mostly
everyone on a day by day basis.

Now I also understand the rush of getting this feature in PHP considering
the voted and approved deadline for feature freeze of PHP 7. However, we're
not in a mission critical, losing millions or facing a world collapse if it
takes an extra day or two to figure it out what people want, specially such
an important feature. That said, I consider the feature freeze date a soft
deadline than a hard one, and again, keeping in mind we could be
potentially delaying the freeze due to the importance of what we're
deciding.

Back to the subject. I am a a strict camper, but I understand the nature of
PHP and its loose type.
Considering the 3 RFCs, and also counting the number of WTFs each one adds,
I hereby describe my choice.

By considering PHP's nature, having a dual mode is a WTF. I can see myself
asking multiple times a day "is this file strict or not?" to trace
potential bugs or type juggling. I do want strict, but I don't think it's
the right time for PHP to make this move. Userland would have strictness,
but all internal functions are a weird WTF type juggling mode. I originally
switched my vote many times in the v3 of the RFC, mainly because PHP
developers are the ones that would suffer by these configurability on a
daily basis. I ended up with a YES vote because when considering STH or
nothing at all, I prefer to have some.
Coercive STH already added a WTH by not being inline with ZPP. It also have
a timely migration path to turn them in sync, which would bring more
breakage, more refactoring and more headache.
Basic STH is the only one inline with ZPP, and the mostly natural for every
PHP developer. They understand how internal PHP functions work and they
know what to do. It also does not have the duality mode as v5 RFC.
Therefore, this is where I'd place my vote.

However, I do think that ZPP needs to migrate as Coercive STH partially
defined to a stricter conversion scenario. That is what Basic STH should
follow, but at the same time pace, not creating a discrepancy now and a WTF
to userland. Ideally, Basic STH should also reuse ZPP support, meaning that
any updates to ZPP would also benefit the STH.


That said, I'll place my vote as YES in Basic STH and vote NO for the other
ones.


Regards,

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

Re: [PHP-DEV] [RFC] Basic Scalar Types

[guilhermebla...@gmail.com]

+1 on this, as this is more inline with how ZPP currently works, creating
less headaches to end users.

On Fri, Mar 13, 2015 at 2:33 PM, Stelian Mocanita  wrote:

> So to get it clear for everyone: the right way is for internals to ignore
> community as a
> whole, stick to their own views and implement something nobody actually
> wants - just
> because there is no time -  on the idea that "something is better than
> nothing"?
>
> Without pointing any fingers it sure looks like a stalling tactic where
> someone
> eventually gets what they want.
>
> Highly disappointed on this outcome.
>
> On Fri, Mar 13, 2015 at 6:20 PM, Eli  wrote:
>
> > Not that another +1 is needed, but I'm with Andi here.  I do personally
> > like this 3rd proposal as an option, if nothing else because it
> > implements the 'simpler base'  at the moment, and allows us, once people
> > are used to this being part of the language, to continue to evolve
> > later.  And that evolution can be based upon our real world experience
> > of using this 'base level' of typehinting for a while.
> >
> > Versus the more complicated versions, of which both Zeev's and Anthony's
> > are.  In each their own way.
> >
> > Eli
> >
> > On 3/13/15 1:17 AM, Andi Gutmans wrote:
> > > Agree and I would vote +1 on this even if I'd prefer coercive. It is a
> > > very valid option for a 7.0 and it is future proof.
> >
> > --
> > |   Eli White   |   http://eliw.com/   |   Twitter: EliW   |
> >
> >
> >
>



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

Re: [PHP-DEV] [RFC] Basic Scalar Types

[guilhermebla...@gmail.com]

I really want to understand if we're gonna allow this RFC voting or not.
That's important to reconsider my vote on STH

On Fri, Mar 13, 2015 at 5:36 PM, Pierre Joye  wrote:

>
> On Mar 14, 2015 7:50 AM, "Benjamin Eberlei"  wrote:
> >
> > On Fri, Mar 13, 2015 at 9:44 PM, Zeev Suraski  wrote:
> >
> > > > -Original Message-
> > > > From: Derick Rethans [mailto:der...@php.net]
> > > > Sent: Friday, March 13, 2015 10:34 PM
> > > > To: guilhermebla...@gmail.com; Stelian Mocanita
> > > > Cc: Eli; PHP Internals List
> > > > Subject: Re: [PHP-DEV] [RFC] Basic Scalar Types
> > > >
> > > >Chance of this RFC passing is going to be slim, as it only caters for
> one
> > > >of the
> > > > three groups that Antony described...
> > > >
> > > > I certainly will vote against it.
> > >
> > > You may very well be right, but the only way of truly knowing would be
> > > putting it up for a vote.  I'd feel a lot more comfortable if this was
> also
> > > available for a vote before moving my nay to yay on the Dual Mode RFC.
> > >
> >
> > I don't get it.
> >
> > you called Andrea out for not putting up v1 of her RFC for vote because
> it
> > had so much momentum behind it.
> > Instead of just doing what bwoebi did you put up another RFC that got
> *much
> > more* negative tone from the beginning.
> > We agree on having a vote on two RFCs, coercive and v5.
> > Now that coercive is the clear loser suddenly v1 must be up for vote as
> > well?
>
> I totally agree with your comment, it looks a bit like a desperate move or
> attempt to block or counter the other one.
>
> We should really stop that...
>
> > You had the chance to do just this.
>
> >
> > > Zeev
> > >
> > > --
> > > 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] Basic Scalar Types

[guilhermebla...@gmail.com]

And none answered me... is this RFC gonna be allowed to enter on voting
phase for 7.0 or not?

This drastically changes my voted on STH v5 which ends EOD today.

[]s,

On Fri, Mar 13, 2015 at 6:17 PM, Stelian Mocanita  wrote:

> Zeev, allow me to understand how this goes. Bob's discussions on the RFC
> started 2 days ago. Based on the current rules, the RFC can only go to vote
> after 2 weeks. That means in 12 days starting now.
>
> So we are either violating the RFC rules by pushing the vote tomorrow or
> we're
> delaying PHP7 for another 2 weeks maybe yet another TH RFC passes?
>
> Pointing at number 6 from https://wiki.php.net/rfc/howto
>
> On Fri, Mar 13, 2015 at 11:07 PM, Pierre Joye 
> wrote:
>
> > On Mar 14, 2015 9:03 AM, "Zeev Suraski"  wrote:
> >
> > >
> > > Maybe I was naïve, but I thought I had a better way to make both weak &
> > > strict camps happy,
> >
> > By dropping strict despite all discussions, proposing a pandara box rfc
> by
> > changing the casting rules and now suddenly proposing to go vote to yet
> > another "perfect" RFC? Sorry, it does not help anyone and damages php,
> > creates yet more issues. This is not a good call.
> >
>



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

Re: [PHP-DEV] [RFC] Basic Scalar Types

[guilhermebla...@gmail.com]

I'll switch my vote on STH v5 to YES.
If we get Basic STH into voting phase, I change my vote to NO and vote on
YES on Basic STH.


[]s,

On Fri, Mar 13, 2015 at 6:35 PM, Pierre Joye  wrote:

> On Mar 14, 2015 9:24 AM, "Zeev Suraski"  wrote:
> >
> > > -Original Message-
> > > From: stelian.mocan...@gmail.com [mailto:stelian.mocan...@gmail.com]
> > > On Behalf Of Stelian Mocanita
> > > Sent: Saturday, March 14, 2015 12:18 AM
> > > To: Pierre Joye
> > > Cc: Zeev Suraski; PHP internals; Benjamin Eberlei
> > > Subject: Re: [PHP-DEV] [RFC] Basic Scalar Types
> > >
> > > Zeev, allow me to understand how this goes. Bob's discussions on the
> RFC
> > > started 2 days ago. Based on the current rules, the RFC can only go to
> > > vote
> > > after 2 weeks. That means in 12 days starting now.
> > >
> > > So we are either violating the RFC rules by pushing the vote tomorrow
> or
> > > we're delaying PHP7 for another 2 weeks maybe yet another TH RFC
> passes?
> >
> > Bob's RFC is effectively Andrea's v0.1 RFC which was discussed in detail
> and
> > introduced well over two weeks ago.
>
> No it is not. It is a new one, period. Just like this other rfc, discussed
> months ago just went to vote without any discussions.
>
> This is not the way it works and it has the bad taste of political moves.
>
> > I hope we're not going to go into more and more extremes of playing a law
> > firm and not an OS project.
>
> So law is firm when it fits your goal but flexible when not? We have
> relatively strict rules for this exact reason: nk double standard. Stop
> playing with the rules and stand as someone willing to find compromises.
>



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

Re: [PHP-DEV] JsonSerializable New Interface method Proposal

[guilhermebla...@gmail.com]

What about JsonDeserializable? I would like to have the choice to have a
serialize-only operation.

On Mon, Jul 13, 2015 at 10:13 AM, Dean Eigenmann 
wrote:

> The Additional function you have proposed seems like the easiest and best
> way to do it currently without changing the language. I was thinking of
> giving the cast syntax special meaning if used in connection with
> json_decode, but this would most likely be near to impossible.
>
> On Jul 13, 2015, at 04:08 PM, "Sebastian B.-Hagensen" <
> sbj.ml.r...@gmail.com> wrote:
>
> Hi,
>
> I like the general idea behind that proposal.
>
> I'm not sure how you would want to implement that however (please
> expand the rfc on that topic).
> Do you want to give the cast syntax a special meaning if used in
> connection with json_decode or add the general ability to
> cast a stdClass object (as returned by json_decode) to a specific user
> type or do you want to change json_decode to return a new class
> (extending stdclass) that can be casted in the way you want? The first
> two could be considered fundamental changes to the language, the third
> may include serious bc concerns.
>
> Wouldn't an additional function (maybe in addition to your proposed
> interface; example: json_decode_to(string $json, string $className,
> int $options)) solve the issue without changing the language?
>
> Regards,
>
>
> 2015-07-13 15:22 GMT+02:00 Dean Eigenmann :
>
> Ive just opened a new RFC https://wiki.php.net/rfc/jsonserializable
>
> regarding Json to Object unserialization.
>
>


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

Re: [PHP-DEV] Accessors v2 Patch

[guilhermebla...@gmail.com]

I have just one question, partially unrelated.

How can I make something similar to Interceptors of Java according to
your approach?
For those that have no idea, interceptors is a way to intercept
get/set of a property inside the class and act under this
circumstance.

[]s,

On Sun, Dec 11, 2011 at 8:01 PM, Clint M Priest  wrote:
> To be complete I should probably add something to the reflection system as 
> well.  At present the getters/setters would show up as functions.
>
> What would be preferable?
> 1) Show up as regular functions and let users fend for themselves?
> 2) Hide from getMethods() and:
>  2.1) Provide getAccessors() - Probably returning a new 
> ReflectionPropertyAccessor class?
>  2.2) Provide getGetters(), getSetters()
> 3) Modify ReflectionProperty to include hasGetter() and hasSetter()
>
> Comments?
>
> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: Sunday, December 11, 2011 6:47 PM
> To: Clint M Priest
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Accessors v2 Patch
>
> oh right, I missed them. Yes, so it is covered as well :)
>
> On Mon, Dec 12, 2011 at 1:42 AM, Clint M Priest  wrote:
>> There are already two tests against private read and private write, should I 
>> add two for protected as well?
>
> 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
>



-- 
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] Accessors v2 Patch

[guilhermebla...@gmail.com]

hi Will,

That's what I've been thinking about.
I have a special necessity to overload a class in a Proxy
implementation (an instance that wraps a real Entity), demanding the
load when any getter is active.

This implementation seems to fit perfectly my needs, while still be cleaning.

I wonder if the user have already implemented a getter in this
approach, how can I overload this one?
Example:

class Foo
{
protected $name {
get { return $this->name; }
set { $this->name = $value; }
}
// ...
}

class FooProxy extends Foo
{
protected $name {
get { $this->__load(); parent::get(); }
set { $this->__load(); parent::set($value); }
}
// ...
}


How would it act in this situation?

Cheers,

On Sun, Dec 11, 2011 at 10:18 PM, Will Fitch  wrote:
> This approach, in theory, is an interceptor itself.  Most use-cases around 
> this approach will be changing or augmenting an existing property that is not 
> public.  If you wanted to modify this interception, you'd need to extend the 
> class using it and redefine the getter and/or setter.
>
>
> On Dec 11, 2011, at 10:02 PM, guilhermebla...@gmail.com wrote:
>
>> I have just one question, partially unrelated.
>>
>> How can I make something similar to Interceptors of Java according to
>> your approach?
>> For those that have no idea, interceptors is a way to intercept
>> get/set of a property inside the class and act under this
>> circumstance.
>>
>> []s,
>>
>> On Sun, Dec 11, 2011 at 8:01 PM, Clint M Priest  wrote:
>>> To be complete I should probably add something to the reflection system as 
>>> well.  At present the getters/setters would show up as functions.
>>>
>>> What would be preferable?
>>> 1) Show up as regular functions and let users fend for themselves?
>>> 2) Hide from getMethods() and:
>>>  2.1) Provide getAccessors() - Probably returning a new 
>>> ReflectionPropertyAccessor class?
>>>  2.2) Provide getGetters(), getSetters()
>>> 3) Modify ReflectionProperty to include hasGetter() and hasSetter()
>>>
>>> Comments?
>>>
>>> -Original Message-
>>> From: Pierre Joye [mailto:pierre@gmail.com]
>>> Sent: Sunday, December 11, 2011 6:47 PM
>>> To: Clint M Priest
>>> Cc: internals@lists.php.net
>>> Subject: Re: [PHP-DEV] Accessors v2 Patch
>>>
>>> oh right, I missed them. Yes, so it is covered as well :)
>>>
>>> On Mon, Dec 12, 2011 at 1:42 AM, Clint M Priest  wrote:
>>>> There are already two tests against private read and private write, should 
>>>> I add two for protected as well?
>>>
>>> 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
>>>
>>
>>
>>
>> --
>> 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
>>
>



-- 
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] Accessors v2 Patch

[guilhermebla...@gmail.com]

Hi,

I don't see how we could possibly do as option 1.
The structure would be weird, because considering I'm looking for an
specific ReflectionMethod that matches a property name, I'd also be
able to call it through invoke, but also regularly through
$obj->Setter($value);
Since I don't see in the match as possible to be executed as the
second possibility, I'd rather bring to a more centralized approach.

$reflProperty = $reflClass->getProperty('Hours');
$reflProperty->hasGetter() === true
$reflProperty->hasSetter() === true

Also,

$reflProperty->setValue($object, $value); would call the Setter method
as well as
$reflProperty->getValue($object) would call the Getter method

It seems the most consistent and centralized approach.


Regards,

2011/12/12 Johannes Schlüter :
> On Mon, 2011-12-12 at 01:01 +, Clint M Priest wrote:
>> To be complete I should probably add something to the reflection system as 
>> well.  At present the getters/setters would show up as functions.
>>
>> What would be preferable?
>> 1) Show up as regular functions and let users fend for themselves?
>> 2) Hide from getMethods() and:
>>   2.1) Provide getAccessors() - Probably returning a new 
>> ReflectionPropertyAccessor class?
>>   2.2) Provide getGetters(), getSetters()
>> 3) Modify ReflectionProperty to include hasGetter() and hasSetter()
>>
>> Comments?
>
> Reflection in PHP typically is leaking the implementation details
> typically quite a lot instead of abstracting things away (interfaces and
> Traits are ReflectionClass instances etc.)
>
> I didn't look at the implementation but if these accessors are
> implemented as methods (especially if it can be called just like one) I
> would go for approach 1) and probably mark with a flag. For everything
> else we'd probably have to clean-u reflection to leak less details to
> make sense.
>
> johannes
>
>> -Original Message-
>> From: Pierre Joye [mailto:pierre@gmail.com]
>> Sent: Sunday, December 11, 2011 6:47 PM
>> To: Clint M Priest
>> Cc: internals@lists.php.net
>> Subject: Re: [PHP-DEV] Accessors v2 Patch
>>
>> oh right, I missed them. Yes, so it is covered as well :)
>>
>> On Mon, Dec 12, 2011 at 1:42 AM, Clint M Priest  wrote:
>> > There are already two tests against private read and private write, should 
>> > I add two for protected as well?
>>
>> 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
>



-- 
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] php.net - The Website Ahead Contains Malware

[guilhermebla...@gmail.com]

More info about it: https://news.ycombinator.com/item?id=6604156


On Thu, Oct 24, 2013 at 7:40 AM, Lester Caine  wrote:

> Thomas Hruska wrote:
>
>> and again waiting up to 48 hours to be removed globally.
>>
>
> If it is only 48 hours ... took over two weeks to sort one of my customers
> sites that had been spammed and they had not noticed. Certainly it should
> now be easy to report problems direct to a site rather than this 'guilty
> until proved we got it wrong' approach ?
>
> As a slight aside, it is nice to see phishing sites being dealt with
> promptly and sensibly. I do follow the links knowing they are fraudulent,
> but all but one in the last few months has either just been killed, or has
> a message saying that there was a problem. Something that we can all help
> with when managing sites.
>
>
> --
> 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
>
>


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

Re: [PHP-DEV] [RFC] Introduce Abstract Syntax Tree

[guilhermebla...@gmail.com]

OMG, so +1 on this! *rolling eyes*
We'd be a step away for hookable grammars! \o/


On Thu, Jul 31, 2014 at 2:27 PM, Michael Wallner  wrote:

> On 31 July 2014 20:11, Nikita Popov  wrote:
>
> > Hi internals!
> >
> > I've created a draft RFC and implementation for the introduction of an
> > Abstract Syntax Tree (AST) as an intermediate structure in our
> compilation
> > process:
> >
> >  https://wiki.php.net/rfc/abstract_syntax_tree
> >
> > The RFC outlines why an AST is beneficial, how it impacts performance and
> > memory usage of the compile process and what changes to syntax or
> behavior
> > it introduces.
> >
> > Furthermore the RFC contains an outline of how the current implementation
> > works and what APIs it provides. This section is just an overview and I
> > hope to extend it in the future.
> >
>
> Sounds great! BTW, wasn't there a related AST GSOC project once?
>
>
> --
> Regards,
> Mike
>



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

Re: [PHP-DEV] [RFC] Introduce Abstract Syntax Tree

[guilhermebla...@gmail.com]

When is this planned to go through voting process?


On Sat, Aug 2, 2014 at 5:27 PM, Andrea Faulds  wrote:

> Hi!
>
> On 2 Aug 2014, at 21:44, Nikita Popov  wrote:
>
> > Why do you think this isn't a good idea? I think it would be a nice way
> to prototype language features before pulling them into PHP. Though
> admittedly I don't think there are many things that could be implemented
> that way.
>
> If people can extend the syntax, they will, and I don’t like the possible
> consequences of that. I’m all for overloading, but if people start relying
> on custom syntactical features, it means non-portable and confusing to read
> code. Granted, it might be useful for prototyping, but prototyping itself
> would be easier with an AST, so I’m not sure it matters.
>
> > A native extension has the limitation that it will not be able to parse
> files for newer PHP versions (which, depending on the use case may or may
> not be a problem) and probably won't provide a stable structure across
> versions. At least I think giving BC guarantees on the AST structure
> between minor versions would be way too limiting for us. As such I think
> both a native ext (which provides awesome perf) and PHP-Parser (which
> provides x-compat) have their place ;)
>
> Yeah, I was thinking that you could keep it around for version
> compatibility. You could even make your library pass through to the native
> ext where possible. :)
>
> > Yes, the AST structure is based on the existing work on constant scalar
> expressions, though by now the structure and API deviate a good bit from
> that. It doesn't cause problems for them - constant expressions go through
> a validation that checks that only valid nodes are used and adjusts those
> nodes that have special representation for the constexpr case (e.g.
> constant and class constant access)
>
> Ah, I see.
>
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>
> --
> 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] Optional nowait argument to sem_acquire

[guilhermebla...@gmail.com]

Hi,

Since I don't know where you guys like to discuss implementations, I'm
pasting same thing I did in php-src PR:

 I'd propose instead of accepting "nowait" only, I'd use a better support
and accept "until", dealing with possible cases:

   - -1: Blocks and wait until lock is acquired
   - 0: Exactly what your patch does, attempt to grab and if it fails, just
   return false (I'd remove the E_WARNING)
   - > 0: Acceptable time in milliseconds it would wait until consider the
   acquire failed


Cheers,



On Tue, Sep 2, 2014 at 8:50 AM, Matteo Beccati  wrote:

> Hi everyone,
>
> the following patch:
>
> https://github.com/php/php-src/pull/741
>
> has been lying around somewhere on my box since years and I recently
> stumbled upon it.
>
> However 5.6 was already RC and Ferenc suggested to eventually wait for
> 5.6.1.
>
> Do you think it's ok to add such a minor feature to 5.6.1?
>
>
> Cheers
> --
> Matteo Beccati
>
> Development & Consulting - http://www.beccati.com/
>
> --
> 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] Optional nowait argument to sem_acquire

[guilhermebla...@gmail.com]

Hi Matteo,

BSD does accept it as sem_timedwait, which I could find a reference for
FreeBSD:

http://www.freebsd.org/cgi/man.cgi?query=sema&sektion=9

Cheers,


On Tue, Sep 2, 2014 at 10:01 AM, Matteo Beccati  wrote:

> Hi,
>
> On 02/09/2014 15:38, guilhermebla...@gmail.com wrote:
> > I'd propose instead of accepting "nowait" only, I'd use a better support
> > and accept "until", dealing with possible cases:
> >
> >   * -1: Blocks and wait until lock is acquired
> >   * 0: Exactly what your patch does, attempt to grab and if it fails,
> > just return false (I'd remove the E_WARNING)
>
> (It doesn't. The warning is raised when the semaphore can't be acquired
> for other reasons)
>
> >   * > 0: Acceptable time in milliseconds it would wait until consider
> > the acquire failed
>
> TBH, I don't know. semtimedop is not universally available (no BSD, as
> far as I can tell) and I would prefer to avoid writing an alternative
> implementation in case it's not available. On the other hand triggering
> an error in such case wouldn't be nice.
>
>
> Cheers
> --
> Matteo Beccati
>
> Development & Consulting - http://www.beccati.com/
>



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

Re: [PHP-DEV] Optional nowait argument to sem_acquire

[guilhermebla...@gmail.com]

It's also supported by System V using exactly same API.
Some references:

http://fossies.org/dox/glibc-2.19/sem__timedwait_8c_source.html
http://manned.org/sem_timedwait/83baa20c
http://linux.die.net/man/3/sem_timedwait
http://pubs.opengroup.org/onlinepubs/009695399/functions/sem_timedwait.html


On Tue, Sep 2, 2014 at 10:46 AM, Matteo Beccati  wrote:

> On 02/09/2014 16:39, guilhermebla...@gmail.com wrote:
> > Hi Matteo,
> >
> > BSD does accept it as sem_timedwait, which I could find a reference for
> > FreeBSD:
> >
> > http://www.freebsd.org/cgi/man.cgi?query=sema&sektion=9
>
> that's part of the FreeBSD Kernel Developer's Manual, not SysV semaphores
> ;)
>
>
> Cheers
> --
> Matteo Beccati
>
> Development & Consulting - http://www.beccati.com/
>



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

Re: [PHP-DEV] Optional nowait argument to sem_acquire

[guilhermebla...@gmail.com]

After discussing with Matteo, I realized I was referring to POSIX
sempahores and not to System V.

Patch looks ok to me.

Is it possible to have this merged?

Thanks,


On Tue, Sep 2, 2014 at 11:03 AM, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:

> It's also supported by System V using exactly same API.
> Some references:
>
> http://fossies.org/dox/glibc-2.19/sem__timedwait_8c_source.html
> http://manned.org/sem_timedwait/83baa20c
> http://linux.die.net/man/3/sem_timedwait
> http://pubs.opengroup.org/onlinepubs/009695399/functions/sem_timedwait.html
>
>
> On Tue, Sep 2, 2014 at 10:46 AM, Matteo Beccati  wrote:
>
>> On 02/09/2014 16:39, guilhermebla...@gmail.com wrote:
>> > Hi Matteo,
>> >
>> > BSD does accept it as sem_timedwait, which I could find a reference for
>> > FreeBSD:
>> >
>> > http://www.freebsd.org/cgi/man.cgi?query=sema&sektion=9
>>
>> that's part of the FreeBSD Kernel Developer's Manual, not SysV semaphores
>> ;)
>>
>>
>> Cheers
>> --
>> Matteo Beccati
>>
>> Development & Consulting - http://www.beccati.com/
>>
>
>
>
> --
> Guilherme Blanco
> MSN: guilhermebla...@hotmail.com
> GTalk: guilhermeblanco
> Toronto - ON/Canada
>



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

[PHP-DEV] [RFC] Move pecl_sync to core

[guilhermebla...@gmail.com]

Hi,

Here is a new RFC: https://wiki.php.net/rfc/sync

Thoughts appreciated.

Cheers,

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

Re: [PHP-DEV] [RFC] Move pecl_sync to core

[guilhermebla...@gmail.com]

> Fix the title? :)  Is it for sync or pecl_http?

Someone already fixed that.

> Isn't this extension a bit "young" to join php core ?

I agree. However, there's no equivalent existing support in PHP atm.
Also, any new functionality introduced to PHP would always be new, young
and caring maturity.

> What are the actual benefits of this being included in core? The RFC
> doesn't really list any.

I updated the RFC to include some rationale around it.

> Also, there was a discussion in June (started by Julien) about
> refactoring PHPs IO layer, where many people expressed a wish to have
> something libuv based in core, this comes with cross-platform
> semaphors and mutexes as well as a TON of other awesome goodies. If
> anything, this is what I would prefer in core.

I would love that, because it would make this RFC obsolete IF the low level
API also gets exposed to userland.
But if I/O gets refactored we have 2 alternatives:
- Locking is built-in concurrency intensive places, such as file creation,
writing, cache inclusion, etc.
- Low level API gets exposed to consumers, then any extension or userland
code could benefit

> Why would you use PHP for such low level concepts ?

I think I was able to answer that through the rationale section exposing an
example on RFC.
Please reply back if not.

> Why would we support it in Core?
> Why is this good for PHP?

PHP doesn't offer an easy cross-platform way to implement locking.
All you can do is through flock emulating Mutexes and Semaphores, but even
this is not cross-platform; for example, Windows does not support blocking
until it acquires the lock.

> Why will a significant percentage of users be interested in this?
> Why is it necessary?

Not a significant percentage would use it at userland level, I agree.
However, low level libraries could benefit that would later benefit many
other projects and people.
I, for example, would consider to add locking support inside of
Doctrine\Cache, which would benefit Zend, Symfony, Drupal, CMSs and many
other projects that rely on this low level abstraction API. But currently,
I'm unable to do it since there's no PHP support and also because we avoid
enforcing the necessity of PECL extensions to get code up and running.

PHP is not a toy language anymore and more robust functionality is severely
needed to the language move forward. I consider Locking is one of the
missing pieces to the language, but the world is not made of Guilherme
Blanco's... =P


PS: I'll answer Thomas' email later.


On Tue, Sep 30, 2014 at 1:27 PM, Sara Golemon  wrote:

> This needs a "Why" section.
>
> Why is this good for PHP?
> Why will a significant percentage of users be interested in this?
> Why is it necessary?
>
> This feel pretty niche to me.
>
> -Sara
>
> > On Sep 30, 2014, at 4:06, "guilhermebla...@gmail.com" <
> guilhermebla...@gmail.com> wrote:
> >
> > Hi,
> >
> > Here is a new RFC: https://wiki.php.net/rfc/sync
> >
> > Thoughts appreciated.
> >
> > Cheers,
> >
> > --
> > Guilherme Blanco
> > MSN: guilhermebla...@hotmail.com
> > GTalk: guilhermeblanco
> > Toronto - ON/Canada
>



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

Re: [PHP-DEV] [RFC] Move pecl_sync to core

[guilhermebla...@gmail.com]

> What does that even mean?

It means that any new functionality that gets into core could be considered
"young". Like when PHAR got introduced, it was a "young" extension. Same
for PDO, same for FileInfo...
What I'm trying to highlight is that being a recently coded extension or
not, it's not a good argument to say join/no join.

On Tue, Sep 30, 2014 at 4:05 PM, Andrea Faulds  wrote:

>
> On 30 Sep 2014, at 20:56, guilhermebla...@gmail.com wrote:
>
> >> Isn't this extension a bit "young" to join php core ?
> >
> > I agree. However, there's no equivalent existing support in PHP atm.
>
> That, in itself, is not necessarily a justification. Unless an awful lot
> of PHP users need this, it shouldn’t be in core.
>
> > Also, any new functionality introduced to PHP would always be new, young
> > and caring maturity.
>
> What does that even mean?
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>


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

Re: [PHP-DEV] [RFC] Move pecl_sync to core

[guilhermebla...@gmail.com]

Hi,

Ferenc nailed why this RFC could be considered invalid. Maintenance burden
and separate releases would be bad if tied to php-src. I'll update its
status to declined.

Joe, as I said in the RFC, Mutex could only be supported through pthreads
PECL.
So your answer was still not 100% accurate from my POV.

Julien, you know I don't feel offended with no-go feedbacks. All I want is
a reasonable argumentation over a topic and general consensus.

Cheers,


On Wed, Oct 1, 2014 at 9:46 AM, Julien Pauli  wrote:

> On Wed, Oct 1, 2014 at 3:08 PM, Johannes Schlüter
>  wrote:
> > On Wed, 2014-10-01 at 14:26 +0200, Ferenc Kovacs wrote:
> >> .
> >> personally I think that a pecl extension needs to have stronger
> arguments
> >> to be bundled with php-src than the fact that it would probably create a
> >> bit more exposure for the ext.
> >>
> >
> > Fully agree and mind this:
> >
> > For an average user it doesn't really make a difference if we bundle it
> > or not - linux distributions move even bundled extensions into own
> > packages and package pecl ones, too. On Windows installers bundle pecl
> > things too.
> >
> > For the extension maintainer not being bundled has the benefit of having
> > its own release cycle. They are not bound to core PHP's rules and add
> > minor features as they like and roll bug fixes as needed, while even
> > fixes are simpler - they don't have to merge between as many branches.
> >
> > For core PHP having it in PECL has the benefit that a showstopper in the
> > extension won't stop the PHP release. If the extension takes a week more
> > that is fine.
> >
> > One might say that is a downside of using pecl that less people test it
> > and in core the extension would receive more attention but I seriously
> > doubt that many core developers enable all extensions (lester i.e.
> > rightfully complains about the lack of attention on firebird)
> >
> > Now looking at this specific thing: PHP is a shared nothing environment
> > for handling web requests. By having the isolation between request
> > containers we can easily scale PHP by adding more machines, which is
> > easy as we don't share state. sync does the opposite, its purpose is to
> > break this isolation and offering a way to make request dependent on
> > each other. There are cases where this is useful and it is great that we
> > have a module with this option but in my opinion is not what PHP core
> > should do. And yes, we have sysvmsg, sysvsem and sysvshm in the core
> > distributions, but in my opinion more due to the fact that they predate
> > pecl by a few years.
>
> That's a good sum-up.
> Locking is the opposite of PHP model, which is based on non-locking
> model, fire-and-forget , scale easilly
>
> And seriously, if you need locking, mutexes etc... in PHP, then you
> should probably write your stuff in C or Java. The PHP engine can't
> fully support such concepts to provide them to userland, or at least
> it won't be cheap in human effort to have such a thing reach a stable
> state so that we can ship it into PHP.
>
> This is not a troll, or a "go away from PHP", please don't feel
> offended , but PHP is just not designed to do that, this is not the
> language you'll use when you face such problems. PHP is mature, but
> still has a target, don't target something its not been designed for.
>
>
>
> Julien.Pauli
>



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

Re: [PHP-DEV] RFC: Return Types Update

[guilhermebla...@gmail.com]

Hi Levi,

This RFC is pretty consistent, small and focused on a specific part of the
overall previously desired support.
I do think many more subsequent RFCs would come up after this one to expand
return typehint support, but as it stands right now is extremely good. Any
further inclusion would drastically delay possible acceptance of this RFC
and a possible withdrawn, since every piece left out are different
discussion points.

+1 so far.

[]s,


On Thu, Oct 16, 2014 at 10:46 AM, Nikita Nefedov  wrote:

> On Thu, 16 Oct 2014 18:39:06 +0400, Davey Shafik  wrote:
>
>  I very much like this — though I would say it was dependent on the
>> nullable
>> types RFC (like splat and variadics were codependent).
>>
>> While I would like to see the introduction of a void type, I understand
>> and
>> respect the limitations on the RFC.
>>
>> However, one thing that I do think is missing, is the equivalent of Hacks
>> `$this` return type. You have `self` and `parent`, but I think without a
>> `static` equivalent you can break things:
>>
>> class foo {
>>  static public function instanceOf(): self {
>>return new static();
>>  }
>> }
>>
>> class bar extends foo { }
>>
>> foo::instanceOf(); // new foo, this is fine, returns `self`.
>> bar::instanceOf(); // new bar, no longer `self`
>>
>
> Hi,
>
> bar is considered as instance of foo so shouldn't be any problem.
> Otherwise it would break LSP
>
>
> --
> 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] Annotation PHP 7

[guilhermebla...@gmail.com]

Hi,

As one of the original authors of both Doctrine Annotations and previous
RFC of native Annotations in PHP, I can go thoroughly on every specific
detail about challenges of design decisions to make.

Primarily, I do not see docblocks as the right place to store class'
metadata information. Metadata != Comments.
This brings the next piece of the puzzle. We have to update lexical and
semantical understanding of PHP. Taking Java's approach (@) does not work
in PHP, because it conflicts with error supression. Same thing happened for
{}. When Pierrick and I wrote the RFC, [] was not supported, so likely
it'll break parsing too now, but at that point, we got [] to work.
Ultimately, we chose <> to avoid headaches.

After that, we entered on how we could semantically validate arguments. We
could easily create an array declaration (as Benjamin suggested), but that
would become near to impossible for a large system to figure it out where
it was the problem, the small made typo. The solution was to instantiate
classes (or what we folded during development, a special class type,
annotation), because we could validate semantically not only classes, but
also properties. We could also implement annotation targets (something can
only be used in a method or at the class level).
This is a valid thing to consider... more effort to the language means less
efforts from end-users (consumers). Bringing annotation targeting,
semantical validation was a great addiction to the RFC, because it makes
easier to developers find bugs, but it exposed another set of problems (and
their solutions):

1- How to instantiate them?

We dropped "new" necessity under that scope and used <>. Again, it made
more sense to specialize class definition into a new type (annotation), but
we kept same implementation for simplicity.

2- How to consume on Reflection?

We decided to use it by fetching based on class name. This added the
enforcement of only having 1 instance of a class per annotation context.

3- How to partially attribute class properties while others rely on
convention over configuration?

We had to bring named parameters to fix this.

4- How to deal with nested Annotations?

When we dropped "new", it became easy to support them by using <>.

Despite any decision, inheritance is also a problem to solve. Should it
clear everything out if a method is overwritten? Should a class require
redeclaration of everything? This adds complexity and error-prone
situations.
What if everything gets inherited by default? Well, then we need a way to
remove other previously declared items. We came up with the solution to
just clear them until we got into further discussion. We had an Override
patch that would inherit everything by default and with Override it would
clear any previously declared Annotations too based on discussion's result.

I hope that gives a but more insight on how RFC Annotations reached that
level of maturity.

Cheers,

On Tue, Nov 4, 2014 at 1:58 PM, Andrea Faulds  wrote:

>
> > On 4 Nov 2014, at 18:27, Stas Malyshev  wrote:
> >
> > For python-style decorators, at least the way they work in Python, we'd
> > need to organize our function tables differently, as Python just
> > replaces the function with another one while decorating, and I'm not
> > sure it'd be as easy to do with PHP.
>
> Are you sure this would be difficult? We could create a closure of the
> class method (trivial to do), pass it to a userland function upon creating
> the class (the former is easy, the “upon creating the class” is the issue),
> and use the closure it returns as the class method. There’d be issue with
> autoloading to iron out, but I don’t think it’d be a problem.
>
> > You'd have to convert all such functions to closures (or something that
> > can be both, maybe) and have the engine be aware that function table now
> > can store closures. And, also, inheritance may get a bit weird there. It
> > would be very powerful, but it may not be very simple to do.
>
> A closure is just a normal function, actually. The Closure class just
> wraps a zend_function and a this pointer. There’s no reason you couldn’t
> substitute here. I believe you could literally just copy the zend_function
> across, though there’d obviously be some complications.
>
> Not sure about inheritance.
>
> > Also, it is a major overkill for what annotations are commonly used -
> > attaching a piece of data to an entity. In Python, decorators are very
> > powerful for modifying function behavior (i.e., attaching pre/post
> > conditions to functions or doing some things phpunit does is really
> > easy) but it is too much for just attaching data.
>
> This is useful for merely attaching data as well (just return the function
> passed), but it also enables manipulating the function. It could replace
> some cases of merely attaching data, too, by making the function do
> something itself, rather than having something else do something if a
> function has a certain annotation, when calling that 

Re: [PHP-DEV] Annotation PHP 7

[guilhermebla...@gmail.com]

Hi,

By dealing with annotations in docblocks will force the Annotations parser
to *much* smarter than you imagine.

Currently in Doctrine Annotations implementation, @param and @Param are
considered different not only by first character to be uppercased, but
rather because a class also exist in that namespace and also because it's
an @Annotation.
Smarter I mean that you'll have to build a rejection list of
non-standardized annotations, such as phpdoc and phpunit. It also makes
pretty hard to parse emails.
You can see the list of ignored names as part of
https://github.com/doctrine/annotations/blob/master/lib/Doctrine/Common/Annotations/AnnotationReader.php#L48

Regards,


On Tue, Nov 4, 2014 at 5:20 PM, Andrea Faulds  wrote:

>
> > On 4 Nov 2014, at 21:31, Stas Malyshev  wrote:
> >
> >> This brings the next piece of the puzzle. We have to update lexical and
> >> semantical understanding of PHP. Taking Java's approach (@) does not
> >> work in PHP, because it conflicts with error supression. Same thing
> >
> > Except for the mental context, how @ conflicts with errors? Suppression
> > is always in runtime context and applied to expressions, annotations are
> > always outside of it and apply to declarations. Unless of course you
> > want to annotate variables and closures, but I'm not sure annotating
> > expressions is such a good idea anyway
>
> At the top-level, @ is a shift/reduce conflict due to ambiguity between
> statement annotation and expression.
>
> Though it might be possible to work around that with the AST (ew).
>
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>


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

Re: [PHP-DEV] Annotation PHP 7

[guilhermebla...@gmail.com]

Sorry, I forgot to add references to how we fixed emails handling. It got
split in 2 places:

- Initial root level annotation
https://github.com/doctrine/annotations/blob/master/lib/Doctrine/Common/Annotations/DocParser.php#L350

- Subsequent root level annotations
https://github.com/doctrine/annotations/blob/master/lib/Doctrine/Common/Annotations/DocParser.php#L631

[]s,

On Tue, Nov 4, 2014 at 5:42 PM, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:

> Hi,
>
> By dealing with annotations in docblocks will force the Annotations parser
> to *much* smarter than you imagine.
>
> Currently in Doctrine Annotations implementation, @param and @Param are
> considered different not only by first character to be uppercased, but
> rather because a class also exist in that namespace and also because it's
> an @Annotation.
> Smarter I mean that you'll have to build a rejection list of
> non-standardized annotations, such as phpdoc and phpunit. It also makes
> pretty hard to parse emails.
> You can see the list of ignored names as part of
> https://github.com/doctrine/annotations/blob/master/lib/Doctrine/Common/Annotations/AnnotationReader.php#L48
>
> Regards,
>
>
> On Tue, Nov 4, 2014 at 5:20 PM, Andrea Faulds  wrote:
>
>>
>> > On 4 Nov 2014, at 21:31, Stas Malyshev  wrote:
>> >
>> >> This brings the next piece of the puzzle. We have to update lexical and
>> >> semantical understanding of PHP. Taking Java's approach (@) does not
>> >> work in PHP, because it conflicts with error supression. Same thing
>> >
>> > Except for the mental context, how @ conflicts with errors? Suppression
>> > is always in runtime context and applied to expressions, annotations are
>> > always outside of it and apply to declarations. Unless of course you
>> > want to annotate variables and closures, but I'm not sure annotating
>> > expressions is such a good idea anyway
>>
>> At the top-level, @ is a shift/reduce conflict due to ambiguity between
>> statement annotation and expression.
>>
>> Though it might be possible to work around that with the AST (ew).
>>
>> --
>> Andrea Faulds
>> http://ajf.me/
>>
>>
>>
>>
>>
>
>
> --
> Guilherme Blanco
> MSN: guilhermebla...@hotmail.com
> GTalk: guilhermeblanco
> Toronto - ON/Canada
>



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

[PHP-DEV] [IDEA] Class modifiers support expansion

[guilhermebla...@gmail.com]

Hi internals,

Library developers sometimes plan for extensibility of their code, but not
all pieces are able to be extended and unexpected usage can lead to
unpredictable behavior.
Based on that, I consider it may be a good addition to PHP to add class
visibility support and enhance existing modifiers' support.

First, we should discuss about possible enhancements on current existing
class modifiers' support (abstract and final). Currently, just as an
example, I can create a trait with abstract methods, but I cannot declare
an abstract trait.
My proposed enhancements are:

- abstract traits: Currently we only add implicit abstract. We should allow
explicit declarations too. Nothing to change in the overall support, seems
just a scanner inclusion.
- final traits: prevent to be composed in other traits
- final interfaces: prevent to be extended in other interfaces

By adding these minor additions, we may likely simplify the scanner a bit.
This would also make easier to support class visibility in the scanner.

Unfortunately, PHP does not support nested classes. Personally speaking, I
feel that the language can live happy without it, as soon as we can have
class visibility support.

Now what I mean by class visibility, it requires a better discussion on how
it could behave, since any other language relies on nested classes to
expose this support. Nevertheless, PHP's lack of Open/Close principle
support could be addressed easily. This is my POV on how it could behave:

- private classes: Can only be extended and instantiated inside of the same
namespace it sits. This is the similar to private-package support in Java.
- protected classes: I can't determine any similarity to any other language
in this one, but it could behave somehow like: can be extended and
instantiated anywhere within the root namespace.
- public classes: same as current PHP support

What do you think about it?

Cheers,

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

Re: [PHP-DEV] [IDEA] Class modifiers support expansion

[guilhermebla...@gmail.com]

I think parts of this can easily be handled in zend_compile.
Other pieces requires runtime introspection that could be done at
zend_vm_def. My only concern is how to know what's the active scope
(class)...

While researching for data flow, I also saw that with the inclusion of AST,
some checks currently in zend_inheritance could be moved to zend_compile
too.

If we can discuss and reach some consensus, I can work (or at least try to)
on a patch and propose officially as an RFC. But before doing that, we need
to resolve how private/protected should behave. My suggestion could work,
but it may not be a sane approach.

[]s,

On Tue, Nov 18, 2014 at 12:58 PM, Andrea Faulds  wrote:

>
> > On 18 Nov 2014, at 17:33, guilhermebla...@gmail.com wrote:
> >
> > Library developers sometimes plan for extensibility of their code, but
> not
> > all pieces are able to be extended and unexpected usage can lead to
> > unpredictable behavior.
> > Based on that, I consider it may be a good addition to PHP to add class
> > visibility support and enhance existing modifiers' support.
>
> I was thinking the very same thing after __construct() came up, but wasn’t
> sure how it should work. :)
>
> > Now what I mean by class visibility, it requires a better discussion on
> how
> > it could behave, since any other language relies on nested classes to
> > expose this support. Nevertheless, PHP's lack of Open/Close principle
> > support could be addressed easily. This is my POV on how it could behave:
> >
> > - private classes: Can only be extended and instantiated inside of the
> same
> > namespace it sits. This is the similar to private-package support in
> Java.
> > - protected classes: I can't determine any similarity to any other
> language
> > in this one, but it could behave somehow like: can be extended and
> > instantiated anywhere within the root namespace.
> > - public classes: same as current PHP support
> >
> > What do you think about it?
>
> I think it’s a good idea, the problem is defining private and protected.
>
> I wonder if this is something autoloaders could handle? private classes
> might be visible only within the same file, while protected classes might
> be visible only to other files the autoloader can see.
>
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>


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

[PHP-DEV] [RFC] Abstract final classes

[guilhermebla...@gmail.com]

Hi,

I worked on an implementation of a somehow controversial concept that
exists in hack and C#: abstract final classes.

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

My motivation is to further expand class support to add modifiers (PPP -
public, protected, private). I added this change to initially segregate
grammar rules. It was an easy feature without extensive complexity and
covers some use-cases.

As a reference, here is the commit hash that added this feature to Hack:
https://github.com/facebook/hhvm/commit/faedfaf46b0deb859b0c20fb36a574be7a4f2f55

Cheers,

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

Re: [PHP-DEV] [RFC] Abstract final classes

[guilhermebla...@gmail.com]

> In the RFC, I think one phrase needs clarification:
>
> Currently, PHP developers' only resource is to create a final class with
> a private constructor, leading to untestable and error prone code.
>
> What is "error prone" in private __construct(); and how the RFC improves
> the testability of such class?

The reason comes not to the construct method itself, but to other
implemented methods.
By forgetting "static" in any of your declared methods, you get no parse
error and gives you 2 possibilities:
- With E_STRICT enabled: Fatal error when non-static method is being
statically called. You'll only get this at runtime, leading to potentially
error prone. Now the testability come that with this addiction, you get a
fatal error, which is easily fixable at compile time, not runtime.
- With E_STRICT disabled: You get a warning on php log and everything works
(which is a huge wtf mode).

> The vote should be 2/3+1 surely as it is a language change.

Sure, I can update the RFC to clarify this.


>> My motivation is to further expand class support to add modifiers (PPP -
>> public, protected, private). I added this change to initially segregate
>> grammar rules. It was an easy feature without extensive complexity and
>> covers some use-cases.
>
> I'm not sure I understand this part. Could you explain more?

My end goal is to add class visibility to PHP. Unfortunately, I was forced
to change bison grammar, reduce one ACC flag, so I could add this support.
While doing that, I realized that "abstract final" was an easy support to
add, since the entire engine already deals with both cases smoothly. All I
had to do was remove the compiler check that was fataling and add necessary
checks for class members.
I stopped to code class visibility so we could vote on small incremental
feature addictions. https://github.com/php/php-src/pull/911 is a
requirement for class visibility too, because I'll move the ZEND_ACC_TRAIT
to a proper binary value and address builtin_functions accordingly. I saw
not linear room for a new flag, so I worked on reusing FINAL and now I
worked on grammar support as part of this RFC's patch. Next patch will add
PPP (public, protected, private) support to classes.

> "Abstract final" is a strange way to name it. What you want is a "static"
class:

> This has always been my feeling. To me, "abstract" means "must be
extended", and "final" means "can't be extended", so > combining the two
seems like a self-contradiction.
>
> The fact that abstract classes allow static methods to be called without
sub-classing always seems a bit odd to me - it's as > though only the
constructor is really abstract, not the whole class.
>
> A "static" class, however, whether "final" or not, is definitely
something I've wanted.

> for the record I also brought up this argument (abstract and final being
> contradicting ideas) in the pull request comments(before this thread was
> created).

No, because conceptually, a static something means that subsequent calls
always return same value. A static class means a singleton, not what this
patch proposal.
You have to remember:
- "abstract" means it cannot be instantiated directly
- "final" means it cannot be extended

> The example is a little bit misleading: Instead of a new concept you can
use functions, right?

Yes, but allowing namespace level functions does not give you property
level functions.

> Does this mean that the following will be flagged as invalid? If so, what
error message will be raised?
>
> abstract final class Foo {
> abstract public function doTheImpossible();
> }
>
> This class is technically valid as an abstract class, but the addition of
the "final" keyword makes the abstract method
> declaration completely meaningless, since it can never be implemented.

You are correct. Methods cannot be declared abstract if you have an
"abstract final". They must also be static. I added these checks together
with static properties here:
- Properties:
https://github.com/php/php-src/pull/923/files#diff-3a8139128d4026ce0cb0c86beba4e6b9R4251
- Methods:
https://github.com/php/php-src/pull/923/files#diff-3a8139128d4026ce0cb0c86beba4e6b9R3936

I'm able to expand the RFC in any way you may like before entering voting
phase... just mention to me and I do it! =)

Cheers,

On Thu, Nov 27, 2014 at 8:14 AM, Rowan Collins 
wrote:

> guilhermebla...@gmail.com wrote on 27/11/2014 03:47:
>
>> I worked on an implementation of a somehow controversial concept that
>> exists in hack and C#: abstract final classes.
>>
>> https://wiki.php.net/rfc/abstract_final_class
>>
>
> The explanation of what exactly has been implemented could perhaps be

Re: [PHP-DEV] [RFC] Abstract final classes

[guilhermebla...@gmail.com]

> This is true of classes intended to be static whether or not they are
final. Allowing a "static class" would allow you to
> enforce that all methods (and properties) must be static without banning
users from extending it (which is a completely
> orthogonal decision).

So if I still want to not allow anyone to extend it, I would then have a
final static class. Remember, I don't want people to change methods'
visibility.
How does that become different from final abstract? I know you answered
below... =)

> That's not how they're interpreted with regard to methods, unless I'm
missing something:
>
> - "abstract function" means a method which must be implemented by a
sub-class
> - "static function" means a method with no access to $this, operating
outside of any instance
>
> Taking those behaviours for class definitions leads to the interpretation
that seems natural to me:
>
> - "abstract class" means a class which must be extended before use, and
may contain abstract methods
> - "static class" would mean a class which can never be used to create an
instance, and can contain only static methods
>
> "final" is orthogonal to these, and means that a class cannot be
extended; under this interpretation, "abstract final" is a
> contradiction, but "static final" makes perfect sense.

The piece it's missing in "static" definition: there can only be one
instance of something.
I'd argue that declaring a class static is the same as declaring a
singleton. Multiple object instantiations over a static class would return
always same instance.
Now taking this into consideration, I'd modify your concepts to the
following:

- "abstract function" means a method which must be implemented by a
sub-class
- "static function" means a method with no access to $this, operating
outside of any instance. This means it's bound to class entry, which can
only have one possibility to be called: statically and given same
parameters it should return same output, unless normal flow controlled by a
static variable.

I'm more than happy to change "abstract" to "static" if it's the desire of
everybody. That would match C# implementation as defined here:
http://msdn.microsoft.com/en-us/library/79b3xss3.aspx Now it's funny that
C# also accepts "abstract final" with the same idea/concept of their
documentation of static classes. #weird

[]s,


On Thu, Nov 27, 2014 at 10:06 AM, Rowan Collins 
wrote:

> guilhermebla...@gmail.com wrote on 27/11/2014 14:08:
>
>> > In the RFC, I think one phrase needs clarification:
>> >
>> > Currently, PHP developers' only resource is to create a final class with
>> > a private constructor, leading to untestable and error prone code.
>> >
>> > What is "error prone" in private __construct(); and how the RFC improves
>> > the testability of such class?
>>
>> The reason comes not to the construct method itself, but to other
>> implemented methods.
>> By forgetting "static" in any of your declared methods, you get no parse
>> error and gives you 2 possibilities:
>> - With E_STRICT enabled: Fatal error when non-static method is being
>> statically called. You'll only get this at runtime, leading to potentially
>> error prone. Now the testability come that with this addiction, you get a
>> fatal error, which is easily fixable at compile time, not runtime.
>> - With E_STRICT disabled: You get a warning on php log and everything
>> works (which is a huge wtf mode).
>>
>
> This is true of classes intended to be static whether or not they are
> final. Allowing a "static class" would allow you to enforce that all
> methods (and properties) must be static without banning users from
> extending it (which is a completely orthogonal decision).
>
>
>  > "Abstract final" is a strange way to name it. What you want is a
>> "static" class:
>>
>> > This has always been my feeling. To me, "abstract" means "must be
>> extended", and "final" means "can't be extended", so > combining the two
>> seems like a self-contradiction.
>> >
>> > The fact that abstract classes allow static methods to be called
>> without sub-classing always seems a bit odd to me - it's as > though only
>> the constructor is really abstract, not the whole class.
>> >
>> > A "static" class, however, whether "final" or not, is definitely
>> something I've wanted.
>>
>> > for the record I also brought up this argument (ab

Re: [PHP-DEV] [RFC] Abstract final classes

[guilhermebla...@gmail.com]

Ok... so if I update the RFC to be "static class", does that make everybody
happy?
I mainly wanna get this forward thinking trend... =)

On Thu, Nov 27, 2014 at 10:49 AM, Rowan Collins 
wrote:

> guilhermebla...@gmail.com wrote on 27/11/2014 15:34:
>
>> > This is true of classes intended to be static whether or not they are
>> final. Allowing a "static class" would allow you to
>> > enforce that all methods (and properties) must be static without
>> banning users from extending it (which is a completely
>> > orthogonal decision).
>>
>> So if I still want to not allow anyone to extend it, I would then have a
>> final static class. Remember, I don't want people to change methods'
>> visibility.
>>
>
> Yep, that's the idea. I see no reason, particularly with Late Static
> Binding, that it shouldn't be possible to have a static class which can be
> extended by a static sub-class, if that fits a particular use case.
>
>
>
> --
> 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] Static classes (Was Abstract final classes)

[guilhermebla...@gmail.com]

Hi Andrea,

Thanks a lot for putting efforts thinking through this problem.
Indeed we have 3 problems that leads to "static classes". You detailed 2 of
them.
The third is around encapsulation. I may want functions that are reused by
other functions at the namespace level, but that shouldn't be used outside
of it. By purely supporting (1), you still didn't address this issue. That
would be easily addressed by having private static functions inside of the
static class.
So, let me recap the 3 motivations:

(1) Function/Namespaced function autoloading
(2) State encapsulation
(3) Function scoping

Heading back to your drill down in (2), I feel that we're adding more
complexity to something that can and it is at some extent be easily
supported through classes.
I actually thought about having "let" originally and using as "global", but
I gave up on the idea due to patch's complexity and also because it didn't
matter how far I was thinking through this, something was popping up my
head telling it was wrong. I decided to share my idea with a friend which
pointed me to HHVM's support and then I decided to work on that original
patch.
So, as you walk through your options, didn't it feel wrong to you? Static
classes are an easy addiction to the language and would have a negligent
performance impact, since it just adds 2 conditions in zend_vm and zend_api.

Again, I wouldn't necessarily use this concept I'm proposing right out the
bet, but I do see there are use cases.
I plan to redo my patch and get back for review once I finalize.

Cheers,

On Mon, Dec 1, 2014 at 9:32 AM, Andrea Faulds  wrote:

> Hi all!
>
> > On 1 Dec 2014, at 13:58, Robert Stoll  wrote:
> >
> > I read your updated RFC:
> > https://wiki.php.net/rfc/abstract_final_class
>
> Hmm, I don’t like this new RFC either. Static classes in languages like C#
> exist because the language designers made the dogmatic decision to require
> everything to be a class. Thus, to make collections of functions, your only
> choice is to make a “utility class" with a bunch of static methods. To make
> this easier, the `static` keyword was added to make this easier in C# -
> Java doesn’t have this keyword, but it has the same pattern of static
> method-only classes. But PHP is not one of these dogmatic “everything must
> be a class” languages: it has true global functions which can be namespaced.
>
> So, why, then, does PHP need static classes? As I see it, there are two
> reasons:
>
>   (1) Functions currently cannot be autoloaded
>
>   (2) Encapsulation of state (private/protected static properties)
>
> I think both of these can be solved without perpetuating what I feel is an
> anti-pattern, the “utility class”. If they are solved, the need for utility
> classes goes away.
>
> To implement (1), someone just needs to go and finally implement function
> autoloading. I think Joe Watkins (krakjoe) might’ve said he’d write a patch
> for that, but I may be wrong. I’d certainly like to help with this effort.
>
> Implementing (2) is more difficult. We currently don’t have file-local
> variables like C has, we don’t even have namespaced variables. We do have
> static variables within functions, however. I can think of a few possible
> approaches to this:
>
>   (1) Say that global state is evil and refuse to implement it. Some
> people (myself included, to an extent) would argue that global state is
> “spooky action at a distance” and we shouldn’t be encouraging it. In this
> case we encourage users to simply make normal, non-static/abstract classes
> and to pass an instance around. This is generally good programming practise
> anyway.
>
>   (2) Add lexically-scoped variables, and allow normal global functions to
> be closures. By this I mean we add something like JavaScript’s `let`
> keyword that would make a variable that is unset when it falls out of scope
> (end of a {} block, end of a file etc.). Then, we allow normal functions to
> use the `use ($var)` syntax and close over variables. That’d look something
> like this:
>
>  let $x = 0;
> function getCounter() use(&$x) {
> return $x;
> }
> function incrementCounter() use(&$x) {
> return $x++;
> }
> // since this is the end of the file, $x falls out of scope
>
>   I’d quite like this, as the introduction of lexically-scoped
> variables would have other advantages, too. They would make foreach()
> by-reference much less error-prone, for example:
>
>  foreach ($array as let &$item) {
>  // do stuff with $item
> }
> // $item is unset here, since it fell out of scope when we left
> the {} block
>
>   (3) Add file-local variables using the `static` keyword (à la C). That’d
> work something like this:
>
>  static $x = 0;
> function getCounter() {
>   global $x;
>   return $x;
> }
> // etc.
>
>   This would work similarly to `let`, I suppose,

Re: [PHP-DEV] [RFC] Static classes (Was Abstract final classes)

[guilhermebla...@gmail.com]

I'm working on a patch right now and I removed the implicit configuration
of static to methods.
It's only missing reflection magic. Should be out of the oven in one hour
or less.

On Mon, Dec 1, 2014 at 2:44 PM, Lars Strojny  wrote:

> Hi Guilherme, hi Robert.
>
> > On 01 Dec 2014, at 14:58, Robert Stoll  wrote:
> >
> > I am not sure what makes more sense for PHP, but just as
> thought-provoking impulse, wouldn't it be better just to check that all
> methods are static and __construct private instead of turning methods
> magically into static methods and __construct private?
>
> I very much like the RFC in its current state except for the implicit
> static. While we can preserve the behaviour of automatically turning
> methods into static methods, this should indeed trigger a warning.
>
> cu,
> Lars




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

Re: [PHP-DEV] [RFC] Static classes (Was Abstract final classes)

[guilhermebla...@gmail.com]

PR with this feature request: https://github.com/php/php-src/pull/929

On Mon, Dec 1, 2014 at 4:56 PM, Rowan Collins 
wrote:

> On 1 December 2014 20:30:46 GMT, Andrea Faulds  wrote:
> >
> > The problem is that, well, global state is rarely a good thing, I don’t
> think we should be encouraging it.
>
> To get a bit philosophical: Is it really the language's job to make that
> decision? Is there a difference between "encouraging", "allowing", and
> "enabling"?
>
> Purely static classes are a reality whether this feature is added or not.
> They do things namespaces can't (and probably shouldn't), but are simpler
> to work with than singletons (which they closely resemble) or full-blown
> Dependency Injection. Declaring a static class is just a way of
> acknowledging that this is a deliberate decision, and instance members
> should not be added.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


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

Re: [PHP-DEV] [RFC] Static classes (Was Abstract final classes)

[guilhermebla...@gmail.com]

Yes, C# documented here:
http://msdn.microsoft.com/en-us/library/79b3xss3.aspx

On Mon, Dec 1, 2014 at 5:41 PM, Levi Morrison  wrote:

> Perhaps I have missed it in the noise, but have any other mainstream
> languages (or new hipster ones; I don't care) have something
> equivalent to the proposed static classes?
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


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

[PHP-DEV] Zend language parser improvements

[guilhermebla...@gmail.com]

Hi,

I made some improvements that would like to get merged into PHP, but I
require someone with Zend karma to review and merge.
The patches are all related and included in each other as a progressive
effort.
As a quick explanation, the removal of ZEND_ACC_FINAL_CLASS addresses some
classes that were not properly assigned as final. They're now final.
Examples are COM, PDO Statement, DOM XML and MySQLi.
They also reduce the amount of checks of bison when parsing a php file, it
provides a nicer fatal error around multiple final and multiple abstract
mix between abstract and final instead of a generic parser error.
Finally, ZEND_ACC_TRAIT got updated to a saner value. It was pretty complex
to comprehend why it was 0x120. It was done because a trait was considered
internally as abstract because of instantiation and inheritance checking.
This all got addressed too.

Here they are:

- ZEND_ACC_TRAIT value update: https://github.com/php/php-src/pull/931
(includes the next one)
- Zend language parser class decoupling:
https://github.com/php/php-src/pull/928 (includes the next one)
- ZEND_ACC_FINAL_CLASS removal: https://github.com/php/php-src/pull/911

Theoretically, merging the first one would mean merging all, but I left
them separate for proper case by case evaluation.


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

Re: [PHP-DEV] Zend language parser improvements

[guilhermebla...@gmail.com]

On Wed, Dec 3, 2014 at 8:06 PM, Levi Morrison  wrote:

> The parser changes need to be careful reviewed; I don't have time at
> the moment to verify it but I think you unintentionally allowed some
> syntax's that shouldn't be valid because of the addition to
> `inner_statement`.
>

Shouldn't. I broke down class_declaration_statement into 3 pieces:
class_declaration_statement, interface_declaration_statement and
trait_declaration_statement.
At the end, all I've done is adding the other 2 new rules back to where it
was consumed.


>
> Maybe I just looked too quickly. In any case, parser changes should
> always get several people reviewing them.
>

Agreed. =)

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

Re: [PHP-DEV] Zend language parser improvements

[guilhermebla...@gmail.com]

Hi guys,

I'd really appreciate some review around the before-mentioned PRs. I have
added a new one to the list now:

- https://github.com/php/php-src/pull/937

This PR addresses the parsing support for traits to have "extends" and
"implements", as they are invalid.

There's another one in the oven, which prevents extension developers to
create classes that extends traits or interfaces.
This is currently supported only for userland classes, but not for Zend API.

Cheers,

On Wed, Dec 3, 2014 at 8:39 PM, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:

>
>
> On Wed, Dec 3, 2014 at 8:06 PM, Levi Morrison  wrote:
>
>> The parser changes need to be careful reviewed; I don't have time at
>> the moment to verify it but I think you unintentionally allowed some
>> syntax's that shouldn't be valid because of the addition to
>> `inner_statement`.
>>
>
> Shouldn't. I broke down class_declaration_statement into 3 pieces:
> class_declaration_statement, interface_declaration_statement and
> trait_declaration_statement.
> At the end, all I've done is adding the other 2 new rules back to where it
> was consumed.
>
>
>>
>> Maybe I just looked too quickly. In any case, parser changes should
>> always get several people reviewing them.
>>
>
> Agreed. =)
>
> --
> Guilherme Blanco
> MSN: guilhermebla...@hotmail.com
> GTalk: guilhermeblanco
> Toronto - ON/Canada
>



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

Re: [PHP-DEV] Zend language parser improvements

[guilhermebla...@gmail.com]

Hi Dmitry,

As I said, these patches are not huge beneficial, but enablers. Enablers in
the sense that further development over class/interface/trait simplified.
It's not a short win benefit, but a mid/long term.

Also defer currently checks done in zend_compile to Bison (such as trait
extends and implements), addresses small inconsistencies (such as an
extension class that extend an interface) and also easier to comprehend for
newcomers (such as trait flag value).

Now development that happens over this (such as abstract final/static
class, package private class) become easy, as you can see in PR for static
class for example.

Cheers,

On Mon, Dec 8, 2014 at 7:33 AM, Damien Tournoud  wrote:

> On Mon, Dec 8, 2014 at 1:30 PM, Damien Tournoud  wrote:
> > PDO statement should not be made final, or this is a breaking language
> > change (requiring an RFC and a 2/3 majority).
>
> I see from the PR that it's PDORow, not PDOStatement. That one is not
> actually exposed as such to userspace, so it is fine.
>
> Damien
>



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

Re: [PHP-DEV] Zend language parser improvements

[guilhermebla...@gmail.com]

Nikita,

Shouldn't #3 make more sense taking into consideration this commit:
https://github.com/guilhermeblanco/php-src/commit/872a97c8dbc1c8823985d9a0305938c508865a0d
It is part of a followup PR https://github.com/php/php-src/pull/937 that
removes compiler code checks and delegates to bison, since it's a grammar
issue to accept "trait Foo extends Bar".

Regards,

On Mon, Dec 8, 2014 at 3:06 PM, Nikita Popov  wrote:

> On Mon, Dec 8, 2014 at 11:45 AM, Dmitry Stogov  wrote:
>
>> I don't see technical problems with the patch.
>> However, I also don't see any significant benefits.
>> From the user perspective it'll just change error messages and prevent
>> "final final class" declarations.
>>
>> Nikita, what do you think?
>>
>> Thanks. Dmitry.
>>
>
> The three parts:
>
> 1. Use ZEND_ACC_FINAL instead of ZEND_ACC_FINAL_CLASS: Looks sensible,
> given how many extensions have confused this. We should be careful that
> this change does not make anything final that many people extended (even if
> it was originally meant to be final.)
>
> 2. Don't use magic value for ZEND_ACC_TRAIT: Also makes sense, the
> behavior of the current value is pretty unclear.
>
> 3. Changing the grammar to separate class/trait declarations and have a
> modifier list: This doesn't really make much sense as things currently are
> (only one modifier allowed). I'd suggest to change this when we actually
> support multiple modifiers (e.g. with the static classes patch).
>
> Nikita
>



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

Re: [PHP-DEV] 64-bit performance improvement by reducing zend_op size.

[guilhermebla...@gmail.com]

Seems good for me. =)

On Wed, Dec 10, 2014 at 10:27 AM, Dmitry Stogov  wrote:

> Hi,
>
> Please, review the following patch
> https://gist.github.com/dstogov/fba2cc621ef121826efe
>
> It's huge, but actually, only changes in zend_compile.h are matter. The
> rest is obvious renaming.
>
> the main idea - the smaller the zend_op structure, the lees memory traffic
> is required to load VM instructions during execution. The patch reduces the
> size of each opcode from 48 to 32 bytes (saves 16 bytes for each opcode,
> and applications use thousands of opoceds). This reduced the number of CPU
> cache misses by 12% and improved performance of real-life apps by 1-2%.
>
> The patch affects how constants and jump targets are represented in VM
> during execution. Previously they were implemented as absolute 64-bit
> pointers. Now they are relative 32-bit offsets.
>
> In run-time constant now should be accessed as:
>   RT_CONSTANT(op_array, opine->op1) instead of opline->op1.zv
>   EX_CONSTANT(opline->op1) instead of opline->op1.zv
>
> Jump targets:
>   OP_JMP_ADDR(opline, opline->op2) instead of opline->op2.jmp_addr
>
> The patch doesn't change zend_op representation for 32-bit systems. They
> still use absolute addresses. The compile-time representation is also kept
> the same.
>
> The patch must affect xdebug and may be other very engine depended
> extensions, but it must not be a big problem to fix them (only ext/opcache,
> ext/reflection and sapi/phpdbg required minor changes).
>
> If nobody objects, I'm going to commit this.
>
> Thanks. Dmitry.
>



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

Re: [PHP-DEV] [RFC] Nullsafe calls

[guilhermebla...@gmail.com]

Hi,

Not trying to demerit the proposal, but accepting ?-> and black magic just
seems wrong, very wrong.
You need to write defensive code, not rely on the language to do that for
you.

[]s,

On Thu, Dec 11, 2014 at 2:35 AM, Stanislav Malyshev 
wrote:

> Hi!
>
> > First, how is this substantially different from catching an
> > exception? With Nikita’s Exceptions in the Engine RFC
> > (https://wiki.php.net/rfc/engine_exceptions_for_php7), something like
> > this would be possible:
> >
> > try { return $foo->bar()->qux()->elePHPant()->dance(); } catch
> > (EngineException $e) { return NULL; }
>
> This actually is not a good code. Exceptions should not be used for
> something that is expected and normal, they should rather be used for
> situations where you code does something you could not predict.
> Programming for exceptions is usually bad style, and designing code flow
> expecting exceptions is usually bad idea. So I'd actually prefer being
> able, like, say, in Groovy, to say "try to call this long chain of
> whatever, but if it doesn't work out, just give me null". Of course, it
> is not for carefully controlled code with error reporting, but for some
> prototype code dealing with dirty data I found such shortcuts be rather
> helpful. I'd like PHP to be more Groovy and less Java, in other words ;)
>
> > Second, not short-circuiting is rather unintuitive. I think most
> > people would expect it to short-circuit. Note that ?? and isset()
> > short-circuit, so this would be inconsistent with existing
> > NULL-checking operators. So why, then, are you proposing that it
> > should not short-circuit? Is there some obscure case that this makes
> > easier? If anything, I’d expect that short-circuiting is the more
> > useful behaviour. For example, take the following hypothetical line
> > of code:
> >
> > $elePHPantParty->danceClub?->addToDanceFloor($elePHPantPool->remove());
>
> I agree, for this feature I think it is a must that it would have no
> magic like evaluating code way past the first null in ?-> chain. As soon
> as there's null on the left of ?->, we should be done and return null,
> it should work just like the if would work. In fact, it can even compile
> to the same code as if() would.
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> 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] persistent zval

[guilhermebla...@gmail.com]

IIRC, we used to support that back in ~2000s, but it got removed based on
the lack of usage and poor implementation.

Connection pooling could be a good usage of this if we manage to get this
working again.

[]s,

On Thu, Dec 11, 2014 at 1:46 PM, Marc Bennewitz  wrote:

>
> Am 10.12.2014 um 09:53 schrieb Stanislav Malyshev:
>
>> Hi!
>>
>>  Why?
>>>
>>> There is a reference counter, which should be increased on put a value
>>> into persistence and on removing a value from persistence decrease it.
>>> So the GC could handle unreferenced zvals.
>>>
>> Because memory which is allocated by the engine is freed at the end of
>> the request. You could copy the memory values but by then unless your
>> zvals are pretty simple you'll be pretty close to what the serializer
>> does, so no really big win there. The only advantage would be that when
>> you use it, if you're really careful, then you can use the data without
>> reallocating memory and freeing it. But it's not just putting a
>> flag/refcount on it, it requires some copying before that and some
>> careful setting of the refcounts too. So in theory, it can be done at
>> least for scalars and arrays (objects would be a problem since they need
>> class, and what if the class changed?) but it's not trivial.
>>
>>  Thanks for the explanation!
> I'll experiment with it for scalars as extension.
>
> Marc
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


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

[PHP-DEV] [VOTE] Abstract final / Static classes

[guilhermebla...@gmail.com]

Hi internals,

After a good round of discussion, I updated the original "abstract final
class" proposal into a "static class" proposal.
However, I kept both patches online so it's up to voters decide which one
it could be implemented.
Patches are now complete and voting phase starts now and will be active
until 12/19/2014.

As this is a language update, it requires 2/3 pro or against the feature.

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

Happy voting!

Regards,

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

Re: [PHP-DEV] [VOTE] Abstract final / Static classes

[guilhermebla...@gmail.com]

It's part of the history of that RFC, accessible here:
https://wiki.php.net/rfc/abstract_final_class?rev=1417060830

On Fri, Dec 12, 2014 at 11:18 AM, Florian Margaine 
wrote:
>
> Hi,
>
>
>
> On Fri, Dec 12, 2014 at 5:12 PM, guilhermebla...@gmail.com <
> guilhermebla...@gmail.com> wrote:
>>
>> Hi internals,
>>
>> After a good round of discussion, I updated the original "abstract final
>> class" proposal into a "static class" proposal.
>> However, I kept both patches online so it's up to voters decide which one
>> it could be implemented.
>> Patches are now complete and voting phase starts now and will be active
>> until 12/19/2014.
>>
>> As this is a language update, it requires 2/3 pro or against the feature.
>>
>> https://wiki.php.net/rfc/abstract_final_class
>
>
> Why does the example use `final`?
>
> final static class Environment
> {
> private static $rootDirectory = '/var/www/project';
> public static function getRootDirectory()
> {
> return self::$rootDirectory;
> }
> }
>
> Also, the vote presents 2 options. The RFC is in a weird state where it
> mentions "abstract final" but doesn't explain anything about them. The
> votes don't seem to be what the example is...
>
> Could you edit your RFC?
>
>
>>
>>
>> Happy voting!
>>
>> Regards,
>>
>> --
>> Guilherme Blanco
>> MSN: guilhermebla...@hotmail.com
>> GTalk: guilhermeblanco
>> Toronto - ON/Canada
>>
>
> Cheers,
> --
> Florian Margaine
>


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

Re: [PHP-DEV] [VOTE] Abstract final / Static classes

[guilhermebla...@gmail.com]

RFC is updated exposing both possible usages with both explanations.
Hope it doesn't confuse even more.

On Fri, Dec 12, 2014 at 11:30 AM, Florian Margaine 
wrote:
>
> Hi,
>
> Le 12 déc. 2014 17:28, "guilhermebla...@gmail.com" <
> guilhermebla...@gmail.com> a écrit :
> >
> > It's part of the history of that RFC, accessible here:
> https://wiki.php.net/rfc/abstract_final_class?rev=1417060830
> >
>
> But then it isn't clear as of right now. What is proposed? The example?
> The votes? What does `final` has to do with `static`?
>
> I'm confused.
>
> > On Fri, Dec 12, 2014 at 11:18 AM, Florian Margaine 
> wrote:
> >>
> >> Hi,
> >>
> >>
> >>
> >> On Fri, Dec 12, 2014 at 5:12 PM, guilhermebla...@gmail.com <
> guilhermebla...@gmail.com> wrote:
> >>>
> >>> Hi internals,
> >>>
> >>> After a good round of discussion, I updated the original "abstract
> final
> >>> class" proposal into a "static class" proposal.
> >>> However, I kept both patches online so it's up to voters decide which
> one
> >>> it could be implemented.
> >>> Patches are now complete and voting phase starts now and will be active
> >>> until 12/19/2014.
> >>>
> >>> As this is a language update, it requires 2/3 pro or against the
> feature.
> >>>
> >>> https://wiki.php.net/rfc/abstract_final_class
> >>
> >>
> >> Why does the example use `final`?
> >>
> >> final static class Environment
> >> {
> >> private static $rootDirectory = '/var/www/project';
> >> public static function getRootDirectory()
> >> {
> >> return self::$rootDirectory;
> >> }
> >> }
> >>
> >> Also, the vote presents 2 options. The RFC is in a weird state where it
> mentions "abstract final" but doesn't explain anything about them. The
> votes don't seem to be what the example is...
> >>
> >> Could you edit your RFC?
> >>
> >>>
> >>>
> >>>
> >>> Happy voting!
> >>>
> >>> Regards,
> >>>
> >>> --
> >>> Guilherme Blanco
> >>> MSN: guilhermebla...@hotmail.com
> >>> GTalk: guilhermeblanco
> >>> Toronto - ON/Canada
> >>
> >>
> >> Cheers,
> >> --
> >> Florian Margaine
> >
> >
> >
> > --
> > Guilherme Blanco
> > MSN: guilhermebla...@hotmail.com
> > GTalk: guilhermeblanco
> > Toronto - ON/Canada
>
> Cheers,
> Florian
>


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

Re: [PHP-DEV] [RFC][VOTE] Objects as Keys

[guilhermebla...@gmail.com]

> On Tue, Dec 16, 2014 at 9:39 AM, Matteo Beccati 
wrote:Hi Guilherme,
>
>> On 16/12/2014 12:34, Guilherme Blanco wrote:
>> Hi,
>> All I can say is that the lack of this feature is one of the main
reasons why Doctrine doesn't fully work with composite keys.
>> With this enhancement it would now become possible to implement a proper
IdentityMap.
 >
>Are you sure you haven't misinterpreted the RFC?

Hi Matteo,

I did not. You may think I mentioned IdentityMap as entity map, but I'm
talking about entityPersister mapping or resultPointers consumptions that
happens inside Doctrine throughout the execution. Entity IdentityMap is
enough to use purely spl_object_hash(). We should focus on the main goal
here, which is complex structures as keys.

As a very complex library developer I do see lots of use cases for this.

[]s,


On Tue, Dec 16, 2014 at 6:52 PM, Rowan Collins 
wrote:
>
> On 16 December 2014 18:50:06 GMT, Stanislav Malyshev 
> wrote:
> >Hi!
> >
> >> Explicit conversion is trivial, just call whatever method you like.
> >> Sure, you can't write (int)$obj, but $obj->toInt() is just as
> >> expressive.
> >
> >Exactly the same applies to __toString and whole ArrayAccess, yet we
> >still have them. Avoiding boilerplate code helps. Especially if
> >boilterplate code would look like:
> >
> >if(is_object($foo)) {
> >  $foo_key = $foo->toInt();
> >} else {
> > $foo_key = $foo;
> >}
> >$a[$foo] = 1;
> >
> >Doing it each time is annoying.
>
> I was just confused by your statement that "explicit conversion is
> inacessible from userspace". But yeah, I guess with string keys you can
> just write $a[(string)$foo] and assume/hope it will do something meaningful
> whatever the type of $foo.
>
>
>
> --
> 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][VOTE] Objects as Keys

[guilhermebla...@gmail.com]

Hi,

Answering the question of Christopher Becker. It is not possible to
traverse and get your desired elements.
How would you achieve a foreach by key (returning object) without having to
store a separate list and track by hash or through an interface?

Cheers,

On Wed, Dec 17, 2014 at 10:04 AM, Derick Rethans  wrote:
>
> On Tue, 16 Dec 2014, Stanislav Malyshev wrote:
>
> > I'd like to initiate a vote on "objects as keys" RFC:
> > https://wiki.php.net/rfc/objkey
>
> I wonder why you opened voting on this, before resolving the "Open
> Issues":
>
> Open Issues
>
> Should SplFixedArray support object indexes?
> Should SplObjectStorage support calling __hash for an object if it
> exists?
>
> cheers,
> Derick
>
> --
> 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][VOTE] Objects as Keys

[guilhermebla...@gmail.com]

Hi,

I originally considered you could retrieve the object key, but if it is not
possible by this RFC, I will switch my vote to no.

By storing hash one way it introduces a huge wtf to the language.

Cheers,
On Dec 17, 2014 8:40 PM, "Rowan Collins"  wrote:

> On 17/12/2014 22:05, Rowan Collins wrote:
>
>> For one thing, I think it might be interesting to explore whether real
>> objects as keys is actually as difficult as some people are assuming. I can
>> naively imagine a few ways it could be implemented that seem in my mind to
>> have minimal impact on any array that doesn't use it, but haven't yet seen
>> anyone seriously discuss any possible approaches.
>>
>
> In fact, to expand on this, I'm going to stick my neck out and tell
> everyone my crackpot theory, which someone who actually understands the
> engine will probably demolish in 5 seconds flat, but makes sense in my
> mind. :P
>
> The implementation of arrays could remain the same, with a single pointer
> to a second "shadow" HashTable, which would only be initialised when an
> object was actually added as a key. Thus the memory overhead would be
> reserving a single pointer per array (not per item), and the execution
> overhead (for any existing array usage) would be a single if(shadowPointer)
> check in a few key places.
>
> The idea would be that the object would still be hashed - e.g. by default
> with spl_object_hash, but with __hash if set - and that key would be stored
> in the normal way. However, an extra entry would be added to the shadow
> array, as though you had also called $shadow[ $obj->__hash() ] = $obj.
>
> We might want to do something tricksy to the key, like adding a null byte
> at the beginning, to make it less likely for a scalar key and an object
> hash to collide. This would also allow further short-cutting in lookups,
> since if the first byte was not \0, there would be no chance of a match in
> the shadow array. (If it was \0, there might still not be a shadow object,
> because null-prefixed strings are actually valid scalar keys, but this
> seems unlikely to be a common occurrence.)
>
> Whenever an array key is taken as *input* (e.g. $foo[$bar],
> array_key_exists()), the hash function would be called (much as in the
> current RFC), and the corresponding value could be returned directly - the
> shadow table would not need to be touched, so performance would be
> identical to that of the current proposal.
>
> A lookup in the shadow array would need to happen only when writing to the
> array, and when a key was being given as *output* (e.g. foreach ( $a as $k
> => $v ), array_search(), key()). This would happen at the speed of normal
> random access, and scale with the number of objects used as keys, not the
> number of items in the main array.
>
> Like I say, I'm sure this is full of holes, and I'll leave it there before
> I get too far down a dead end, but I thought it might be a more productive
> line of thought than "this will probably never happen".
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [VOTE] Abstract final / Static classes

[guilhermebla...@gmail.com]

Hi Pascal,

I said this earlier, but considering purely namespaced functions and
autoloading is not the same as static classes. Namespaced functions doesn't
have support for variables and that's a huge strike against it and in favor
of static classes.

Cheers,

On Thu, Dec 18, 2014 at 6:54 PM, Pascal Martin, AFUP <
mail...@pascal-martin.fr> wrote:
>
> On 12/12/2014 17:12, guilhermebla...@gmail.com wrote:
>
>> Patches are now complete and voting phase starts now and will be active
>> until 12/19/2014.
>>
>> https://wiki.php.net/rfc/abstract_final_class
>>
>
> Hi,
>
> After speaking about this RFC with other members of AFUP, we would be on
> the -1 side for this.
>
> Summarizing our thoughts :
>  *  static classes should not be encouraged
>  *  if the goal is to have a set of utility functions, they can be set up
> in a namespace -- being able to autoload functions could prove useful,
> though.
>
> --
> Pascal MARTIN, AFUP - French UG
> http://php-internals.afup.org/
>
>
> --
> 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] [VOTE] Abstract final / Static classes

[guilhermebla...@gmail.com]

Hi everyone,

Voting is now closed.
Since this RFC required a 2/3 majority, the result is against the
implementation of this feature in PHP.
RFC is now updated and moved to withdrawn section.

Thanks,

On Fri, Dec 19, 2014 at 10:43 PM, Tjerk Meesters 
wrote:

>
> > On 13 Dec 2014, at 00:35, guilhermebla...@gmail.com wrote:
> >
> > RFC is updated exposing both possible usages with both explanations.
> > Hope it doesn't confuse even more.
>
> Hi, in your "As static class” example, it doesn’t really demonstrate that
> you can omit the “static” modifier from the function declarations.
>
> Also, it’s not clear if the same applies to “As abstract final”.
>
> >
> > On Fri, Dec 12, 2014 at 11:30 AM, Florian Margaine  >
> > wrote:
> >>
> >> Hi,
> >>
> >> Le 12 déc. 2014 17:28, "guilhermebla...@gmail.com" <
> >> guilhermebla...@gmail.com> a écrit :
> >>>
> >>> It's part of the history of that RFC, accessible here:
> >> https://wiki.php.net/rfc/abstract_final_class?rev=1417060830
> >>>
> >>
> >> But then it isn't clear as of right now. What is proposed? The example?
> >> The votes? What does `final` has to do with `static`?
> >>
> >> I'm confused.
> >>
> >>> On Fri, Dec 12, 2014 at 11:18 AM, Florian Margaine <
> flor...@margaine.com>
> >> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>>
> >>>>
> >>>> On Fri, Dec 12, 2014 at 5:12 PM, guilhermebla...@gmail.com <
> >> guilhermebla...@gmail.com> wrote:
> >>>>>
> >>>>> Hi internals,
> >>>>>
> >>>>> After a good round of discussion, I updated the original "abstract
> >> final
> >>>>> class" proposal into a "static class" proposal.
> >>>>> However, I kept both patches online so it's up to voters decide which
> >> one
> >>>>> it could be implemented.
> >>>>> Patches are now complete and voting phase starts now and will be
> active
> >>>>> until 12/19/2014.
> >>>>>
> >>>>> As this is a language update, it requires 2/3 pro or against the
> >> feature.
> >>>>>
> >>>>> https://wiki.php.net/rfc/abstract_final_class
> >>>>
> >>>>
> >>>> Why does the example use `final`?
> >>>>
> >>>> final static class Environment
> >>>> {
> >>>>private static $rootDirectory = '/var/www/project';
> >>>>public static function getRootDirectory()
> >>>>{
> >>>>return self::$rootDirectory;
> >>>>}
> >>>> }
> >>>>
> >>>> Also, the vote presents 2 options. The RFC is in a weird state where
> it
> >> mentions "abstract final" but doesn't explain anything about them. The
> >> votes don't seem to be what the example is...
> >>>>
> >>>> Could you edit your RFC?
> >>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Happy voting!
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> --
> >>>>> Guilherme Blanco
> >>>>> MSN: guilhermebla...@hotmail.com
> >>>>> GTalk: guilhermeblanco
> >>>>> Toronto - ON/Canada
> >>>>
> >>>>
> >>>> Cheers,
> >>>> --
> >>>> Florian Margaine
> >>>
> >>>
> >>>
> >>> --
> >>> Guilherme Blanco
> >>> MSN: guilhermebla...@hotmail.com
> >>> GTalk: guilhermeblanco
> >>> Toronto - ON/Canada
> >>
> >> Cheers,
> >> Florian
> >>
> >
> >
> > --
> > Guilherme Blanco
> > MSN: guilhermebla...@hotmail.com
> > GTalk: guilhermeblanco
> > Toronto - ON/Canada
>
>


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

[PHP-DEV] [RFC] Package private class

[guilhermebla...@gmail.com]

Hi internals,

I finalized a new proposal for PHP. It consists into adding support for
package-private classes in the language.

A package private class is basically a class that can only be instantiated
in its declared namespace. This means that you cannot extend, implement or
use a class, interface or trait outside of declared namespace. It can be
referenced outside of the package, but instantiation can only be done there.

Other languages such as Java and C# consider package-private class as a
top-level class without any declared visibility. PHP cannot enforce this as
it would be an incredible BC break, but we can reuse an already declared
keyword "private" to fit this purpose. A class declared without any
visibility modifier is considered "public" and works exactly as it
currently does. The same applies to a class written with "public" keyword
(ie. public class Foo {}).

Most of checks are done at compile time and only instantiation is done at
runtime (the only place I found out it could be done). Performance impact
seems negligible as only one top condition is added during instantiation
bytecode executor.


At this stage I want to collect implementation feedback. Explanation is
done above and the extensive amount of tests self explains what the entire
purpose of this feature is. RFC will be created together with voting once
I'm able to gather some considerations.

Link to PR: https://github.com/php/php-src/pull/947


Cheers,

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

Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols

[guilhermebla...@gmail.com]

+1 for adding E_DEPRECATED and removing support in PHP 8.

On Mon, Dec 22, 2014 at 11:17 PM, Ferenc Kovacs  wrote:

> On Sat, Dec 20, 2014 at 11:01 PM, F & N Laupretre 
> wrote:
>
> > Hi,
> >
> >
> >
> > I don't know if this was discussed before. So, tell me what you think
> > before
> > I write an RFC.
> >
> >
> >
> > I would like to propose that namespaces, functions, and classes become
> > case-sensitive (constants are already case-sensitive). Actually, I never
> > understood why they are case-insensitive. Even if the performance gain is
> > negligible, I think it could be the right time to question this.
> >
> >
> I think that the cost of that BC break is too high, and will only happen in
> an alternative implementation (if at all).
> Putting that aside, if we want to go down that road, we should first
> discourage people from such usage, and as we never did that(no E_STRICT no
> E_DEPRECATED) it would be extremely rude to remove support for that in 7.0.
> I think that a Pull Request for adding E_STRICT or maybe even E_DEPRECATED
> would have a chance of getting voted in but depends on the implementation
> and how much overhead would it cost.
>
> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu
>



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

Re: [PHP-DEV] [RFC] Package private class

[guilhermebla...@gmail.com]

Hi Robert,

Answers inline.

On Tue, Dec 23, 2014 at 7:59 AM, Robert Stoll  wrote:

>
>
> > -Ursprüngliche Nachricht-
> > Von: Leigh [mailto:lei...@gmail.com]
> > Gesendet: Dienstag, 23. Dezember 2014 04:34
> > An: guilhermebla...@gmail.com
> > Cc: PHP internals
> > Betreff: Re: [PHP-DEV] [RFC] Package private class
> >
> > On 23 December 2014 at 00:32, guilhermebla...@gmail.com <
> guilhermebla...@gmail.com> wrote:
> > > Hi internals,
> > >
> > > I finalized a new proposal for PHP. It consists into adding support
> > > for package-private classes in the language.
> > >
> > > A package private class is basically a class that can only be
> > > instantiated in its declared namespace. This means that you cannot
> > > extend, implement or use a class, interface or trait outside of
> > > declared namespace. It can be referenced outside of the package, but
> instantiation can only be done there.
> > >
> > > Other languages such as Java and C# consider package-private class as
> > > a top-level class without any declared visibility. PHP cannot enforce
> > > this as it would be an incredible BC break, but we can reuse an
> > > already declared keyword "private" to fit this purpose. A class
> > > declared without any visibility modifier is considered "public" and
> > > works exactly as it currently does. The same applies to a class
> > > written with "public" keyword (ie. public class Foo {}).
> > >
> > > Most of checks are done at compile time and only instantiation is done
> > > at runtime (the only place I found out it could be done). Performance
> > > impact seems negligible as only one top condition is added during
> > > instantiation bytecode executor.
> > >
> > >
> > > At this stage I want to collect implementation feedback. Explanation
> > > is done above and the extensive amount of tests self explains what the
> > > entire purpose of this feature is. RFC will be created together with
> > > voting once I'm able to gather some considerations.
> > >
> > > Link to PR: https://github.com/php/php-src/pull/947
> > >
> > >
> > > Cheers,
> > >
> > > --
> > > Guilherme Blanco
> > > MSN: guilhermebla...@hotmail.com
> > > GTalk: guilhermeblanco
> > > Toronto - ON/Canada
> >
> > Hey Guilherme,
> >
> > Good work, namespace visibility on classes and functions is something I
> have been working on over the past few months.
> > The reason I haven't created an RFC is because I couldn't decide on what
> "private" and "protected" should mean for a class
> > or function within a namespace.
> >
> > To me, a private class can only be instantiated within it's own
> namespace (this seems the same as you have defined), but
> > can be typehinted and used anywhere else.
> >
> > Maybe I was wrong to try and include "protected" in my own work, as it
> caused me the most problems when trying to
> > define what it should mean.
> > My original feeling was that it should mean it can only be instantiated
> in it's own namespace or sub-namespaces.
> >
> > I also considered a strict "visibility" view, private classes would not
> be "visible" outside of their own namespace, and
> > protected would not be "visible" outside of their own or child
> namespaces ("visible"
> > meaning no type hints or usage too).
> >
> > It is reassuring to see that your approach is the same as my initial
> feelings, the accessibility keywords define instantiation
> > usage, rather than a strict visibility.
> >
> > I haven't looked at your patch in detail. My PoC code revolved around
> comparing the start of class names with the current
> > namespace. Is yours the same? How do you feel about extending this to
> functions?
> >
> > Thank's for the work on this. I wasn't sure I had the willpower to
> finish my patch for PHP7, it's nice to see you have the
> > same idea.
> >
> > Cheers,
> >
> > Leigh.
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
> visit: http://www.php.net/unsub.php
>
> [Robert Stoll]
>
> Hey Guilherme,
>
> I like the idea but I am not sure whether it is wise to define private in
> the way you did, namely that such classes can be seen outside of its
> namespace. You referenced Java, which behaves di

Re: [PHP-DEV] [RFC] Skipping parameters take 2

[guilhermebla...@gmail.com]

Hi,

-1 on this proposal

+1 on named parameters

As of for this...

> > handy and easier. I could dig the archives but I don't remember what
> > was the reason why we rejected the idea back then.
>
> Bikeshedding about the syntax mostly, but that all pales compared to
> amount of work that needs to be done in the engine to support named
> params. Unless, of course, I'm completely wrong and there's an easy way
> to do it, which I am totally missing - in which case please point it out.

Pierrick and I both implemented this support for Annotations back in 2010.
Maybe it's worth to look into that patch for some ideas.

Regards,

On Wed, Jan 14, 2015 at 2:50 PM, Marc Bennewitz  wrote:

>
> Am 14.01.2015 um 20:21 schrieb Adam Harvey:
>
>> On 14 January 2015 at 11:15, Marc Bennewitz  wrote:
>>
>>> But I think adding "default" as new keyword is a big BC break!
>>>
>> Default already is a keyword: http://php.net/switch. There's no BC break.
>>
>
> OMG you are right - my fault
>
>
>
>>  I personally also don't like it and asked myself why can't the parameter
>>> simply skipped?
>>>
>> That was in the original proposal, but counting commas is pretty lousy
>> if you're skipping more than one or two parameters. Having a keyword
>> makes it more readable.
>>
>> Adam
>>
>>
>
> --
> 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] Skipping parameters take 2

[guilhermebla...@gmail.com]

Hi Stas,

As I said, we should look at that patch as we implemented Named Parameters
there with everything you mentioned.

Cheers,

On Wed, Jan 14, 2015 at 3:23 PM, Stanislav Malyshev 
wrote:

> Hi!
>
> > -1 on this proposal
> >
> > +1 on named parameters
>
> Come on, we've already talked about it like 20 times and it has special
> paragraph in the RFC dedicated exactly to this. It's not instead named
> params, we can do both.
>
> > Pierrick and I both implemented this support for Annotations back in
> 2010.
> > Maybe it's worth to look into that patch for some ideas.
>
> Annotations are great and I'd like them to be resurrected (provided that
> we don't get bogged down again with "let's implement a Turing-complete
> DSL for for ORMs inside annotations because we have like 1 or even 2 use
> cases for it!") but how it is relevant to the topic or to named params?
> That said, if you want to branch the topic and discuss it it's fine,
> just please change the subj.
> --
> Stas Malyshev
> smalys...@gmail.com
>



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

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

[guilhermebla...@gmail.com]

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

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

[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

[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

[guilhermebla...@gmail.com]

Pierrick, before update v3 of patch, let's first clarify things that need
to be discussed.
Rasmus, you have no idea how happy you made me for a gentle comment
pointing something we should think before propose a patch instead of on
(sorry for the wording) bitching about the idea.

There're tons of elements that need to be addressed before working on a
patch.
The latest annotations RFC is a small subset of what other languages
support. To a more complete feature-wise, it is required to go to a
previous revision: https://wiki.php.net/rfc/annotations?rev=1302087566

Some of the elements that needs to be considered:

- Should we support nested annotations?

- How [Foo()] will be different from new Foo()? If they are not different,
is there an alternative to not bloat lexical parsing?

- How parameters would be injected? Is constructor the only way to inject
parameters?

- How would we handle optional parameters, like [Foo("bar", null, null,
"woo")]?

- Suppose you wanna fix the optional arguments by named parameters, like
[Foo("bar", test="woo")]. Doesn't it diverge with PHP interests of not
supporting parametrized arguments? Should we modify the former or the
later? Personally I'm a fan of named parameters.

- How would we deal with inheritance? Should a method, for example, inherit
the same annotations from parent or not?

- Suppose that you define annotations to fix the inheritance problem, how
would it be?

- How would we cast possible usages of an annotation to only class, method
or property? Using annotations too?

- How would it be the syntax to declare a new annotation?

- Would it be possible to modify an annotation value using Reflection, for
example?

- How could it be handled on APC to minimize the performance impact?


Let's discuss? Thanks.



On Wed, Jan 9, 2013 at 2:24 PM, Marco Pivetta  wrote:

> @Stas we've already come to that, and this is a way to store metadata: the
> discussion here is just if and how it should get to PHP :)
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>



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

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

[guilhermebla...@gmail.com]

Clint,

If you switch from [] to <> everything works like a charm. =)
Everything was working smoothly on version 2. Version 3 was an attempt to
simplify the patch, but removing tons of things that would pop in a few
time if patch was accepted.

Cheers,


On Wed, Jan 9, 2013 at 3:24 PM, Clint Priest  wrote:

> This version of annotations (attributes?) is much more interesting than
> the most recent version, but I could see this syntax as being a problem if
> it were allowed to apply to plain functions because then the parser would
> have difficulty distinguishing from an array.  I suppose the same could be
> said of applying it to a class.
>
> In essence though, this prior revision is exactly the kind of thing that I
> would be interested in if we could get past the parsing issues...
>
>
> On 1/9/2013 1:57 PM, guilhermebla...@gmail.com wrote:
>
>> Pierrick, before update v3 of patch, let's first clarify things that need
>> to be discussed.
>> Rasmus, you have no idea how happy you made me for a gentle comment
>> pointing something we should think before propose a patch instead of on
>> (sorry for the wording) bitching about the idea.
>>
>> There're tons of elements that need to be addressed before working on a
>> patch.
>> The latest annotations RFC is a small subset of what other languages
>> support. To a more complete feature-wise, it is required to go to a
>> previous revision: 
>> https://wiki.php.net/rfc/**annotations?rev=1302087566<https://wiki.php.net/rfc/annotations?rev=1302087566>
>>
>> Some of the elements that needs to be considered:
>>
>> - Should we support nested annotations?
>>
>> - How [Foo()] will be different from new Foo()? If they are not different,
>> is there an alternative to not bloat lexical parsing?
>>
>> - How parameters would be injected? Is constructor the only way to inject
>> parameters?
>>
>> - How would we handle optional parameters, like [Foo("bar", null, null,
>> "woo")]?
>>
>> - Suppose you wanna fix the optional arguments by named parameters, like
>> [Foo("bar", test="woo")]. Doesn't it diverge with PHP interests of not
>> supporting parametrized arguments? Should we modify the former or the
>> later? Personally I'm a fan of named parameters.
>>
>> - How would we deal with inheritance? Should a method, for example,
>> inherit
>> the same annotations from parent or not?
>>
>> - Suppose that you define annotations to fix the inheritance problem, how
>> would it be?
>>
>> - How would we cast possible usages of an annotation to only class, method
>> or property? Using annotations too?
>>
>> - How would it be the syntax to declare a new annotation?
>>
>> - Would it be possible to modify an annotation value using Reflection, for
>> example?
>>
>> - How could it be handled on APC to minimize the performance impact?
>>
>>
>> Let's discuss? Thanks.
>>
>>
>>
>> On Wed, Jan 9, 2013 at 2:24 PM, Marco Pivetta  wrote:
>>
>>  @Stas we've already come to that, and this is a way to store metadata:
>>> the
>>> discussion here is just if and how it should get to PHP :)
>>>
>>> Marco Pivetta
>>>
>>> http://twitter.com/Ocramius
>>>
>>> http://ocramius.github.com/
>>>
>>>
>>
>>
> --
> -Clint
>



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

Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision

[guilhermebla...@gmail.com]

I'd love if Stas, Derick, Rasmus or Zeev comment here on criteria about
acceptance of new features.
You all claim that PHP is simple, that features include should be widely
used and only important functions, classes that have regular and extensive
usage would be in.

I wonder how Annotations is different from Traits or Aspects.
They all include new tokens on parser, they all "slow down" (as you keep
claiming everytime) and they all have specific niches to be used. Now I
wonder how Traits got IN, Aspects got rejected in 2007 and Annotations is
being a nightmare to you guys.
Or will you guys claim that Traits will be vastly used?

Also talking about widely used support, I wonder about how
SplDoubleLinkedList, SplInt, SplMaxHeap and all these classes that have
very specific usages, just like also data structure readers like
json_decode, parse_ini_file are part of the core while others also used as
much as these ones like yaml_file are out.

If this is a clear vision, sorry, I'm probably too dumb to understand.

OOP is a trend in PHP and no matter what you guys try to do, procedural
support is quite decent, OOP is getting there aswell as functional. We're
just trying to improve OOP, which lacks of many different features that
many users ask and keep hitting the wall.
You guys may now know, but 9 out of 10 most used frameworks are entirely
OO. It's a shame that because Yahoo code is procedural (worked at Yahoo
already), SugarCRM code has terrible OO decisions (I've seen its code),
adopting exceptions handling !!!in July 2012!!! that makes you guys say
there's no need to improve on OO features that community is claiming.
I implemented support in 2009, asked for this in 2010 and since then I've
seen only in this ML the same feature being asked not by me at least more
10 times. Isn't it a sign of a feature demand?


On Wed, Jan 9, 2013 at 9:52 PM, Tyler Sommer  wrote:

> Great points, Adam. I disagree with this one feature being excluded but I
> do agree that just because something is in the userland doesn't necessarily
> mean it should be in the core-- making my point rather moot.
>
>
> Cheers.
>
> On Wed, Jan 9, 2013 at 6:28 PM, Adam Harvey  wrote:
>
> > On 10 January 2013 10:05, Tyler Sommer  wrote:
> > > Annotations are already a part of PHP. They are widely used in one of
> the
> > > most prolific frameworks, Symfony, and it's ORM "counterpart" Doctrine.
> >
> > To explain what I meant by "PHP", since I think we're arguing
> > semantics there: I mean php-src specifically, rather than the broader
> > userland community, since we're on Internals.
> >
> > > To say "they shouldn't be part of PHP" is fine, but it's too late for
> > that.
> > > Annotations are already here. Are we going to just ignore this fact and
> > hold
> > > back what a very significant portion of the community wants to see
> > because
> > > it conflicts with some ambiguous master plan for PHP?
> >
> > I don't have a master plan (that would be the part of this thread I'm
> > not touching), but if it's a poorly thought out feature, sure. Pretty
> > much every major project out there uses a unit testing framework and
> > ORM: does that mean we should also be including equivalents for
> > PHPUnit and Doctrine in core?
> >
> > Basically, I think the trend towards configuration as behaviour is an
> > antipattern that results in less readable, harder to debug code.
> > Having said that, the beauty of our userland being a set of
> > communities is that each community can make their own decisions —
> > since the good folks behind Doctrine have written an excellent
> > annotation parser, those who want to go that way can, but it doesn't
> > mean PHP has to go out of its way to encourage it.
> >
> > Or, to put it another way, not everything has to be a language
> > feature. That way lies Perl.
> >
> > Adam
> >
>



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

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

[guilhermebla...@gmail.com]

We all agree that nullable properties need to be addressed.
Now why just don't discuss a possible syntax and move on?
Initializers, parenthesis around unsetters, etc can all be detailed and
discussed later.

Here are the proposed syntaxes:

public DateTime? $date {
  get { ... }
  set { ... }
}

public DateTime $date = null {
  get { ... }
  set { ... }
}

public DateTime $date {
  get { ... }
  set($value = null) { ... }
}

public $date {
  get { ... }
  set(DateTime $value = null) { ... }
}


Now choose your options from 1-4 and move on...
Sometimes you truly love to discuss instead of act. Tsc, tsc, tsc...


Cheers,


On Thu, Jan 10, 2013 at 7:24 PM, Lazare Inepologlou wrote:

> Nikita,
>
>
> 2013/1/10 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 updated the RFC to include the current state regarding default value
> and
> > nullability:
> >
> >
> https://wiki.php.net/rfc/propertygetsetsyntax-alternative-typehinting-syntax
> >
> > One question that still needs to be discussed is what syntax regarding
> > parentheses we want to use if this makes it. Currently both set { } and
> > set($foo) { } style accessors are supported. Do we want to keep those two
> > with the new syntax?
> >
> > Nikita
> >
> > PS: I hope I'm not interrupting all those heated annotations discussion
> too
> > much ^^
> >
>
>
>
> In the RFC, one thing is not clear: How to provide typehints for nullable
> properties that actually have accessors.
>
> Will it be like this?
>
> public DateTime $date = null {
>   get { ... }
>   set { ... }
> }
>
>
>
>
> Lazare INEPOLOGLOU
> Ingénieur Logiciel
>



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

Re: [PHP-DEV] A remark about PHP's Vision and new things.

[guilhermebla...@gmail.com]

Stas,

I totally agree and Pierrick and I faced all these problems during the
creation of patch.
If PHP doesn't all have support required for a given feature, let's just
not only discuss feature, but also the required support too. Named
parameters is a great example. I'd also name another one,
ReflectionNamespace; namespaces are converted to strings and attached to
their classes during compile time and you can never reflect over them to
grab for example their names.
I even mentioned to Andi back in 2010 that ZE gets re-written every 5
years. That happened in 2000, 2005 and we're now hitting walls because of
"monster" changes required to implement feature A or B. Maybe it's time to
consider a rewrite again?

Cheers,


On Thu, Jan 10, 2013 at 3:36 PM, Stas Malyshev wrote:

> Hi!
>
> > I strongly suggest to anyone following the (too many) threads about
> > annotations to try the C# annotation and see what it allows. It goes
>
> As far as I can see, C# annotations rely on two very important things:
> 1. Compiler support. Compiler really knows a lot about what annotations do.
> 2. Extensive library support. Annotations themselves are just passive
> metadata, what makes them work is .net framework that uses them.
>
> This means to make annotations as useful in PHP we would have to have
> substantial support in the engine (including bytecode caching
> provisions, etc.) and some libraries that require very
> latest-and-greatest version of PHP.
>
> Another thing is that we're not having some features that are used
> extensively in C# annotations, main being named parameters support.
>
> I am saying this not to oppose the idea of annotations or the idea of
> looking into C# and other languages (actually, I think anybody who talks
> about it should look at least into what C# and Java do with it - and
> also what Python does, which is completely different direction, just to
> know other options). I'm just saying porting this to PHP may be less
> than straightforward.
>
> --
> 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
>
>


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

Re: [PHP-DEV] A remark about PHP's Vision and new things.

[guilhermebla...@gmail.com]

Not really insane.

PHPPHP is very powerful. Imagine someone that have no idea about C but
would love to propose something.
Just fork the project, add the desired support in PHP and propose here. I
guarantee it'll be easier to understand the caveats and the final patch
easily.

Cheers,


On Sat, Jan 12, 2013 at 12:57 AM, Clint Priest  wrote:

> That is seriously funny
>
> On Jan 11, 2013, at 11:35 PM, Levi Morrison 
> wrote:
>
> >> Can we re-write PHP with PHP? ;)
> >
> > Anthony and Nikita are already on it:
> https://github.com/ircmaxell/PHPPHP
> >
> > --
> > 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
>
>


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

Re: [PHP-DEV] [RFC] Allow trailing comma in function call argument lists

[guilhermebla...@gmail.com]

+1
 On Feb 19, 2013 10:13 AM, "Cyberspice"  wrote:

> On 19 Feb 2013, at 12:06, Sara Golemon  wrote:
>
> > Opening RFC to allow trailing comma in function call argument lists
> >
> > https://wiki.php.net/rfc/trailing-comma-function-args
>
> +1
>
> Melanie
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Internal object orientation documentation available!

[guilhermebla...@gmail.com]

Nikita,

That's f*ckin' awesome. Thanks a lot!!!

Cheers,


On Tue, Jun 11, 2013 at 1:56 PM, Lars Strojny  wrote:

> Thank you, thank you, thank you all!
>
> Am 10.06.2013 um 20:33 schrieb Nikita Popov :
>
> > Hi internals!
> >
> > We just published some rather extensive documentation on internal object
> > orientation:
> >
> >http://www.phpinternalsbook.com/classes_objects.html
> >
> > This is part of a larger project aimed at documenting the engine and
> making
> > it accessible to new contributors.
> >
> > Any feedback is appreciated!
> >
> > Thanks,
> > Nikita
>
>
> --
> 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] Wake up

[guilhermebla...@gmail.com]

Hi Johannes,

I do understand motivations behind keeping core simple and stable that
majority of internals always promote. I also understand the majority of
user base is on shared host.
But as a counterpart, what about large agencies that do want to extract
every single feature PHP has to provide?
That's the part it sounds blurry. Which side should PHP take? Trying to
keep both sides happy is becoming more and more
difficult along the years.

Who would make this decision? What is gonna happen with the other side?
Someone needs to address this.
Why don't we reevaluate all highlighted topics provided on that
StackOverflow thread (use my comment as base) as it was done in that 2005
Paris meeting? That should be a great start for ZE3.

>From the personal side, I truly agree with this thread. I tried 5 times to
contribute to internals, all of them generated endless flames, and even
RFCs where over 50% was pro the support, I got an answer like "most core
devs were against it, so no". I'm pretty much on Anthony's side.


Thanks,


On Wed, Sep 11, 2013 at 5:58 PM, Johannes Schlüter
wrote:

> On Wed, 2013-09-11 at 23:34 +0200, Florin Patan wrote:
> > First, I didn't said anything about attitude to new comers. For me it
> > was quite well and people offered to help out in solving issues.
>
> Thanks.
>
> > Second, if you read the posting rules of this mailing list, top
> > posting is one of those things that you should avoid.
> >
> > Given the following factors:
> > - lack of clear language scope: yes we build webpages but guess what,
> > we aren't doing blogs for a long time ago. if you dimiss Wikipedia,
> > Facebook and some other sily sites in the top 100 hits / month that
> > use PHP you are given a whole slew of startups and some of them even
> > businesses which are using PHP. Some of them might even prefer to have
> > in-house developed tools but then for those tools PHP says: sorry, you
> > should check another language if you want this or that. It's simply
> > frustrating :)
>
> Facebook is not using PHP but HipHop. Weblogs and small sites are still
> a big part of the user base (shared hosters still seem to see enough
> market to battle in that market, I know different "web agencies" serving
> those).
>
> > - lack of a clear roadmap: as I said earlier, can someone really tell
> > what's in the next two versions of php from now
>
> ... and never will. I commented on that in a different mail.
>
> > - lack of clear authority - who can and should steer discussions to a
> > desired path and stop trolling (even by core devs)
>
> A troll has no respect on authority. The community at large has to
> handle that.
>
> > - lack of actual feedback from the community on topics/rfcs: there's
> > always a 'but people need/want/don't need/don't want' with no concrete
> > way to really gauge what the community position really is
>
> “Nobody knows what most PHP programmers do.”
> - Bjarne Stroustrup (inventor of C++, parapharsed)
>
> There is no single community, there are wikipedia and yahoo and such
> (which itself aren't homogeneous entities), there are wordpress users,
> there are small special interest forums, there people just learning
> programming, using it on intranet sites, ...
>
> This actually is the cause for the discussions here - everybody here
> lives in a different world, facing different challenges.
>
> > - lack of clear documentation about the internals: you really can't
> > tell me that the docs out there are clear because I did a bunch of
> > searching for them and I'm pretty good at finding stuff
>
> What specifically do you need? I often hear this abstract comment. Often
> these either are very specialized questions or lack of C knowledge or
> such.
>
> > - personal feelings on a subject instead or rational ones
>
> Depending on what kind of challenges you are coming from you rank
> requirements differently. This impacts"rationalism". If you want a jack
> of all trades language you rank additions differently from when you are
> aiming for a beginner-friendly language, which you value differently
> from when you put BC first, ...
>
> That said: Not all arguments are good, but often a disagreement here
> comes from different views colliding, which, to some degree, is healthy
> in order to find the right path working for as many users as possible.
>
> joahnnes
>
>
>
> --
> 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] PHP 5.4: Annotations

[guilhermebla...@gmail.com]

Hi Derick,

I'm all for it.
Although I have karma, I'm not an active PHP core contributor, but I
would like to participate of such discussion, mainly because I have
plenty experience with Annotations from another languages.

I'll spend some time re-reading the entire Annotations thread and come
up with another proposal at the right time.

Regards,

On Mon, Nov 1, 2010 at 8:33 PM, Derick Rethans  wrote:
> Hi!
>
> The RFC on annotations for PHP http://wiki.php.net/rfc/annotations
> suggests to add new syntax to the language to provide meta data for use
> in reflection. This sort of meta data is usually provided in the form of
> docblocks, which this RFC does *not* state isn't good enough.
>
> The discussion on the mailinglist did not provide a clear consensus for
> either for or against. We could put this up for a vote, but I feel that
> that is not useful right now, because a few issues needs to be sorted
> out first. First, where we actually require annotations (over the
> current practise of using docblocks); and secondly whether we really
> want to introduce another syntax into the PHP scanners and parsers.
>
> For now I would suggest that this proposal needs to be sorted out before
> we can even suggest of putting it in PHP 5.4.
>
> cheers,
> Derick
>
> --
> http://derickrethans.nl | http://xdebug.org
> Like Xdebug? Consider a donation: http://xdebug.org/donate.php
> twitter: @derickr and @xdebug
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



-- 
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil

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

[PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support discussion

[guilhermebla...@gmail.com]

Hi folks,

I'll start a series of topics (in this thread) about meta attribute
(aka. Annotations) discussion.
So as soon as we agree on each topic I'll open another point to be discussed.
Only when we reach some consensus I'll open another topic discussion.
I suggest to have a poll for each topic, so we can do some democratic
internals decision. I'd reduce the scope of voters to only people with
PHP karma.

The first topic to be defined is: Does PHP need meta attribute support?

Any language is built at the top of syntax, words, semantics and context.
We cannot define it as a language if we don't have these 4 parts well
fit together.
For a simple sentence like: I am all ears, we can easily identify these parts.
But the real meaning of this sentence (context) is only achieved with
another part of the language: signifier-significate.
A signifier is an atomic form, material element, visible, sensitive.
A significate is an idea, semantic content, conceptual element, not
sensitive perceptive.

This important part is only reminded when we get back to semantics,
specifically when talking about idiomatic expressions, a metaphor in
our sample. The meaning will only work if we have the context, a known
information. Our sentence would mean that spoker person only have
ears, while the true meaning is that he/she is paying attention.
A computer language doesn't differ from a language by any means. We
have tokens (words), a syntax, semantic. But the lack of
contextualization brings a hole on language and how your application
should behave. This behavior can be achieved by many different ways;
the simplest way is known as meta information.

Considering you have a lack of idiomatic expressions knowledge of
someone that is reading. He'd think person only have ears, but if you
meta notify him that it is a metaphor, he'd try to find a different
meaning. Example: (Metaphor) I am all ears.

Now that we find how meta-information can benefit languages, it is
time to understand how meta-information can benefit a computer
language.

A good example is define a Service that validates Domain Objects.
Imagining a scenario where you have a User class that holds email and
password. Email and password fields must be validated, for example,
email as an email and password with at least 6 chars. A generic
validation service could not have the User validation hardcoded inside
the service, so the solution would be an external factor that explains
to service how to validate the DO. One of the possible implementations
would be a UserValidator class that contains validation rules for each
field. This external factor is a good sample of meta-information. But
how would a meta attribute would solve this situation?
A Service could simple retrieve the validation instructions by
Reflecting the class which instance is going to be validated.
Basically, to validate a Domain Object, it is simply required to add
validation rules on desired attributes. Example:

class User {

protected $email;


protected $password;
}

*NOTE*: Please understand that this do not enter in any implementation
details. It is not time (yet) to talk baout docblock, new syntax, etc.
Scope now is simpler than that.

Now that is possible to see how meta attribute support could benefit a
language, I compiled a simple list of known projects and how can they
benefit of meta support:
- phpUnit Providing meta functionality for test cases, examples:
@dataProvider for test data iteration, @expectedException for catching
exceptions, etc.
- Doctrine For Object-Relational mapping, examples: @Entity,
@OneToOne, @Id, etc.
- Zend Framework Server classes Used to automate mappings for XML-RPC,
SOAP, etc.
- FLOW3 for dependency injection and validation
- Symfony2 for validation and routing rules
- Others: Validation, Functional Behavior injection (which could take
advantage of Traits), etc.


Poll will be opened for voting for 7 days (1 week) starting from now.
Poll will be closed next Monday at 5pm GMT.
Question: Does PHP need meta attribute support?

Happy voting!

-- 
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil

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

Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support discussion

[guilhermebla...@gmail.com]

@Zeev: That topic was related to an already built patch, which some
where in favor, some against. That discussion lead to nowhere.
So I opened a thread topic by topic for some democracy approval. As
soon as we reach some reasonable consensus, we can start another patch
implementation based on what we end up with this thread.

If result of the poll says "OK" to meta attribute, then we can discuss
next topic (possible implementations).
Until then, I'd rather appreciate everyone to stick to their votes
instead of revamp another discussion that lead to nothing.

BTW, I forgot to add my vote:

+1

On Mon, Nov 15, 2010 at 8:22 PM, Zeev Suraski  wrote:
> I don't see a point in repeating the discussion we've already had on that 
> topic several weeks ago.  There needs to be an overwhelmingly good reason to 
> add a brand new syntax to the language, a whole branch of it in the case of 
> annotations - and there simply isn't.
>
> Zeev
>
>> -Original Message-
>> From: guilhermebla...@gmail.com [mailto:guilhermebla...@gmail.com]
>> Sent: Monday, November 15, 2010 7:08 PM
>> To: PHP internals
>> Subject: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support
>> discussion
>>
>> Hi folks,
>>
>> I'll start a series of topics (in this thread) about meta attribute (aka.
>> Annotations) discussion.
>> So as soon as we agree on each topic I'll open another point to be discussed.
>> Only when we reach some consensus I'll open another topic discussion.
>> I suggest to have a poll for each topic, so we can do some democratic
>> internals decision. I'd reduce the scope of voters to only people with PHP
>> karma.
>>
>> The first topic to be defined is: Does PHP need meta attribute support?
>>
>> Any language is built at the top of syntax, words, semantics and context.
>> We cannot define it as a language if we don't have these 4 parts well fit
>> together.
>> For a simple sentence like: I am all ears, we can easily identify these 
>> parts.
>> But the real meaning of this sentence (context) is only achieved with another
>> part of the language: signifier-significate.
>> A signifier is an atomic form, material element, visible, sensitive.
>> A significate is an idea, semantic content, conceptual element, not sensitive
>> perceptive.
>>
>> This important part is only reminded when we get back to semantics,
>> specifically when talking about idiomatic expressions, a metaphor in our
>> sample. The meaning will only work if we have the context, a known
>> information. Our sentence would mean that spoker person only have ears,
>> while the true meaning is that he/she is paying attention.
>> A computer language doesn't differ from a language by any means. We have
>> tokens (words), a syntax, semantic. But the lack of contextualization brings 
>> a
>> hole on language and how your application should behave. This behavior can
>> be achieved by many different ways; the simplest way is known as meta
>> information.
>>
>> Considering you have a lack of idiomatic expressions knowledge of someone
>> that is reading. He'd think person only have ears, but if you meta notify him
>> that it is a metaphor, he'd try to find a different meaning. Example:
>> (Metaphor) I am all ears.
>>
>> Now that we find how meta-information can benefit languages, it is time to
>> understand how meta-information can benefit a computer language.
>>
>> A good example is define a Service that validates Domain Objects.
>> Imagining a scenario where you have a User class that holds email and
>> password. Email and password fields must be validated, for example, email
>> as an email and password with at least 6 chars. A generic validation service
>> could not have the User validation hardcoded inside the service, so the
>> solution would be an external factor that explains to service how to validate
>> the DO. One of the possible implementations would be a UserValidator class
>> that contains validation rules for each field. This external factor is a good
>> sample of meta-information. But how would a meta attribute would solve
>> this situation?
>> A Service could simple retrieve the validation instructions by Reflecting the
>> class which instance is going to be validated.
>> Basically, to validate a Domain Object, it is simply required to add 
>> validation
>> rules on desired attributes. Example:
>>
>> class User {
>>     
>>     protected $email;
>>
>>     
>>     protected $password;
>> }
>>
>> *NOTE*: Please underst

Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support discussion

[guilhermebla...@gmail.com]

@Will: Patch works perfectly with PHP 5.3. There is just a minor issue
related to APC not caching instances.
That patch didn't reach a consensus and that's why I opened a
different thread to implement a patch based on poll results.

Cheers,

On Mon, Nov 15, 2010 at 10:55 PM, Will Fitch  wrote:
> Wow. I should actually look at the RFCs more frequently.
>
> I have to say, assuming the patch is valid for PHP 5.3 (which I have no
> doubt it is), I don't see why this can't be taken more seriously.  I know
> the discussion was brought up a few weeks ago, but what are the objections
> to injecting this functionality into the next major post-5.4 release?
>
> On Mon, Nov 15, 2010 at 6:47 PM, Alec  wrote:
>
>> The patch is already written and a RFC created by Guilherme:
>> http://wiki.php.net/rfc/annotations .
>>
>> I personally think annotations could make a *great* addition to PHP.
>>
>> I agree with Will that annotations are especially useful for SOAP and
>> XML-RPC. I personally think annotations are useful for APIs in general.
>>
>> Instead of creating a method to respond to a XML-RPC call, then binding it
>> to a specific XML-RPC call with a line in the initialization you could just
>> do this:
>>
>> @xmlrpc({
>>        name : "server.getValue",
>>        params : {
>>                param1 : {
>>                        type : "number",
>>                        docs : "This is documentation for param1"
>>                }
>>        }
>> });
>> public getValForXMLRPC ($param) {
>> ...
>>
>> I just used JSON for the syntax of annotation. I did this for two reasons:
>> 1. most PHP developers can write some Javascript, and 2. since this is
>> supposed to avoid syntax discussions, I used a syntax no one uses for
>> annotations, but everyone understands.
>>
>> The possibilities are endless with Annotations and as long as they are
>> pretty speedy I think they would be picked up quite quickly and we would get
>> some great examples from the community.
>>
>> My 2 cents.
>>
>> -Alec
>>
>>
>> On 11/15/2010 6:54 PM, Will Fitch wrote:
>>
>>> I have certainly wanted them many times - especially when using SOAP.
>>>  Having WSDL auto-generation without compromising developer
>>> documentation and attempting to have user-land code parse phpdoc for this
>>> purpose seem{ed,s} counterintuitive.  That said, introducing annotations
>>> is
>>> a HUGE undertaking and would require a ton of work with potentially little
>>> return.  I do think it would be worth looking into in a future major
>>> release, but there are quite a few other things that would be more
>>> beneficial to the community for immediate discussions.
>>>
>>> Did anyone write and RFC on this? guilhermeblanco has a good start.
>>>
>>> On Mon, Nov 15, 2010 at 5:44 PM, Pierre Joye
>>>  wrote:
>>>
>>>  On Tue, Nov 16, 2010 at 12:39 AM, Zeev Suraski  wrote:

> Suggesting phpdoc is used for the purposes mentioned does not mean we
>
 don't understand what we're talking about.

 I feel like you never used annotations in other languages, did you?

 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
>>
>>
>
>
> --
>
> Thanks,
>
> Will Fitch
> Director of Operations | Quepasa.com
> 931.205.8242 | will.fi...@quepasacorp.com
> Twitter: twitter.com/willfitch
>



-- 
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil

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

Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support discussion

[guilhermebla...@gmail.com]

Hi Zeev,

On Tue, Nov 16, 2010 at 5:10 AM, Zeev Suraski  wrote:
> I hope I won't stir the pot too much, but with all due respect to the vote of 
> at-best a two digit subset of an arbitrary 3000+ subscribers to internals, 
> there's an overwhelming majority amongst the principal developers of PHP that 
> voiced an opinion against it.  While we have no official rules or structures 
> for voting features into PHP, PHP being a meritocracy, that should be enough 
> to put this RFC to bed.

Thanks for the input, but that's what I want to see in a democratic way.
*YOU* closed the previous thread, saying that "PHP does not need Annotations.".
Ok, I may have did something wrong previously, adding new syntax, etc.
So I decided to make it more democratic, and identify what can be done
in this subject.
If you READ what I wrote in the first email of this thread, you may
find that I do not add any implementation details. I'm just asking if
you agree into more discussion on this topic - on how can it be
implemented, syntax, where, etc -, or drop the entire idea completely.

So I'd second the same thing I did previously...
Let's listen to what people want. I already restricted the counting of
votes to people with PHP karma, so meritocracy is perfectly being
counted here.

Please stick to your vote and let other people vote. Do not close this
thread, again.

Cheers,

>
> Zeev
>
>> -Original Message-
>> From: guilhermebla...@gmail.com [mailto:guilhermebla...@gmail.com]
>> Sent: Tuesday, November 16, 2010 4:28 AM
>> To: Zeev Suraski
>> Cc: PHP internals
>> Subject: Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support
>> discussion
>>
>> @Zeev: That topic was related to an already built patch, which some where in
>> favor, some against. That discussion lead to nowhere.
>> So I opened a thread topic by topic for some democracy approval. As soon as
>> we reach some reasonable consensus, we can start another patch
>> implementation based on what we end up with this thread.
>>
>> If result of the poll says "OK" to meta attribute, then we can discuss next
>> topic (possible implementations).
>> Until then, I'd rather appreciate everyone to stick to their votes instead of
>> revamp another discussion that lead to nothing.
>>
>> BTW, I forgot to add my vote:
>>
>> +1
>>
>> On Mon, Nov 15, 2010 at 8:22 PM, Zeev Suraski  wrote:
>> > I don't see a point in repeating the discussion we've already had on that
>> topic several weeks ago.  There needs to be an overwhelmingly good reason
>> to add a brand new syntax to the language, a whole branch of it in the case 
>> of
>> annotations - and there simply isn't.
>> >
>> > Zeev
>> >
>> >> -Original Message-
>> >> From: guilhermebla...@gmail.com [mailto:guilhermebla...@gmail.com]
>> >> Sent: Monday, November 15, 2010 7:08 PM
>> >> To: PHP internals
>> >> Subject: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations)
>> >> support discussion
>> >>
>> >> Hi folks,
>> >>
>> >> I'll start a series of topics (in this thread) about meta attribute (aka.
>> >> Annotations) discussion.
>> >> So as soon as we agree on each topic I'll open another point to be
>> discussed.
>> >> Only when we reach some consensus I'll open another topic discussion.
>> >> I suggest to have a poll for each topic, so we can do some democratic
>> >> internals decision. I'd reduce the scope of voters to only people
>> >> with PHP karma.
>> >>
>> >> The first topic to be defined is: Does PHP need meta attribute support?
>> >>
>> >> Any language is built at the top of syntax, words, semantics and context.
>> >> We cannot define it as a language if we don't have these 4 parts well
>> >> fit together.
>> >> For a simple sentence like: I am all ears, we can easily identify these 
>> >> parts.
>> >> But the real meaning of this sentence (context) is only achieved with
>> >> another part of the language: signifier-significate.
>> >> A signifier is an atomic form, material element, visible, sensitive.
>> >> A significate is an idea, semantic content, conceptual element, not
>> >> sensitive perceptive.
>> >>
>> >> This important part is only reminded when we get back to semantics,
>> >> specifically when talking about idiomatic expressions, a metaphor in
>> >> our sample. The meaning will 

Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support discussion

[guilhermebla...@gmail.com]

Hi Lester,

If you READ my first email of this thread, you'll find out I do not
speak about new syntax, etc.

No matter if you say "that can be done through docblock", you're
automatically saying +1 to this thread.

Please re-read the topic and vote. Thanks.


Cheers,

On Tue, Nov 16, 2010 at 5:38 AM, Lester Caine  wrote:
> ( Try again Zeev changing the pigging address ;) )
> Zeev Suraski wrote:
>>
>> I hope I won't stir the pot too much, but with all due respect to the vote
>> of at-best a two digit subset of an arbitrary 3000+ subscribers to
>> internals, there's an overwhelming majority amongst the principal developers
>> of PHP that voiced an opinion against it.  While we have no official rules
>> or structures for voting features into PHP, PHP being a meritocracy, that
>> should be enough to put this RFC to bed.
>
> I'd second that.
> There have been a number of developments added to PHP5 in the last few major
> versions that offer little but irritation to main stream users. phpdoc is
> used extensively for documentation, and it would be nice to see THAT fully
> supporting these other tangents rather than simply inventing a new way of
> doing the same thing. Lets please finish what we currently have work rather
> than adding yet another layer of complexity.
>
> --
> 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//
> Firebird - http://www.firebirdsql.org/index.php
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



-- 
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil

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

Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support discussion

[guilhermebla...@gmail.com]

@Chad: You're getting me wrong here.

If results of poll decide for OK to meta attribute support, next poll
would be which implementation to choose.
I can find 3 different implementations that we can choose, but anyone
is free to contribute.

- Docblock

/** @Foo */
class User { ... }

- New syntax similar to first patch

[Foo]
class User { ... }

- A keyword scope similar to method/namespace declaration

annotate { return new Foo(); }
class User { ... }

But before even spend time talking over and over about implementation,
I wanna ask if we should invest time into it, since I got a lot of
flaming responses (and I still continue, even though people barely see
what I'm asking).

If you say that we should enhance docblock to allow retrieve of @foo,
you're automatically saying +1 to this thread.
I do not want to enter in discussion about implementation because I
don't even know if it will be accepted. I don't want to spend a lot of
time to produce a patch to something that will not be accepted. So
let's decide IF and possibly WHAT to implement, then I can work on it.

All I want is a democratic decision, and not something that one guy
answer as "NO" and end of story.
If majority says "YES", one person being against it doesn't sound to
me like a democracy/meritocracy.


Cheers,

On Tue, Nov 16, 2010 at 3:37 PM, Chad Fulton  wrote:
> On Tue, Nov 16, 2010 at 6:03 AM, Lars Schultz  
> wrote:
>> Hi,
>>
>> I certainly don't have PHP-Karma (Does meritocracy really refer to that?),
>> but simply I can't believe that you're talking about this, again.
>>
>> I think Annotation-Supporters have made their point, but shouldn't they let
>> the PHP 5.4 Developers get on with it and let them roll out a new version
>> instead of forcing them to reply to lengthy emails about the same topic over
>> and over again. One could almost believe that you're hoping to drown their
>> voices by frustrating them into not replying anymore, therefore winning your
>> vote.
>>
>> cheers.
>> Lars
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
> ^ I agree.
>
> 
>
> I also don't think you can discuss annotations without simultaneously
> discussing their implementation. To me, it looks like you're trying to
> force through a vote on a very vague topic "should PHP support
> Annotations", and then use that vote later to force through an
> implementation that many core people have already said is not
> desirable.
>
> Many of the arguments that are central to the question of "should PHP
> support Annotations" MUST deal with their implementation because they
> add a large new set of syntax to the language.
>
> I doubt anyone would support annotations "at any cost", and yet that's
> the vote you're trying to force here.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



-- 
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil

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

Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support discussion

[guilhermebla...@gmail.com]

I don't wanna be bad interpreted or considered as rude, but I wonder
why is it so hard for all of you to just vote instead of stay crying
like lost babies.
PHP is open for everyone to contribute, I want to help it but it seems
impossible to help language move forward without people that accept
global decisions.

Cheers,

On Tue, Nov 16, 2010 at 3:47 PM, guilhermebla...@gmail.com
 wrote:
> @Chad: You're getting me wrong here.
>
> If results of poll decide for OK to meta attribute support, next poll
> would be which implementation to choose.
> I can find 3 different implementations that we can choose, but anyone
> is free to contribute.
>
> - Docblock
>
> /** @Foo */
> class User { ... }
>
> - New syntax similar to first patch
>
> [Foo]
> class User { ... }
>
> - A keyword scope similar to method/namespace declaration
>
> annotate { return new Foo(); }
> class User { ... }
>
> But before even spend time talking over and over about implementation,
> I wanna ask if we should invest time into it, since I got a lot of
> flaming responses (and I still continue, even though people barely see
> what I'm asking).
>
> If you say that we should enhance docblock to allow retrieve of @foo,
> you're automatically saying +1 to this thread.
> I do not want to enter in discussion about implementation because I
> don't even know if it will be accepted. I don't want to spend a lot of
> time to produce a patch to something that will not be accepted. So
> let's decide IF and possibly WHAT to implement, then I can work on it.
>
> All I want is a democratic decision, and not something that one guy
> answer as "NO" and end of story.
> If majority says "YES", one person being against it doesn't sound to
> me like a democracy/meritocracy.
>
>
> Cheers,
>
> On Tue, Nov 16, 2010 at 3:37 PM, Chad Fulton  wrote:
>> On Tue, Nov 16, 2010 at 6:03 AM, Lars Schultz  
>> wrote:
>>> Hi,
>>>
>>> I certainly don't have PHP-Karma (Does meritocracy really refer to that?),
>>> but simply I can't believe that you're talking about this, again.
>>>
>>> I think Annotation-Supporters have made their point, but shouldn't they let
>>> the PHP 5.4 Developers get on with it and let them roll out a new version
>>> instead of forcing them to reply to lengthy emails about the same topic over
>>> and over again. One could almost believe that you're hoping to drown their
>>> voices by frustrating them into not replying anymore, therefore winning your
>>> vote.
>>>
>>> cheers.
>>> Lars
>>>
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>>
>> ^ I agree.
>>
>> 
>>
>> I also don't think you can discuss annotations without simultaneously
>> discussing their implementation. To me, it looks like you're trying to
>> force through a vote on a very vague topic "should PHP support
>> Annotations", and then use that vote later to force through an
>> implementation that many core people have already said is not
>> desirable.
>>
>> Many of the arguments that are central to the question of "should PHP
>> support Annotations" MUST deal with their implementation because they
>> add a large new set of syntax to the language.
>>
>> I doubt anyone would support annotations "at any cost", and yet that's
>> the vote you're trying to force here.
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
>
> --
> Guilherme Blanco
> Mobile: +55 (16) 9215-8480
> MSN: guilhermebla...@hotmail.com
> São Paulo - SP/Brazil
>



-- 
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil

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

Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) supportdiscussion

[guilhermebla...@gmail.com]

Hi Stas,

A full RFC will be written based on results of polls.
I'm able to write 10 RFC's, but none will care until we reach this
list with a patch.

So instead of lose time, I prefer to discuss what can be done here,
write an RFC then finally implement it.
But without having feedback from core developers, it's difficult to
make any decision.

Cheers,

On Wed, Nov 17, 2010 at 12:11 AM, Stas Malyshev  wrote:
> Hi!
>
>> I think my reply ( http://article.gmane.org/gmane.comp.php.devel/63203 )
>> addresses this. It doesn't introduce any new language constructs per se.
>> You could make it even more standard and clear by adding "new" after
>> "annotation".
>
> How about making it a full RFC? It's kind of hard to keep track of things in
> all threads.
> --
> 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
>
>



-- 
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil

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

Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) supportdiscussion

[guilhermebla...@gmail.com]

Hi Stas,

Ok, so you think I should just consider everyone want some sort of
meta attribute support and start discussing the topics?
Should I separate it in different threads or put it all here?

The subject is big and I identify at least 5 different discussions
that can diverge.

Cheers,

On Wed, Nov 17, 2010 at 12:26 AM, Stas Malyshev  wrote:
> Hi!
>
>> I'm able to write 10 RFC's, but none will care until we reach this
>> list with a patch.
>
> Not entirely true. Patch helps, but with feature this big and complex having
> consensus on design before actually implementing it may be better and save
> you some time.
> As for polls, I think generic "having annotations" poll is not very useful.
> It's like having a poll "should we have cool features in PHP?" Of course we
> should! The devil is in the details. And so far the details of this thing
> contain a significant number of devils we have to handle.
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>



-- 
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil

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

Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) supportdiscussion

[guilhermebla...@gmail.com]

Hi Alec,

Here is the quick list:
- Where to put the metadata information? docblock or though php code?
- Syntax (based on first decision)
- Return would be an array or object instances
- Compile time or run time (decision is more about APC being able to
cache, but instances being created at runtime automatically or no APC
cache but instances only being created when requested (during
Reflection call)
- Named variables for instantiation or method arguments order? How
would we deal with the need of Reflector during constructor if second
sounds better?
- Would we support inherited metadata?

Cheers,

On Wed, Nov 17, 2010 at 12:33 AM, Alec Gorge  wrote:
> In my opinion (as a person with 0 karma), I think that sounds reasonable
> because most people are most concerned about the actual implementation
> (syntax, performance, apc etc) because I don't think many argue that
> Metadata doesn't have value.
>
> What are the 5 different discussion topics you are thinking of, just out of
> curiosity?
>
> Also, I can just post my syntax idea as a gist or pastie or something
> instead of making an rfc...
>
> -Alec
>
> On 11/16/2010 9:29 PM, guilhermebla...@gmail.com wrote:
>>
>> Hi Stas,
>>
>> Ok, so you think I should just consider everyone want some sort of
>> meta attribute support and start discussing the topics?
>> Should I separate it in different threads or put it all here?
>>
>> The subject is big and I identify at least 5 different discussions
>> that can diverge.
>>
>> Cheers,
>>
>> On Wed, Nov 17, 2010 at 12:26 AM, Stas Malyshev
>>  wrote:
>>>
>>> Hi!
>>>
>>>> I'm able to write 10 RFC's, but none will care until we reach this
>>>> list with a patch.
>>>
>>> Not entirely true. Patch helps, but with feature this big and complex
>>> having
>>> consensus on design before actually implementing it may be better and
>>> save
>>> you some time.
>>> As for polls, I think generic "having annotations" poll is not very
>>> useful.
>>> It's like having a poll "should we have cool features in PHP?" Of course
>>> we
>>> should! The devil is in the details. And so far the details of this thing
>>> contain a significant number of devils we have to handle.
>>> --
>>> Stanislav Malyshev, Software Architect
>>> SugarCRM: http://www.sugarcrm.com/
>>> (408)454-6900 ext. 227
>>>
>>
>>
>



-- 
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil

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

Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support discussion

[guilhermebla...@gmail.com]

Hi Gustavo,

Normal instantiation cannot be done.
Here is a sample where it would fail:

new Foo()
class User { ... }

So it must be something different.

[]s,

On Wed, Nov 17, 2010 at 1:07 AM, Gustavo Lopes  wrote:
> On Wed, 17 Nov 2010 01:54:22 -, Stas Malyshev 
> wrote:
>
>> The problem is not new syntax per se. The problem is new syntax for things
>> that already have old syntax.
>
> This is incontestably false. Although a big portion of the use cases can
> awkwardly use the user-space parsed and interpreted docblocks, I'm more
> interested in the potential for applications that require the engine to
> parse to annotations (like in the patch, not doing it on demand for
> bocblocks) and, for a select few, act upon them.
>
> Your preoccupation with the cost of adding new syntax is reasonable and the
> patch goes too far, but surely we could iron out those details later. Maybe
> even just preceding the class/method/whatever declaration with an annotation
> expressed with normal object instantiation syntax?...
>
> --
> Gustavo Lopes
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



-- 
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil

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

Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support discussion

[guilhermebla...@gmail.com]

Hi Larry,

For existent project examples and usage, here are 2 links of the
upcoming versions of Doctrine 2 and Symfony 2:

http://www.doctrine-project.org/projects/orm/2.0/docs/reference/basic-mapping/en#introduction-to-docblock-annotations
http://docs.symfony-reloaded.org/guides/validator.html

Please understand that Roman, Benjamin, Jonathan and I wrote this
Annotation parser for Doctrine, which was reused by Bernhard on
Symfony.
So I have clean understanding of the issue we have on hands and every
single point that it is required to address. That's why I wrote the
RFC.

Yesterday night a couple of people joined on #php.pecl and discussed a
possible new implementation.
I'll write what was discussed and probably some sample code.

Cheers,

On Thu, Nov 18, 2010 at 3:16 AM, Larry Garfield  wrote:
> On Wednesday, November 17, 2010 5:56:05 am Ferenc Kovacs wrote:
>> On Wed, Nov 17, 2010 at 12:54 PM, Ferenc Kovacs  wrote:
>> > On Wed, Nov 17, 2010 at 11:58 AM, Arvids Godjuks
>> > > >
>> > > wrote:
>> >> Hello Internals!
>> >>
>> >> For me, as a user-land developer, this issue seems as if some people
>> >> are trying to push the annotations at any cost. What they fail to see,
>> >> is that annotations are never described what they are and how they can
>> >> be useful in our developer work. Right now I, and I think many other
>> >> user-land developers, just fail to see what the annotations are
>> >> without any meaningful example.
>
> *snip*
>
>> On the other hand: it seems that more examples about the usage wouldn't
>> hurt in the RFC...
>>
>> Tyrael
>
> I have to agree with this sentiment in particular.  As I've not worked in a
> language with formal annotations, I still don't grok the use case.
>
> To those supporting some form of syntactic annotations (whatever the syntax),
> can you please explain, simply and preferably with examples, what I could do
> with such syntax that I cannot do now in user-space, and/or what I could do
> better/faster/cheaper with such tools than what I can do now in user-space?
>
> I think that's the missing piece here: The practical ever-day example of how
> *my* code would get better because of annotations.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



-- 
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil

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

Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support discussion

[guilhermebla...@gmail.com]

Hi Larry,

Of course I know how it can benefit a full stack framework.
For example Zend Framework can benefit of it by auto-generating WSDL
files in Zend_Soap.

You're right about Symfony integrated system of property validation of
Domain Objects.
If you would like to see how it would be implemented in
Doctrine/Symfony without Annotations, here are the links of them:

Doctrine sample user class:
https://github.com/doctrine/doctrine2/blob/master/tests/Doctrine/Tests/ORM/Mapping/php/Doctrine.Tests.ORM.Mapping.User.php
Symfony injection of property validation:
http://docs.symfony-reloaded.org/guides/validator.html (at the end of
HTML file)

Cheers,

On Thu, Nov 18, 2010 at 3:00 PM, la...@garfieldtech.com
 wrote:
> On 11/18/10 7:34 AM, guilhermebla...@gmail.com wrote:
>>
>> Hi Larry,
>>
>> For existent project examples and usage, here are 2 links of the
>> upcoming versions of Doctrine 2 and Symfony 2:
>>
>>
>> http://www.doctrine-project.org/projects/orm/2.0/docs/reference/basic-mapping/en#introduction-to-docblock-annotations
>> http://docs.symfony-reloaded.org/guides/validator.html
>>
>> Please understand that Roman, Benjamin, Jonathan and I wrote this
>> Annotation parser for Doctrine, which was reused by Bernhard on
>> Symfony.
>> So I have clean understanding of the issue we have on hands and every
>> single point that it is required to address. That's why I wrote the
>> RFC.
>>
>> Yesterday night a couple of people joined on #php.pecl and discussed a
>> possible new implementation.
>> I'll write what was discussed and probably some sample code.
>
> No offense, but as I've noted before Symfony and Doctrine are very very
> different types of frameworks/libraries than a lot of the code out there.
>  Much of what may make sense in a component framework doesn't make sense in
> a full stack framework (e.g., Drupal, which I work on) and vice versa.  So
> while I respect that you put a lot of work into the Doctrine and Symfony
> implementations that does not mean you will understand "every single point
> that it is required to address".
>
> That said, from looking at the Symfony page above it looks like it's an
> integrated system for providing variable-level validation.  True?
>
> If that's the case, what would a before/after look like for code using
> annotations vs. not?
>
> As far as implementation goes, for something like this to be useful for a
> highly-dynamic system like Drupal we'd need to be able to add
> annotations/validation rules out-of-band, that is, from somewhere other than
> syntactically right on the variable/function/method being validated.  We
> frequently have highly-generic objects that get used in a multitude of
> different ways, so we would need to be able to associate validation rules at
> runtime for them to work.
>
> Naturally the error messages from them would also need to be
> returned/thrown, not printed, so an application can take proper steps with
> them in its own error handling routines.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



-- 
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil

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

Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support discussion

[guilhermebla...@gmail.com]

Hi Richard,

The first proposed patch has some performance impact, due to the
parsing time. And that's just it.
Instantiation of annotation classes is irrelevant because it only
happens when you explicitly request for it at runtime. The only
drawback is that it cannot be cached in APC.

Cheers,

On Tue, Nov 16, 2010 at 10:32 AM, Richard Quadling  wrote:
> On 16 November 2010 07:06, Zeev Suraski  wrote:
>>> -Original Message-
>>> From: Pierre Joye [mailto:pierre@gmail.com]
>>> Sent: Tuesday, November 16, 2010 1:45 AM
>>> To: Zeev Suraski
>>> Cc: guilhermebla...@gmail.com; PHP internals
>>> Subject: Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support
>>> discussion
>>>
>>> On Tue, Nov 16, 2010 at 12:39 AM, Zeev Suraski  wrote:
>>> > Suggesting phpdoc is used for the purposes mentioned does not mean we
>>> don't understand what we're talking about.
>>>
>>> I feel like you never used annotations in other languages, did you?
>>
>> You got me...  But as an intelligent human being I'd like to think I can 
>> evaluate the merits of a feature without having to actually use it.
>>
>> I'm not saying that annotations don't give you any value.  Sure they do.  
>> I'm saying that they come at a great price of adding an obscure branch of 
>> syntax into a language that's already grown significantly in complexity, and 
>> the bang for the buck isn't worth it.  Those advanced developers needing 
>> that feature can make do with phpdoc.
>>
>> Zeev
>
> Hi all.
>
> I use PHPDoc. I develop SOAP services and use ZF to autocreate my WSDL
> files. I've used tools to create classes from a WSDL file. I don't
> know how this qualifies specifically as "annotations" - so I'm
> probably in the same camp as Zeev on this.
>
> An issue for me is the lack of ongoing development (it seems) of
> phpdoc. Yes, sure, it is for documentation. But that is just one sort
> of annotation. [1]
>
> I think having a mechanism which is easily understood in both human
> and machine terms and obeys a simple, expandable syntax, then this
> would seem to be extremely useful.
>
> I like the idea of JSON encoded annotations. JSON is very simple to
> understand (if you can manually create a nested associative array in
> PHP, you can create JSON encoded data).
>
> I think for more complex annotations, a simple @tag doesn't seem like
> it is going to be enough. There is no way to nest the tags in any
> meaningful and validatable way. At least not in a way that is obvious
> when you read it. Also, for every new @tag, you have to tell PHPDoc to
> ignore it as it will produces noise.
>
> But consider now the amount of PHPDoc blocks out there. A PHPDoc ->
> annotations converter would have to be developed. Theoretically, one
> _SHOULD_ be able to do that using a PHPDoc template - I think - not an
> area I know well.
>
>
> One issue mentioned is that having annotations will have a
> "performance hit" on PHP.
>
> I'm obviously missing something here. If the annotation is in a
> blockcomment, then that would seem to satisfy the performance issue.
> Reading the annotation for normal runtime execution would seem wrong.
> Only as part of reflection or annotation specific access should the
> block be "decoded" into whatever form is required.
>
> So, aren't annotations really just an extension to the docblock
> decoding aspects of reflection? Do we have a "performance hit" because
> of reflection?
>
>
> I know I know very little about the impact on PHP, but a simple syntax
> wrapped in a comment would really seem to be an ideal approach to me.
> So much so, I'm almost surprised we need anything in the core at all.
>
>
>
> Regards,
>
> Richard.
>
> [1] http://en.wikipedia.org/wiki/Annotation#Software_programming
>
> --
> Richard Quadling
> Twitter : EE : Zend
> @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
>



-- 
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil

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

Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations

[guilhermebla...@gmail.com]

+1 for next major, but not for middle point release. =)

2010/11/29 Pierre Joye :
> my +1 for new major version only, btw :)
>
> 2010/11/27 Pierre Joye :
>> +1 if "While technically possible this RFC suggests that the following
>> shall NOT be valid for keeping the code readable " also means that the
>> patch implements it as well (force the function visibility property
>> usage).
>
> 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
>
>



-- 
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil

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