[PHP-DEV] Re: Unable tor reset Wiki password

[guilhermebla...@gmail.com]

Thank you!

I am able to access my account now.

Regards,

On Tue, Jul 19, 2022 at 12:22 PM Christoph M. Becker  wrote:
>
> On 19.07.2022 at 17:29, guilhermebla...@gmail.com wrote:
>
> > I am currently unable to reset my password on Wiki.
> > Following the process of "forgot password", email with link, click,
> > open page, getting a temporary password.
> >
> > When I attempt to use this temporary password, I experience "Sorry,
> > username or password was wrong.".
> > Is there anything else I need to do?
>
> You have a php.net account[1], so you don't have a separate Wiki
> account.  If you have forgotten your php.net account password, go to
> <https://main.php.net/forgot.php>, and follow the process.
>
> [1] <http://people.php.net/guilhermeblanco>
>
> --
> Christoph M. Becker



-- 
Guilherme Blanco
Senior Director of Infrastructure and Operations @ E Inc.
Mobile: +1 647 232 5599

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

[PHP-DEV] Unable tor reset Wiki password

[guilhermebla...@gmail.com]

Hi team,

I am currently unable to reset my password on Wiki.
Following the process of "forgot password", email with link, click,
open page, getting a temporary password.

When I attempt to use this temporary password, I experience "Sorry,
username or password was wrong.".
Is there anything else I need to do?

Regards,

-- 
Guilherme Blanco

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

Re: [PHP-DEV] Namespace-private class properties

[guilhermebla...@gmail.com]

This should answer your question:
https://github.com/php/php-src/pull/947#issuecomment-224912697

On Tue, Sep 22, 2020 at 7:38 AM Olle Härstedt  wrote:
>
> 2020-09-21 21:50 GMT, Rowan Tommins :
> > On 21/09/2020 17:13, Michael Morris wrote:
> >> Next thing to consider - we have the problem of having already used the
> >> protected keyword in PHP, and honestly I prefer PHP's interpretation of
> >> the
> >> word.
> >
> >
> > I think it's actually Java that's the outlier here: PHP's meaning of
> > "protected" corresponds directly to C++, and to name a few I came upon
> > in a quick search it's also used that way by Kotlin [1], Scala [2], C#
> > [3] and Oxygene [4] - all of which use other ways to signal package
> > visibility:
> >
> > - Kotlin has a fourth visibility, "internal", meaning "public within
> > this module"
> > - Scala has an interesting syntax where you can modify the visibility
> > with the name of a package, as in "private[SomePackage]"
> > - C# adds *three* extra visibility modes: "internal", "internal
> > protected", and "private protected"
> > - Oxygene (a language I know next to nothing about) apparently has no
> > fewer than TEN modes, including both "assembly or protected" and
> > "assembly and protected"
> >
> >
> > All of which I think shows two things: firstly, that there are lots of
> > different ways to express this concept; and secondly, that there are a
> > lot of subtle combinations that might be useful.
> >
> > The C# list is particularly confusing, presumably because it's evolved
> > without a coherent plan. If I'm understanding correctly, C#'s "private
> > protected" corresponds to Oxygene's much clearer "assembly and
> > protected", while "protected internal" corresponds to "assembly or
> > protected". Considering those combinations up front might be sensible,
> > even if they're not implemented at once.
> >
> >
> > If we're considering using namespaces rather than a new package concept
> > for this, we potentially have a third dimension: is it private to _this
> > exact namespace_, or any "child" namespace starting with the same
> > prefix? Maybe something like Scala's modifier syntax might be more
> > useful, for instance:
> >
> > namespace Acme\Frobulator\Helpers\File;
> > class FileWidget {
> >  private[namespace] $foo; // accessible specifically in the
> > "Acme\Frobulator\Helpers\File" namespace
> >  private[Acme\Frobulator\Helpers\File\*] $bar; // accessible in this
> > namespace, and all sub-namespaces
> >  private[Acme\Frobulator\*] $baz; // accessible in "Acme\Frobulator"
> > and all its sub-namespaces
> > }
> >
> >
> > [1] https://kotlinlang.org/docs/reference/visibility-modifiers.html
> > [2] https://www.tutorialspoint.com/scala/scala_access_modifiers.htm
> > [3]
> > https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/access-modifiers
> > [4]
> > https://docs.elementscompiler.com/Oxygene/Members/VisibilityLevels/structs/access-modifiers
> >
> >
> > Regards,
> >
> > --
> > Rowan Tommins (né Collins)
> > [IMSoP]
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
> >
>
> All good ideas, but I still don't know if PHP is aware of current
> namespace at all time? Anyone has this knowledge? It's a precondition
> to check namespace access.
>
> Olle
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>


-- 
Guilherme Blanco
SVP Technology at Statflo Inc.
Mobile: +1 647 232 5599

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

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[guilhermebla...@gmail.com]

Hi Sara,

I'd like to explain my rationale. Most of the time I end up using
"#[todo] Whatever" while documenting my code... my intentions are "#
[todo] ...", but you know... missing that space char doesn't break
anything today...
In any case, BC is broken and FC would also not work. Now I assume
it's a quite rare scenario where someone is doing: @[...] where
suppressing is needed, especially when we check against the #[...]
case.

Cheers,

On Tue, Aug 11, 2020 at 10:55 AM Sara Golemon  wrote:
>
> On Mon, Aug 10, 2020 at 3:41 AM Derick Rethans  wrote:
>
> > https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting
> >
> >
> Just chiming in to say all, y'all voting for @[...] are making a terrible
> choice, and are you sure you're okay with it?
>
> We have options with varying degrees of backward compatibility issues (<<>>
> none, @@ some, #[..] and @[..] a bit more than some), and only one which
> offers forward compatibility (#[..]).
> So why vote in favor of the option with the highest BC breaking probability
> and no FC?
>
> Thank you for coming to my TED talk.
>
> -Sara



-- 
Guilherme Blanco
SVP Technology at Statflo Inc.
Mobile: +1 647 232 5599

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

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[guilhermebla...@gmail.com]

Hi,

One question I'd like answered is that, like me, a few people have
voted NO on the question to re-vote the syntax.
If that is true, shouldn't their first primary choice be implied to be
<<>> instead of anything else? I see 7 votes for no, but I'm the only
one that still kept the first voting choice as <<>>.

On Mon, Aug 10, 2020 at 9:40 AM Rowan Tommins  wrote:
>
> On Mon, 10 Aug 2020 at 14:08, Benjamin Eberlei  wrote:
>
> >
> > On Mon, Aug 10, 2020 at 11:28 AM Peter Bowyer 
> > wrote:
> >
> >>
> >> I have voted no because I asked a question about the ending delimiter and
> >> why () didn't count. Another person asked a similar question and neither
> >> of
> >> us got a reply.
> >>
> >
> > () does not count as ending symbol, because it is not required, as such
> > its not an ending symbol.
> >
>
>
> The question asked was that _if the parentheses were made mandatory_, would
> this provide the same benefits ascribed to the other syntaxes?
>
> To avoid repeating myself, here are the previous posts where I elaborated
> on this question:
>
> * https://externals.io/message/111312#111342
> * https://externals.io/message/111312#111354
>
>
> Regards,
> --
> Rowan Tommins
> [IMSoP]



-- 
Guilherme Blanco
SVP Technology at Statflo Inc.
Mobile: +1 647 232 5599

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

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[guilhermebla...@gmail.com]

On Thu, Jul 30, 2020 at 12:30 PM Rowan Tommins  wrote:
>
> On Thu, 30 Jul 2020 at 17:18, guilhermebla...@gmail.com <
> guilhermebla...@gmail.com> wrote:
>
> >
> > I bet a search/replace wouldn't be that hard to be achieved
> >
>
>
> Find-and-replace always sounds like a good idea, until you realise that
> people run *a lot* of third-party code. I would not enjoy going through
> every Composer package in my vendor directory, checking for or supplying an
> appropriate patch, and then waiting for a tag or forking to create my own.

The beauty is that maintainers could release the packages today, and
not wait for 8.0.0 to be released.

>
> Regards,
> --
> Rowan Tommins
> [IMSoP]



-- 
Guilherme Blanco
SVP Technology at Statflo Inc.
Mobile: +1 647 232 5599

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

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[guilhermebla...@gmail.com]

Question: The key factor of not using @ is due to conflict of
suppression symbol.
While we are in a major (where BC breaks are not encourage, but
tolerable), have we considered the possibility of BC breaking
suppression symbol (@ would become @@) and using @ for Attributes?

I bet a search/replace wouldn't be that hard to be achieved, and it
would function even today (as @@ is acceptable). Basically, it's a BC
break where code needs to be changed, but backwards compatible as new
suppressor symbol is backwards compatible with previous versions of
PHP.

Just some food for thought

On Thu, Jul 30, 2020 at 11:57 AM Rowan Tommins  wrote:
>
> On Thu, 30 Jul 2020 at 14:28, Joe Ferguson  wrote:
>
> > ... I'm still here wanting us to talk about the
> > impact of @@ on static analysis tools. Apparently, internals doesn't care
> > about these projects.
> >
>
>
> I don't think that's a reasonable summary of this thread at all. I've seen
> three main types of response:
>
> 1) "I haven't followed the discussion about PHPCS, please could you
> summarise the problem."
> 2) "I don't understand why tools running on PHP 7.x need to parse PHP 8.x
> syntax."
> 3) "I think #[] will cause as many problems for such tools as @@, just in
> different places."
>
> Maybe they weren't always as polite or succinct as that, but not agreeing
> with you is not the same as not caring.
>
>
> As far as I can make out, attributes that appear entirely on a single line
> with no other text are trivial to ignore in any parser whatever the syntax.
> That trivial case is slightly more trivial with #[] because a PHP 7 parser
> will treat it as a line comment; but add a rule to your parser to also
> treat "@@" as a line comment, and you're done.
>
> The problems come when you have a) an attribute definition spanning
> multiple lines, and/or b) an attribute definition inline with other code.
> As soon as you have that, you have no choice but to parse the code entirely
> according to the grammar of PHP 8, not as "PHP 7 with some warts".
>
> If detecting the end of annotation tokens is really that difficult, would
> it suffice to make the () mandatory (i.e. @@Deprecated() rather than
> @@Deprecated)? The rules for what could appear between @@ and ( are pretty
> simple, and finding the correct ending ) should be pretty much the same
> effort as finding the correct ending ], since both can occur in matching
> pairs inside the argument list.
>
> Regards,
> --
> Rowan Tommins
> [IMSoP]



-- 
Guilherme Blanco
SVP Technology at Statflo Inc.
Mobile: +1 647 232 5599

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

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

[guilhermebla...@gmail.com]

Hi Benjamin,

Overall, all these amendments are good in my opinion, but I'd like to
challenge a few things:

1- On item 3, the acceptable targets would be: class, function,
method, property, class constant, parameter or all.
If possible, I'd like to ask if it's possible to expand this list and
also allow attribute and constructor.

2- Also on item 3, the validation of PhpAttribute targets, it feels
more natural to have this as an array instead of a bitwise or
operator.
Have you evaluated the performance penalty to judge your decision of
bitwise vs array?

3- Repeatability should be on its own PhpAttribute. It would not block
the expansion of the repeatability in future efforts.
One possibility could be group repeated attributes as another
PhpAttribute. Example: Multiple <> be folded into a
<>.
This code:

<>
<>

Would be equivalent to (sorry if syntax is not 100% correct):

<>,
<>
])>>

Considering:

<>
<>
class Schedule { public string $cron; /* ... */ }

<>
class Schedules { public array value = []; // Holds an array of Schedule  }

4- Now you might have recall about my initial thoughts on this
subject, but inheritance is something that would be very interesting
to see as part of this amendment.
If we introduce something like <> to the
Attribute definition, we could then mark the Attribute to be inherited
to subclasses of attributed class, while keeping the default to do not
inherit anything (like we have today).

Cheers,

On Thu, Jun 4, 2020 at 1:49 PM Benjamin Eberlei  wrote:
>
> On Thu, Jun 4, 2020 at 12:54 PM Benas IML  wrote:
>
> > Thank you for the update! Given that there is still an open issue, is the
> > RFC proposing flags or a separate `<>` attribute?
> >
>
> Good point, we came to the conclusion to simplify. Should attributes be in
> the global namespace, then we shouldn't arbitrarily add more, so it will be
> a flag.
> At that point, because you rarely declare new flags we decided to merge
> target and flags and only have one flag. You could do the following:
>
> <>
>
> >
> > Best regards,
> > Benas
> >
> > On Thu, Jun 4, 2020, 12:29 PM Benjamin Eberlei 
> > wrote:
> >
> >> I have changed back the rename from namespacing to Attributes\Attribute to
> >> using just Attribute after a few discussions off list. The reasoning is
> >> that it becomes more clear that a majority of core contributors strongly
> >> prefers using the global namespace as the PHP namespace and opening up
> >> this
> >> point again makes no sense. So the state of the RFC is again what it was
> >> when I originally posted it with renaming PhpAttribute to Attribute.
> >>
> >> Unless there is some new significant feedback I am going to open up this
> >> RFC for voting on Monday next week.
> >>
> >> On Wed, May 20, 2020 at 7:07 PM Benjamin Eberlei 
> >> wrote:
> >>
> >> > Hi everyone,
> >> >
> >> > the Attributes RFC was rather large already, so a few things were left
> >> > open or discussions during the vote have made us rethink a things.
> >> >
> >> > https://wiki.php.net/rfc/attribute_amendments
> >> >
> >> > These points are handled by the Amendments RFC to Attributes:
> >> >
> >> > 1. Proposing to add a grouped syntax <
> >> > 2. Rename PhpAttribute to Attribute in global namespace (independent of
> >> > the namespace RFC)
> >> > 3. Add validation of attribute class targets, which internal attributes
> >> > can do, but userland can't
> >> > 4. Specification if an attribute is repeatable or not on the same
> >> > declaration and fail otherwise.
> >> >
> >> > Each of them is a rather small issue, so I hope its ok to aggregate all
> >> > four of them in a single RFC. Please let me know if it's not.
> >> >
> >> > greetings
> >> > Benjamin
> >> >
> >>
> >



-- 
Guilherme Blanco
SVP Technology at Statflo Inc.
Mobile: +1 647 232 5599

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

[PHP-DEV] Re: Question about merged PR #937

[guilhermebla...@gmail.com]

Thanks for the clarification Christoph!
Somehow I couldn't see it when looking for the commit hash. Sorry for
the disturbance in the list here.

PS: I find it funny that even though I'm the original author of the
code, I don't show as a contributor in any statistics.
It'd be a shame to not be considered as a valid voter for "lack of
recent contribution" to the language.

Cheers,


On Thu, Sep 19, 2019 at 12:58 PM Christoph M. Becker  wrote:
>
> On 19.09.2019 at 17:01, guilhermebla...@gmail.com wrote:
> > One of my old PRs to PHP that was claimed to be merged disappeared
> > from master. However, the upgrade note is still there in master and
> > 7.4beta1.
> >
> > Here is the PR: https://github.com/php/php-src/pull/937
> > Here is the commit referencing it:
> > https://github.com/php/php-src/commit/0adfa03397edcde8cba3bae2032b1f2ef26ea760
> >
> > Please let me know if there's anything I can do to help.
>
> From what I can tell, everything is there.  PR #911 has been merged as
> <http://git.php.net/?p=php-src.git;a=commit;h=094d409b3d34c51f49e0121e5ccfe8b2a717aaf6>,
> and parts of that PR already with PR #928 as
> <http://git.php.net/?p=php-src.git;a=commit;h=f48c2327403ce76a870e74f31a069a64dfb711a2>.
>
> --
> Christoph M. Becker



--
Guilherme Blanco
SVP Technology at Statflo Inc.
Mobile: +1 647 232 5599

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

[PHP-DEV] Question about merged PR #937

[guilhermebla...@gmail.com]

Hi internals!

One of my old PRs to PHP that was claimed to be merged disappeared
from master. However, the upgrade note is still there in master and
7.4beta1.

Here is the PR: https://github.com/php/php-src/pull/937
Here is the commit referencing it:
https://github.com/php/php-src/commit/0adfa03397edcde8cba3bae2032b1f2ef26ea760

Please let me know if there's anything I can do to help.

Regards,

-- 
Guilherme Blanco
SVP Technology at Statflo Inc.
Mobile: +1 647 232 5599

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

Re: [PHP-DEV] Re: [VOTE] Reclassifying engine warnings

[guilhermebla...@gmail.com]

Nikita,

I'd suggest to wait until the current vote ends and then open a new
RFC to vote this one, otherwise it'll be disrupting.

Cheers,

On Wed, Sep 18, 2019 at 12:29 PM Nikita Popov  wrote:
>
> On Thu, Sep 12, 2019 at 2:17 PM Nikita Popov  wrote:
>
> > Hi internals,
> >
> > I've opened the vote on //wiki.php.net/rfc/engine_warnings.
> >
> > There are 4 votes, all of them independent. The first 3 are for specific
> > cases that were controversial during the discussion, the last one is for
> > the remainder of the proposal.
> >
> > Voting closes 2019-09-26.
> >
> > Regards,
> > Nikita
> >
>
> I just realized that I missed one notice here, because it is generated from
> a different location: "Constant %s already defined" (The define/const will
> be ignored and the previous value used.)
>
> It would be great to have that as an exception for optimization reasons,
> but as it's only a notice right now ... what do people think about
> promoting it to a warning?
>
> Nikita



-- 
Guilherme Blanco
SVP Technology at Statflo Inc.
Mobile: +1 647 232 5599

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

Re: [PHP-DEV] Re: P++: FAQ

[guilhermebla...@gmail.com]

Hi all,

I tried as much as I could to stay away from this discussion. My
personal take is that breaking the language in two is a *really bad
idea* (shouldn't I have put caps here instead?).
Anyway, people are commenting a lot on features that adds a feature to
the language, but nothing was being spoken about scenarios where
severe internals changes would be required. Zeev, sorry for taking you
as the guinea pig here, but since you were the one that started this
whole thread, I think it's fair to ask you directly.

1- How would you envision a shared runtime between PHP and P++, in the
case that this new evolved solution decides to support objects as keys
in array structure? This fundamentally changes internals, and a
drastic change to both runtime of PHP and P++ would be required.

2- How would you envision injecting an actual namespace structure,
allowing scoping support for namespaces? FYI, this is what blocked me
to finish class visibility in https://github.com/php/php-src/pull/947
It'd require drastic changes in both PHP runtime and P++ too.

I have added 2 small samples (feel free to ask me if you need a few
more) where in order to add a feature in P++, changes to the way PHP
operated would have to change too.

The only I see this to operate is either P++ re-implementing the same
PHP structures in order to evolve, leading to a full fork becoming
more attractive, or compromises in P++ (like unable to support a given
feature) because PHP would make it set back.

Please let me know your thoughts on this.

Cheers,

On Sat, Aug 10, 2019 at 11:05 AM Rasmus Lerdorf  wrote:
>
> On Sat, Aug 10, 2019 at 5:37 AM Andrea Faulds  wrote:
>
> > As the person who initially proposed and implemented strict_types, I
> > think this is heading in the wrong direction. Perhaps that directive was
> > a mistake, if it will lead to so many attempts inspired by it to
> > fragment the language, including this one. Personally, I don't actually
> > want a language like C++ or Java. PHP's flexibility is great, and I
> > think splitting the language means going in a direction where you are
> > forced to have everything be strict or nothing be. PHP++ sounds like
> > Hack, but in mainline. I think it'll end up a mess in the long term.
> >
>
> Yes, I would suspect it would get a bit weird having a AnythingGoes
> vs. NothingGoes barrier in the code like that. Forcing a balance, even
> if sometimes the arguments get rather heated (and they were just as
> heated, if not more so 20+ years ago), keeps everyone on the same
> page and working on the same code-base without the us vs. them
> situation that is bound to creep in.
>
> -Rasmus



-- 
Guilherme Blanco
SVP Technology at Statflo Inc.
Mobile: +1 647 232 5599

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

Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax

[guilhermebla...@gmail.com]

threat /THret/ noun: a statement of an intention to inflict pain,
injury, damage, or other hostile action on someone in retribution for
something done or not done.

Anyway, can we vote on this RFC?

On Wed, Jul 31, 2019 at 9:54 AM Zeev Suraski  wrote:
>
> On Wed, Jul 31, 2019 at 4:31 PM Dan Ackroyd  wrote:
>
> > On Wed, 31 Jul 2019 at 09:50, Zeev Suraski  wrote:
> > >
> > > This was not a threat of any kind,
> >
> > "If we need to pull rank with group@ here, we will."
> >
> > "I'm confident that if it ever came to that, I'll have the backing of
> > group@, which is why I wrote what I wrote."
> >
> > Those are threats.
> >
>
> No Dan, they are not.  You're remarkably offensive for claiming that - not
> only based on your own initial misinterpretation, but also after I took the
> time to explain[1].  Perhaps it has to do with a very bogus definition for
> the word 'threat', by which one could consider every RFC as a threat as
> well.  It was a clear call to order.  If you want to call it a threat, or
> Coolio, or some other word - that is entirely up to you, but it does not
> change the fact that it wasn't a threat.
>
> Zeev
>
>
> [1] "This was not a threat of any kind, and framing it as such is
> inappropriate by itself.  I wasn't "threatening" to have anyone kicked or
> otherwise penalized.  It was a reminder of one of the ground rules -
> respectful discussion and focusing on the ideas and not the people they
> came from - and making it clear I have no intention to yield on it.  I said
> that if for some reason what has been and should continue to be obvious -
> just as much as the discussions here have to be respectful (and in English)
> - is no longer obvious - we'll make it clear.  That's all."



-- 
Guilherme Blanco
SVP Technology at Statflo Inc.
Mobile: +1 647 232 5599

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

Re: [PHP-DEV] [RFC] [VOTE] Preloading

[guilhermebla...@gmail.com]

Hi,

Besides the yet-another naming convention, I'm quite optimistic about this
RFC.
Now on the convention, is there any reason why single underscore (_) is
used instead of double underscores (__)? We already have __autoload,
__sleep, __toString, __wakeup, etc.

Regards,

On Tue, Nov 6, 2018 at 11:08 AM Levi Morrison  wrote:

> On Tue, Nov 6, 2018 at 3:05 AM Dmitry Stogov  wrote:
> >
> > Hi internals,
> >
> >
> > The preloading RFC is turned into voting state.
> >
> >
> > https://wiki.php.net/rfc/preload
> >
> >
> > Many thanks to Anatol, MZPERX and Xinchen for testing.
> >
> > I hope, most of the implementation issues should be fixed now.
> >
> >
> > Thanks. Dmitry.
> >
>
> I am cautiously optimistic about this RFC. I hope some of the Future
> Scope items can be implemented soon.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 
Guilherme Blanco
Chief Architect at Statflo Inc.

Re: [PHP-DEV] Re: TOKEN_AS_OBJECT for token_get_all()

[guilhermebla...@gmail.com]

Thanks Fleshgrinder!

You expressed exactly what I thought, but was too busy... cough... lazy to
put in an email.

Cheers,

On Fri, Mar 24, 2017 at 2:35 PM, Fleshgrinder  wrote:

> On 3/24/2017 4:23 PM, Andrea Faulds wrote:
> > Hi Nikita,
> >
> > Nikita Popov wrote:
> >
> >> I'd like to add a new TOKEN_AS_OBJECT flag to token_get_all(), which
> >> returns an array of PhpToken objects, rather than the mix of plain
> >> strings
> >> and arrays we currently have. The PhpToken class is defined as:
> >>
> >> class PhpToken {
> >> public $type;
> >> public $text;
> >> public $line;
> >> }
> >
> > Rather than adding a flag to token_get_all() to return objects, you
> > could potentially instead make an equivalent static method on PhpToken
> > (PhpToken::getAll() perhaps). That would avoid mixing “object-oriented”
> > and “procedural” styles, though I don't know if it matters. It seems
> > cleaner to me.
> >
> > Thanks!
> >
>
> I am also against adding another flag because it violates the single
> responsibility principle. However, adding a `getAll` method to the
> `PhpToken` data class also seems very wrong, because it violates the
> single responsibility once again.
>
> The real and proper solution is to have an actual PHP Lexer that is
> capable of creating a token stream.
>
> class Lexer {
> public function __construct(string $source);
> public static function fromFile(string $path): self;
> public function tokenize(): TokenStream;
> }
>
> final class TokenStream implements IteratorAggregate {
> public function getIterator(): Generator
> public function toArray(): Token[]
> }
>
> final class Token {
> // Ideally this would be an enum, but...
> public const OPEN_TAG;
> public const CLOSE_TAG;
> // ...
>
> // I hope these are not mutable!
> public int $category;  // type
> public string $lexeme; // text
> public int $line;
> public int $column;// we don't have that :(
>
> /** @see token_name */
> public function getCategoryName(): string;
>
> // We could add `is*` methods for the various categories here.
> public function isOpenTag(): bool;
> public function isCloseTag(): bool;
> // ...
> }
>
> With this in place, we're ready for the future. The `TokenStream` can
> easily use a generator over the internal array. Or we offer the
> `toArray` method only at the beginning. Users will have to call it, but
> that overhead is tiny, considering that we can extend upon it in the
> future without introducing any kind of breaking change.
>
> Obviously this could go into the namespace `PHP\Parser`, or we prefix
> everything with `PHP` (I'd be for the former).
>
> On a side note, going for `Php` instead of `PHP` is inconsistent with
> the naming that is currently dominating the PHP core:
>
> https://secure.php.net/manual/en/indexes.functions.php
>
> There are already some things that violate it, e.g. `Phar` instead of
> `PHAR`, but most things keep acronyms intact (`DOM`, `XML`, `PDO`, ...).
> Introducing even more inconsistency to PHP seems like a very bad idea to
> me. I know that this is considered bikeshedding by many people, but
> consistency is very important and we are already lacking it on too many
> levels as it is.
>
> --
> Richard "Fleshgrinder" Fussenegger
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Guilherme Blanco
Senior Technical Architect at Huge Inc.

[PHP-DEV] PHP's support to contravariance and covariance

[guilhermebla...@gmail.com]

Hi internals,

During my regular open source work, I realized that PHP yet do not support
contravariance and covariance for user classes.

Some examples that I found that could be really easy to implement and
useful to end user are highlighted here:

- contravariance.php - https://3v4l.org/I3v0u
- covariance.php - https://3v4l.org/i79O5

For all those lazy people that don't want to open 2 new tabs to understand
what I mean, here's a more elaborate example covering both scenarios:

https://github.com/php/php-src/blob/master/Zend/zend_inheritance.c#L184,
which would require to be decoupled in 2 functions to check which direction
is should support (covariance or contravariance).

Is there anything else that I am missing? I'm happy to write an RFC for
that... =)

Cheers,

-- 
Guilherme Blanco
Senior Technical Architect at Huge Inc.

Re: [PHP-DEV] Typed properties problems

[guilhermebla...@gmail.com]

Where can I see progress of this work?

On Tue, Jan 17, 2017 at 5:03 AM, Dmitry Stogov  wrote:

> Hi Bob,
>
>
> I've found a number of problems:
>
>
> $ sapi/cli/php -r 'class Foo {public bool $b = false;} $x = new Foo;
> $x->b->ops += 5; echo gettype($x->b),"\n";'
>
> object
>
> $  sapi/cli/php -r 'class Foo {public bool $b = false;} $x = new Foo;
> $x->b->ops++; echo gettype($x->b),"\n";'
> object
>
> $  sapi/cli/php -r 'class Foo {public bool $b = false;} $x = new Foo;
> $x->b->ops = 5; echo gettype($x->b),"\n";'
> object
>
> $  sapi/cli/php -r 'class Foo {public bool $b = false;} $x = new Foo;
> $x->b[] = 5; echo gettype($x->b),"\n";'
> array
>
> Thanks. Dmitry.
>
>


-- 
Guilherme Blanco
Senior Technical Architect at Huge Inc.

Re: [PHP-DEV] Re: [RFC] Debugging PDO Prepared Statement Emulation v2

[guilhermebla...@gmail.com]

Hi Adam,

Providing my input on why I voted "NO".
Your proposed new method is not pure. This means it does have distinct
responses depending on where it's located in the code.
That's a big no-no for me.

Cheers,

On Tue, Dec 6, 2016 at 12:15 PM, Lester Caine  wrote:

> On 06/12/16 16:30, Adam Baratz wrote:
> >> This issue is not difficult to solve in userland, at least well enough
> for
> >> debugging in my experience. Here's an older example I wrote up on my
> blog
> >> that worked (but I'm told is broken right now):
> https://daveyshafik.com/
> >> archives/605-debugging-pdo-prepared-statements.html
> >>
> > I want to be able to write .phpt tests that validate how values are
> getting
> > interpolated into emulated prepares. Since this creates a separate code
> > path, it wouldn't let me validate what gets sent to the server.
> > PDO::quote() doesn't necessarily produce the same output as
> > pdo_parse_params().
>
> The whole point of testing is that it tests real results not testing
> 'test code' that tries to emulate the real world. The whole point of
> 'emulated prepare statements' is that it creates a SQL query that the
> target database engine can actually work with rather than one that a
> more capable database engine will process. Testing the innards of some
> driver is simply wrong, one tests the whole process is working! And
> IDEALLY the test suit for PDO should work which ever target is selected,
> but that is not lightly to happen any time soon.
>
> --
> 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
Senior Technical Architect at Huge Inc.

Re: [PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()

[guilhermebla...@gmail.com]

I'd suggest URL to be immutable and have a URLBuilder (obtainable through
URL::createBuilder()) for that...

On Fri, Oct 7, 2016 at 10:45 AM, David Walker  wrote:

> Hi Nikita,
>
> On Fri, Oct 7, 2016 at 4:37 AM Nikita Popov  wrote:
>
> > Are you aware of the WHATWG URL standard [1]? Quoting the first goal
> > statement:
> >
> > > Align RFC 3986 and RFC 3987 with contemporary implementations and
> > obsolete them in the process. (E.g., spaces, other "illegal" code points,
> > query encoding, equality, canonicalization, are all concepts not entirely
> > shared, or defined.) URL parsing needs to become as solid as HTML
> parsing.
> >
>
> I was not.  I assume that WHATWG ought to supersede the IETF standards on
> the subject.  I can obviously make an implementation follow the standards
> and algorithms set out in this doc.
>
> Also quoting from the goals:
> >
> > > Standardize on the term URL. URI and IRI are just confusing. In
> practice
> > a single algorithm is used for both so keeping them distinct is not
> helping
> > anyone. URL also easily wins the search result popularity contest.
> >
> > For this reason, I would recommend against introducing the term "URI"
> > anywhere. In particular the suggestion from this thread to use
> parse_uri()
> > for this functionality seems like it will cause a lot of confusion.
> >
>
> Duly noted.
>
>
> >  The URL standard also specifies the interface of the URL object used by
> > JavaScript and I think we should consider whether we may want to simply
> > adopt this (object-oriented) interface (potentially with adjustments for
> > PHP specifics).
> >
>
> > I think an important part of this interface is that the URL is
> constructed
> > using URL(url [, base]), where "base" is the base URL against which
> > relative URLs are resolved. This base URL is required for parsing
> > non-absolute URLs. To me this makes a lot of sense and I think it makes
> it
> > much clearer how "incomplete" URLs are being treated.
> >
>
> If we go the route of making URL it's own object, and expose an
> object-oriented interface, are we leading it to be more of a total URL
> builder, of sorts? Like:
>
> $url = new URL();
> $url->setScheme('http');
> $url->setHost('example.org');
> $url->setPath('/test.php');
> var_dump($url->build()); // outputs:  http://example.org/test.php
>
> OR, would it, at the end of the day be an object that takes a string, and
> you just call getter's on it that would be akin to the current flags you
> pass into parse_url()?
>
> On both accounts, if we're to go forward with the Object model of URL,
> would this want to be broken into it's own ext/url module, like how date
> exists?  Or retain it in ext/standard?
>
> Cheers
> --
> Dave
>



-- 
Guilherme Blanco
Lead Architect at E-Block

Re: [PHP-DEV] Namespaces internal refactoring

[guilhermebla...@gmail.com]

Hi Stas,

I'll comment your PS, since I'm the author of the PR.

On Sun, Aug 14, 2016 at 6:11 PM, Stanislav Malyshev 
wrote:

> Hi!
>
> > - PHP 7 has private classes through anonymous/inner classes.
>
> It's not exactly the same, and I suspect the same is true for Ruby. It's
> true that anonymous classes can not be instantiated by other code. But
> that is not what we were discussing here. This particular effect is
> somewhat similar, the purpose of the feature is different.
>
> Of course, some languages have them. Others don't. The point is saying
> "it's not OO unless it implements $favorite_feature_of_mine" is not very
> meaningful, at least at this point.
>
> > abstract class Data {
> >   protected $id;
> >   protected $name;
> >   protected function __construct() {}
> >   protected function __clone() {}
> > }
> >
> > final class Entity extends Data {
> >   public function getId() {
> > return $this->id;
> >   }
> >   public function getName() {
> > return $this->name;
> >   }
> > }
> >
> > final class Builder extends Data {
> >   private $entity;
> >   public function build() {
> > return clone $this->entity;
> >   }
> >   public function setId($id) {
> > $this->entity->id = $id;
> >   }
> >   public function setName($name) {
> > $this->entity->name = $name;
> >   }
> > }
> >
> > ?>
>
> I'm afraid I don't understand this code. Why both entity and builder are
> Data? It looks like combining factory object with actual data object.
> This is why __construct/__clone exists - so the object could take care
> of the details and the factory didn't have to know about it in details.
>
> I presume you want to say that Data object should be private class. I
> think - at least from my partial understanding of the code - that it
> shouldn't exist at all, especially given you don't want to expose it to
> the user.
>
> > Another example that is not solvable with friend classes would be the
> > strategy pattern of hidden strategies as we find it for example in
> > Symfony's process component.
> >
> > https://github.com/symfony/process/tree/master/Pipes
> >
> > The pipes are purely internal to work around differences between PHP on
> > Unix and Windows. They are not meant for consumption through users, they
>
> Sure, they aren't useful for most, but I see no problem in somebody
> using them if necessary. Say, you may want to use Unix pipe on Windows
> because you are in unix emulation environment, or you have a weird OS
> that is not Unix and now Windows and want to reuse parts of these
> classes to deal with it. There could be many cases we can't foresee when
> we design it for our ideal use case.
>
> > At trivago we have hundreds of applications, packages, libraries and
> > developers who work in a very fast moving environment. Reading
> > documentation is not something most people spend time with.
>
> I find so many things not right with this statement I don't know where
> to start... So I just leave it with a note that having no time to do
> things right usually means doing things wrong many times, and *then*
> being forced to spend time to do things right because the whole jenga
> tower crashes on your head. That is not a criticism of you or your
> employer, but rather the result of experience learned the hard way. You
> can get away with it from time to time, true, but it's just luck.
>
> > It's also easy to work around property and method access modifiers.
> > However, that is no argument to remove them now.
>
> Not very easy. The only way to work around private is to use heavy
> machinery like reflection. This is why, btw, private should be used very
> carefully - when if you're *sure* nobody will need or is advised to
> access that thing directly. Overuse of private, especially for methods,
> leads to classes that are not extendable without horrendous amounts of
> copypaste.
>
> Also, there's a difference IMO between classes and class' properties.
> Class details may be - indeed, need to be - hidden because this is what
> the class is, one of it's reasons to exist - a tool to reduce complexity
> by hiding irrelevant information and exposing only relevant information
> as class' public API. You hide things not because you're afraid evil
> users would abuse them - but as a service to the user to not overload
> their mental models with irrelevant details and allow to deal with the
> class by only considering the important things.
>
> However, if we're talking about collection of classes sharing a
> namespace, there's no such thing as "namespace's API", at least not in
> common use. There's a concept of library's API, but it's not derived
> from classes alone - it's usually what documentation does, while class
> API can be yet figured from it's methods, library API is usually
> impossible to figure out just looking at the classes - you need the next
> level, documentation.
> So in my opinion, if you hide some classes from instantiation from
> outside namespace (which by 

Re: [PHP-DEV] Namespaces internal refactoring

[guilhermebla...@gmail.com]

Hi Stas,

On Sun, Aug 14, 2016 at 6:35 PM, Stanislav Malyshev 
wrote:

> Hi!
>
> > A realization that needs to be made is that beginners would be using
> > libraries that requires to make valid restrictions, preventing those
> > beginners to mess up with code they shouldn't. So even if the use case
> > is only valid for 0.01% of code producers, it might be valid for 20%+ of
> > consumers.
>
> I don't think PHP needs more bondage-and-discipline. If beginners "mess
> up with code they shouldn't" that is usually, in my experience, a sign
> of library authors not serving their use case well, and not implementing
> functionality that they need. Either because they didn't know, or
> because their opinion about user's needs differs from user's opinion
> about their needs. In this case, I'm on the user's side. Hacker's ethos
> is doing things other people think can't be done.
>

It's a valid point of view, indeed.
But thinking from a different perspective, if you are using a tool that
does X, users shouldn't rely on Y to complete their job. Specially if Y is
already on a namespace marked as "Internal" with @private annotation and a
huge capital disclaimer that it was a private class.

It doesn't matter how much documentation you add, without language tooling
that prevents to use X as Y, all you can expect are weird use cases and
breakages, that re either not intended to work or are just not supposed to
be done at all. Like I always say "never underestimate someone's ignorance".


>
> > It's about defensive programming.
> > I never knew TopologicalSorter was used by several users until I
> > actually broke its API. Imagine the frustration of all those developers
> > with tight deadlines having to deal with a sudden breakage, because the
> > language it too open to notify them about something shouldn't be used.
>
> I'd rather say "imagine the frustration of all those developers that
> rely on the library authors who are oblivious to their true needs and
> still the developers at the mercy of them every day". I agree that can
> be frustrating. The solution is not more detachment from the needs of
> the users and more fencing out so these pesky users would have
> absolutely no way to use my code in ways that I didn't foresee, because
> I'm capable of foreseeing 100% of user's needs and if I'm not, it's
> their fault. At least, I don't think it is.
>

Taking from this perspective (and also inline with your initial comment),
what you are suggesting is basically break down common, reusable piece of
functionality on its own package. Yes, that is valid, and I have nothing
against it.
The lack of breaking X into smaller packages (such as decoupling Y) doesn't
mean users should use Y at will and suddenly expect/blame about API breaks.


>
> > Every time someone questions me about the validity of private classes, I
> > like to exercise replacing the term "private" with "final". Final is
> > part of PHP language and it also there's non application that is
> > prevented without it.
>
> I think most of the usages of final are wrong too, and for the same
> reasons. It's a claim you have foreseen all user's needs and they'd
> never need anything else. It's usually wrong.
>
> > modifier, https://mwop.net/blog/2012-06-28-oop-visibility.html history
> > would be completely different.
>
> There Matthew says pretty much what I say, so I agree:
>
> I feel that frameworks and libraries should use private and final
> sparingly.
>

Here you basically agreed with everything I said. I'm not saying every
single class should be private (or final), but you just agreed with Matthew
and I that there are valid use cases for each one.


>
> > That's not about preventing for no reason and it should be bypassed.
> > It's about somehow telling users that something shouldn't be used at all.
> > The amount of people that takes the wrong approach is insane, and any
> > kind of prevention to do it is beneficial.
>
> If the amount of people using your library in a wrong way is insane,
> maybe something needs to be changed in the library? ;) If you build a
> nice slick walkway and people keep walking over the grass 100 meters
> aside, it may just be you've built the walkway in a wrong place.
>

It's always a balance between what you can do in such a small spare time
and benefits you get out of these contributions that you could use to get
your job done.
I could perfectly decouple 10 sub-packages out of ORM, but that only brings
more maintenance burden that will consume more time that I already don't
have.


>
> > I managed big teams of development where I work, and controlling code
> > produced by 40+ developers is not easy.
> > Countless classes are marked as final and I bet hundreds would be final
> > if I could.
> > Handling a company source code is easy through code reviews, and also
> > walk a few steps to ask why a certain class is final or (hypothetically,
> > private).
>
> Maybe it makes sense to a company which works on its 

Re: [PHP-DEV] Namespaces internal refactoring

[guilhermebla...@gmail.com]

Hi Stas,

Answers inline.

On Sun, Aug 14, 2016 at 5:14 AM, Stanislav Malyshev 
wrote:

> Hi!
>
> > Today I see 2 sides in PHP Internals. One that truly believes that PHP
> > should adopt more concepts of object orientation, such as Annotations,
> > Generics, Overloading, Class visibility, Collections, Exceptions, etc
>
> Object orientation is a very broad term. You can be very well object
> oriented language and not be Java. In fact, almost all OO languages are
> not Java ;) And a lot of OO languages (most of ones I know) don't have
> Javaesque features like private classes, many also do fine without
> generics.
>

I agree that we shouldn't copy and paste features as is. However, whenever
a need is found and there are common agreement over the existence of a
feature, we need to understand the decisions over each one and how are they
valid for PHP.
I'll draw 2 simple examples:

1- Generics: They solve a very interesting problem that is highlighted by
the usage of strict types.
It also hardens the implementation code, allowing to write more robust and
reliable libraries that could be used by others.
However, should it be a blind copy of Java generics? Of course no. In the
context of PHP, lower bounds, lower bounded wildcards, unbounded wildcards
and upper bounded wildcards make absolutely no sense.

Now let's suppose people decide to implement polymorphism in PHP and
everyone agrees with it. All of a sudden, lower bounded wildcards would
become a necessity.


>
> > One thing that didn't change is the constant increase of developers
> > writing and rewriting software using the language. Now these developers
> > are also improving their skills, and demanding more flexible ways of
> > achieving their needs. Language evolution should also be in compass with
> > these new needs, and that's where I think PHP is struggling to keep up,
> > for a variety of reasons.
>
> Please do not forget that PHP was designed as beginner's language with
> low barrier of entry. Making EJB out of it goes contrary to that, and
> introducing features that would serve 0.01% of very complex cases while
> complicating the language model for 100% of the users does not seem to
> be worth it to me.
> Especially if in those 0.01% cases I don't see a lot of real
> improvement, but rather a "good feeling" that you can write "really
> strict" code even though there's nothing better in that code than if it
> were written without all the complexities.
>

A realization that needs to be made is that beginners would be using
libraries that requires to make valid restrictions, preventing those
beginners to mess up with code they shouldn't. So even if the use case is
only valid for 0.01% of code producers, it might be valid for 20%+ of
consumers.


>
> > Being a constant contributor to open source and many libraries that now
> > drives most of what people consider as "Modern PHP", I constantly face
> > problems with the language itself being unable to achieve my needs. When
> > I say my needs, I mean needs of heavily used libraries, with hundreds or
> > thousands of other projects depending on them.
>
> I would like to see what is impossible to implement in PHP without
> private classes. I mean useful functionality, not circular reference "I
> need private classes because I need classes to be private" of course.
> What application can not be implemented without it? I have very hard
> time imagining such application.
>

It's not about being possible or impossible. It's about to prevent
unexpected breakages and headaches that sometimes you're not even aware.
It's about defensive programming.
I never knew TopologicalSorter was used by several users until I actually
broke its API. Imagine the frustration of all those developers with tight
deadlines having to deal with a sudden breakage, because the language it
too open to notify them about something shouldn't be used.

Every time someone questions me about the validity of private classes, I
like to exercise replacing the term "private" with "final". Final is part
of PHP language and it also there's non application that is prevented
without it.

Doctrine's code, taking advantage of "final" modifier also allowed Zend
Framework to take the right path in their implementation. We carefully
think about everything we implement there, always making sure defensive
programming is used for every class. Now if it was not for the existence of
"final" modifier, https://mwop.net/blog/2012-06-28-oop-visibility.html
history would be completely different.

The same would happen for "private" classes. It prevents consumers of
taking the wrong approach when developing their apps, other libraries, etc.


>
> > working on a bug fix. If this class was never intended to be used
> > outside of the scope of this project, how can restrict its usage by
> > outside packages? Feel free to provide me answers or alternatives, and
> > I'll happily agree with you that private classes is a bad idea.
>
> You can 

Re: [PHP-DEV] Namespaces internal refactoring

[guilhermebla...@gmail.com]

Hi Stas,

I'll answer your message as it directly refers to links with my name.
I understand the reasons of why namespaces were implemented that way, as I
follow this list for quite a long time. I never complained about the
implementation itself as it was publicly introduced originally back in
August 2008, when first PHP 5.3 alpha 1 got released.

Today I see 2 sides in PHP Internals. One that truly believes that PHP
should adopt more concepts of object orientation, such as Annotations,
Generics, Overloading, Class visibility, Collections, Exceptions, etc (the
side I support) and the other side that wants to make the engine more
robust, stable and faster, without entering in a rollercoaster of new
functionality to be introduced that brings instability.

One thing that didn't change is the constant increase of developers writing
and rewriting software using the language. Now these developers are also
improving their skills, and demanding more flexible ways of achieving their
needs. Language evolution should also be in compass with these new needs,
and that's where I think PHP is struggling to keep up, for a variety of
reasons.

Being a constant contributor to open source and many libraries that now
drives most of what people consider as "Modern PHP", I constantly face
problems with the language itself being unable to achieve my needs. When I
say my needs, I mean needs of heavily used libraries, with hundreds or
thousands of other projects depending on them.

I'll highlight the main driver of "private classes" conceptualization, in
an attempt to make this email short (which I already failed). I wrote a DAG
sorter as part of one of Doctrine packages. Many people started to
instantiate (and use this class, even though it was marked as an @internal)
and consume the benefits it provides, until I changed its API working on a
bug fix. If this class was never intended to be used outside of the scope
of this project, how can restrict its usage by outside packages? Feel free
to provide me answers or alternatives, and I'll happily agree with you that
private classes is a bad idea.

Namespace implementation is now the blocker of many new features that could
help solve complex problems that you don't see on a daily basis, but
library developers face daily. For example: allowing to assess
imported/used structs when declaring a class would drastically reduce the
complexity of Doctrine's annotation parser, which required token_get_all
and several logic to check for what you're including. Is there a better
solution for that too? Well, I'd argue Annotations has a market, and people
are just blind if they don't wanna see it. Answering that implementing
Annotations in userland is a bad idea is like telling a corporation
shouldn't create a product because you don't like it. Makes absolutely no
sense.

I do have a lengthy, detailed and complex plan of how namespace refactoring
could be made, what it would enable feature-wise, and how it would benefit
many projects. I'm open to share with you or any other internals developer,
assess impact over PHP source code and even help implementing it. I'm just
unable to do it all by myself due to my poor C knowledge. What I don't want
to see is blind resistance to language evolution and blaming over something
as badly designed without understanding the circumstances that drove to
that implementation decision.

Regards,


On Sat, Aug 13, 2016 at 3:20 PM, Stanislav Malyshev 
wrote:

> Hi!
>
> > The current approach to namespaces blocks new features like you see it
> > in the following PR. The link already points to the two most relevant
> > comments that should give you full context:
> >
> > https://github.com/php/php-src/pull/947/#issuecomment-224912697
>
> I don't think this - private classes, etc. - is a good idea. It looks
> like Javaization of the language and introducing more and more
> complexity without any clear benefit, and AFAIK none of the mainstream
> scripting languages have such concept. Anyway, this doesn't even have an
> RFC, so I don't see why we should refactor everything to accommodate it.
>
> But it is certainly does not fit the concept of namespaces. It needs
> completely different packages concept - one that currently does not
> exist on PHP. Trying to bolt it on existing concept is not going to do
> any good. I think this is what it should start with - developing a good
> concept, not trying to go from code modification to design. Design
> should come first, then code modification.
>
> > You might know other approaches to solve this. What I want to say is, we
> > should not re-discuss everything that was discussed before, we should
> > discuss the proposed features and refactor the namespaces IF it is
> required.
>
> Indeed.
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Guilherme Blanco
Lead Architect at E-Block

Re: [PHP-DEV] Set object properties inline

[guilhermebla...@gmail.com]

Hi,

I very much liked the proposal, specially if we do consider a potential
reusability if anyone ever decide to revisit Attributes RFC. It's out of
scope how I'd see this implemented, so let me focus on the proposal only.
There're some edge cases that need to be discussed and considered here.
Here's one quick example:

declare("foo", "bar");

class Foo {
public $bar;
}

$f = new Foo() {
foo = "bar"
};

Should "foo" be considered as a property identifier or as a constant, which
would then be converted into "bar" and then used as $f->bar = "bar"?


Regards,


On Wed, Jun 1, 2016 at 5:49 AM, Peter Cowburn 
wrote:

> On 1 June 2016 at 03:15, Jesse Schalken  wrote:
>
> > Hi internals,
> >
> > I often have code dealing with plain old PHP objects with properties and
> no
> > methods, either as a substitute for keyword arguments, or to represent a
> > JSON or YAML document for a web service, configuration file or schemaless
> > database.
> >
> > At the moment, instantiating an object and setting public properties
> > requires a temporary variable for each object in the structure:
>
>
> > $obj1 = new Obj1();
> > $obj1->prop1 = ...;
> > $obj1->prop2 = ...;
> >
> > $params = new FooParams();
> > $params->prop1 = ..;
> > $params->prop2 = ...;
> > $params->prop3 = $obj1;
> >
> > $this->fooMethod($arg1, $arg2, $params);
> >
> >
> > For large structures, this gets verbose very quick. There is a good
> example
> > of this here
> > <
> >
> https://github.com/jesseschalken/fail-whale/blob/72870b37c4c21d19f17324a966344ec476b432a7/src/FailWhale/Introspection.php#L22
> > >
> > involving
> > 18 unnecessarily variables.
> >
> > I can remove the local variables by defining setters for all the
> > properties:
> >
> > $this->fooMethod(
> >
> > $arg1,
> > $arg2,
> > (new FooParams())
> >
> > ->setProp1(...)
> >
> > ->setProp2(...)
> >
> > ->setProp3((new Obj1())
> >
> > ->setProp1(...)
> >
> > ->setProp2(...))
> >
> > );
> >
> >
> > But now for each property I have to spend an extra 3-5 lines of code
> > defining a setter, which is more code than it saved (unless the class is
> > used heavily enough).
> >
> > I could define __construct() taking every property as a parameter, but
> then
> > each property has to be mentioned another three times (four times with a
> > doc comment), and the type twice:
> >
> > class FooParams {
> >
> > public int $prop1;
> > // ...
> >
> >
> > public function __construct(
> > int $prop1
> > // ...
> > ) {
> >
> > $this->prop1 = $prop1;
> > // ...
> >
> > }
> >
> > }
> >
> >
> > and where the object is constructed, it isn't immediately visible what
> the
> > meaning of each positional parameter is without some IDE assistance (eg
> > Ctrl+P in PhpStorm), and only specifying some parameters requires filling
> > preceding ones with defaults.
> >
> > I could also define the __call() method to automatically expose setters,
> > but then IDEs and static analysis can't understand what's going on (it
> > can't see that those methods exist, what their parameters are and what
> they
> > return). @method doc comments on the class help, but that's another line
> > for every property which I have to manually keep in sync with the real
> > properties.
> >
> > It would be great if there was a simple shorthand syntax for setting
> > properties on an object in-line, without needing to extract a variable:
> >
> > $this->fooMethod(
> > $arg1,
> > $arg2,
> > new FooParams() {
> > prop1 = ...,
> > prop2 = ...,
> > prop3 = new Obj1() {
> > prop1 = ...,
> > prop2 = ...,
> > },
> > }
> > );
> >
>
> While it's not as concise as your example, anonymous classes can do this
> already after a fashion.
>
> $this->fooMethod(
> $arg1,
> $arg2,
> new class() extends FooParams {
> // Constructor because prop3's value isn't a constant expression
> function __construct() {
> $this->prop1 = '...';
> $this->prop2 = '...';
> $this->prop3 = new class() extends Obj1 {
> public $prop1 = '...';
> public $prop2 = '...';
> };
> }
> }
> );
>
>
> >
> >
> > This way the structure can be written directly in the code as an
> expression
> > and FooParams and Obj1 remain simple containers for properties.
> >
> > The grammar might look like (I haven't used bison/yacc before):
> >
> > expr_without_variable:
> > /* ... */
> > |   expr '{' inline_set_properties '}'
> > ;
> >
> > inline_set_properties:
> > /* empty */
> > |   identifier '=' expr
> > |   identifier '=' expr ',' inline_set_properties
> > ;
> >
> >
> > (Although I think that would conflict with the alternative $var{8} syntax
> > for array/string offset.)
> >
> > Has this been explored before? What problems can you foresee 

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[guilhermebla...@gmail.com]

Joe, I fixed a minor typo in the RFC, hope you didn't mind. =)

On Fri, May 20, 2016 at 5:25 AM, Lester Caine  wrote:

> On 20/05/16 07:05, Joe Watkins wrote:
> > Morning internals,
> >
> > Since we have our answer on nullable types, typed properties can now
> go
> > to vote.
> >
> > https://wiki.php.net/rfc/typed-properties#vote
> >
> > Note that, support for nullability as RFC'd will be merged when the
> > implementation for nullable_types is merged into master.
>
> I have just realised exactly why I have a problem with most of this ...
> Domain! Used as an 'OtherThing'
>
> This is ALSO attributes, since an SQL domain defines all of the
> attributes that I need to handle in relation to variables. 'int' on it's
> own does very little since one still needs to add all the other checks,
> but adding 'types' as a properly formatted domain solves all the
> problems I'm looking at ... and leaves plenty of room for others to
> abuse the in their own way?
>
>
> http://www.firebirdsql.org/file/documentation/reference_manuals/fblangref25-en/html/fblangref25-ddl-domn.html
>
> Note such elements as [] to allow for arrays of a datatype
> although that still leaves the handling of mix arrays.
>
> Some of the conditions may seem irreverent, but if the domain is a set
> of keys for an array that logic then makes sense?
>
> I can even see the addition of a 'read only' flag to solve that problem
> while still constraining the initial setting of a domain.
>
> But this is simply user land code and does not need a small subset of
> elements of it added to the code base?
>
> --
> 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
Lead Architect at E-Block

Re: [PHP-DEV] [RFC] Simple Annotations

[guilhermebla...@gmail.com]

@Rasmus: This approach is too broad, allowing situations like Marco pointed
out. I'd have to vote -1 on it too if you move forward, specially if you
consider things like << "How do I grab this?" >> and other weirdness.


@Rowan: Annotations should be immutable by nature. Still, I would love if
you can detail (in the context of your example) what should be the output
in the following examples:

<>
function foo(int $percentage) {
$reflection = new \ReflectionFunction(__FUNCTION__);

var_dump($reflection->getAnnotations()); // #2
}


$reflection = new \ReflectionFunction("foo");

var_dump($reflection->getAnnotations()); // #1

foo(10);

When executing the code, what should I expect from #1 and #2? I can foresee
that #1 should crash (?) or should it return an ast\node or what?
It all sounds reasonable on #2 what everyone is heavily forcing/suggesting
because of DbC, but it *only* makes sense in the context of a function call
(or a bound object in case of OO members). In any other case its outcome is
unpredictable.




There're 2 potential approaches I can foresee with future for Annotations:

1- This one I see as a simple approach. Take the idea of Dmitry and extend
to support scalars and arrays (only, no objects, no AST\Nodes). Example: <<
Entity(["name" => "User"]) >>
Strings could be easily converted into AST\Nodes internally and DbC would
be possible. Context is inferred at libraries' desire.
Solution here would not have a 1-1 dependency with classes, simplifying the
implementation for meta parameters such as "override", "inherit",
"memoize", "jit", etc.

2- Take an OO approach and correlate 1-1 class. But before that I'd tackle
object initialization first. We'd require to make this to work:

new Foo() {
"property" => "value"
}

After that, we could get back to Annotations and support a subset of PHP
grammar, similar to this:

<< Foo { "property" => "value" } >>


Why I suggest this approach, some may ask? Simple young padawans... We're
already seeing people discuss about final/read-only properties, where they
could only be set at constructor time. We could easily expose this
possibility through scopes. The {} block would be post constructor, but
still in the initialization context, allowing sets to happen for read-only
properties. It's a smart solution against adding a long list of constructor
arguments (and handling default values for each one) and also a nice
alternative to "named parameters".
However, this approach would still require a 1-1 dependency with classes,
which would make "override", "inherit", "jit" a PITA, and likely empower a
more robust annotation solution (like defining which class can be an
annotation and what cannot, or specify annotation target, like class,
method, property, etc).


PS: I hate to write long emails... =(

Cheers,

On Tue, May 17, 2016 at 11:28 AM, Rowan Collins 
wrote:

> On 17/05/2016 15:22, Rasmus Schultz wrote:
>
>> The other issue is the dependency (context) injection example - no one
>> seems to be able to cite an actual use-case, and if that's the case, I
>> should probably just remove it from the RFC entirely?
>>
>> @Larry can you think of a case example in the myriad annotations
>> you've seen in Drupal code? :-)
>>
>> Anyone else using Doctrine Annotations actually seen anyone making use
>> of a closure in an annotation?
>>
>
> Possibly nobody's responded to your call for an example because they're
> not sure what it is you're asking for an example of. I don't really
> understand what closures have to do with annotations, or how that relates
> to capturing context.
>
> An example from the other thread of a context-bound annotation would be
> implementing validation like this:
>
> <>
> function foo(int $percentage)
>
>
> This would appear to be unsupported as such by your proposal, so you would
> instead just have to use strings to represent how it needed to be accessed:
>
> <>
>
> and then have extra machinery in the reflection logic to extract the
> parameters and pass them to the object, e.g.
> $annotation->validate($reflected_parameters)
>
>
> This might be the more sensible approach to such an annotation anyway, but
> without any access to variables, I don't really understand the value of
> evaluating an expression for the annotation, just to get a constant value
> that is cached by the Reflection infrastructure.
>
> If the expression would have to be made up entirely of constants anyway,
> might the same "constant expressions" used in class const definitions be a
> better fit than "any valid PHP expression" - plus a specific exception for
> creating objects out of those constant expressions.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Guilherme Blanco
Lead Architect at E-Block

[PHP-DEV] Assess acceptability of having php-ds into core

[guilhermebla...@gmail.com]

Hi internals,

PHP 7 leverages a lot the performance internally and many PHP applications
in the wild. Much of these improvement came by experimentation through
PHPNG and the usage of efficient data structures internally. This idea of
performance improvements are crucial to handle more requests, reduce server
overload, etc.

However, what lacks in PHP is the exposure of more efficient, use case
specific data structures, that could allow end users to easily improve
performance of their applications, instead of using a general,
multi-purpose data structure that we have as "array".

Based on that (please keep in mind I haven't spoken with library author),
I'd like assess the receptability of incorporating php-ds library into core.

Library author wrote a good (and lengthy) article explaining his motivation
and performance benchmarks around it. Here are the related links:

Article:
https://medium.com/@rtheunissen/efficient-data-structures-for-php-7-9dda7af674cd
Extension: https://github.com/php-ds/extension
Polyfill: https://github.com/php-ds/polyfill
Tests: https://github.com/php-ds/tests
Benchmark: https://github.com/php-ds/benchmarks


Best regards,

-- 
Guilherme Blanco
Lead Architect at E-Block

Re: [PHP-DEV] PHP Attributes -> docBloc alternatives ...

[guilhermebla...@gmail.com]

Lester,

I understand that IDEs are doing a nice job over the toolset already
created around documentation. That's what phpdoc and friends do.
Also, if you take PHPStorm, it also helps you add Doctrine annotations with
ease. But this is just one IDE, and that's what they're supposed to do;
help developers to code faster with fewer keystrokes.

All docblock annotations support, such as PHPUnit, Doctrine, Addendum,
php-annotations, etc (but with the except of documentation frameworks, like
Doxygen, phpdoc, etc) were created to address a lack of support in the
language itself. Doctrine didn't want to start an Annotations project if
the language already supported, and we even attempted to add this support
to the language back in 2010, which got rejected.

Now time flies and annotation frameworks have mature enough that multiple
codebases are relying on them to help with very day problems, such as
validation, which is what you're referring. phpDocumentor is a purely
strict documentation framework, and that's why it doesn't provide
validation support.

In any case, the usage of docblock for annotations is very bad because it's
extremely error prone. IDEs are helping users, providing autocomplete, but
nothing better than a native language support to validate your annotation
input. Also, there is a fundamental problem of taking docblocks as the rule
to thumb for annotations. Most people just blindly ignore it, but at least
Doctrine team already had to handle this problem educating users multiple
times.

In PHP, to create a docblock you have to start with /** and end with */;
anything inside is considered as text. We also know that most people align
the docblock lines with an idented *. Now to illustrate the problem I want
to provide a mathematical operation *. Here is a sample docblock:

/**
 * @Some\Annotation(5 * 8)
 */

This is easily understood as a quick operation of 5 * 8. However, look at
the next example:

/**
 * @Some\Annotation(5
 * 8)
 */

Or this one:

/**
 * @Some\Annotation(5
 * *
 * 8)
 */

While this might not sound clear, but the docblock parse would have to
consider either the second example or the third example invalid. If you
consider that user must not add a *, then second example is 5 * 8, while
third is 5 * * 8, which is wrong.

Things get a little more tricky when you consider multiline strings. A
couple examples:

/**
 * @Some\Annotation("This
 * is a
 * multiline string")
 */

/**
 * @Some\Annotation("This
 *  is a
 * multiline string")
 */

/**
 @Some\Annotation("This
is a
multiline string")
 */

/**
 * @Some\Annotation("The result of 5
 * 8 is 40")
 */

Assuming I'm removing the new line of all examples now, just to reduce
email size and more clarity...

The first example is "This is a multiline string" or "This * is a *
multiline string"?
Let's say we also add more tricks in the parser (like Doctrine did) to
ignore idented * + 1 space. In second example, is it "This is a multiline
string" or "This   is a  multiline string". Did you notice that now the
spaces now inside of this string in the dockblock may/might matter?
In the third example it is basically what I highlighted on first one... "The
result of 5 * 8 is 40" or "The result of 5 8 is 40"?

Dockblock parsing is hard, unpredictable and may generate a lot of edge
cases. It's just not worth trying to determine all possible conditions
users may face.

Regards,


On Fri, Apr 29, 2016 at 11:18 AM, Lester Caine  wrote:

> On 29/04/16 14:51, Rowan Collins wrote:
> > Lester Caine wrote on 29/04/2016 14:18:
> >> But where will annotations like @range(0,110) fit in the new model?
> >> Along with the likes of '@notnull' and similar annotations that are also
> >> currently being planned to be spread around the rest of the code? If a
> >> variable is defined via the metadata as 'not null', then assigning null
> >> to it is an error
> >
> > Hi Lester,
> >
> > Do you mean you are currently using these attributes / annotations with
> > a reflection library to generate assertions in the code and throw errors
> > at runtime? If so, yes, the native syntax will be used for that going
> > forward, once the tools catch up (though they're likely to provide
> > backwards compatibility modes for a fairly long time).
>
> I think that is part of the problem here. IDE's are currently making
> quite good use of existing annotation text, but if they have to be
> switched to modes where some other option takes priority then once again
> all the code has to be reworked ... which is where I'm stuck at the moment.
>
> > However, there's no support built into the core for doing the actual
> > checks now, and there's no plan (that I know of) to build one in in
> > future. All that's proposed is to add more support in the language for a
> > general syntax which can be used by such tools, to avoid them doing so
> > much string parsing.
> >
> > If you're just using these annotations for documentation (as your
> > references to phpDocumentor imply), 

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

[guilhermebla...@gmail.com]

Sorry for top-posting... it looks like GMail top-posts everything that
doesn't have a reply character right before the inherited (replied email),
which i just did.

On Fri, Apr 29, 2016 at 10:26 AM, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:

>
>
> On Fri, Apr 29, 2016 at 4:55 AM, Jesse Schalken <m...@jesseschalken.com>
> wrote:
>
>>
>>
>> On Wed, Apr 27, 2016 at 6:50 AM, guilhermebla...@gmail.com <
>> guilhermebla...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> Yesterday I spent a considerable 2h talking about Generics in Doctrine
>>> channel.
>>> We discussed the specifics of each boundary that PHP's implementation
>>> could
>>> take advantage. Here are our findings, which I'll illustrate using Java
>>> equivalents:
>>>
>>> 1- Upper bounds (T extends A)
>>>
>>> We all understood they're required. Whenever you mention class Foo>> A>
>>> {}, we're talking that T can be A or any of its subtypes.
>>> Also, we debated over intersection types. It's an edge case, and its
>>> support could be done as a subsequent RFC once union and intersection
>>> types
>>> gets resolved.
>>>
>>> 2- Lower bounds (T super A)
>>>
>>> It was just not possible to come up with a single use case or
>>> possibility.
>>> It not only violates Liskov, but it also doesn't make any sense in the
>>> context of PHP.
>>> When we debate about Java, it does make sense because of polymorphism and
>>> the requirement removal of implementing multiple methods.
>>>
>>> 3- Unbounded wildcards (?)
>>>
>>> It wouldn't be necessary in the context of PHP. Why?
>>> Once we introduce Generics, the difference between process(List $list)
>>> and
>>> process(List $list) would be none, as due to PHP's nature.
>>>
>>> 4- Upper bounded wildcard (? extends A)
>>>
>>> Again, invalid in the context of PHP. Let me explain why...
>>> In Java context, whenever you declare something as List, you can only
>>> add As to the list, but no subtypes. When you declare List,
>>> you can add A and also any of its subtypes.
>>> PHP is loose in this restriction, so there's no way of strict-ing to
>>> only A
>>> but not subtypes. Defining as List would be enough, and PHP wouldn't
>>> support adding A and A only.
>>>
>>
>>
>> You can add subtypes of A to a List in Java. What List
>> means is that the list itself may be a list of any type, provided that type
>> is compatible with A. So if B extends A, List is compatible with List> extends A>, and when reading items you can assume they will be compatible
>> with A (since B extends A) but you can't add an A (because it's actually a
>> list of Bs).
>>
>>
> Wrong. This is documented here
> https://docs.oracle.com/javase/tutorial/java/generics/upperBounded.html
> and specifically states:
>
> To write the method that works on lists of Number and the subtypes of
>> Number, such as Integer, Double, and Float, you would specify List> extends Number>. The term List is more restrictive than List> extends Number> because the former matches a list of type Number only,
>> whereas the latter matches a list of type Number or any of its
>> subclasses.
>
>
>
>
>> Similarly, List means it may be a list of A or some super type
>> of A. So if A extends C, List is compatible with List, and
>> you can add an A (because A is compatible with C) but when reading items
>> you can't assume they're going to be As (because it's actually a list of
>> Cs).
>>
>>
> Again wrong. The lower bound also respect the rules of upper bound
> wildcard. If you return a List, you cannot add an A instance.
>
>
>> This is my understanding of variance behaviour and notation in the three
>> languages I'm most familiar with:
>>
>> Covariance (Foo is a subtype of Foo)
>>
>> Java  Foo at usage  Methods accepting T as parameter cannot
>> be called
>> Hack  Foo<+T> at declaration Methods accepting T as parameter cannot
>> be defined
>> C#Foo at declaration  Methods accepting T as parameter cannot
>> be defined
>>
>>
>> Contravariance (Foo is a subtype of Foo)
>>
>> Java  Foo at usage   Methods returning T can be called but
>> return Object
>> Hack  Foo<-T> at declarationMethods returning T cannot be defined
>> C#Foo at declaration  Methods returning T cannot be defined
>>
>>
>

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

[guilhermebla...@gmail.com]

On Fri, Apr 29, 2016 at 4:55 AM, Jesse Schalken <m...@jesseschalken.com>
wrote:

>
>
> On Wed, Apr 27, 2016 at 6:50 AM, guilhermebla...@gmail.com <
> guilhermebla...@gmail.com> wrote:
>
>> Hi all,
>>
>> Yesterday I spent a considerable 2h talking about Generics in Doctrine
>> channel.
>> We discussed the specifics of each boundary that PHP's implementation
>> could
>> take advantage. Here are our findings, which I'll illustrate using Java
>> equivalents:
>>
>> 1- Upper bounds (T extends A)
>>
>> We all understood they're required. Whenever you mention class Foo
>> {}, we're talking that T can be A or any of its subtypes.
>> Also, we debated over intersection types. It's an edge case, and its
>> support could be done as a subsequent RFC once union and intersection
>> types
>> gets resolved.
>>
>> 2- Lower bounds (T super A)
>>
>> It was just not possible to come up with a single use case or possibility.
>> It not only violates Liskov, but it also doesn't make any sense in the
>> context of PHP.
>> When we debate about Java, it does make sense because of polymorphism and
>> the requirement removal of implementing multiple methods.
>>
>> 3- Unbounded wildcards (?)
>>
>> It wouldn't be necessary in the context of PHP. Why?
>> Once we introduce Generics, the difference between process(List $list) and
>> process(List $list) would be none, as due to PHP's nature.
>>
>> 4- Upper bounded wildcard (? extends A)
>>
>> Again, invalid in the context of PHP. Let me explain why...
>> In Java context, whenever you declare something as List, you can only
>> add As to the list, but no subtypes. When you declare List,
>> you can add A and also any of its subtypes.
>> PHP is loose in this restriction, so there's no way of strict-ing to only
>> A
>> but not subtypes. Defining as List would be enough, and PHP wouldn't
>> support adding A and A only.
>>
>
>
> You can add subtypes of A to a List in Java. What List
> means is that the list itself may be a list of any type, provided that type
> is compatible with A. So if B extends A, List is compatible with List extends A>, and when reading items you can assume they will be compatible
> with A (since B extends A) but you can't add an A (because it's actually a
> list of Bs).
>
>
Wrong. This is documented here
https://docs.oracle.com/javase/tutorial/java/generics/upperBounded.html and
specifically states:

To write the method that works on lists of Number and the subtypes of Number,
> such as Integer, Double, and Float, you would specify List Number>. The term List is more restrictive than List Number> because the former matches a list of type Number only, whereas
> the latter matches a list of type Number or any of its subclasses.




> Similarly, List means it may be a list of A or some super type
> of A. So if A extends C, List is compatible with List, and
> you can add an A (because A is compatible with C) but when reading items
> you can't assume they're going to be As (because it's actually a list of
> Cs).
>
>
Again wrong. The lower bound also respect the rules of upper bound
wildcard. If you return a List, you cannot add an A instance.


> This is my understanding of variance behaviour and notation in the three
> languages I'm most familiar with:
>
> Covariance (Foo is a subtype of Foo)
>
> Java  Foo at usage  Methods accepting T as parameter cannot
> be called
> Hack  Foo<+T> at declaration Methods accepting T as parameter cannot
> be defined
> C#Foo at declaration  Methods accepting T as parameter cannot
> be defined
>
>
> Contravariance (Foo is a subtype of Foo)
>
> Java  Foo at usage   Methods returning T can be called but
> return Object
> Hack  Foo<-T> at declarationMethods returning T cannot be defined
> C#Foo at declaration  Methods returning T cannot be defined
>
>
> Invariance (no relationship between Foo and Foo)
>
> Java  Foo at usage   Methods accepting T and returning T can
> both be called
> Hack  Foo at declaration Methods accepting T and returning T can
> both be defined
> C#Foo at declaration Methods accepting T and returning T can
> both be defined
>
>
> (There are more general rules for method signatures when T is used as the
> parameter for another generic type, but I can't remember what they are.)
>
> I can't see variance mentioned in the RFC, but when I asked about it when
> the RFC was posted on Reddit, Rasmus said the type parameters would always
> be covariant, so Foo in PHP as an annotation would be equivalent to
> Foo in Java, even though th

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

[guilhermebla...@gmail.com]

Nice!

I've read the RFC and there's only one missing thing that is either
undocumented or missed during patch creation: instanceof.
I'd be amazing if we could do: $foo instanceof Foo & Bar

Cheers,

On Thu, Apr 28, 2016 at 5:00 AM, Josh Di Fabio 
wrote:

> On Thu, Apr 28, 2016 at 4:54 AM, Levi Morrison  wrote:
> > Internals,
> >
> > As alluded to last week I have another RFC for improving the type
> > system: [intersection types][1].
> >
> > It allows parameters to define multiple type constraints that must be
> > satisfied. Common combinations of our built-in types include
> > `ArrayAccess & Traversable & Countable` and `Countable & Iterator`.
> >
> > Some people have suggest I merge this and union types into one RFC.
> > For now I'll just proceed with them separately to gain feedback.
> >
> >   [1]: http://wiki.php.net/rfc/intersection_types
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
> To me, it seems that intersection types are more useful than union
> types (other than the obvious null|Foo and array|Traversable cases) as
> they'd allow us to write smaller interfaces and better follow ISP in
> userland, with interfaces becoming much more convenient for
> documenting the requirements of a parameter.
>
> At present we tend to have incomplete implementations of interfaces
> (e.g. throw OperationNotSupportedException). Union types would allow
> us to create more, smaller interfaces and avoid situations where the
> type of a parameter doesn't accurately reflect the method's true
> requirements, or where concretions are incomplete implementations of
> an interface.
>
> Thanks for your efforts, Levi, I'm excited about this one!
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Guilherme Blanco
Lead Architect at E-Block

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

[guilhermebla...@gmail.com]

Hi all,

Yesterday I spent a considerable 2h talking about Generics in Doctrine
channel.
We discussed the specifics of each boundary that PHP's implementation could
take advantage. Here are our findings, which I'll illustrate using Java
equivalents:

1- Upper bounds (T extends A)

We all understood they're required. Whenever you mention class Foo
{}, we're talking that T can be A or any of its subtypes.
Also, we debated over intersection types. It's an edge case, and its
support could be done as a subsequent RFC once union and intersection types
gets resolved.

2- Lower bounds (T super A)

It was just not possible to come up with a single use case or possibility.
It not only violates Liskov, but it also doesn't make any sense in the
context of PHP.
When we debate about Java, it does make sense because of polymorphism and
the requirement removal of implementing multiple methods.

3- Unbounded wildcards (?)

It wouldn't be necessary in the context of PHP. Why?
Once we introduce Generics, the difference between process(List $list) and
process(List $list) would be none, as due to PHP's nature.

4- Upper bounded wildcard (? extends A)

Again, invalid in the context of PHP. Let me explain why...
In Java context, whenever you declare something as List, you can only
add As to the list, but no subtypes. When you declare List,
you can add A and also any of its subtypes.
PHP is loose in this restriction, so there's no way of strict-ing to only A
but not subtypes. Defining as List would be enough, and PHP wouldn't
support adding A and A only.

5- Lower bounded wildcard (? super A)

Applies the same concept of #2. PHP doesn't need it as it doesn't fully
support polymorphism.

6- Reflection

We discussed over an example I extracted from a piece of code I currently
work on. We came with several ideas, but couldn't wrap up (but we're 80%) a
valid approach. The example we debated was this one:
https://gist.github.com/guilhermeblanco/56ec0e11e7b029c2cfdcaf6fe2323742




So I'll have to say sorry for poking around of "missing implementation"
while in reality most of them cannot be applied in the context of PHP.
I've reviewed the RFC again and it mostly makes sense surrounding
boundaries. I still have to talk about diamond operator and constructor
generic type.


[]s,


On Tue, Apr 26, 2016 at 4:15 PM, Robert Stoll  wrote:

>
>
> > -Ursprüngliche Nachricht-
> > Von: Rasmus Schultz [mailto:ras...@mindplay.dk]
> > Gesendet: Montag, 25. April 2016 18:09
> > An: Josh Di Fabio
> > Cc: Dominic Grostate; Guilherme Blanco; Mathieu Rochette; Ben Scholzen
> 'DASPRiD'; Sara Golemon; PHP internals; Mathieu
> > Rochette
> > Betreff: Re: [PHP-DEV] [RFC:generics]
> >
> > > I really don't like 'as' in this context, even if Hack uses it, as it
> > > doesn't reflect in English terms what the code is doing. As others
> > > have already said, it reads as if 'T' is being aliased to 'Bar'.
> >
> > I second that.
> >
> > I hear the concerns about adding another reserved word "is" though, so
> I'd like to suggest simply using a ":" ... as in:
> >
> > class A { ... }
>
> In this case I would suggest to use class A which leaves room
> open to define lower bounds later on (either with <: as well or with :> as
> in scala)
>
> >
> > Consistent with return type-hints, it should feel like home?
> >
> > For sure nobody wants to type out "instanceof", and (as pointed out in
> the RFC) the instanceof operator checks the type of
> > an object, which is *not* what this is doing - a type argument is not an
> "instance of" anything. The ":" is more neutral in that
> > regard maybe?
> >
> >
> > On Thu, Apr 21, 2016 at 10:32 AM, Josh Di Fabio 
> wrote:
> > > On Wed, Apr 20, 2016 at 8:17 PM, Dominic Grostate
> > >  wrote:
> > >> Thanks for you're input everyone.
> > >>
> > >> So far, we have read some ideas for handling upper bounds, or
> > >> multiple there of.
> > >> The preferred keywords appear to be either "as" or "instanceof".
> > >>
> > >> class Foo {}
> > >> class Foo {}
> > >>
> > >> We would like to know for sure then if everyone is largely against
> > >> the addition of an "is" keyword, in favour of one of the other two.
> > >>
> > >
> > > I really don't like 'as' in this context, even if Hack uses it, as it
> > > doesn't reflect in English terms what the code is doing. As others
> > > have already said, it reads as if 'T' is being aliased to 'Bar'.
> > >
> > > On Wed, Apr 20, 2016 at 8:17 PM, Dominic Grostate
> > >  wrote:
> > >> Thanks for you're input everyone.
> > >>
> > >> So far, we have read some ideas for handling upper bounds, or
> > >> multiple there of.
> > >> The preferred keywords appear to be either "as" or "instanceof".
> > >>
> > >> class Foo {}
> > >> class Foo {}
> > >>
> > >> We would like to know for sure then if everyone is largely against
> > >> the addition of an "is" keyword, in favour of one of the other two.
> > >>
> > >> 

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

[guilhermebla...@gmail.com]

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

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

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

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

[guilhermebla...@gmail.com]

On Mon, Apr 25, 2016 at 3:42 AM, Dmitry Stogov <dmi...@zend.com> wrote:

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

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

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

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

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

[guilhermebla...@gmail.com]

On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov <dmi...@zend.com> wrote:

>
>
> On 04/22/2016 04:05 AM, guilhermebla...@gmail.com wrote:
>
> Hi Dmitry,
>
> As a previous suggester of metadata information built-in into PHP, and
> also one of developers of the most used metadata library written in PHP, I
> understand this feature implementation requires several design decisions
> and also a good understanding of specific situations users may require.
>
> While I am a strong supporter of a more robust solution, this is already a
> good start.
> A few things I'd like to ask for my own understanding and also suggestions
> too:
>
> 1- I understand you took a minimalistic approach towards a "dumb"
> implementation for attributes (when I mean "dumb", the idea here is towards
> a non-OO approach). Can you explain your motivations towards this approach?
>
> I see two distinct approaches of implementation for this feature. Both of
> them have some common demands, like lazy initialization of metadata. Here
> they are:
>
> - Simplistic approach, which lets consumers of the feature do all the work
> related to validation, assertion of valid keys, values, etc
> This does not invalidate the ability to leverage of some features that a
> more robust implementation demands.
>
> - Robust approach: language takes the burden of instantiating complex
> structures, validating, assertion of valid keys, values, if this complex
> structure is allowed to be instantiated in that given class, method, etc.
>
>
> I didn't exactly understand what do you suggest.
> If you are talking about Attribute objects initialization during
> compilation - this is just not possible from implementation point of view.
> Now attributes may be stored in opcache SHM and relive request boundary.
> Objects can't relive requests.
>


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

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

So basically in this example:

use Doctrine\ORM;

<<ORM\Entity("user")>>
class User {}

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

We'd be changing from this:

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

Into this:

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


>
> 1- Your approach is basically defining an array. Could you explain your
> line of thinking on why you didn't consider a syntax like the one below?
>
> <["key" => "value"]>
> class Foo {}
>
> I didn't try to invite new syntax. Just completely took it from HHVM.
>

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


>
>
>
> 2- I see that you added support over functions, classes, constants and
> properties. According to the RFC, getAttributes() was added over
> ReflectionFunction. Is there a reason why support was not added to methods
> (ReflectionMethod extends ReflectionFunctionAbstract, which was not
> mentioned on RFC)? Any reason to not support it in function/method
> parameters?
>
> ReflectionMethod is a child of ReflectinFunction, so it's supported.
>
Attributes are allowed for the same entities as doc-comments (they are not
> allowed for parameters)
>

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

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

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

var_dump($reflParameter->getAttributes());


>
>
>
> 3- Did you put any thought on inheritance? What I mentioned in comment #1
> is even smaller than what you implemented in RFC.
> Assuming you keep the RFC approach, did you consider support overrides,
> inherit, etc?
>
>
> In my opinion,

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

[guilhermebla...@gmail.com]

Hi Dmitry,

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

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

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

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

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

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

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

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

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

3- Did you put any thought on inheritance? What I mentioned in comment #1
is even smaller than what you implemented in RFC.
Assuming you keep the RFC approach, did you consider support overrides,
inherit, etc?

4- I understand that a more robust attribute solution would be required to
achieve this, but one of the biggest advantages of AOP is the ability to
perform custom logic before, after or around... However, I don't know if
any kind of triggers came in your head or are planned as a future RFC.
Let me highlight one example: Every time a class, property or method is
called that is annotated as <>, I would like to issue an
E_USER_DEPRECATED warning. A trigger-like solution would be required. Did
this concept came to your mind?



Regards,

On Thu, Apr 21, 2016 at 7:44 PM, Dmitry Stogov  wrote:

>
>
> On 04/22/2016 02:16 AM, Dominic Grostate wrote:
>
>>
>> This is amazing.  It would actually allow us to implement our automated
>> assertions ourselves, as opposed to requiring it within the language.
>>
>> this was the idea - to give a good tool instead of implementing every
> possible use-case in the language.
>
> Could it also support references?
>>
>> <>
>> function foo($a) {
>>
>> }
>>
>> yes. "&$a" is a valid PHP expression.
>
> If you plan to use this, I would appreciate, if you to build the patched
> PHP and try it.
> The early we find problems the better feature we will get at the end.
>
> Thanks. Dmitry.
>
>
> On 21 Apr 2016 10:13 p.m., "Dmitry Stogov"  dmi...@zend.com>> wrote:
>>
>> Hi,
>>
>>
>> I would like to present an RFC proposing support for native
>> annotation.
>>
>> The naming, syntax and behavior are mostly influenced by HHVM
>> Hack, but not exactly the same.
>>
>> The most interesting difference is an ability to use arbitrary PHP
>> expressions as attribute values.
>>
>> These expressions are not evaluated, but stored as Abstract Syntax
>> Trees, and later may be accessed (node by node) in PHP extensions,
>> preprocessors and PHP scripts their selves. I think this ability
>> may be useful for "Design By Contract", other formal verification
>> systems, Aspect Oriented Programming, etc
>>
>>
>> https://wiki.php.net/rfc/attributes
>>
>>
>> Note that this approach is going to be native, in contrast to
>> doc-comment approach that uses not well defined syntax, and even
>> not parsed by PHP itself.
>>
>>
>> Additional ideas, endorsement and criticism are welcome.
>>
>>
>> Thanks. Dmitry.
>>
>>
>


-- 
Guilherme Blanco
Lead Architect at E-Block

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

[guilhermebla...@gmail.com]

I see that some of you are confusing union types with intersecting types
here. The idea is not an OR, but an AND.
I'll repeat the same example again to try to exemplify what I mentioned:

class AA {}
interface B {}
interface C {}
class BB extends AA implements B {}
class CC extends AA implements B, C {}

class Foo {}
class Bar {}

Class Foo means an intersecting type, where only class CC is applicable
there. Class Bar means a union type, whee both AA, BB and CC are applicable.

I understand others mentioned we could create a new interface that wraps
the other two interfaces, but that still doesn't solve the problem where I
want to extend a class AND also implement a specific interface.
Surely this can be a subsequent RFC, but I see that as a deficiency of the
currently proposed one and consider it incomplete. What happens if the
initial one get approved but it is too late to propose the subsequent one?
Then PHP 7.1 would be released with a partial implementation and not fully
featured as it should.


Regards,


On Wed, Apr 20, 2016 at 11:18 PM, Jesse Schalken 
wrote:

> On Thu, Apr 21, 2016 at 8:56 AM, Rowan Collins 
> wrote:
> >
> > I'm not quite sure what bounds would mean for anything other than classes
> > or interfaces. A generic type that specified that its type parameter must
> > be an int seems to me to be a non-generic type, because nothing other
> than
> > an int "is int". How is "class Foo { public function
> > __construct(T $arg) { ... } }" different from just saying "class Foo {
> > public function __construct(int $arg) { ... } }"? (Unless there were some
> > kind of overloading, such that you could also have Foo, but
> > please let's not go there...)
> >
>
> Sticking with your example for a moment, if the type parameter is an "int",
> then the only type that can *currently* be expressed in the type language
> that is a subtype of "int" is "int", so it's not very useful *right now*.
> However, a possible introduction of integer literal types would change
> that, especially in combination with unions. This would enable you to
> express the type "1|2|3", i.e. only one of those three integers. This would
> be useful to typecheck enums, which are typically an "int" or "string"
> which only accepts a finite set of values. As such, the type parameter "T
> is int" could be filled with "int" or "1" or "0|1|2". (Imagine a class
> "Bar" and various subclasses which each must select a single
> integer as kind of tag, "Foo extends Bar<1>", "Baz extends Bar<2>" etc. I
> do this in TypeScript with string literal types all the time.)
>
> Beside from that, the introduction of any one of union types, intersection
> types, generic array types or callable types would mean the type constraint
> for a generic type can usefully be something besides a single
> class/interface. For example, if "" were written
> "" I would expect to be able to do "$t
> instanceof array|Traversable", but I wouldn't be able to unless
> "instanceof" is intended to and is extended to support arbitrary types.
>
> Note that generic arrays are out of scope of the current RFC anyway, so
> > it's possible that "$t instanceof array" could be added at the same
> > time as "Foo>", presumably with the meaning that
> > "array" would be considered to pass the check.
> >
> > Regards,
> >
> > --
> > Rowan Collins
> > [IMSoP]
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>



-- 
Guilherme Blanco
Lead Architect at E-Block

Re: [PHP-DEV] Quick sanity check ...

[guilhermebla...@gmail.com]

The question here is how type strictness would benefit the language.
I agree with you on most parts. But still... if the class was declared like
this:

class CancelOutdatedOrdersDTO {
public int $olderThan;
}

Wouldn't that be solved entirely? Code would crash (through a TypeError),
it would never be pushed to production and we would never have experienced
this problem.


PS: I just gave one example... we didn't actually loose 100k, but I had to
spend an hour manually addressing the sales back to pending status.

Regards,

On Wed, Apr 20, 2016 at 4:01 PM, Stanislav Malyshev 
wrote:

> Hi!
>
> > The outcome is easy to grasp. Because it did not crash by a TypeError
> > (which would also require the file to be declared as strict), and we lost
> > 100k in sales. But PHP does not need more strictness...
>
> In other words, somebody wrote code that is supposed to only accept ints
> but does no checks. Somebody wrote tests that actually don't test
> anything. Somebody signed off on code that was not properly designed or
> tested to go into production. And the language is to blame. Right.
>
> --
> Stas Malyshev
> smalys...@gmail.com
>



-- 
Guilherme Blanco
Lead Architect at E-Block

Re: [PHP-DEV] Quick sanity check ...

[guilhermebla...@gmail.com]

I might answer you by given a scenario that happened this week here at work.

Because our non-broken language relies on a loose type system, a developer
of my company wrote a property that accepts null, int, string, object,
whatever as a property.

This property was declared in a class that is used in a console command
that runs weekly. This property was supposed to hold an integer (value in
hours) that would calculate a difference in time and cancel prospected
purchases older than this variable hours. All unit tests passed, because
they inspect the parts not the whole. By mistake, the developer forgot to
provide a value.
Nothing was reported in PHP because the language is not broken, and because
there's no final and no typed property, no error was reported and code
proceed execution. That value that was not initialized and got assigned as
null. This value was then converted to 0, and all purchases older than "now
- 0 hours" got cancelled.

The outcome is easy to grasp. Because it did not crash by a TypeError
(which would also require the file to be declared as strict), and we lost
100k in sales. But PHP does not need more strictness...


Regards,


On Wed, Apr 20, 2016 at 3:22 PM, Lester Caine  wrote:

> With all of the debate on the 'type system', can I just ask a probably
> silly question ;)
>
> I'm currently working on porting an application that has been running on
> windows as C++ code for 20 years. The main reason for changing is that
> While it worked fine when sites upgraded to XP, the move to W7 and later
> really needs all the code recompiled, something that will need a big
> cheque book to buy a current compiler set. So for many reasons a switch
> to web based using already existing tools makes perfect sense.
>
> The database is still running Firebird since the switch from interbase
> in the late 90's so all of the existing data can be maintained, and I
> already have a working base on which to build a new set of page
> templates. ( Only hole is the need for a decent javascript scheduler
> function to replace the desktop one :( )
>
> This is all running on SQL based schema's which have not changed in
> years, and ADOdb still quite happily produces arrays of results for
> which there is little point creating new 'objects', just simply handling
> the basic variable entries in the arrays just as I have for years. The
> various tools handle data validation, and 'null' is an essential
> component of that validation process. This does not need any of the
> overload of creating 'getters and setters' and I see little point trying
> to add any 'type' casting into the process since the validation layer
> simply works with the bog standard variables without and need for
> 'special cases'.
>
> So what benefit does all of the additional 'facilities' now being piled
> on give that would actually improve that process. I am now seeing a
> speed improvement on the PHP7 ports, but I'm not seeing any point to
> make any changes to code OTHER than making the PHP5.2 code clean on PHP7
> ... As Zeev has already said "PHP is not broken" ... Do I really need to
> change the way I work which is running fine for my clients?
>
> --
> 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
Lead Architect at E-Block

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

[guilhermebla...@gmail.com]

PHP lacks of enterprise engineering over the language, and that is the
problem. You're not resolving the holism in the language, but rather a
specific part without consider the whole.

Yes, it makes sense to support ?Foo for and only for return types, but what
about everything else? What about future scope? Sure, future scope is
unknown, but we do have scope that is currently being defined, you're even
debating over it and it'll severely impacted by this small little support
that we're adopting right now only for this specific case.

The problem of not thinking in the language as a whole and just fixing
small bits every time lead to the inconsistency hell we live today. So
please, step back and look over that introducing this tiny language
enhancement will impact final properties, typed properties and add a
language inconsistency with already defined standard (instanced may be
absent of value like in function parameters). If you don't think what I'm
saying is true, look at return type hint and how you define parameter type
hint. And with typed properties (as the patch currently stands), it will
follow parameter type hint instead of return type hint.


Regards,

On Wed, Apr 20, 2016 at 12:13 PM, Dmitry Stogov <dmi...@zend.com> wrote:

> What we really miss now, is an ability to define nullable return types.
>
>
> https://wiki.php.net/rfc/nullable_return_types
>
>
> I don't care about the same notations for arguments (and everything else),
> because we already may use NULL default value.
>
> However usage of "?" for arguments also may make sense. Someone may like
> this, someone not.
>
>
> Thanks. Dmitry.
>
> ------
> *From:* guilhermebla...@gmail.com <guilhermebla...@gmail.com>
> *Sent:* Wednesday, April 20, 2016 18:05
> *To:* Lin Yo-An
> *Cc:* Dmitry Stogov; Tom Worster; internals
> *Subject:* Re: [PHP-DEV] [RFC] Nullable Types
>
> I read the RFC and I want to highlight why I'll vote -1 on it even before
> it goes to voting.
>
> IMHO, it looks backwards to what the language is progressing. The
> introduction of nullable type hint as a separate notation than a simple
> type hint makes it *very* hard to implement typed properties, factory
> methods and constructor verifications.
>
> Dmitry is even involved in the discussion of having IS_UNDEF until
> constructor ends, then enforcing type hinting at the end of constructor to
> trigger potential invalid instance state. It created a mess in the internal
> structure by creating a 3-state value: uninitialized, absent of value
> (null) and assigned value. All this problem would be solved by merging null
> into accepted value.
> So far the proposed solution there to take a wrong assumption to assume a
> default value based on type defined (like int = 0, string = '', etc), which
> are all potential valid values, leading to unpredictable behavior if a
> develop misses to assign a value to that property.
>
> Sure, people will say that now PHP will require a NullPointerException,
> PHP is turning into Java, or that I don't know what I'm talking about
> because they coded for Amiga and I don't (yes, I've seen that already in
> this mailing list). But the fact is that keeping control of 3-state flags
> are hard to maintain.
>
> Constructor verifications is actually a completely different subject that
> shouldn't be considered as part of typed properties, but for final
> properties (or whoever other keyword someone think is smarter because
> *reasons*). It's bad to bring this already to typed properties, specially
> because of its runtime performance impact.
>
> Now let's say we move forward with nullable type hint, ignore everything
> what I said and move forward. Congratulations, we just created a language
> inconsistency. Example:
>
> function foo(Bar $bar = null);
>
> Why now I have 2 ways to define a nullable value? Shouldn't this be
> changed into this:
>
> function foo(?Bar $bar);
>
> But of course, changing this would be a BC break and should be left for
> *reasons*. But accepting the absence of value (null) as a valid value, it
> would address the language inconsistency (the current support would be
> kept, so no BC break), and would solve a huge mess that typed properties
> patch currently needs to solve. Ah, and we don't continue into this path of
> madness where same thing have 144 different ways in different areas to be
> defined.
>
>
> Regards,
>
> On Mon, Apr 18, 2016 at 12:24 PM, Lin Yo-An <cornelius.h...@gmail.com>
> wrote:
>
>> On Mon, Apr 18, 2016 at 4:59 PM, Dmitry Stogov <dmi...@zend.com> wrote:
>>
>> > The grammar is taken from HHVM.
>> > Using any other would make more mess.
>> >
>> I agree
>>
>
>
>
> --
> Guilherme Blanco
> Lead Architect at E-Block
>



-- 
Guilherme Blanco
Lead Architect at E-Block

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

[guilhermebla...@gmail.com]

Sure, the usage of "instanceof" is an alternative to prevent declaring a
new keyword. PHP doesn't have the same problem as Java does to enforce the
first generic type information to be a class and others interfaces. So in
this:

class A {}
interface B {}
interface C {}

class Foo {}

Java required A to be the first due to its compilation process, which PHP
does not have. PHP would accept any order of A, B and C there, like "C & B
".


PS: I like to use Java as a base for Generics because I feel it more well
thought than other language implementations (like .NET and Swift).

Regards,

On Wed, Apr 20, 2016 at 11:01 AM, Rowan Collins <rowan.coll...@gmail.com>
wrote:

> guilhermebla...@gmail.com wrote on 20/04/2016 03:54:
>
>> 1- Even though mentioned, I'd still use "extends" or "implements" instead
>> of "is" (which would be a new pseudo-reserved keyword) to enforce data
>> type
>> consistency and prevent developers to potentially referring to one thing
>> while consider another.
>>
>
> Perhaps "instanceof" would make more sense here? "class FileProcessor extends FileHandle>" seems to exclude instantiating
> FileProcessor, because "FileHandle extends FileHandle" doesn't
> make any sense.
>
> You could read "class Box" as an assertion that the
> class passes the constraint, as in "public function __construct(T $t) {
> assert($t instanceof Boxable); }"
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Guilherme Blanco
Lead Architect at E-Block

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

[guilhermebla...@gmail.com]

I read the RFC and I want to highlight why I'll vote -1 on it even before
it goes to voting.

IMHO, it looks backwards to what the language is progressing. The
introduction of nullable type hint as a separate notation than a simple
type hint makes it *very* hard to implement typed properties, factory
methods and constructor verifications.

Dmitry is even involved in the discussion of having IS_UNDEF until
constructor ends, then enforcing type hinting at the end of constructor to
trigger potential invalid instance state. It created a mess in the internal
structure by creating a 3-state value: uninitialized, absent of value
(null) and assigned value. All this problem would be solved by merging null
into accepted value.
So far the proposed solution there to take a wrong assumption to assume a
default value based on type defined (like int = 0, string = '', etc), which
are all potential valid values, leading to unpredictable behavior if a
develop misses to assign a value to that property.

Sure, people will say that now PHP will require a NullPointerException, PHP
is turning into Java, or that I don't know what I'm talking about because
they coded for Amiga and I don't (yes, I've seen that already in this
mailing list). But the fact is that keeping control of 3-state flags are
hard to maintain.

Constructor verifications is actually a completely different subject that
shouldn't be considered as part of typed properties, but for final
properties (or whoever other keyword someone think is smarter because
*reasons*). It's bad to bring this already to typed properties, specially
because of its runtime performance impact.

Now let's say we move forward with nullable type hint, ignore everything
what I said and move forward. Congratulations, we just created a language
inconsistency. Example:

function foo(Bar $bar = null);

Why now I have 2 ways to define a nullable value? Shouldn't this be changed
into this:

function foo(?Bar $bar);

But of course, changing this would be a BC break and should be left for
*reasons*. But accepting the absence of value (null) as a valid value, it
would address the language inconsistency (the current support would be
kept, so no BC break), and would solve a huge mess that typed properties
patch currently needs to solve. Ah, and we don't continue into this path of
madness where same thing have 144 different ways in different areas to be
defined.


Regards,

On Mon, Apr 18, 2016 at 12:24 PM, Lin Yo-An 
wrote:

> On Mon, Apr 18, 2016 at 4:59 PM, Dmitry Stogov  wrote:
>
> > The grammar is taken from HHVM.
> > Using any other would make more mess.
> >
> I agree
>



-- 
Guilherme Blanco
Lead Architect at E-Block

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

[guilhermebla...@gmail.com]

I don't know if mid-thread answering may lead to top-posting, but if it
does, I'm sorry... =\

Answer inline:

On Wed, Apr 20, 2016 at 5:10 AM, Dominic Grostate <
codekest...@googlemail.com> wrote:

> I've made an amendment to the RFC to clarify on the Nested Types, which is
> indeed supposed to be part of the feature.  Rasmus may want to reword it if
> it isn't very clear.
>
> Regarding union and intersections for upper (and maybe lower) bounds.
> Would it be appropriate to exclude these from type parameters until their
> respective RFCs are approved?  As including them in generics but not in
> standard type hints may create an inconsistency.
>
> In short, perhaps a generics implementation should incorporate unions (and
> any future type constraints) as existing features only.  This would help
> RFC Generics to focus on: Type aliasing, Introspection and Reflection.
>

Unions and Intersections are required anyway, and I don't see how you can
implement generics without supporting them.
Let's say I'm implementing a cache library that segregate the interface of
BulkOperations from the basic operations named CacheDriver.
In a given class, I might want to only accept CacheDrivers that also
support BulkOperations. How would I achieve that?

The same happens to upper bounds that someone asked for an example
privately.
If I want to hire/move a person to a department that is registered in the
system, but is not a 3rd party company person, how would you achieve that
considering the following class structure?

class Person {}
class Employee extends Person {}
class AssociateEmployee extends Employee {}
class Manager extends Employee {}

Considering your function:

function assignToDepartment(T $person) : bool;

Generic type "T" in the function prototype needs to accept Person (new
hire), Employee and Manager (transfer), but not AssociateEmployee.
Considering upper bounds support only, your best bet is "T extends Person",
but that would accept AssociateEmployee to be provided, which contradicts
the business rule. Accepting anything lower in the hierarchy prevents new
hires.
That's when lower bounds comes into play. If you define as "T super Manager",
all Person, Employee and Manager gets accepted, but not the
AssociatedEmployee, matching properly the business rule.


Also, someone else asked about type inference over my comment #4 in this
example:

class Foo {
public function __construct(B $b) {}
}

$foo = new Foo(1);

The question asked is if that "string" was an inference over A or B. The
correct answer is A, because generic type B is inferred from the parameter
(integer) provided. That is exactly why class generic type definition
should never be inferred from the constructor arguments, because you make
it impossible to support both constructor generic types AND class generic
type definitions at the same time.



> On 20 Apr 2016 9:05 a.m., "Mathieu Rochette"  wrote:
>
> >
> >
> > On 20/04/2016 00:22, Sara Golemon wrote:
> >
> >> On Tue, Apr 19, 2016 at 1:16 PM, Mathieu Rochette  >
> >> wrote:
> >>
> >>> about the upper bounds, have you consider another way of describing the
> >>> constraints, eg:
> >>>
> >>> class Box where T is Boxable
> >>>
> >>> this would allow multiple constraints, eg:
> >>>
> >>> class Collection where T is Traversable, T is Countable
> >>>
> >>> IMO, this sort of problem should be solved by combining this feature
> >> with union types, so you could have something like:
> >>
> >> class Collection {...
> >>
> >> And merely inherit the logic rules from that feature rather than
> >> inventing yet another one.
> >>
> > obviously if the union type rfc passes we don't need another way of
> > expressing this.
> > that was only in the case it does not, I think having a way to have at
> > least types intersection
> > is useful here (and I didn't event think about )
> >
> >>
> >> can generic types be nested ?
> >>>
> >>> class Stuff>
> >>>
> >>> I can't imagine why not...
> >>
> > just to be clear, it's not just nested generic. the A type have to be
> same
> > in both "subtypes"
> >
> >>
> >> For my part, I love the concept overall.  Generics are an important
> >> part of moving PHP towards comprehensive type-safety.  But then, you
> >> know how I feel about Hack. :)
> >>
> >> -Sara
> >>
> >>
> >
>



-- 
Guilherme Blanco
Lead Architect at E-Block

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

[guilhermebla...@gmail.com]

Hi,

Here are a couple of comments towards Generics support to PHP.

1- Even though mentioned, I'd still use "extends" or "implements" instead
of "is" (which would be a new pseudo-reserved keyword) to enforce data type
consistency and prevent developers to potentially referring to one thing
while consider another.


2- I'd avoid blindly inferring generic type using constructor without
notifying the user about this being a generic class. I'd still prefer a
diamond operator <> to be used. This would be specially valid if we ever
decide to merge typed properties too. Example:

class Foo {
private Bar bar;

public function __construct() {
$this->bar = new Bar<>("Hello World"); // Can be omitted because of
typed properties already defined it
}
}


3- I didn't see any description related to nested generic type definition.
I hope it is supported. Example:

$pair = new Tuple>();


4- Another thing not mentioned in the RFC is if constructor also support
generic typing, like this:

class Foo {
public function __construct(B $b) {}
}

$foo = new Foo(1);


5- Java provides an enforcement that you can specify multiple bounds.
Imagine a class that contains a generic that that must extend class A, but
also implement interfaces B and C. We'd enter in a language recognition
problem if we take the same approach as class declaration as definition,
such as: class Foo
In order to properly solve this, Java takes the approach of &, and require
the class to be first and interfaces later, like this: class Foo. As I already mentioned in comment #1, we should stick to
extends and implements, but adopt & as multiple interface implementation,
like this:

class Foo {}


6- This could be an independent RFC, but ideally we should support generic
typed arrays using the [] syntax, like this:

function sortElements(E[] $elements) : E[];


7- Typed returns are also not mentioned in RFC:

function newEntity($id) : E;

$user = newEntity(UUID::v4());


8- RFC only handles upper bound generic types, but no support is mentioned
about lower bound generic types.
An upper bound generic type is when it restricts the unknown type to that
type or one of its inherited types. In RFC this is specified by the "is"
keyword and I suggested to still segregate it to "extends" as highlighted
in comment #1. A lower bound generic type is when it restrict the unknown
type to that type or any of the is parent types. I'd suggest to use
"parent", "parents", "parentof" or "super". Example:

class A {}
class B extends A {}
class C extends A {}
class D extends B {}

class Foo {} // T can be an instance of A or B but never C or D.


9- Although not clearly clarified in RFC, I saw some inference over
unbounded wildcard types. However, nothing is mentioned about wildcard
upper bound and wildcard lower bounds. A few examples:

// Unbounded wildcard type
function sort(List $list) : void;

// ... how Java (here, PHPized) does it:
function sort(List list) : void;

// Wildcard upper bound in Java (PHPized)
function sortElements(List $list) : void;

// Wildcard lower bound in Java (PHPized)
function addAll(List $list) : void;

There're problems of using the unbounded wildcard generic type, but I think
you may have to dig through Java language specification to better
understand what I'm saying. You can poke me privately and I can point out
documentation that exposes its limitations/constraints.


10- Reflection plays a very important piece in this support and IMHO it
must be documented with proposed API for verification. A link to a gist is
not enough to fully understand what is proposed, so I'm abstaining from
reviewing it until it gets properly mapped out in RFC.


I hope I gave enough insight of what I consider that needs to be expanded
in RFC, expanded in the proposal, highlighted better, etc. Still, this RFC
is the best attempt I've seen towards improving the reusability of data
structures in PHP. Nice work! =)


Regards,

On Tue, Apr 19, 2016 at 9:17 PM, Sara Golemon  wrote:

> On Tue, Apr 19, 2016 at 4:13 PM, Stanislav Malyshev 
> wrote:
> >> class Collection {...
> >
> > I am sorry if this sounds harsh, but I really hope we won't have
> > something like this in PHP. Java templates are complex and weird enough,
> > adding another layer on top of that to allow type expressions IMHO is
> > really taking it too far.
> >
> Nah, I've yet to actually have use for anything so specific yet
> either, but in the context of Mathieu was asking for, it seemed like a
> good moment to direct the concept back to something more consistent,
> at least.
>
> -Sara
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Guilherme Blanco
Lead Architect at E-Block

Re: [PHP-DEV] Trying to fix "use" language inconsistencies

[guilhermebla...@gmail.com]

You missed what I said.
You can do multiple single class/function/constant in a single statement,
but you cannot do multiple group use in a single statement. This:

use Foo\Bar,
Foo\Baz\{Qux, Corge};

Regards,

On Fri, Apr 15, 2016 at 9:38 PM, Lin Yo-An <cornelius.h...@gmail.com> wrote:

> I thought there was one already?
> https://wiki.php.net/rfc/group_use_declarations
>
> On Sat, Apr 16, 2016 at 9:01 AM, guilhermebla...@gmail.com <
> guilhermebla...@gmail.com> wrote:
>
>> Hi internals,
>>
>>
>> It all started with a PR over doctrine/annotations (
>> https://github.com/doctrine/annotations/pull/69), where a contributor
>> decided to propose supporting group use support.
>>
>> The issue starts with this, which it is perfectly supported:
>>
>> use Foo\Bar, Foo\Woo;
>>
>> While multiple group uses are not:
>>
>> use Foo\{Bar, Baz}, Qux\{Corge, Grault};
>>
>> Then I decided to see what is really supported by the newly introduced
>> group use. According to the grammar, these are the same lines:
>>
>> use Foo\Bar, Foo\Baz;
>> use Foo\{Bar, Baz};
>>
>> use function Foo\Bar\baz, Foo\Bar\qux;
>> use function Foo\Bar\{baz, qux};
>> use Foo\Bar\{function baz, function qux};
>>
>> However, this feature leads to an inconsistent behavior in the language.
>> Mixed group use types are supported:
>>
>> use Foo\Bar\{Baz, function qux};
>>
>> While mixing use types are not:
>>
>> use Foo\Bar\Baz, function Foo\Bar\qux;
>>
>>
>> This brings the question of whether we should continue this madness path
>> of
>> inconsistency or we start addressing inconsistencies one by one in the
>> language.
>> I'd like to propose options that we could fix this:
>>
>> - Remove mixed group use types support (this would become invalid: use
>> Foo\{Bar, function baz};)
>> - Add mixed use support, which would contradict the approach took by typed
>> properties (this would require this approach: use function Foo\Bar\baz,
>> function Foo\Bar\qux;)
>>
>> One of the approaches needs to be taken in order to support multiple group
>> use, otherwise we have a reduce/reduce yacc error that can't be fixed
>> (well, my yacc/compiler's knowledge hit a dead end there, without doubling
>> all the grammar rules and taking an overly complex route). Ultimately, the
>> question comes around if we should consider support of multiple group use.
>> If positive, I'd suggest approach two (I already have a patch for that!
>> =D).
>>
>>
>> I'd like to gather opinions around this, so I can properly implement and
>> propose a patch through an RFC process.
>>
>>
>> Regards,
>>
>> --
>> Guilherme Blanco
>> Lead Architect at E-Block
>>
>
>
>
> --
> Best Regards,
>
> Yo-An Lin
>



-- 
Guilherme Blanco
Lead Architect at E-Block

[PHP-DEV] Trying to fix "use" language inconsistencies

[guilhermebla...@gmail.com]

Hi internals,


It all started with a PR over doctrine/annotations (
https://github.com/doctrine/annotations/pull/69), where a contributor
decided to propose supporting group use support.

The issue starts with this, which it is perfectly supported:

use Foo\Bar, Foo\Woo;

While multiple group uses are not:

use Foo\{Bar, Baz}, Qux\{Corge, Grault};

Then I decided to see what is really supported by the newly introduced
group use. According to the grammar, these are the same lines:

use Foo\Bar, Foo\Baz;
use Foo\{Bar, Baz};

use function Foo\Bar\baz, Foo\Bar\qux;
use function Foo\Bar\{baz, qux};
use Foo\Bar\{function baz, function qux};

However, this feature leads to an inconsistent behavior in the language.
Mixed group use types are supported:

use Foo\Bar\{Baz, function qux};

While mixing use types are not:

use Foo\Bar\Baz, function Foo\Bar\qux;


This brings the question of whether we should continue this madness path of
inconsistency or we start addressing inconsistencies one by one in the
language.
I'd like to propose options that we could fix this:

- Remove mixed group use types support (this would become invalid: use
Foo\{Bar, function baz};)
- Add mixed use support, which would contradict the approach took by typed
properties (this would require this approach: use function Foo\Bar\baz,
function Foo\Bar\qux;)

One of the approaches needs to be taken in order to support multiple group
use, otherwise we have a reduce/reduce yacc error that can't be fixed
(well, my yacc/compiler's knowledge hit a dead end there, without doubling
all the grammar rules and taking an overly complex route). Ultimately, the
question comes around if we should consider support of multiple group use.
If positive, I'd suggest approach two (I already have a patch for that! =D).


I'd like to gather opinions around this, so I can properly implement and
propose a patch through an RFC process.


Regards,

-- 
Guilherme Blanco
Lead Architect at E-Block

Re: [PHP-DEV] Re: Typed properties patch

[guilhermebla...@gmail.com]

Hi,

Unsetting properties is used by a range of libraries I am aware of,
including Doctrine (actually any project that relies on proxy generation).
Breaking this "feature" would be a catastrophe to a lot of projects.
There is an alternative though, which would help: property getter/setter
would not only address the unsetting hack, but also allow read only
properties (final properties). IMHO, we should look back at that
implementation (it was mainly rejected because of the patch complexity (not
the idea), which would kill two birds with one stone.

Cheers,
On Apr 13, 2016 2:59 AM, "Dmitry Stogov"  wrote:



On 04/13/2016 07:33 AM, Stanislav Malyshev wrote:

> Hi!
>
>  Thanks for your time reviewing the patch, appreciated.
>>
>>  > 1) nullable properties
>>
>>  I agree that we need a way to that, but I would rather see it
>> covered by nullable types rfc.
>>
> I think this is an attempt to achieve more type safety than even fully
> typed languages like Java, and it will only get in the way in PHP.
>
>  > 3) disable unset
>>
> This sounds very weird. Why I would suddenly unable to unset a property?
>

Because if you unset() a property it's type is not guaranteed anymore.

x + 5; /* we know $a->x is "int" and may use optimized code */
unset($a->x);
$b = $a->x + 5; /* $a->x is not "int" any more  and we can't use optimized
code */
?>

As we can't be sure where the property may be unset(), we won't be able to
use optimized code at all (even in first place).

Thanks. Dmitry.



>

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

Re: [PHP-DEV] Access and Visibility Modifiers

[guilhermebla...@gmail.com]

Hi,

I was working on a private-class support for PHP an year ago, until I hit a
problem I couldn't fix myself.
Now I have some more expertise of what I could do to resolve it, but I
still didn't start on rebase/update of patch yet.
However, I'd like to describe my line of thinking here, so people can
debate about it even without me working on an updated patch yet. It's a
preliminary work that needs to happen before people spend time on a patch,
that will later be transformed into an RFC.

The situation that brought me to work on this is, as a library developer,
people reuse internal classes that are not meant to be reused outside of
library's code. Changes to its API can potentially break consumers of the
library, making upgrades hard to happen.
To mitigate this problem, I thought about working on two patches to the
language that could help library/application developers, self-containing
code that is not meant to be reused. They're detailed as follow:

1- Private-class visibility: Only classes in the same namespace (siblings)
or child ones could instantiate the class. Cloning would still be possible
outside of namespace's scope, the same to access public members.
This is what is currently 90% done in:
https://github.com/php/php-src/pull/947
It requires changes to Zend Engine to include a start namespace and an end
namespace opcodes, allowing to locate in which scope you are. There are
failing tests that are not passing because of this right now.

2- Protected-class visibility: It would work the same way as private-class
visibility, but with the difference that other classes in the same
namespace/child namespaces could access protected members of the specified
protected class.

Of course both of them would require to go through RFC writing, idea
validation, voting and performance assessment process, but it's already a
start.


Regards,

On Thu, Apr 7, 2016 at 2:05 PM, Rowan Collins 
wrote:

> Fleshgrinder wrote on 07/04/2016 18:35:
>
>> I would like to change above definition for properties since the*var*
>> deprecation was voted negative:
>>
>> # Properties
>> private   := limited to the current class
>> protected := limited to the current and child classes
>> var   := limited to the current assembly
>> public:= global
>>
>
> I'm not convinced of the value of reusing the keyword in this way. To me,
> there is nothing in the term "var" that means "slightly less than public",
> and if we want to have package/assembly/whatever visibility, we should
> reserve a new keyword for that use.
>
> Meanwhile, it might be worth checking the list archives for previous
> discussions of package visibility; I know it has come up a couple of times
> recently, in various forms, so it would be good not to repeat the same
> points again and again.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>



-- 
Guilherme Blanco
Lead Architect at E-Block

Re: [PHP-DEV] [RFC Discussion] Typed Properties

[guilhermebla...@gmail.com]

My code version is not complete, as the references changed when you include
the optional_type.
It shouldn't be hard to change though... like $$ = $3 and also hold $2
somewhere.

On Thu, Mar 31, 2016 at 2:09 PM, Zeev Suraski <z...@zend.com> wrote:

>
> > On 31 במרץ 2016, at 20:48, "guilhermebla...@gmail.com" <
> guilhermebla...@gmail.com> wrote:
> >
> > To me it's simply as that:
> >
> >
> > class_statement:
> >variable_modifiers optional_type property_list ';' { $$ = $2;
> > $$->attr = $1 }
> >|   ...
> >
> > property_list:
> >property_list ',' property { $$ = zend_ast_list_add($1, $3); }
> >|   property { $$ = zend_ast_create_list(1, ZEND_AST_PROP_DECL, $1); }
> > ;
> >
> >
> > I think this makes the concept more palatable compared to others and
> other
> > languages (single type declaration per statement).
> >
>
> Exactly (code version).
>
> >> Honestly I never even realized that you could put multiple declarations
> on
> >> a single line, have never done so, and would reject code from any of my
> >> projects that did so as poor style. :-)  That said, since it is legal I
> >> agree that it should be kept unambiguous and consistent.
> >>
> >> From what Zeev is saying, the following seems like a reasonable rule:
> You
> >> get ONE visibility modifier and ONE type statement per declaration, and
> >> both must come at the beginning, period.  That is, the following are
> legal:
> >>
> >> public int $a, $b;
> >> protected $a, $b;
> >> var int $a, $b;
> >>
> >> And always apply across the entire line, period.
> >>
> >> The following are all syntax errors:
> >>
> >> public int $a, string $b;
> >> var int $a, protected $b;
> >> private $a, float $b;
> >>
> >> That seems fairly easy for a reader to follow, reasonably consistent,
> and
> >> I presume straightforward to implement (not being a C developer I
> hand-wave
> >> that part...).  If you want to do something more complex... make it
> >> multiple statements.  That's why multiple statements exist.
> >>
> >> Zeev, is that an accurate summary of what you're arguing?
> >>
>
> Exactly (human version :)
>
> Zeev
>



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

Re: [PHP-DEV] [RFC Discussion] Typed Properties

[guilhermebla...@gmail.com]

To me it's simply as that:


class_statement:
variable_modifiers optional_type property_list ';' { $$ = $2;
$$->attr = $1 }
|   ...

property_list:
property_list ',' property { $$ = zend_ast_list_add($1, $3); }
|   property { $$ = zend_ast_create_list(1, ZEND_AST_PROP_DECL, $1); }
;


I think this makes the concept more palatable compared to others and other
languages (single type declaration per statement).

Regards,

On Thu, Mar 31, 2016 at 12:19 PM, Larry Garfield 
wrote:

> On 3/31/16 8:01 AM, Zeev Suraski wrote:
>
>>
>> -Original Message-
>>> From: Joe Watkins [mailto:pthre...@pthreads.org]
>>> Sent: Thursday, March 31, 2016 3:41 PM
>>> To: Dmitry Stogov 
>>> Cc: Björn Larsson ; Phil Sturgeon
>>> ; Krakjo ; PHP internals
>>> 
>>> Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
>>>
>>> Morning Dmitry,
>>>
>>> This should be a error. I also think, that "public" might be omitted,
 and it should be possible to write "int $bar, $foo"

>>> Omitting public might be nice, but also totally separate, you should be
>>> able to
>>> omit it for untyped properties too.
>>>
>>> You say - C, C++, Java, HHVM, etc - all made worse decision? OK

>>> No. C, C++, C#, and Java had a different decision to make.
>>>
>> I don't think the decision is fundamentally different.  It's
>> fundamentally very similar if not identical.
>>
>> [public] int foo, bar;
>>>
>>> It is obvious that bar is an int in any of those languages precisely
>>> because it
>>> necessarily has a type.
>>>
>>> Why we should jump to the same conclusion, in a system where properties
>>> do
>>> not necessarily have types is not clear to me.
>>>
>> Because we're dealing with a single statement, and we already have the
>> concept that a modifier for that statement is enforced throughout the
>> statement - I don't see how whether that modifier is mandatory or not makes
>> any meaningful difference.  Having an access modifier affect the entire
>> statement, while a type modifier affecting only the variable next to it -
>> is extremely inconsistent.
>>
>> If
>>
>> Private Person $p, Car $c;
>>
>> works, why shouldn't:
>> Private Person $p, public Car $c;
>>
>> Work as well?
>>
>> In addition to being inconsistent, it also calls for poor coding
>> practices - mixing typed and untyped declarations in a single statement -
>> as well as different types in a single declaration.  In that context, what
>> drove other languages to pick their syntax and force developers to separate
>> declaration of different variables types into different statements -
>> applies exactly in the same manner for all other languages, us included.
>>
>> Zeev
>>
>
> Honestly I never even realized that you could put multiple declarations on
> a single line, have never done so, and would reject code from any of my
> projects that did so as poor style. :-)  That said, since it is legal I
> agree that it should be kept unambiguous and consistent.
>
> From what Zeev is saying, the following seems like a reasonable rule: You
> get ONE visibility modifier and ONE type statement per declaration, and
> both must come at the beginning, period.  That is, the following are legal:
>
> public int $a, $b;
> protected $a, $b;
> var int $a, $b;
>
> And always apply across the entire line, period.
>
> The following are all syntax errors:
>
> public int $a, string $b;
> var int $a, protected $b;
> private $a, float $b;
>
> That seems fairly easy for a reader to follow, reasonably consistent, and
> I presume straightforward to implement (not being a C developer I hand-wave
> that part...).  If you want to do something more complex... make it
> multiple statements.  That's why multiple statements exist.
>
> Zeev, is that an accurate summary of what you're arguing?
>
> --
> --Larry Garfield
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


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

Re: [PHP-DEV] Proposal for a new array function

[guilhermebla...@gmail.com]

My personal take on this:

Let's add just more 1 function over a 9 function's array API, because I
want to optimize 3 lines in my PHP code, and language lack of Generics
while we still refuse to carefully think about a proper OO Collection API.

Regards,

On Tue, Feb 9, 2016 at 6:19 AM, Matthew Setter  wrote:

> Thanks kindly for the rapid and very helpful feedback. I'm going over it
> today and will collate it and think over it further. Given that the
> feedback's been so constructive and positive, I'll be getting started on an
> RFC over the next day or so.
>
> Matt
>
>
> --
> Kind regards,
>
>
> *Matthew Setter*
> *Freelance Software Developer & Technical Writer *
> *Host of Free the Geek  | Author of Zend Framework
> 2
> Foundations *
>
> w:  http://www.matthewsetter.com
> t:  *@settermjd *
> g+: *+MatthewSetterFreelanceWriterDeveloper
>  >*
> li: *in/matthewsetter *
>
> On Mon, Feb 8, 2016 at 6:43 PM, Matt Prelude  wrote:
>
> > Hi,
> >
> >> I want to propose a new PHP array method, called has_numeric_keys (or
> >> something similar/better), that would have the following method
> signature:
> >>
> >> bool has_numeric_keys(array $array)
> >>
> >> The reason for it is to check if the array passed to it only had numeric
> >> keys.
> >>
> >> Why this method, when you could do it in userland PHP? Answer?
> >> Convenience.
> >> I found, recently, that I had to perform this kind of check, when
> patching
> >> Zend\Db\Sql\Insert.php. The approach I took was this:
> >>
> >> return array_keys($arr) !== range(0, count($arr) - 1);
> >>
> >> Not sure of my approach, I took to Twitter and received the following
> >> suggestions, amongst others:
> >>
> >> function isArrNum($arr) {
> >>foreach($arr as $i =>$v){
> >>  if (!is_int($i)) {
> >>return false;
> >>  }
> >>}
> >>return true;
> >> }
> >>
> >> count(array_filter(array_keys($array), 'is_string')) > 0
> >>
> >> array_filter([...], 'is_int', ARRAY_FILTER_USE_KEY)
> >>
> >> This convinced me that it wasn't just me seeing a valid use case for it,
> >> and that others have implemented differing solutions when presented with
> >> the same situation. Given that, I believe a simple, utility, function
> such
> >> as this would be of help.
> >>
> >> As for who would implement it, that would be me.
> >>
> > I like it. Would like to see it be a bit more generic though, something
> > like (ignore the name, I can't name functions):
> >
> > array_validate_keys($array, is_int);
> >
> > I say this because it allows for more potential uses (that and I've done
> > exactly the same to check all keys are strings before).
> >
> > - Matt.
> >
> >
>



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

Re: [PHP-DEV] Re: [RFC][VOTE] Allow specifying keys in list()

[guilhermebla...@gmail.com]

Here is my reasons for no:

1- Non-intuitive behavior
2- Hard to read code, takes more time to understand underlying logic/flow
3- YAANPI => Yet Another Alternate Named Parameters Implementation (when I
look at future scope)
4- Most common usage form (first example) still forces you to type almost
same amount of logic with less readability and little value

Regards,

On Tue, Feb 9, 2016 at 1:50 AM, Joe Watkins  wrote:

> Morning internalz,
>
> As mentioned the future scope stuff is scary, but not enough on it's
> own to vote no.
>
> So I want to vote yes, but I'm just waiting to hear objections from no
> voters, in case they thought of something I didn't ...
>
> Cheers
> Joe
>
> On Mon, Feb 8, 2016 at 8:18 PM, Andrea Faulds  wrote:
>
> > Hi again,
> >
> > There's been a lot of No votes on this RFC, but I haven't received much
> > feedback as to why. Would any of you mind sharing your reasons, if
> > possible? It would be helpful if I knew why people have voted against it,
> > as then I might be able to modify the RFC to be more palatable, or
> > understand where I went wrong.
> >
> > Thanks!
> >
> >
> > Andrea Faulds wrote:
> >
> >> Hi everyone,
> >>
> >> It's been more than two weeks since I first proposed this RFC, and
> >> there's no outstanding issues preventing moving towards a vote. There's
> >> not yet a language specification patch, but that can be done later.
> >>
> >> So, I'm opening the vote on this RFC today, 2016-02-05, and it'll close
> >> the Sunday after next, 2016-02-14. The vote requires a 2/3 majority as
> >> it's a language change.
> >>
> >> The RFC page is here: https://wiki.php.net/rfc/list_keys
> >>
> >> Happy voting!
> >>
> >
> >
> > --
> > Andrea Faulds
> > https://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] Class Friendship in PHP

[guilhermebla...@gmail.com]

Hi,

My biggest concern about supporting friend classes is the ability to access
non-intentional to be accessed code outside of the original class's
knowledge. This by itself is very dangerous.

I do see however package-private classes as a possibility (I actually have
a partially running patch for that) and allowing it to access protected
(not private) members is a second stage of my goal, so very similar to what
your suggested, with the exception that the original class defined what can
be accessed.

Regards,

On Mon, Dec 7, 2015 at 10:55 PM, Dustin Wheeler  wrote:

> Hi!
>
> The topic of class / function friendship has been recently discussed and
> previously covered in the past through this list as well as through feature
> requests against bugs.php.net. I've recently developed an interest in the
> feature after reaching for a tool that just didn't exist in a language I
> really love. Given the opportunity to learn something new, I decided I
> would learn what it took to add a new feature to PHP7. That said, I would
> like to describe the case for class friendship in the context of a
> landscape of discussion around private collaborators, in general. I would
> then like to submit an RFC for discussion that proposes class friendship
> (without friend functions; reasons described below). In addition, I have a
> functional implementation with tests that is ready for review. I have begun
> a draft of the RFC but am unable to post it do to lack of wiki karma. If I
> need to contribute in other ways to gain karma, please let me know!
>
> As an aside (before I continue), I would like to contribute implementation
> notes I took along this path to the project wiki and would like review
> (fact-checking) from those more knowledgeable to that regard as there is
> little recent online documentation on implementing a feature that cuts
> across language internals like this does. In order to implement this
> feature, I had to source information from a 2012 article from nikic, the
> RFC for AST and random tweets to SaraMG. Not exactly the clearest path for
> a newbie! I would like to get this information somewhere it might be useful
> so that others may benefit. That said, I do not want the fact that I have
> implemented this feature before engaging this mailing list to sway
> consideration for RFC discussion. I did this as a learning opportunity,
> first; to scratch an itch, second.
>
> To continue; class friendship allows an object to be better encapsulated by
> granting per-class access to private and protected properties that would
> otherwise have to be marked public or exposed through public getters. This
> feature affords developers an opportunity to better model objects as
> behavioral units while making explicit presentation concerns through
> friendship. Admittedly, class friendship has a narrow use-case, but is
> nonetheless a valuable expression for object modeling when used properly.
>
> The purpose of the feature should not be conflated / confused with the
> goals of something like package protected classes or package visibility, in
> general. I feel those features apply more closely to the types of behaviors
> user-land sees in Symfony (and other framework) packages that mark
> properties as `@internal` but are forced to make them public to share
> access between internal data structures. I don't necessarily feel that
> class friendship is the "Right Answer TM" in this case, but I think that
> the dance package developers currently have to do to express "don't use
> this property, we use this internally to help you" is worth improving.
>
> In my opinion, class friendship has at least two known (to me)
> applications:
>
> 1. White-box (characterization) testing as a tactical refactoring tool when
> approaching legacy codebases
> 2. Modeling a tightly-coupled relationship between behavioral and
> presentation concerns in a domain model
>
> Class friendship allows a developer to make a specific test-case a friend
> of a unit under test. This grants the test-case access to internal
> implementation details of what may or may not be a properly factored
> behavioral unit. While it may be "best practice" to model behavior rather
> than expose state, the latter is a grossly common case in many PHP
> code-bases, thus lending value to the strategy of white-box testing /
> characterization testing in the short-term to enable a safe refactoring
> process. In a language that does not implement class friendship (or private
> collaborators, in general) a developer is left with a trade-off to
> sacrifice modeling concerns for the benefit of a passing test-suite. If the
> situation dictates characterization tests as "what's best", then the
> developer either marks internal state as public or has to implement public
> getters to proxy calls to internal state. In either case, for the duration
> of refactor, the unit is vulnerable to misuse by clients of the package the
> unit is a member of. Thus, a 

Re: [PHP-DEV] Native Annotation Syntax

[guilhermebla...@gmail.com]

Let's be clear. I haven't seen any user asking for traits, which introduced
almost the same amount of performance cost and complexity to ZE. It was
proposed by a "long term contributor" and everybody said yay.

When multiple userland people ask about the same feature, every single
major framework uses a hackish way to suppress a language deficiency, and
internals developers don't move a finger (or even care to reply here) about
the subject, it clearly exposes to me they're not paying attention to
user's needs. This is lack of interest, but you can choose better words.

Regards,

On Thu, Nov 26, 2015 at 9:51 AM, Levi Morrison  wrote:

> > Ah, and please stop saying "it should be in docblock". This argument is
> > just bull... to suppress the actual people interested to see this
> natively
> > available and just exposes your lack of interest into language
> improvement.
>
> Every feature has a cost and benefit. It is perfectly fine to have the
> opinion that a feature is better left out of the language based on
> that cost. Being against a feature does not mean that person is
> against language improvement or has a lack of interest.
>



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

Re: [PHP-DEV] Native Annotation Syntax

[guilhermebla...@gmail.com]

Ok then. I'll pretend that lack of interest didn't happen many other
situations (like http://marc.info/?t=14460876781) and move on.

I don't want to bring the patch up to date/simplify it without a clear
decision of at least be willing to discuss the patch and not reject by all
means.
I'd propose a voting as "Are you ready for Annotations yet?". Every core
developer understands (and can base their decisions) by looking at the
complexity of the old patch.

Once voting completes and IF it gets approved, I'll gladly put it up to
date for consideration and update the RFC.

[]s,

On Thu, Nov 26, 2015 at 10:53 AM, Rowan Collins <rowan.coll...@gmail.com>
wrote:

> guilhermebla...@gmail.com wrote on 26/11/2015 15:14:
>
>> I haven't seen any user asking for traits
>>
>
> Just because you didn't see it, doesn't mean it didn't happen.
>
> I just did a very quick search on Google for php + mixins, limited to 2007
> or earlier (long before the current Trait implementation was born), and got
> plenty of results lamenting the lack of support for horizontal reuse in PHP.
>
> See for yourself:
> https://encrypted.google.com/search?q=php+%22horizontal+reuse%22=active=en=lnt=cdr%3A1%2Ccd_min%3A%2Ccd_max%3A12%2F31%2F2007=#safe=active=en=cdr:1%2Ccd_max:12%2F31%2F2007=php+mixins
>
> It's a common accusation of projects like this that time was spent on X
> that should have been spent on Y, but that's nearly always a massive
> over-simplification.
>
> Let's not spend too much time worrying if specific people are interested -
> they may just be on holiday, or busy elsewhere, or just not have much to
> say until someone assembles a few more details about the proposed feature.
> Keep it constructive, lay out how you think the feature should look and
> why, what questions are still open, and see what's needed to move it
> forward.
>
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


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

Re: [PHP-DEV] Native Annotation Syntax

[guilhermebla...@gmail.com]

Answers inline

On Thu, Nov 26, 2015 at 11:58 AM, Chris Riley <t.carn...@gmail.com> wrote:

>
> On 26 November 2015 at 16:05, guilhermebla...@gmail.com <
> guilhermebla...@gmail.com> wrote:
>
>> Ok then. I'll pretend that lack of interest didn't happen many other
>> situations (like http://marc.info/?t=14460876781) and move on.
>>
>> I don't want to bring the patch up to date/simplify it without a clear
>> decision of at least be willing to discuss the patch and not reject by all
>> means.
>> I'd propose a voting as "Are you ready for Annotations yet?". Every core
>> developer understands (and can base their decisions) by looking at the
>> complexity of the old patch.
>>
>> Once voting completes and IF it gets approved, I'll gladly put it up to
>> date for consideration and update the RFC.
>>
>> []s,
>>
>> On Thu, Nov 26, 2015 at 10:53 AM, Rowan Collins <rowan.coll...@gmail.com>
>> wrote:
>>
>> > guilhermebla...@gmail.com wrote on 26/11/2015 15:14:
>> >
>> >> I haven't seen any user asking for traits
>> >>
>> >
>> > Just because you didn't see it, doesn't mean it didn't happen.
>> >
>> > I just did a very quick search on Google for php + mixins, limited to
>> 2007
>> > or earlier (long before the current Trait implementation was born), and
>> got
>> > plenty of results lamenting the lack of support for horizontal reuse in
>> PHP.
>> >
>> > See for yourself:
>> >
>> https://encrypted.google.com/search?q=php+%22horizontal+reuse%22=active=en=lnt=cdr%3A1%2Ccd_min%3A%2Ccd_max%3A12%2F31%2F2007=#safe=active=en=cdr:1%2Ccd_max:12%2F31%2F2007=php+mixins
>> >
>> > It's a common accusation of projects like this that time was spent on X
>> > that should have been spent on Y, but that's nearly always a massive
>> > over-simplification.
>> >
>> > Let's not spend too much time worrying if specific people are
>> interested -
>> > they may just be on holiday, or busy elsewhere, or just not have much to
>> > say until someone assembles a few more details about the proposed
>> feature.
>> > Keep it constructive, lay out how you think the feature should look and
>> > why, what questions are still open, and see what's needed to move it
>> > forward.
>> >
>> >
>> > 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
>>
>
> Given that a lot of userland people have voting rights; I would suspect
> that an annotations rfc would pass, provided it met the needs of these
> users. As far as docblocks vs native goes - you've convinced me that native
> would be best, previously I'd have been more in favour of adding a
> getAnnotations method to ReflectionClass/Method/Property, to pull in
> annotations from docblocks.
>
> I'd like to see this goto a new RFC here are some questions though:
>
> - Can annotations be applied to functions?
>

Yes, classes, interfaces, traits, methods, properties, functions.
Unfortunately we can't apply to namespaces as they don't exist after
compile time.


> - Class constants?
>

No, there's no Reflection data structure around them and imposing one would
be a serious BC break


> - Should annotations be a special type eg annotation Foo{} or just a class?
>

Annotation classes would be annotated with @Annotation and their
corresponding @Target (where they could be applied).


> - Do we want to add decorator support at the same time? (
> http://thecodeship.com/patterns/guide-to-python-function-decorators/)
>

No. Annotations by itself is already a big endeavor and including more
stuff would only make it harder to implement/digest/approve.
What if Annotation gets approved, but people want decorator out? More
work...
Nothing prevent us to make a subsequent RFC to support decorators if the
first one gets accepted.


Regards,

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

Re: [PHP-DEV] Native Annotation Syntax

[guilhermebla...@gmail.com]

Hi,

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

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

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

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


Regards,


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

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


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

Re: [PHP-DEV] Native Annotation Syntax

[guilhermebla...@gmail.com]

Hi Rowan,

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

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

On Wed, Nov 25, 2015 at 1:50 PM, Pedro Cordeiro <pedronar...@gmail.com>
wrote:

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


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

Re: [PHP-DEV] Native Annotation Syntax

[guilhermebla...@gmail.com]

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

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

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

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

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

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

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

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


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


Regards,

On Wed, Nov 25, 2015 at 5:03 PM, Rowan Collins <rowan.coll...@gmail.com>
wrote:

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

Re: [PHP-DEV] Native Annotation Syntax

[guilhermebla...@gmail.com]

Hi Rowan,

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

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

Or:

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

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

 Regards,

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


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

Re: [PHP-DEV] Native Annotation Syntax

[guilhermebla...@gmail.com]

I can give you a good argument.

opcache.save_comments=0

Make it work.

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

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


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

Re: [PHP-DEV] 7.0.0 release

[guilhermebla...@gmail.com]

+1 on (a)

It's perfectly normal to have issues fixed between last RC and GA.

[]s,

On Tue, Nov 24, 2015 at 10:51 AM, Bishop Bettini  wrote:

> On Mon, Nov 23, 2015 at 4:10 PM, Anatol Belski 
> wrote:
>
> > a) release on 26th including all known bug fixes
> > b) do RC8, assume there are no bugs, so target 10th for RTM
> > c) do RC8, release on 3rd, expect there are no bugs come in
> > d) continue issuing release candidates till it's stable enough (needs
> > definition of stable and probably an RFC)
> >
> > I would really ask to reach a consent on either a) or c). IMO, the
> options
> > b) and d) are the direct road to curbing 7.0.0.  There is no hurry to
> > release just to release, but it is definitely harmful to slow down the
> rise.
> >
>
> The little poll I sent yesterday in response to Phil's email has an even
> split.
>
> Question: Create an RC for this count($array) fix?
> Responses: 26 for, 26 against
> http://poll.pollcode.com/92997454_result?v
>
> Maybe all it says is the community is split, and we won't reach consensus.
>
> So while I'm +1 on (c), I defer to the wisdom and guidance of our RMs. :)
>



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

Re: [PHP-DEV] Package / namespace visibility

[guilhermebla...@gmail.com]

Hi,

I am currently working on class visibility support aiming PHP 7.1. Spoke
with Derick to give me some north to finalize the patch and write the RFC.

Your wishes are being listened, my friend! =)
On Nov 10, 2015 19:25, "Karoly Negyesi"  wrote:

> Hi,
>
> As one of the Drupal core developers I need to say: we would *love* to have
> some sort of cross class visibility. Visibility within a namespace looks
> like a very nice solution to this. May I recommend adding nspublic to
> public/private/protected? Or a similar word but the same meaning.
>
> Thanks,
>
> Karoly Negyesi
>

Re: [PHP-DEV] Friend class/function

[guilhermebla...@gmail.com]

Hi,

One thing that should be worth mentioning is that my approach of private
classes is decoupled in 2 parts.

The first one as the ability to prevent instantiation outside of namespace
and sub-namespaces. The second is the ability to access protected members,
which matches your wish of friend classes nicely.

However, I could not even tackle the second part without discussing and
agreeing on the first one, so I limited the scope of my wish in order to
simplify overall RFC phase.

Regards,
On Nov 2, 2015 7:17 AM, "François Laupretre"  wrote:

> Hi Georges,
>
> Le 01/11/2015 17:04, georges a écrit :
>
>> ​Hi php internals,
>>
>> I recently discovered ​the "friendship concept" in c++ and i really love
>> the concept.
>> And i wonder if the php internals would be interested to implements it in
>> the next 7.x major version.
>>
>>
> You may be interested by an article I wrote some weeks ago about adapting
> the 'friendship' concept to PHP (
> http://tekwire.net/joomla/projects/ideas/php-friend). IMO, we should
> enable friendship from classes and/or namespaces, with and without
> inheritance, giving four cases : class, class and descendants, namespace,
> namespace and sub-namespaces.
>
> One more detail : I wouldn't set the 'friend' information on the same line
> as the class declaration. First reason is that it already contains
> 'extends' and 'implements' stances. 2nd reason is that the information is
> not required by the compiler to start compiling the class body. So,
> 'friend' lines can be part of the class body.
>
> Use cases go well beyond test classes. There are many cases where you need
> to access methods and/or even whole classes from a set of known locations,
> but don't want to make them public. Today, the only way is to use protected
> access but it implies class inheritance which, often, is not an option. An
> example is symfony using the '@internal' tag to mark
> class/properties/methods which mustn't be accessed from the outside of
> symfony (see
> http://symfony.com/doc/current/contributing/code/bc.html#using-our-classes).
> Information is better than nothing but a way to enforce access restrictions
> would be welcome.
>
> About Guilherme's proposal : it seems fine but, IMHO, the 'friend' concept
> includes it, is easier to implement, and goes much further.
>
> Regards
>
> François
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Re: Support execution scope realization at runtime (or last pieces forprivate class support)

[guilhermebla...@gmail.com]

Hi Andrea,

I'm very happy to see you back! You're a great contributor to PHP... =)
Sorry, I may have written in a bad form, but here is the context...

Looking at this phpt file
https://github.com/guilhermeblanco/php-src/blob/class-modifiers/Zend/tests/visibility_modifiers/namespaced_private_class_different_namespace_instantiation.phpt
It currently fails giving this error: "Fatal error: Top level scope cannot
instantiate package private class A\B in %s on line %d"
What happens is that at runtime, there is no scope definition defined when
I look for EG(scope) in the zend_vm. This means that it doesn't matter if
the code is in a top-level or inside of a namespace (but not inside of a
class/method/function), scope is always null.
This breaks the execution, because it can't correlate to the proper
namespace it's instantiating and the entire approach of restricting usage
of private classes doesn't work.
Does that make sense now? I actually detailed in all the written tests
which ones currently fail, all because of exact same situation.

My question falls back to anyone with deeper knowledge of zend_vm or
internals how and what would be necessary to finalize the patch (this is
the last missing piece as it currently stands), so I could officially
propose for discussion by everyone here.

Regards,


On Thu, Oct 29, 2015 at 2:41 PM, Andrea Faulds <a...@ajf.me> wrote:

> Hi Guilherme,
>
> guilhermebla...@gmail.com wrote:
>
> Currently, there's no way to determine at runtime what is the scope of the
>> execution. This means you can't resolve if the current instruction is
>> happening on a top-level scope, in a class definition, namespace, function
>> or method.
>>
>> Together with this (maybe even more importantly), there's no way to
>> resolve
>> namespaces in any way, since they only exist up to compile time (they
>> become part of class name through string append), and no real data
>> structure around it exists. I was forced to create a weird string check to
>> make it work... =(
>>
>
> Making plain string literals in function calls be interpreted differently
> depending on context does not sound like a good idea to me. Functions
> shouldn't rely on hidden (non-syntactically-obvious) contextual
> information; I think func_get_args() et al. were a mistake.
>
> I'm not sure why we'd need to resolve namespaces at runtime anyway. If you
> just need to pass the name of a class to a function, we have ::class. Is
> there some use-case I'm unaware of?
>
> Thanks.
>
> --
> 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

[PHP-DEV] Support execution scope realization at runtime (or last pieces for private class support)

[guilhermebla...@gmail.com]

Hi internals!

I want to revive an old patch I was working on last year, and open for
discussion the last missing piece to make it fully complete, allowing me to
write a RFC.

Link to patch introducing support to private classes:
https://github.com/php/php-src/pull/947

Currently, there's no way to determine at runtime what is the scope of the
execution. This means you can't resolve if the current instruction is
happening on a top-level scope, in a class definition, namespace, function
or method.

Together with this (maybe even more importantly), there's no way to resolve
namespaces in any way, since they only exist up to compile time (they
become part of class name through string append), and no real data
structure around it exists. I was forced to create a weird string check to
make it work... =(

I wonder what would be necessary to make this patch possible, if there's
any interest to move this forward and potentially target it for 7.1 release.

Regards,

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

Re: [PHP-DEV] Some words about the basic ideas of PHP

[guilhermebla...@gmail.com]

Finally someone understood precisely what PHP needs to evolve as a language
for the next 35 years! #not

On Mon, Oct 26, 2015 at 8:26 AM, Joe Watkins  wrote:

> This brightened up my Monday morning.
>
> Cheers
> Joe
>
> On Mon, Oct 26, 2015 at 11:43 AM, Michael Kliewe 
> wrote:
>
> > Hi Frank,
> >
> > On 26.10.2015 11:09, Frank Meier wrote:
> > > Hi to all of you,
> > >
> > > first I want to apologize for may bad English,
> > >
> > No problem, it's good enough to understand you.
> > > I write because I feel that that the way how you see your own product
> PHP
> > > is totally wrong. I do not mean with it that the construction of the
> > > language is wrong.
> > >
> > > Your basic aproach is wrong.
> > >
> > > PHP is a server side programming language. That means that the most
> work
> > > what PHP have to do is to be the boss of the data servers and handle
> the
> > > data.
> > >
> > > Create database or tables  or records,  edit,  delete and read and
> write
> > > them.
> > Which database do you mean? MySQL, MSSQL, CouchDB, Redis
> > > And where is your fantastic programming language so incredible lousy
> that
> > > me, I am since 35 years a database programmer, just shake my head???
> > >
> > > Exact in this operations!!!
> > >
> > > I know that it is for free and I can not tell you how much I value your
> > > work on it, but  all of you, WAKE UP
> > >
> > > You sent the handling of records from modern handling via recordsets
> back
> > > to computer stone age. It is a  torture to use PHP without tools (and
> > they
> > > are lousy too) for database operations.
> > >
> > >
> > > I can give you a example:
> > >
> > > It is in PHP a lot of work to just read the next record in a table.
> > >
> > > With ADO is it just nextrecord().
> > With PDO it's
> > $result = $sth->fetch();
> >
> > http://php.net/manual/de/pdostatement.fetch.php
> >
> > I don't see that much of a difference... And PDO is built-in.
> > > The PHP  way is a insult to the modern world of programming.
> > >
> > > Maybe you should consider to write internal  functions for the record
> > > handling which do take all the sql waste of time away  from the
> > programmer
> > > and create just short command words that the developer can use them.
> > >
> > > This would be a "small step  for you but a  huge leap for mankind!".
> > >
> > > And you would finally win the race  in the language battle.
> > >
> > > I am sorry that I write it so harsh, but PHP is for me the definition
> of
> > > server data handling and exact there you fail in a big way.
> > >
> > > All the programmers around the world reinvent every time the wheel new?
> > >
> > > Have this really to be?
> > >
> > > In my opinion should exist  commands like:
> > > recordnew(table)
> > > recordread(id, table)
> > > recordwrite(id, table)
> > > recorddelete(id, table)
> > > recordprev(currentrecord, table)
> > > recordnext(currentrecord, table)
> > >
> > > This is the minimum what I expect from a program language in the year
> > 2015.
> > Maybe you should have a look at PDO:
> > http://php.net/manual/de/book.pdo.php
> >
> > Or other database abstraction layers out there, there are plenty. Search
> > at packagist.org for example.
> > Just to name a few that I heard of, but don't use myself: Doctrine,
> > Propel, RedBeanPHP
> > > I am database programmer  for international police organizations.
> > >
> > > Please keep my name confident.
> > >
> > You are writing to a public mailing list, what do you expect?
> >
> > Michael
> >
>



-- 
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 dean.eigenm...@icloud.com
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 dean.eigenm...@icloud.com:

 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

[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 steli...@php.net 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 e...@eliw.com 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 pierre@gmail.com wrote:


 On Mar 14, 2015 7:50 AM, Benjamin Eberlei kont...@beberlei.de wrote:
 
  On Fri, Mar 13, 2015 at 9:44 PM, Zeev Suraski z...@zend.com 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]

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 pierre@gmail.com wrote:

 On Mar 14, 2015 9:24 AM, Zeev Suraski z...@zend.com 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] [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 steli...@php.net 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 pierre@gmail.com
 wrote:

  On Mar 14, 2015 9:03 AM, Zeev Suraski z...@zend.com 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] 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 ric...@gmail.com 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 ras...@lerdorf.com 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

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 j.boggi...@seld.be 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

[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] 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:

orm(new Entity(foo))
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:

orm(
[
new OneToOne(Address),
new JoinColumn(default, default, default, default, CASCADE)
]
)
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 dmi...@zend.com wrote:



 On Wed, Feb 18, 2015 at 6:14 PM, François Laupretre franc...@php.net
 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

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 franc...@php.net
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] [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 ?php 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.

[]s,


On Mon, Feb 9, 2015 at 1:02 PM, Andrey Andreev n...@devilix.net wrote:

 Hi,

 On Mon, Feb 9, 2015 at 7:22 PM, Jordi Boggiano j.boggi...@seld.be 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 a...@ajf.me 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 ?php
 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] 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 yohg...@ohgaki.net wrote:

 Hi Stas,

 On Mon, Feb 9, 2015 at 8:11 AM, Stanislav Malyshev smalys...@gmail.com
 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(input-assert-expression)
   ensure(output-assert-expression)
   {
 ...
   }
 
  Why not do it simpler?
 
  function foo() {
  // require
  assert(input-assert-expression);
  ...
  // ensure
  assert(output-assert-expression);
  }
 
  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 yohg...@ohgaki.net 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] 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 franc...@tekwire.net
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(condition)'
 and '@assert condition', 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 uses 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 dmi...@zend.com 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 franc...@tekwire.net
 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(condition)'
  and '@assert condition', 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 uses 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 dmi...@zend.com 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 franc...@tekwire.net
 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(condition)'
  and '@assert condition', 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 den...@birkholz.biz
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 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 pierre@gmail.com wrote:

 On Fri, Feb 6, 2015 at 11:08 AM, guilhermebla...@gmail.com
 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 pierre@gmail.com
 wrote:
 
  On Thu, Feb 5, 2015 at 11:36 PM, Dmitry Stogov dmi...@zend.com 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 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 pierre@gmail.com wrote:

 On Thu, Feb 5, 2015 at 11:36 PM, Dmitry Stogov dmi...@zend.com 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] 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 ras...@lerdorf.com 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] [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 smalys...@gmail.com
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] 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 dev@mabe.berlin wrote:


 Am 14.01.2015 um 20:21 schrieb Adam Harvey:

 On 14 January 2015 at 11:15, Marc Bennewitz dev@mabe.berlin 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] Package private class

[guilhermebla...@gmail.com]

Hi Robert,

Answers inline.

On Tue, Dec 23, 2014 at 7:59 AM, Robert Stoll p...@tutteli.ch 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 differently for instance.
 Classes not defined public are only visible in the same namespace. C#
 classes with internal are visible in other namespaces but only within the
 same assembly (correct me if I am wrong).


I understand how C# and Java define class visibility and even inside of PR
I mentioned that (
https://github.com/php/php-src/pull/947#discussion_r21542750 ).

I would think of private classes in PHP as Java has implemented them hence
 they are not visible outside of its namespace. Why? I think one specifies
 private classes if he/she wants to hide the concrete implementation to
 others and hence it does not make sense IMO that it can be used as type
 hint outside. One should use the corresponding interface instead.
 Therefore, I believe it promotes better code style if we do not restrict
 the visibility to instantiation only. I think a private class should not be
 visible at all to others (cannot be used as type hint either).


Please remember that Java supports 4 levels of visibility on nested classes
and only 2 on top level

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 tjerk.meest...@gmail.com
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 flor...@margaine.com
 
  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 tyr...@gmail.com wrote:

 On Sat, Dec 20, 2014 at 11:01 PM, F  N Laupretre nf.laupre...@yahoo.fr
 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] [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] [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 der...@php.net 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 rowan.coll...@gmail.com 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

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