[PHP-DEV] "PHP" namespace?

[Yasuo Ohgaki]

Hi all,

Since we have discussion for Next PHP, "PHP" namespace discussion would be
nice
to have.

Currently, PHP module functions/classes/interfaces are using global(root)
namespace.
If it is changed to use its own namespace, user space APIs may be changed
flexible and user controlled manner. Thus, PHP may have

 - Consistent naming
 - Consistent parameter order
 - Graceful function/class/interface deprecation
(We know what we should do for these, right?)

without much compatibility issues.


"PHP" namespace may be used to provide PHP(and 3rd party)
functions/classes/interfaces/constants.
"PHP\Legacy" (or whatever) may be used for legacy
functions/classes/interfaces/constants.

>From PHP 5.6, userland function aliasing can be done with namespace.
Following code overrides existing function.



Result:
int(3)

It's good to use prefered API, but it requires "use" for every function
APIs to be overridden.
Note: Classes/Interfaces may override by "use" one by one also.

With "PHP" and "PHP\Legacy" namespace, user may write:





For compatibility, default namespace setting would be nice to have.
  - None for compiled default
  - "PHP" for php.ini-*

Previous example codes became:





Issue would be codes that assume PHP functions/classes/interfaces/constants
are
defined in global(root) namespace. (e.g. \strlen()) This could be
workaround by allowing
"use"  aliasing to global(root) namespace. (e.g. "use PHP\Legacy as \;") In
this case,
current functions/classes/interfaces may stay in global(root) namespace.
(or "use PHP as \;")


Programmers may shoot their own foot by this. This is the trade off of
flexibility.

Any thoughts and/or comments?

Regards,

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

[PHP-DEV] Re： [PHP-DEV] RFC: Move phpng to master

[David Dai]

> 
> 
> On 27 07 2014, at 11:44, Kris Craig  (mailto:kris.cr...@gmail.com)> wrote:
> 
> [a lot]
> 
> Maybe because you see those as competitors, but I see HHVM and friends as 
> current competitors, being evaluated to replace stock PHP, which is 
> definitely not covered by any nice statistics you can currently view.
> 
I can confirm that,  wikimedia is migrating from PHP to HHVM, see:  
http://lists.wikimedia.org/pipermail/wikitech-l/2014-July/077690.html
and I also have saw many friends talking about migrating from PHP to HHVM only 
for performance gain. 
> 
> Cheers,
> Mike
> 
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php



Cheers,
David Dai

  

Re: [PHP-DEV] RFC: Move phpng to master

[Mike Willbanks]

First off, I realize I am top posting but this thread is becoming extremely
off-topic, unbalanced and overall ridiculous to see from the sidelines as
someone that contributes to open source and also utilizes PHP on a daily
basis for more than the last decade.

Seriously, cut the shit!  Everyone is bringing this to a personal and
completely insane area; let's focus on the facts not the reactions wherever
they might come from.  Work together, no one ever agrees 100% of the time
and continuing on that note, no one makes the best choices 100% of the
time.  Surely, as a community we will not always agree on implementations,
timing and what is done in "secret" vs. not, what is more maintainable vs.
what is not.  Where to dedicate focus etc.  Open source projects often have
this issue.  Also, no I am not taking a stance or side on what is best for
the language.  People contributing to the engine are much smarter than I in
this level and the right choice I am certain will prevail.  But have a
reasonable conversations on facts vs. personal opinions and vendettas.

Now, PHP is a balanced language; performance comes with a cost if it be
memory, CPU spikes, maintainability, readability, etc.   We all program
here; this is always a trade off we need to determine, analyze and
identify.  These things have to be taken into account.  Documentation is
nice but not always necessary.  Depending on what it will change and how
much affect it will have on say extension developers and existing people
contributing to core has to be taken into account.

Let's get our heads straight, determine our focus for the next few years
and start to move forward.  Sure other languages gain and lose on PHP but
this will always be the case and should not be the core focus; we're not a
company that's on the stock market.  Languages will evolve, change, become
invented but it's not like PHP is going away in a rapid decline; sure there
is more languages and more competition out there.  For instance, I have
been writing node.js lately and find a massive benefit in certain types of
projects; it comes to utilizing the right tool for the right job.  Surely
you are not going to attempt to write PHP for something that should be done
in assembly or visa-versa.  Market share does affect our jobs and careers
but there is a reason the language has been successful and will continue to
be.  A speed increase is not a magical bullet here, if that was the case
and they wanted to use PHP they'd use HHVM or even Hack lang and change
their usage.  (Yes, there are other things there but come on, 99% of the
time core PHP speed is not the issue.)

Let's save the effort on this useless conversation, focus on driving
SOMETHING forward, WHATEVER that may be and stop taking everything so damn
personal.

Regards,

Mike


On Sun, Jul 27, 2014 at 7:18 PM, Kris Craig  wrote:

> On Sun, Jul 27, 2014 at 3:54 PM, Yasuo Ohgaki  wrote:
>
> > Hi all,
> >
> > On Sun, Jul 27, 2014 at 5:03 PM, Michael Wallner  >
> > wrote:
> >
> >>
> >> On 27 Jul 2014 09:26, "Kris Craig"  wrote:
> >> >
> >> >
> >> >
> >> >
> >> > On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner <
> >> mike.php@gmail.com> wrote:
> >> >>
> >> >>
> >> >> On 27 Jul 2014 08:23, "Kris Craig"  wrote:
> >> >> >
> >> >> > Here's my question to counter yours, Michael:  What's the rush?
> >> >> >
> >> >>
> >> >> Every day php-ng is not GA, PHP is losing ground to its competitors.
> >> >
> >> > Umm, how?  Do you have any data to support this?  According to
> >> http://php.net/usage.php, as of 2012, PHP's usage is steadily
> >> increasing.  As far as our competitors are concerned, well:
> >> >
> >> >
> >>
> http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python
> >> >
> >> >
> >> > As you can see, PHP continues to dominate with over 80% market share
> >> and no signs-- at least, none that I can see-- that we are "losing
> ground"
> >> as you stated.
> >> >
> >>
> >> Surely it's wise to make the same wrong assumptions Microsoft did with
> >> Internet Explorer?
> >>
> > PHP is losing as a general scripting language for sure.
> > JavaScript is winning in this area even if it was originated as "a web
> > client scripting language".
> >
> > http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
> > http://langpop.com/
> >
> > We are better to consider this situation seriously. IMHO.
> > Focus on web as well as encourage general usage is what we need.
> > Making PHP a choice for "new" project should be one of the most important
> > objective.
> >
> > Regards,
> >
> > --
> > Yasuo Ohgaki
> > yohg...@ohgaki.net
> >
> >
> According to w3techs, JavaScript retains an extremely tiny market share in
> terms of general purpose languages:
>
>
> http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python,pl-js
>
>
> It looks like the sources are all measuring different metrics.  It would be
> interesting to see a closer analysis of the data and figure out which
> metrics are the most relevant to 

Re: [PHP-DEV] RFC: Move phpng to master

[Yasuo Ohgaki]

Hi Kris,

On Mon, Jul 28, 2014 at 9:18 AM, Kris Craig  wrote:

> According to w3techs, JavaScript retains an extremely tiny market share in
> terms of general purpose languages:
>
>
> http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python,pl-js
>
>
> It looks like the sources are all measuring different metrics.  It would
> be interesting to see a closer analysis of the data and figure out which
> metrics are the most relevant to this question.
>

Since we have enough market share on web apps already, why don't we focus
more on developers? There are many awesome none web app tools that are
developed with JavaScript because of it's popularity and developers'
passion.

PHP is losing popularity for sure.

http://www.tiobe.com/index.php/content/paperinfo/tpci/PHP.html

PHP is the worst in terms of lost popularity among top 20 languages. It
should be
a flag for us to adjust our strategy/view. Market share comes after
language popularity.
When market share has changed, it would be too late.

Anyway, I'm willing to have phpng as master, as well as INT64 branch.
Both are good for PHP. IMO.

Regards,

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

Re: [PHP-DEV] RFC: Move phpng to master

[Kris Craig]

On Sun, Jul 27, 2014 at 3:54 PM, Yasuo Ohgaki  wrote:

> Hi all,
>
> On Sun, Jul 27, 2014 at 5:03 PM, Michael Wallner 
> wrote:
>
>>
>> On 27 Jul 2014 09:26, "Kris Craig"  wrote:
>> >
>> >
>> >
>> >
>> > On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner <
>> mike.php@gmail.com> wrote:
>> >>
>> >>
>> >> On 27 Jul 2014 08:23, "Kris Craig"  wrote:
>> >> >
>> >> > Here's my question to counter yours, Michael:  What's the rush?
>> >> >
>> >>
>> >> Every day php-ng is not GA, PHP is losing ground to its competitors.
>> >
>> > Umm, how?  Do you have any data to support this?  According to
>> http://php.net/usage.php, as of 2012, PHP's usage is steadily
>> increasing.  As far as our competitors are concerned, well:
>> >
>> >
>> http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python
>> >
>> >
>> > As you can see, PHP continues to dominate with over 80% market share
>> and no signs-- at least, none that I can see-- that we are "losing ground"
>> as you stated.
>> >
>>
>> Surely it's wise to make the same wrong assumptions Microsoft did with
>> Internet Explorer?
>>
> PHP is losing as a general scripting language for sure.
> JavaScript is winning in this area even if it was originated as "a web
> client scripting language".
>
> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
> http://langpop.com/
>
> We are better to consider this situation seriously. IMHO.
> Focus on web as well as encourage general usage is what we need.
> Making PHP a choice for "new" project should be one of the most important
> objective.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
>
According to w3techs, JavaScript retains an extremely tiny market share in
terms of general purpose languages:

http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python,pl-js


It looks like the sources are all measuring different metrics.  It would be
interesting to see a closer analysis of the data and figure out which
metrics are the most relevant to this question.

--Kris

Re: [PHP-DEV] RFC: Move phpng to master

[Kris Craig]

On Sun, Jul 27, 2014 at 3:00 AM, Michael Wallner 
wrote:

>
> On 27 07 2014, at 11:44, Kris Craig  wrote:
>
> [a lot]
>
> Maybe because you see those as competitors,


You're the one who said PHP was losing ground to its "competitors", not I.

but I see HHVM and friends as current competitors, being evaluated to
> replace stock PHP, which is definitely not covered by any nice statistics
> you can currently view.
>

So, in other words, you're basing your claim on anecdotal and purely
hypothetical assumptions about unnamed people "evaluating" other languages
to replace PHP.  Even if your self-serving guess were true, for which there
is no evidence that has been presented here, it still wouldn't substantiate
your claim because evaluating alternatives to your current codebase doesn't
mean you're going to actually switch to any of them.  So either way, PHP is
not, as you claimed, "losing ground" to anyone.

[a lot]
>

I've been trying to maintain a civil discussion here, but I have to say,
Michael, thus far you have done nothing but make immature, snyde personal
attacks and baseless, factually inaccurate claims.  You have not
contributed anything substantive or constructive to this debate up to this
point.  From your "rolling eyes" comment where you speculated about your
dog wanting voting rights to now, you have been very disrespectful and
uncivil toward everyone here.  I don't want to discourage anyone from
expressing their views, but on the same token, I'm not here to feed trolls.

This issue clearly brings out strong emotions in some people and we clearly
disagree on certain points.  That said, please make a greater effort to be
respectful toward other people on this list, whether you agree with them or
not.  Your trolling comments have all but hijacked this thread over the
last 17 hours and it's detracting from substantive debate that needs to
happen.

If you have some issue with me personally, please take it off-list.  If
you're going to post further on this thread, please try to be more
respectful and mature in your comments.

--Kris


http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python,pl-js

Re: [PHP-DEV] [VOTE] RFC: Catchable "call to a member function of a non-object"

[Yasuo Ohgaki]

Hi Timm,

On Sun, Jul 27, 2014 at 5:56 PM, Timm Friebe  wrote:

> >  Only thing that I don't like is it depends on error message to be useful
> >  rather than error code/status. Was this discussed? Just curious.
>
> No, this wasn't discussed so far. You're right, this could make the code
> inside
> the error handler more readable and robust. It would mean, however,
> changing all
> the other E_RECOVERABLE_ERRORs too, like argument type mismatching and
> certain
> closure and generator operations; and thus was out of scope.
>
> I remember this from a couple of years back though; but can't recall why
> it was
> never done.


Looking forward new RFC.
We are better to have cleaner API.
Optional parameter for user defined error handler is adequate, probably.
Addition to error context is the cleanest, perhaps.

Regards,

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

Re: [PHP-DEV] RFC: Move phpng to master

[Yasuo Ohgaki]

Hi all,

On Sun, Jul 27, 2014 at 5:03 PM, Michael Wallner 
wrote:

>
> On 27 Jul 2014 09:26, "Kris Craig"  wrote:
> >
> >
> >
> >
> > On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner <
> mike.php@gmail.com> wrote:
> >>
> >>
> >> On 27 Jul 2014 08:23, "Kris Craig"  wrote:
> >> >
> >> > Here's my question to counter yours, Michael:  What's the rush?
> >> >
> >>
> >> Every day php-ng is not GA, PHP is losing ground to its competitors.
> >
> > Umm, how?  Do you have any data to support this?  According to
> http://php.net/usage.php, as of 2012, PHP's usage is steadily increasing.
>  As far as our competitors are concerned, well:
> >
> >
> http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python
> >
> >
> > As you can see, PHP continues to dominate with over 80% market share and
> no signs-- at least, none that I can see-- that we are "losing ground" as
> you stated.
> >
>
> Surely it's wise to make the same wrong assumptions Microsoft did with
> Internet Explorer?
>
PHP is losing as a general scripting language for sure.
JavaScript is winning in this area even if it was originated as "a web
client scripting language".

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
http://langpop.com/

We are better to consider this situation seriously. IMHO.
Focus on web as well as encourage general usage is what we need.
Making PHP a choice for "new" project should be one of the most important
objective.

Regards,

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

Re: [PHP-DEV] [RFC] imagettf* deprecation/removal

[Nikita Popov]

On Sun, Jul 27, 2014 at 9:30 PM, Pierre Joye  wrote:

> On Jul 27, 2014 8:17 PM, "Lonny Kapelushnik"  wrote:
> >
> > On Jul 27, 2014, at 1:19 PM, Pierre Joye  wrote:
> >>
> >>
> >> However the idea to add yet other warnings/notices to ext/gd is not
> >> something I like to see in GD. I will rather remove many for php-next
> >> instead of adding more. Also some new font APIs may as well make the
> >> whole ttf ones less relevant, see the upstream version.
> >
> >
> > Pierre,
> >
> > I would only want to add E_DEPRECATED to the function calls if we are
> actually going to remove them.
>
> Hm. I do not think it is a good idea. As I said, I am really not willing to
> add more warnings for the sake of adding them.
>
> There is no difference in the implementation whether one uses these
> functions or the other. A note in the doc stating that should suffice. Or
> do you have an argument to still do it? What would the win?
>

If there are two functions doing essentially the same thing, we should
remove one of them. In order to remove a function it must first be
deprecated. The proposal sounds reasonable to me. There's no need to keep
around legacy cruft through aliases.

Nikita

Re: [PHP-DEV] [RFC] imagettf* deprecation/removal

[Pierre Joye]

On Jul 27, 2014 8:17 PM, "Lonny Kapelushnik"  wrote:
>
> On Jul 27, 2014, at 1:19 PM, Pierre Joye  wrote:
>>
>>
>> However the idea to add yet other warnings/notices to ext/gd is not
>> something I like to see in GD. I will rather remove many for php-next
>> instead of adding more. Also some new font APIs may as well make the
>> whole ttf ones less relevant, see the upstream version.
>
>
> Pierre,
>
> I would only want to add E_DEPRECATED to the function calls if we are
actually going to remove them.

Hm. I do not think it is a good idea. As I said, I am really not willing to
add more warnings for the sake of adding them.

There is no difference in the implementation whether one uses these
functions or the other. A note in the doc stating that should suffice. Or
do you have an argument to still do it? What would the win?

> Otherwise, I agree that we should not add it. Also, I noted it in the
RFC, but want to make mention here in case you did not see: I’m suggesting
E_DEPRECATED in 5.6.z+1 and removal in php.next.
>

> On Jul 27, 2014, at 1:22 PM, Andrea Faulds  wrote:
>>
>> The API signatures are compatible, yes? In which case, just make the
legacy functions be aliases of the new ones. This avoids breaking
everyone’s code.
>
>
> Andrea,
>
> I don’t think that assessment accurately reflects the situation. I’m
suggesting to change the userland API in php.next. According to the release
process the whole point of a php.next is to break the API for improvements.
Anyone upgrading to php.next is going to have to check for BC breaks.
>
> I’m suggesting having this minor change be one of the BC breaks in
php.next. I’m not making the argument that it is important from a purely
technical POV; I don’t believe it is. I’m making the argument that it is
important from an operational POV. Removing them prevents newcomers and
gurus from ever having any question about which function to use.

Re: [PHP-DEV] [RFC] imagettf* deprecation/removal

[Andrea Faulds]

On 27 Jul 2014, at 19:17, Lonny Kapelushnik  wrote:

> I’m suggesting having this minor change be one of the BC breaks in php.next. 
> I’m not making the argument that it is important from a purely technical POV; 
> I don’t believe it is. I’m making the argument that it is important from an 
> operational POV. Removing them prevents newcomers and gurus from ever having 
> any question about which function to use.

Making them FALIASes also clears up any doubts. Either is equally valid.

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





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

Re: [PHP-DEV] [RFC] imagettf* deprecation/removal

[Lonny Kapelushnik]

On Jul 27, 2014, at 1:19 PM, Pierre Joye  wrote:
> 
> However the idea to add yet other warnings/notices to ext/gd is not
> something I like to see in GD. I will rather remove many for php-next
> instead of adding more. Also some new font APIs may as well make the
> whole ttf ones less relevant, see the upstream version.

Pierre,

I would only want to add E_DEPRECATED to the function calls if we are actually 
going to remove them. Otherwise, I agree that we should not add it. Also, I 
noted it in the RFC, but want to make mention here in case you did not see: I’m 
suggesting E_DEPRECATED in 5.6.z+1 and removal in php.next.

On Jul 27, 2014, at 1:22 PM, Andrea Faulds  wrote:
> The API signatures are compatible, yes? In which case, just make the legacy 
> functions be aliases of the new ones. This avoids breaking everyone’s code.

Andrea,

I don’t think that assessment accurately reflects the situation. I’m suggesting 
to change the userland API in php.next. According to the release process the 
whole point of a php.next is to break the API for improvements. Anyone 
upgrading to php.next is going to have to check for BC breaks.

I’m suggesting having this minor change be one of the BC breaks in php.next. 
I’m not making the argument that it is important from a purely technical POV; I 
don’t believe it is. I’m making the argument that it is important from an 
operational POV. Removing them prevents newcomers and gurus from ever having 
any question about which function to use.

Re: [PHP-DEV] On voting, including the next release name.

[Sean Coates]

> The way voting works now, I happen to know which option is "winning".  I
> happened to know that *before* I cast my vote.  The current results are
> posted on the RFC, and the same information percolated into emails
> encouraging folks to vote. I wonder, though, if knowing which was "leading"
> and who chose which "side" affected my vote

(This is hardly an internals topic, and I'm hesitant to reply on this list, 
but…)
FWIW, I think it's valuable to see what other people have voted. For example, 
if I'm looking over an RFC and see that my opinion is in opposition to someone 
else I respect in the community, it may cause me to reconsider. (e.g. if I 
noticed that I'd voted against Sara's vote, it would make me wonder what I 
missed).

S

Re: [PHP-DEV] PHP Language Specification

[Rowan Collins]

On 26/07/2014 22:55, Chris Wright wrote:

On 25 July 2014 17:25, Larry Garfield  wrote:

On 7/24/14, 2:38 PM, Sara Golemon wrote:

On Thu, Jul 24, 2014 at 12:29 PM, Rowan Collins 
wrote:

Zend is only one of many
contributors. Yes, the engine is still named Zend Engine but the
language has been improved by many php.net contributors.


The idea was that "ZPHP" is PHP running on top of the Zend Engine, in the
same way that "JRuby" is Ruby running on top of the JVM, and "CPython" is
Python implemented in C.  In my mind, it doesn't imply any connection to
the
company of the same name - especially if we're only borrowing its first
letter - but perhaps others would see that differently.


We (HHVM) ran into this issue as well.  We'd talk about the way PHP
(the reference implementation) does something and needed to
disambiguate it from PHP (the language syntax).  Prior to my joining
the project "Zend" was the go-to moniker for this.  Since I've seen
that go down very poorly many times in the past (who here remembers
the ZendCon where they included "Zend === PHP" on their marketing
materials?) I pushed the team towards saying "PHP5" when referring to
the implementation, and "PHP" when referring to the language syntax.

That's not really a solution for us (PHP), but I do think the issue of
separating the language from the implementation is useful, even if our
(PHP) implementation of PHP (syntax) is and will always be the
de-facto reference implementation.

-Sara

P.S. - Pronouns are getting hard, yo.


Until we figure it out, I will be referring to the current common
implementation as "Zippy".  Hopefully it catches on.


Sounds like a Zend ImPlementation of PYthon...



All I could think was "in that case, who's Bungle?" ;)

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] [RFC] imagettf* deprecation/removal

[Andrea Faulds]

On 27 Jul 2014, at 18:09, Lonny Kapelushnik  wrote:

> Whom are you suggesting the alias would be simpler for?
> 
> Personally, I do not think it would be simpler for the userland API to have 
> them aliased. I think an alias will cause unneeded confusion, discussions, 
> and waste time in an office.

The API signatures are compatible, yes? In which case, just make the legacy 
functions be aliases of the new ones. This avoids breaking everyone’s code.

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





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

Re: [PHP-DEV] [RFC] imagettf* deprecation/removal

[Pierre Joye]

On Sun, Jul 27, 2014 at 7:09 PM, Lonny Kapelushnik  wrote:
>
>>> Wouldn’t it be simpler to just make them aliases?
>>
>> Indeed, and as I have no problem if  Lonny likes to go ahead with this
>> RFC, I do not think we need one for such trivial change.
>
>
> Andrea,
>
> Whom are you suggesting the alias would be simpler for?
>
> Personally, I do not think it would be simpler for the userland API to have 
> them aliased. I think an alias will cause unneeded confusion, discussions, 
> and waste time in an office.
>
> Pierre,
>
> The idea behind making this an RFC is to come to an agreement on both the 
> change and the timeline now so there are little/no questions later.

Yes, and I appreciate your work :)

However the idea to add yet other warnings/notices to ext/gd is not
something I like to see in GD. I will rather remove many for php-next
instead of adding more. Also some new font APIs may as well make the
whole ttf ones less relevant, see the upstream version.

I will take a deeper look at the function you refer to and see what
would fit best. If a documentation only deprecation works I will go
for it.

Cheers,
-- 
Pierre

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

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

Re: [PHP-DEV] [RFC] imagettf* deprecation/removal

[Lonny Kapelushnik]

>> Wouldn’t it be simpler to just make them aliases?
> 
> Indeed, and as I have no problem if  Lonny likes to go ahead with this
> RFC, I do not think we need one for such trivial change.


Andrea,

Whom are you suggesting the alias would be simpler for?

Personally, I do not think it would be simpler for the userland API to have 
them aliased. I think an alias will cause unneeded confusion, discussions, and 
waste time in an office.

Pierre,

The idea behind making this an RFC is to come to an agreement on both the 
change and the timeline now so there are little/no questions later.


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

Re: [PHP-DEV] RFC: Move phpng to master

[Kristopher]

Instead of endless, useless bickering, how about everyone both for and
against merging jump in and start helping with phpng (docs, api
cleanup/stabilization, but fixes, etc)?

Imagine how much more stable and ready to merge it would be if you
concentrated the saber rattling energy towards actually accomplishing
something.




On Sun, Jul 27, 2014 at 6:00 AM, Michael Wallner 
wrote:

>
> On 27 07 2014, at 11:44, Kris Craig  wrote:
>
> [a lot]
>
> Maybe because you see those as competitors, but I see HHVM and friends as
> current competitors, being evaluated to replace stock PHP, which is
> definitely not covered by any nice statistics you can currently view.
>
> Cheers,
> Mike
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Weird constant expression syntax and bug

[Bob Weinand]

Am 27.7.2014 um 10:55 schrieb Stas Malyshev :
> Hi!
> 
>> Yes, I agree that this is not correct behavior - and I don't really
>> understand why it was introduced and why it isn't trivial to fix.
>> PHP-5.5 had a check for this case in place
>> (http://lxr.php.net/xref/PHP_5_5/Zend/zend_compile.c#7071) and phpng
>> contains an AST-compatible variant of the array check
>> (http://lxr.php.net/xref/phpng/Zend/zend_compile.c#7776). Shouldn't
>> copying the condition from phpng into PHP-5.6 resolve this issue?
> 
> I agree it should be easy to fix it this way, but I'd like for Bob to
> provide a bit more input here as to best way to resolve it. I'm not sure
> why usage of arrays in runtime is disallowed now in 5.6 code, so I'm not
> sure if we should enable it or remove it.
> 
> If we don't find another way soon, I guess porting one from phpng is
> what we'll have to do.
> -- 
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/


The AST compatible fix in phpng is just for top-level arrays, but not for 
something like "constant ? [1] : [2]".

I think we should just enable it, that would lower the level of confusion.

I totally agree that current status isn't optimal.

Bob

Re: [PHP-DEV] RFC: Move phpng to master

[Michael Wallner]

On 27 07 2014, at 11:44, Kris Craig  wrote:

[a lot]

Maybe because you see those as competitors, but I see HHVM and friends as 
current competitors, being evaluated to replace stock PHP, which is definitely 
not covered by any nice statistics you can currently view.

Cheers,
Mike


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

Re: [PHP-DEV] RFC: Move phpng to master

[Kris Craig]

On Sun, Jul 27, 2014 at 1:03 AM, Michael Wallner 
wrote:

>
> On 27 Jul 2014 09:26, "Kris Craig"  wrote:
> >
> >
> >
> >
> > On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner <
> mike.php@gmail.com> wrote:
> >>
> >>
> >> On 27 Jul 2014 08:23, "Kris Craig"  wrote:
> >> >
> >> > Here's my question to counter yours, Michael:  What's the rush?
> >> >
> >>
> >> Every day php-ng is not GA, PHP is losing ground to its competitors.
> >
> > Umm, how?  Do you have any data to support this?  According to
> http://php.net/usage.php, as of 2012, PHP's usage is steadily increasing.
>  As far as our competitors are concerned, well:
> >
> >
> http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python
> >
> >
> > As you can see, PHP continues to dominate with over 80% market share and
> no signs-- at least, none that I can see-- that we are "losing ground" as
> you stated.
> >
>
> Surely it's wise to make the same wrong assumptions Microsoft did with
> Internet Explorer?
>
Again, where's your evidence, Michael?  I provided two separate sources
that provide data showing that PHP is *gaining* market share and continues
to dominate over the competition, which directly contradicts the claim you
made.  Simply brushing this factual data as "wrong assumptions"-- without
any data of your own to back-up that claim-- does not constitute a valid
counter-argument, nor does introducing a non sequitur by comparing PHP to
Internet Explorer.

These aren't "assumptions", wrong or otherwise.  This is data pulled from
reliable sources.  If you have separate data that calls it into question,
then please share it with us.  Otherwise, you're just making baseless and
factually inaccurate claims about PHP to justify your argument about
PHP-NG.  As far as I can tell from the evidence available, your statement
that "PHP is losing ground to its competitors" appears to be false.  In
fact, the exact opposite appears to be true.  Again, that's not an
assumption.  That's just looking at the available data.

--Kris

Re: [PHP-DEV] [VOTE] RFC: Catchable "call to a member function of a non-object"

[Timm Friebe]

Hello,
 

> Yasuo Ohgaki  hat am 27. Juli 2014 um 10:11 geschrieben:
>
>  Hi Timm,
>
>  On Sun, Jun 29, 2014 at 7:40 PM, Timm Friebe  > wrote:
>    > >    a couple of weeks ago, I proposed a change to the handling of the
>situation
> >    where methods are called on non-objects. Instead of an E_ERROR, the
> >engine would
> >    raise an E_RECOVERABLE_ERROR, and enable framework and library authors to
> >handle
> >    this.
[...]
>
>  I like the idea.
>   
>  Only thing that I don't like is it depends on error message to be useful
>  rather than error code/status. Was this discussed? Just curious.

No, this wasn't discussed so far. You're right, this could make the code inside
the error handler more readable and robust. It would mean, however, changing all
the other E_RECOVERABLE_ERRORs too, like argument type mismatching and certain
closure and generator operations; and thus was out of scope.

I remember this from a couple of years back though; but can't recall why it was
never done.

-Timm

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

Re: [PHP-DEV] Weird constant expression syntax and bug

[Stas Malyshev]

Hi!

> Yes, I agree that this is not correct behavior - and I don't really
> understand why it was introduced and why it isn't trivial to fix.
> PHP-5.5 had a check for this case in place
> (http://lxr.php.net/xref/PHP_5_5/Zend/zend_compile.c#7071) and phpng
> contains an AST-compatible variant of the array check
> (http://lxr.php.net/xref/phpng/Zend/zend_compile.c#7776). Shouldn't
> copying the condition from phpng into PHP-5.6 resolve this issue?

I agree it should be easy to fix it this way, but I'd like for Bob to
provide a bit more input here as to best way to resolve it. I'm not sure
why usage of arrays in runtime is disallowed now in 5.6 code, so I'm not
sure if we should enable it or remove it.

If we don't find another way soon, I guess porting one from phpng is
what we'll have to do.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

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

Re: [PHP-DEV] Weird constant expression syntax and bug

[Nikita Popov]

On Sun, Jul 27, 2014 at 12:02 AM, Stas Malyshev 
wrote:

> Hi!
>
> > Could somebody please clarify what issues are still open here? From what
> > I understand, both the opcache issue and the recursion issue are fixed
> > now. What's the discussion about?
>
> As I understand, the issue is that if you define class constant like this:
>
> class Foo { const Bar = [0]; }
>
> everything works fine. But if you do var_dump(Foo::Bar), it bombs out
> with fatal error (the same goes for every other usage of that constant
> in expression). Please correct me if my info is outdated, but I think it
> is a behavior that should not be left in the release. If for some reason
> we can't make array constants work normally, we should just omit them
> altogether.
>

Yes, I agree that this is not correct behavior - and I don't really
understand why it was introduced and why it isn't trivial to fix. PHP-5.5
had a check for this case in place (
http://lxr.php.net/xref/PHP_5_5/Zend/zend_compile.c#7071) and phpng
contains an AST-compatible variant of the array check (
http://lxr.php.net/xref/phpng/Zend/zend_compile.c#7776). Shouldn't copying
the condition from phpng into PHP-5.6 resolve this issue?

Nikita

Re: [PHP-DEV] [VOTE] RFC: Catchable "call to a member function of a non-object"

[Yasuo Ohgaki]

Hi Timm,

On Sun, Jun 29, 2014 at 7:40 PM, Timm Friebe  wrote:

> a couple of weeks ago, I proposed a change to the handling of the situation
> where methods are called on non-objects. Instead of an E_ERROR, the engine
> would
> raise an E_RECOVERABLE_ERROR, and enable framework and library authors to
> handle
> this.
>
> An intriguing usecase from my POV is to make use of this in tools like
> PHPUnit;
> instead of just printing a fatal error in the middle of a test run and
> exiting,
> the tools can decide to raise an exception and display the very much more
> helpful backtrace. No third-party PHP extensions needed for this, just a
> simple
> set_error_handler() call [1].
>
> I've verified various places like phpdbg and added a bunch of tests and am
> glad
> to extend that should anyone come up with a situation he/she feel this
> would
> behave in an unstable manner; athough this is realized in a somewhat
> similar
> manner to type hint mismatches, which have proven to be quite stable.
>
> Anyhow, I'd now like to see where we'd come out at and would kindly ask
> you to
> vote for or against inclusion of this feature:
>
> https://wiki.php.net/rfc/catchable-call-to-member-of-non-object#vote
>
> Thanks in advance!
>

I like the idea.

Only thing that I don't like is it depends on error message to be useful
rather than error code/status. Was this discussed? Just curious.

Regards,

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

Re: [PHP-DEV] RFC: Move phpng to master

[Michael Wallner]

On 27 Jul 2014 09:26, "Kris Craig"  wrote:
>
>
>
>
> On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner 
wrote:
>>
>>
>> On 27 Jul 2014 08:23, "Kris Craig"  wrote:
>> >
>> > Here's my question to counter yours, Michael:  What's the rush?
>> >
>>
>> Every day php-ng is not GA, PHP is losing ground to its competitors.
>
> Umm, how?  Do you have any data to support this?  According to
http://php.net/usage.php, as of 2012, PHP's usage is steadily increasing.
 As far as our competitors are concerned, well:
>
>
http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python
>
>
> As you can see, PHP continues to dominate with over 80% market share and
no signs-- at least, none that I can see-- that we are "losing ground" as
you stated.
>

Surely it's wise to make the same wrong assumptions Microsoft did with
Internet Explorer?

Re: [PHP-DEV] RFC: Move phpng to master

[Lester Caine]

On 27/07/14 08:26, Kris Craig wrote:
> As you can see, PHP continues to dominate with over 80% market share and no
> signs-- at least, none that I can see-- that we are "losing ground" as you
> stated.
> 
> So again:  What's the rush?

Especially since 75% of that are still on PHP5.3 or 5.2 ;)

But I had forgotten the comparison has a breakdown by ranking. I made
the unsubstantiated comment about big sites not using PHP which of cause
this shows, but there is no reference to the alternative PHP engines?
One question that does come too mind is "Why is python so popular with
the bigger sites?" Is it because compiled builds are fully supported?
Certainly if any of my own sites traffic started to take off I would be
looking down that avenue, so while improving the speed of interpreted
working is important, it is still stability in the language that blocks
uptake?

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] RFC: Move phpng to master

[Lester Caine]

On 27/07/14 07:23, Kris Craig wrote:
> Here's my question to counter yours, Michael:  What's the rush?

I think that the only 'objection' I have to 'simply' merging phpng is
that it is not just a 'single' change? This vote is all or nothing, so
every change is bundled without a vote on particular elements. That many
elements ARE simply improvements to the speed at which things   are
processed is not the problem here, and it may well be that the changes
that do affect BC have a practical justification, but there will not be
a discussion on that?

I'm currently fighting a problem due to a blanket change to a number of
systems, which offer a vast speed improvement, but now apparently make
it impossible to identify the location of the client machine. The change
to VDI is a done deal but nobody on site seems to be interested in
fixing the resulting problem :( Due diligence would have addressed the
problem beforehand and could well have steered things a different way.

The 'rush' with phpng is that people need to have a stable base to be
working with, and if php-next is to be phpng, then we need to be working
with it. If I magically found some spare time today should I be looking
at the current code base or phpng going forward? Documentation IS
crucial here, and documenting those changes and providing information
where an individual change affects BC  is essential, but there should be
some mechanism to review elements that are not so clear cut? IS_BOOL
object container against IS_TRUE and IS_FALSE new values is probably not
a good example, but it is a change that I don't currently see full
rational behind ... if I create a bool container I don't know which
value it is ...

We do not want to complicate things by voting on each element, but it's
the simple fact that so many elements have been re-engineered without
the normal process that is causing irritation, so some agreement that if
questions are raised about an element then it WILL get a proper
discussion and if justified get reverted? I think that this is part of
the debate on 2/3rds or 50-50 ... there are elements which would
normally be a 2/3rds decision? So there should be an agreement that
these can be reviewed again later?

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] RFC: Move phpng to master

[Kris Craig]

On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner 
wrote:

>
> On 27 Jul 2014 08:23, "Kris Craig"  wrote:
> >
> > Here's my question to counter yours, Michael:  What's the rush?
> >
>
> Every day php-ng is not GA, PHP is losing ground to its competitors.
>
Umm, how?  Do you have any data to support this?  According to
http://php.net/usage.php, as of 2012, PHP's usage is steadily increasing.
 As far as our competitors are concerned, well:

http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python


As you can see, PHP continues to dominate with over 80% market share and no
signs-- at least, none that I can see-- that we are "losing ground" as you
stated.

So again:  What's the rush?

--Kris

Re: [PHP-DEV] RFC: Move phpng to master

[Michael Wallner]

On 27 Jul 2014 08:23, "Kris Craig"  wrote:
>
> Here's my question to counter yours, Michael:  What's the rush?
>

Every day php-ng is not GA, PHP is losing ground to its competitors.

People seem to ignore this because of cosmetics.