Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Arvids Godjuks]

Hello to everyone.

The Draft states:

"This Code of Conduct applies both within project spaces and in public
spaces when an individual is representing the project or its community."

TL;DR: Just no.

Long version:

What is the definition of "representing project or it's community". If I
make a single commit that get's accepted to the project, and then I say
something 3 years down the line about the project (in this case PHP), do I
still represent the project or it's community? Or I have added to
conversations on this mailing list for years now, does that mean i'm a
contributor now and I'm responsible for anything I say about the project or
it's community going forward?
And what is PHP community? It's not like PHP community is a tight group -
it's huge, with tens of millions of people at least all over the world.

This is especially a worry for me, because I run a PHP conference, and
people come to speak to it. I do not want to deal with people dictating me
"I want you to pull this person because his views on blah are bla bla bla
and that is unacceptable". I do not care about the persons views on any
subject, unless:
a). It breakes the laws of my country (hate speech, harassment, gender
discrimination and all that stuff that is actually covered by laws).
b). The person goes into issues, that are not the topic of the conference.
c). Behaves in a way, that is not acceptable in the society (personal
insults, unacceptable language, and so on).
And what if I actually agree with that person in my own views? And why
someone thinks he has the right to dictate what views are acceptable and
witch are not? (i'm not talking about issues, that are universally
unacceptable to talk about).

Regarding c) - you should remember, that in different parts of the world
the social norms vary - from slightly to moderate between western cultures,
to quite a lot for asian/latin american/african/etc. . Every country is
different, especially those, that are quite far apart. That means that
people will be doing things, that are totally acceptable and are the norm
in their country, when they are preforming at the local conference, but
will probably trigger a storm somewhere else, and that may result in things
going horribly wrong.

So, as far as my personal opinion goes, CoC has to apply only to project
spaces in full, and for the public spaces it has to have a clear
definition, when CoC applies. I really do not want to see situation like
they happened in other projects, when a person can be booted off the
project just because he does not support some trending new thing in social
areas (pick any social issue in recent 20 years), but is absolutely a model
member of the project. This is a tech project, not a social gathering to
impose social trends and rallying support for social issues.

* Any personal opinions on any subject not directly related to the project
itself should be out of the scope of CoC. This has to be written in from
the start, otherwise people will find a way to exploit it to generate
controversy and drama on the subjects that are not related to the PHP
project.
* CoC should clearly state that it is designed only to handle the conduct
in project channels and official representation of the project. The
representation part should be defined.
* Any requests coming in on the issues, that are not directly related to
the PHP project itself, should be outright rejected. In case of abuse
(trying to re-open the issues) the access should be restricted if that's
technically possible.

Otherwise, as history shows, the rules are abused sooner or later. And the
amount of controversy we have around PHP every minor and major release,
that's a given.

Above written is a rough thought list on the subject. Proposed CoC is too
generic and allows for a lot of loopholes. We should really take out time,
read up on the issues that did happen on other projects (and there are a
lot of those), and not making a mistake of adopting a general CoC. Personal
life's have nothing to do with the PHP project. Personal thoughts expressed
outside of the project are just that - personal. And here in Europe, we
have quite strict laws about personal stuff too, so even bringing up issues
like "that person thinks that ... that he said to me in a personal
conversation" are subject to laws, that prohibit this explicitly.

Thank your for your time,
Arvids.

Re: [PHP-DEV] Re: PHP 5.6 life cycle

[Arvids Godjuks]

2015-12-07 17:11 GMT+02:00 Zeev Suraski :

> > -Original Message-
> > From: Rowan Collins [mailto:rowan.coll...@gmail.com]
> > Sent: Monday, December 07, 2015 4:42 PM
> > To: internals@lists.php.net
> > Subject: Re: [PHP-DEV] Re: PHP 5.6 life cycle
> >
> > Rowan Collins wrote on 07/12/2015 14:35:
> > > - On what factors will the decision be based? If the reason to delay
> > > the decision is lack of information, what information are we planning
> > > to use? Are there metrics we can use to make a more objective
> decision?
> >
> > Come to think, this works the other way as well: if we *do* make a
> decision
> > now, are there factors that would allow the question to be reopened?
> Again,
> > to have any trust in the announced date, people would need to know what
> > these were - if the decision is "probably August 2017", then that would
> be no
> > decision at all.
>
> It's always possible to submit another RFC to alter the end date, even if
> we decide about one now.  But I do think it'll send a different message -
> that we think it's going to take extraordinary circumstances  for us to
> change the decision - vs. us saying "we'll wait and see", which at least I
> would interpret as "they'll probably delay it".
>
> Zeev
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
According to PHP release RFC - the date is already set. To extend support
for 5.6 you actually now need an RFC. Without the RFC any decision made by
anybody in that regard is invalid and irrelevant.

RFC or didn't happen.

Just to be clear people do not forget what they actually voted on and that
they have to stick to a process to make decisions.

Re: [PHP-DEV] PHP 5.6 life cycle

[Arvids Godjuks]

Hello internals,

In my opinion, right now what dictates the timeframes is Release Process
RFC: https://wiki.php.net/rfc/releaseprocess
It clearly states the rules of how things are done.
If dates for the PHP 5.6 are to be adjusted, than it requires an RFC
process and should be an exception, not the rule.

But, for what it's worth - it's fine as it is. Distros will support 5.6 as
long as they need, you can always download older versions for Windows from
php.net archive and so on. It still has almost 2 years in security fixes
left, and that's more than enough time for people to make a move. Others
will just not care to do that anyway for whatever reasons, and nothing can
be done about it.

Arvids.

Re: [PHP-DEV] taint

[Arvids Godjuks]

I fully support your effort to get this into the PHP to be part of core
extensions, or at least one of those that keep up with the language
releases.
This is a very good tool to have, and you can actually run it in production
to catch things that may slipped the stating (things happen). And it's
invaluable during during testing.

Re: [PHP-DEV] Re: Adding numeric type hint

[Arvids Godjuks]

пн, 11 Май 2015, 10:21, Yasuo Ohgaki yohg...@ohgaki.net:

Hi all,


I've never wrote my blog in English, but I wrote one because peice by piece
discussion is not going to anywhere.

http://blog.ohgaki.net/dont-use-php7-type-hint-for-external-data

How many of you think current scalar type hint is useful enough to interact
with database/json/xml/yaml/rest/etc? We need numeric hint at least. IMHO.

If not, we need large warning sign in documentation as a last resort at
least.

Regards,

P.S. We may be better to declare 32 bit CPU support EOL by PHP 7 to reduce
the impact. We'll have the same issue when 128 bit CPU or 128 bits IEEE 754
float
became in common, though.

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


 Hello, I have read through your blog post, and I agreed on the issue
earlier, nut I have a question that bugs me for a while: what DoS issue are
you talking about? I tried to imagine any scenario that can lead to a DoS
wuith a type hint and can't think of any happening...

Re: [PHP-DEV] Adding numeric type hint

[Arvids Godjuks]

 Stop trying to fix clever idiots from shooting themselves in the foot. The
 standard result from these actions is to make life a pain for regular or
 better programmers while only adding mild speed bumps to those clever
 idiots.

 Things like a numeric type will only encourage the clever idiots to write
 half broken code.


Hello, just want to chip in.

I use INT UNSIGNED for the MySQL primary keys since ages, because
negative primary keys make no sense. Well, mostly ID's for the records
actually can stay strings, but I will have to remember to use a string type
hint every time I pass a record ID. I expect a lot of times to forget that
and write int...
I was bitten a few times by the limits of 32 bit integer sizes too (moved
to a 64 bit server that time), but there are also unsigned 64 bit integers
that can and will be used in math operations and passed around. And we
don't have the unsigned int.

Okay, we have GMP. I will have to use it. But let me just ask - if I work
with a DB handling 64 bit integers (all I know handle them) or use a
DECIMAL field - automaticly use GMP then? Oh gosh

Arvids.

Re: [PHP-DEV] Re: PDO Oracle driver

[Arvids Godjuks]

2015-04-24 12:59 GMT+03:00 Johannes Schlüter johan...@schlueters.de:

 On Fri, 2015-04-24 at 09:16 +0300, Arvids Godjuks wrote:
  May I question the sanity of the words written in this email? :D (it's a
  joke).
 
  The whole point of mysqlnd drivers and other improvements was to cut down
  on data copying, improving performance and doing a lot of other stuff.
  Moving PDO to a PHP implementation will kill it all: preformance will
  suffer, memory usage will skyrocket, dealing with charsets - I don't even
  wana pretend I understand how to deal with that part in a proper fasion.
  Doesn't it require access to internal PHP api's to do a lot of what PDO
 and
  other native drivers do?
  Well, the Zephyr could pitch in here, MAYBE, depending on how good it
  actually is and what it can do, but still, it feels more like a cruch to
 me.

 In many many different topics I stressed that we should do things in
 userland and use extensions only when needed for performance.

 Doing things in userland gives
   * better debugability
   * better understanding for users
   * lower entry barrier
   * faster development time
   * better ability to evolve (different library versions can coexist
 on a system, for old and new code)

 With the changes in PHP 7 this is viable for even more areas. What PDO
 does is very thin. And mind: If a user truly cares about the last bit of
 performance they won't use an abstraction, they use DBMS-specific SQL
 and cut out abstractions. But for many cases that level of performance
 matters, as usage of ORMs etc. show. Also mind that processing in the
 database server and network traffic probably cost way more time than a
 thin wrapper even in userspace (in real life, not in SELECT 1)

 johannes


 It may have a merit to try it out, and as I said - Zephyr is an
interesting idea to try - may work quite well considering.

Re: [PHP-DEV] Re: PDO Oracle driver

[Arvids Godjuks]

2015-04-24 4:42 GMT+03:00 Benjamin Eberlei kont...@beberlei.de:

 On Thu, Apr 23, 2015 at 3:45 PM, Arvids Godjuks arvids.godj...@gmail.com
 wrote:

  PDO is everywhere. Doctrine? Based on PDO.


 You can use mysqli, oci8 or sqlsrv for example without problems in
 Doctrine.

 Exposing some of the internal api of PDO as php functions (SQL Parser) I
 would bet it is possible to reimplement PDO in PHP code using mysqli etc..
 as drivers.

 I think we could discuss going that road as well and we could save
 ourselves maintaining some thousands of lines of C code.


May I question the sanity of the words written in this email? :D (it's a
joke).

The whole point of mysqlnd drivers and other improvements was to cut down
on data copying, improving performance and doing a lot of other stuff.
Moving PDO to a PHP implementation will kill it all: preformance will
suffer, memory usage will skyrocket, dealing with charsets - I don't even
wana pretend I understand how to deal with that part in a proper fasion.
Doesn't it require access to internal PHP api's to do a lot of what PDO and
other native drivers do?
Well, the Zephyr could pitch in here, MAYBE, depending on how good it
actually is and what it can do, but still, it feels more like a cruch to me.

Re: [PHP-DEV] Re: PDO Oracle driver

[Arvids Godjuks]

2015-04-23 17:02 GMT+03:00 Pierre Joye pierre@gmail.com:


 On Apr 23, 2015 8:45 PM, Arvids Godjuks arvids.godj...@gmail.com
 wrote:
 
  My view is that this really needs a good discussion and regardless of the
  desicions made - resource allocation to move it forward.
  Whatever the intent was originally for the PDO and and regardless of what
  the docs say about it, as Christoph has linked and quoted, the reality is
  PDO is everywhere. Doctrine? Based on PDO. Yii 1/2 ActiveRecord? PDO.
  Laravel's Eloquent ? PDO again. You get the picture.

 Not being in core is an issue with PDO. Sqlsrv is in pecl, maintained, and
 support both native and PDO.

I do not think it's a in core vs in pecl issue at all. It's the fact
that that it is data objects and it was new back in the day - the adoption
of it was lightning fast. It was easy to make an abstraction over it, it
fit to major patterns, like AR, like a glove.
Besides, installing DB modules for PHP under ubuntu is done by hand - it's
not built into the php5 package.

Re: [PHP-DEV] Re: ***SPAM*** [PHP-DEV] Refund on order 204-2374256-3787503

[Arvids Godjuks]

2015-04-23 15:56 GMT+03:00 Lester Caine les...@lsces.co.uk:

 On 23/04/15 13:46, Amazon.co.uk wrote:
  We are writing to confirm that we are processing your refund in the
 amount of £4.89 for your
  Order 204-2374256-3787503.

 Curious phishing attempt ... seems to have forgotten the aim? Or was
 there something stripped by the mail list?

 (Some hit PEAR list as well)

 --
 Lester Caine - G8HFL


Curiously enough - it's a book...
Someone used lists email while ordering a book?...

Anyway, I have to give points for entertainment it just brought :)

Re: [PHP-DEV] Re: PDO Oracle driver

[Arvids Godjuks]

чт, 23 Апр 2015, 13:00, Lester Caine les...@lsces.co.uk:

On 23/04/15 06:50, christopher jones wrote:
 Yes, we do recommend using OCI8 over PDO_OCI.  This is partly due to
 some inherent design and performance weaknesses of the overall PDO
 architecture.

 So, lets not mark PDO_OCI as dead just yet.

It's nice to hear that it's not only the pdo_firebird driver that is
restricted by PDO. Which why I was asking for a general review on the
situation on database access.

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


 Hello,

I can definetly make a case that PDO restricts MySQL too. It lacks a lot of
functionality comparing to mysqli. I also found out recently that you can't
have a named param appear in a query more than once (an OR case, where 2
fields are compared against sma e value). The more you work, the more you
understand that PDO was a hype, that never got finished and got almost
abandoned.

Re: [PHP-DEV] Re: PDO Oracle driver

[Arvids Godjuks]

My view is that this really needs a good discussion and regardless of the
desicions made - resource allocation to move it forward.
Whatever the intent was originally for the PDO and and regardless of what
the docs say about it, as Christoph has linked and quoted, the reality is
PDO is everywhere. Doctrine? Based on PDO. Yii 1/2 ActiveRecord? PDO.
Laravel's Eloquent ? PDO again. You get the picture.
It's all ponies and rainbows untill you start doing something besides the
basic typical website (wich I tend to get more and more nowdays, as my
experience growed to a certain level and projects started to get big and
serious). At that point you just start to hit those annoyances with the
PDO. Thank god I didn't hit a really big snag yet, but it caused me a few
headaces and ugly workarounds.  I just can't write a standalone script with
a different driver (mysqli) in a big application - chances are I need that
applications AR models, it's bussiness logic and so on.
I even once had to do a major server upgrade just because of the bug in PDO
- well, I have to confess it was due anyway in a year's time frame, but
works great as illustration to it's problems and how much attention it gets.
A lack of basic ping function: I had to emulate it by sending a SELECT
NOW() request every 30 seconds and make sure my MySQL server has a
connection timeout of atleast 60 seconds, so a long running CLI script can
do it's job. I do not remember why, but I was unable to reconnect after
loosing the connection - it was a while ago and may have changed since
then. Still, left a certain impression.

Anyway, not to dwell on my ramblings, the situation needs a long overdue
discussion. A dealogue with the respective database developers would be
helpfull, if not instrumental, in changing things around.


Answering to Matteo Beccati's email:
Not everyone has C knowlage (nor leared it at any point in their career).
On top of that it's databases we are talking about - how many people are
able to develop proper drivers for DB's?
And not everyone has the funding to sponsor things like these. I certanly
nor have the money, nor I know of anyone who I could give the task to do
it. I'm from small Baltic country - I do not think we have any brains here
that are up to the challenge, atleast I have no idea of anyone even remotly
in this country despite my over 10 years in webdev.
My thinking is that things like these have to be spearheaded by the
respective database developers with the help of the PHP core team and the
community.

Re: [PHP-DEV] Voting irregularities

[Arvids Godjuks]

C'mon guys, vote didn't pass, it's time to do something about it and not
start conspiracy theories (or I will loose hope for humanity completely). I
happened to have a job-free next week, i've been saying for a long time now
that this has to be tackled differently and even layed down some thoughts
on this. I do not think this can be done in single RFC, too much things to
handle, too much things are left out, many things are ignored by the RFC
people.

What we need, is a MANAGER! To manage the Type Hint development. And one
that is not doing real development on PHP core, but someone with
understanding.
I can offer myself at this point. I do not really care if thouse would be
strict or coercive type hints as long as it's not the dual mode stuff.

Re: [PHP-DEV] Voting irregularities

[Arvids Godjuks]

2015-03-15 20:55 GMT+02:00 Levi Morrison le...@php.net:

  What we need, is a MANAGER! To manage the Type Hint development. And one
  that is not doing real development on PHP core, but someone with
  understanding.

 You are basically saying we should hand development of a critical
 language feature over to someone not doing real development on the
 language. I don't see how that could possibly end well.

I'm saying you need a manager to orginize the process, and as I see it,
make it a multi-version effort, like the OOP has evolved. Well, I probably
over-generalized. It has to be atleast a userland developer with good
amount of PHP development experiense under his/her belt to understand, he
needs to have patiense, and above all, he needs to discipline himself on
amount of writing and replying, otherwise it will get messy again. It can
be a core dev too, it's just from what I have seen, people push their own
agenda too much when they are the developer behind the RFC. It's good over
all, but I think this paticular case is an exception.

And based on how long the type hints are taking to get anywhere, I say it
needs some special handling.

Type hints mutated over time from a simple proposal into something big,
over-engeneered and over-agressive. I have never seen a feature so complex
being done in a single go into PHP since i'm folowing internals list, and
that's since late days of PHP4...

So, long story short: I suggest we restructure the effort and have someone
impartial at the helm mediating the work being done, draw some lines and
execute a plan people can agreee on.

Re: [PHP-DEV] A plea for unity on scalar types

[Arvids Godjuks]

пт, 13 Мар 2015, 23:01, Philip Sturgeon pjsturg...@gmail.com:

 Pavel,

 On Fri, Mar 13, 2015 at 3:38 PM, Pavel Kouřil pajou...@gmail.com wrote:
  On Fri, Mar 13, 2015 at 4:45 PM, Anthony Ferrara ircmax...@gmail.com
 wrote:
 
  But for today, I firmly believe that the Dual-Mode proposal is the
  only one that stands a chance of passing. I think it's the best chance
  for the language, and it's the only one that tries to unite the
  different usages of PHP into a single group, rather than alienating
  users.
 
 
  Hello,
 
  I see (as a userland developer) these problems with dual mode:
  - It is a setting that changes the language's behavior; I don't
  think that it matters whether or not it would be an INI setting or the
  declare() one, because both of them are bad.
  - It does not unite different usages of PHP into a single group; it
  does exactly the opposite, splitting PHP usage into TWO groups.
  - Once this dual mode would be introduced to PHP, there would probably
  be no way of removing it later without massive BC break, once most
  people would realize that it is really awful to have it in the
  language.
 
  (There's probably more of them, but these are the biggest issues I
  currently have.)
 
  Regards
  Pavel Kouril
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 

 Hang on. This is not the time to nitpick things in various RFCs that
 have already been answered time and time again.

 An ini setting would be insane because taking an app that works on one
 machine and putting it on another would completely break the app.
 Hello anything using Composer, hello any CMS, hello any system moving
 to a new host that doesn't let you change ini settings, or you dont
 know how.

 A declare statement in the top of the file changing how that file
 handles things is hardly a problem, and is exactly how a lot of other
 languages do things. Hello JavaScript.

 It seems like you didn't read anything now you're just saying it's
 bad a lot. Please don't do that.

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

 That declare thing with the removal of block-aware declare(){} kills one
of the fundamental optimizations you can do for large PHP projects -
compacting most used files into one single big file and caching it. And you
never had to  care what the files are - just splice it all together and let
autoload handle the rare cases. With single declare statement I effectivly
have to scan all the code, remove declare statements and choose a mode
globally. Well, it might work for a small project, but in a big project
with multiple teams or even multiple vendors doing different parts

At this point I have only swearing words for the proposing persons and
supporters.
It's magic_quotes and register_globals all over again, but this time you
can't fix it with some PHP code.

You really had to fuck it all up for us, the userland developers, didn't
you?

Sorry, but I now question the wisdom and sanity of most new PHP folks.
Because the old once see the danger and vote no. And everyone just thinks
they act up. Well, you wrong. I will nit be surprised if they just leave
the project for good after this.

Re: [PHP-DEV] A plea for unity on scalar types

[Arvids Godjuks]

Opcode caches just cache the compiled code - you still need to load the
code into the engine, do checks for file modifications and other stuff.

Yes, if you are a badass and have full controll, all that can be solved.
Reality, however, is one big f***up. I had to fix a lot of weird stuff,
including the cases where there was some kind of opcode cache and it still
was horrible. Or shared enviroment. Or just bad code. You havent seen
FTP/SFTP project deployment in last few years? I envy you. You work for
godly clients. Or it's just that you are a rockstar in a rockstar friendly
company with resources and will to do things right. But most of us a far
lower in the food chain. We have to deal with things that would give you
nightmares.

Or take most of Open Source PHP code - besides a few high quality projects
like Symfony and the bunch, it's bad. And I know one instanse of an Open
Source project with PHP part that will go full retard mode with strict
typehints no matter the cost or consiquences. Probably will end up killing
the company behind it in the long run.

There is one thing that you learn when you actually go beyound the coding:
never ever give user a choise - he doesn't know what he wants anyway. He
thinks he needs one thing, in reality tests show absolutelly different
stuff. You need to make a decision select a way you wana do it. It newer
works out with choises - people always make a mess.

сб, 14 Мар 2015, 1:11, Benjamin Eberlei kont...@beberlei.de:

 On Sat, Mar 14, 2015 at 12:02 AM, Arvids Godjuks arvids.godj...@gmail.com
  wrote:

 пт, 13 Мар 2015, 23:01, Philip Sturgeon pjsturg...@gmail.com:

  Pavel,
 
  On Fri, Mar 13, 2015 at 3:38 PM, Pavel Kouřil pajou...@gmail.com
 wrote:
   On Fri, Mar 13, 2015 at 4:45 PM, Anthony Ferrara ircmax...@gmail.com
 
  wrote:
  
   But for today, I firmly believe that the Dual-Mode proposal is the
   only one that stands a chance of passing. I think it's the best
 chance
   for the language, and it's the only one that tries to unite the
   different usages of PHP into a single group, rather than alienating
   users.
  
  
   Hello,
  
   I see (as a userland developer) these problems with dual mode:
   - It is a setting that changes the language's behavior; I don't
   think that it matters whether or not it would be an INI setting or the
   declare() one, because both of them are bad.
   - It does not unite different usages of PHP into a single group; it
   does exactly the opposite, splitting PHP usage into TWO groups.
   - Once this dual mode would be introduced to PHP, there would probably
   be no way of removing it later without massive BC break, once most
   people would realize that it is really awful to have it in the
   language.
  
   (There's probably more of them, but these are the biggest issues I
   currently have.)
  
   Regards
   Pavel Kouril
  
   --
   PHP Internals - PHP Runtime Development Mailing List
   To unsubscribe, visit: http://www.php.net/unsub.php
  
 
  Hang on. This is not the time to nitpick things in various RFCs that
  have already been answered time and time again.
 
  An ini setting would be insane because taking an app that works on one
  machine and putting it on another would completely break the app.
  Hello anything using Composer, hello any CMS, hello any system moving
  to a new host that doesn't let you change ini settings, or you dont
  know how.
 
  A declare statement in the top of the file changing how that file
  handles things is hardly a problem, and is exactly how a lot of other
  languages do things. Hello JavaScript.
 
  It seems like you didn't read anything now you're just saying it's
  bad a lot. Please don't do that.
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 
  That declare thing with the removal of block-aware declare(){} kills one
 of the fundamental optimizations you can do for large PHP projects -
 compacting most used files into one single big file and caching it. And
 you
 never had to  care what the files are - just splice it all together and
 let
 autoload handle the rare cases. With single declare statement I effectivly
 have to scan all the code, remove declare statements and choose a mode
 globally. Well, it might work for a small project, but in a big project
 with multiple teams or even multiple vendors doing different parts


 The same is true for namespaces, but Symfony for example works around it
 by introducing block syntax.
 You can just remove the declares, during concatenation, or move a single
 strict to the top.

 Also this is not a fundamental optimization (I'd argue never has been)
 anymore since opcache is in core of PHP since 5.5


 At this point I have only swearing words for the proposing persons and
 supporters.
 It's magic_quotes and register_globals all over again, but this time you
 can't fix it with some PHP code.

 You really had to fuck it all up for us, the userland developers, didn't
 you

Re: [PHP-DEV] A plea for unity on scalar types

[Arvids Godjuks]

And actually, I would plea for a moment of sanity right now.

As far as i'm concerned - the RM for the 7.0 had to step in a long time ago
and said guys, I do not accept any typehint proposals into the 7.0
release, work it out and come back for 7.1.
Because if this would be a commercial development before a release -
feature would be scrapped and re-sheduled for later release.
Why? Because the clusterf**k happened at RFC level already, the development
itself is going to be haisty considering the timeline and definetly being
bombarded by the protesters, countless critisism and so on. It is going to
affect the projects. And that is a bad thing. Look past the damn typehint
RFC's and just try to asses the big picture. Right now it's a tunnel vision
for many on the list.

сб, 14 Мар 2015, 1:29, Arvids Godjuks arvids.godj...@gmail.com:

 Opcode caches just cache the compiled code - you still need to load the
 code into the engine, do checks for file modifications and other stuff.

 Yes, if you are a badass and have full controll, all that can be solved.
 Reality, however, is one big f***up. I had to fix a lot of weird stuff,
 including the cases where there was some kind of opcode cache and it still
 was horrible. Or shared enviroment. Or just bad code. You havent seen
 FTP/SFTP project deployment in last few years? I envy you. You work for
 godly clients. Or it's just that you are a rockstar in a rockstar friendly
 company with resources and will to do things right. But most of us a far
 lower in the food chain. We have to deal with things that would give you
 nightmares.

 Or take most of Open Source PHP code - besides a few high quality projects
 like Symfony and the bunch, it's bad. And I know one instanse of an Open
 Source project with PHP part that will go full retard mode with strict
 typehints no matter the cost or consiquences. Probably will end up killing
 the company behind it in the long run.

 There is one thing that you learn when you actually go beyound the coding:
 never ever give user a choise - he doesn't know what he wants anyway. He
 thinks he needs one thing, in reality tests show absolutelly different
 stuff. You need to make a decision select a way you wana do it. It newer
 works out with choises - people always make a mess.

 сб, 14 Мар 2015, 1:11, Benjamin Eberlei kont...@beberlei.de:

 On Sat, Mar 14, 2015 at 12:02 AM, Arvids Godjuks arvids.godj...@gmail.com
  wrote:

 пт, 13 Мар 2015, 23:01, Philip Sturgeon pjsturg...@gmail.com:

  Pavel,
 
  On Fri, Mar 13, 2015 at 3:38 PM, Pavel Kouřil pajou...@gmail.com
 wrote:
   On Fri, Mar 13, 2015 at 4:45 PM, Anthony Ferrara 
 ircmax...@gmail.com
  wrote:
  
   But for today, I firmly believe that the Dual-Mode proposal is the
   only one that stands a chance of passing. I think it's the best
 chance
   for the language, and it's the only one that tries to unite the
   different usages of PHP into a single group, rather than alienating
   users.
  
  
   Hello,
  
   I see (as a userland developer) these problems with dual mode:
   - It is a setting that changes the language's behavior; I don't
   think that it matters whether or not it would be an INI setting or
 the
   declare() one, because both of them are bad.
   - It does not unite different usages of PHP into a single group; it
   does exactly the opposite, splitting PHP usage into TWO groups.
   - Once this dual mode would be introduced to PHP, there would
 probably
   be no way of removing it later without massive BC break, once most
   people would realize that it is really awful to have it in the
   language.
  
   (There's probably more of them, but these are the biggest issues I
   currently have.)
  
   Regards
   Pavel Kouril
  
   --
   PHP Internals - PHP Runtime Development Mailing List
   To unsubscribe, visit: http://www.php.net/unsub.php
  
 
  Hang on. This is not the time to nitpick things in various RFCs that
  have already been answered time and time again.
 
  An ini setting would be insane because taking an app that works on one
  machine and putting it on another would completely break the app.
  Hello anything using Composer, hello any CMS, hello any system moving
  to a new host that doesn't let you change ini settings, or you dont
  know how.
 
  A declare statement in the top of the file changing how that file
  handles things is hardly a problem, and is exactly how a lot of other
  languages do things. Hello JavaScript.
 
  It seems like you didn't read anything now you're just saying it's
  bad a lot. Please don't do that.
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 
  That declare thing with the removal of block-aware declare(){} kills
 one
 of the fundamental optimizations you can do for large PHP projects -
 compacting most used files into one single big file and caching it. And
 you
 never had to  care what the files are - just splice it all together and
 let
 autoload handle the rare

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

[Arvids Godjuks]

2015-03-12 11:23 GMT+02:00 Zeev Suraski z...@zend.com:

  -Original Message-
  From: Bob Weinand [mailto:bobw...@hotmail.com]
  Sent: Thursday, March 12, 2015 12:46 AM
  To: Pierre Joye
  Cc: PHP internals
  Subject: Re: [PHP-DEV] [RFC] Basic Scalar Types
 
  Correct. It's just for the case where the other two fail.
  We still can add strict mode in a later version if people need it.
  All the RFC does is the most basic scalar type hinting you can build
 everything
  on. (for example adding the declare(strict_types=1); would work without
 any
  BC break on top of it)

 The issue is that it's only possible to open the voting on this one until
 tomorrow.

 As I said, I do think we need *something* for 7.0.  I went as far as
 saying that I'd change my vote on the quite-bad-IMHO dual mode RFC to yes
 if it seems both present proposals aren't going to succeed.  But I would
 much rather see this one pass over the dual mode if it was available for a
 vote.

 So really, the options we have are:

 1.  Put this one for a vote before the end of tomorrow.  Here too, on a
 personal level, if I see that this proposal isn't gaining enough votes,
 I'd support the dual mode one.
 2.  Don't put it up for a vote, and then we may or may not have something
 for 7.0.

 Zeev

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


At this point I think the best way is to reserve the keywords for
typehints, and not the only 4, but also for resource and null. And work
towards making typehints in 7.1.
Rushing things like it's now never lead to any good results. And that
dual-mode RFC is re-incarnation of the register_globals, just in a
different way. But essentially will make the same mess.

Re: [PHP-DEV] Consistent function names

[Arvids Godjuks]

2015-03-12 4:08 GMT+02:00 Lester Caine les...@lsces.co.uk:

 On 11/03/15 22:44, Yasuo Ohgaki wrote:
  Having namespace for internals would bring much flexibility for API
 changes, both
  OO and procedural API. I may try my best to have consensus.
 
  I think you also like to have OO style API for basic
  variables(int/float/array) as I am.
  Unless we have good/proper procedural API names, it would be an obstacle
 to
  have OO style API for basic variables. I wish you agree to do something
 for it.

 Personally I just want to keep the current name set and so the sheer
 volume of changes proposed is a big kick in the face to me. People are
 talking about the need for an OO based interface, but there has been no
 comment by anybody as to how that should be styled. Having switched
 everything to camelCase as part of the E_STRICT reworking that is
 already well established so while I can see why you want to complete a
 complete switch to underscore padded names THAT is not consistent with
 what everybody else is already using?

 There should not be two naming styles running in parallel and that is
 all I am objecting to. If you get support for this RFC then both an
 extended namespace name set and OO based objects should all follow the
 same rules, and THAT is not what has been happening?

 I think it is equally valid to ask if the current naming guide IS still
 appropriate or if a switch to camelCase for every name space is more
 practical moving forward. In which case dropping the extra underscores
 makes more sense than adding hundreds more! That a name can be written
 all lower case, all upper case or any combination is more a matter of
 choice, but as you say error messages adopt a standard that may not
 match what is in the code anyway?

 --
 Lester Caine - G8HFL


Basically this.

Yasuo asked me some time ago how do I see the new interface, and to be
frank, I do not see a new procedural api interface at all. We have one now,
and adding a new subset of it looks pointless. It has it's problems and
legacy, you can't really fix it. Maybe some adjustments are in order to
make it more consistent where it can be done.

I really see only the OO API as a new additional interface. It's part
started by the DateTime, the MySQLi classes and stuff. At this point all
that stuff can be still namespaced, adjusted if needed and continued, just
from the std library first.
I, actually, use _ for function and variable naming and camelCase for
object methods and properties.  To be frank, I like it - it visually
clearly separates the code styles and for the most part the PHP code is
written that way (well, the MySQLi has -num_rows and stuff - i'd change it
to -numRows and so forth).

Arvids.

Re: [PHP-DEV] Consistent function names

[Arvids Godjuks]

2015-03-12 11:41 GMT+02:00 Lester Caine les...@lsces.co.uk:

 On 12/03/15 09:21, Arvids Godjuks wrote:
  Basically this.
 
  Yasuo asked me some time ago how do I see the new interface, and to be
  frank, I do not see a new procedural api interface at all. We have one
  now, and adding a new subset of it looks pointless. It has it's problems
  and legacy, you can't really fix it. Maybe some adjustments are in order
  to make it more consistent where it can be done.
 
  I really see only the OO API as a new additional interface. It's part
  started by the DateTime, the MySQLi classes and stuff. At this point all
  that stuff can be still namespaced, adjusted if needed and continued,
  just from the std library first.
  I, actually, use _ for function and variable naming and camelCase for
  object methods and properties.  To be frank, I like it - it visually
  clearly separates the code styles and for the most part the PHP code is
  written that way (well, the MySQLi has -num_rows and stuff - i'd change
  it to -numRows and so forth).

 This is exactly the same point I've come to ...

 That MySQLi example is exactly what I am talking about. I know Postgres
 driver has been 'underscored' but it is THAT which is out of sync with
 the rest of the code base. interbase driver has the same problem, and we
 will need to bring in fbird_ to replace ibase_ there, but I use ADOdb
 almost exclusively which has been CamelCase since day one ( all be it
 with a leading capital ). PDO is camelCase but that has other problems ;)

 If there has to be any tidy up, like you, I think switching back to
 loose some underscores is the less painful option.

 --
 Lester Caine - G8HFL


Do you mean the PostgreSQL driver needs to be changed from pg_blah() to
pgBlah() ?
If that's the case - why? For procedural API that's totaly fine. As I said,
I think the functions with _ word separator are totaly fine and it's really
no need to change that.
The OO interface, that needs to be build eventually, that one should use
camelCase for all the methods and properties.
This way the code style clearly separates the OO inteface and the
procedural interface. And I think it's good. At least it served me well all
my 10+ years with PHP.

Arvids.

Re: [PHP-DEV] Consistent function names

[Arvids Godjuks]

2015-03-05 22:20 GMT+02:00 Yasuo Ohgaki yohg...@ohgaki.net:

 Hi Arvids,

 On Thu, Mar 5, 2015 at 9:32 PM, Arvids Godjuks arvids.godj...@gmail.com
 wrote:

 2015-03-05 13:49 GMT+02:00 Pierre Joye pierre@gmail.com:
 
 
  I will say it again a last time, in my opinion only a clean API;
  object-like or real object as long as performance is not affected is
  the only way I could see to actually solve this problem.
 
  Changing the names, argument order (pointless once we will have named
  arguments, btw) and similar solutions are band aids solutions,
  confusing at best, terrible at worst. It is pointless to do it after
  almost two decades for some of them.
 
  --
  Pierre
 
  I'm with Pierre here.
 Adding aliases is gonna mess up things even more. For example -
 autocomplete will become hard to navigate. It's already quite lengthy list
 a lot of the times and it's easier just to write the whole function name
 sometimes by hand. Adding aliases will make it worse.


 I agree. Therefore, I'm going to update manual also so that it recommends
 main function, not aliases. Aliases should be alternative.

 Manual and IDE don't have to list all of them. New manual lists only main
 functions, does not have dedicated pages for aliases but aliases are
 mentioned
 in main function page as aliases.



 We really need a new API, that is not crossing paths with the old. That
 way
 people can start building stuff on new API's and we could phase out the
 old
 mess, for example: depricate in PHP8, remove in PHP9.
 Stop-gap measures have created enough problems already, or did everyone
 suddenly got an amnesia and forgot all the past lessons on the list?


 PHP should be multi paradigm language, not pure OO language.
 IMO. Python does good job.

 Python is a multi-paradigm programming language: object-oriented
 programming
 and structured programming are fully supported, and there are a number of
 language features which support functional programming and aspect-oriented
 programming
 http://en.wikipedia.org/wiki/Python_%28programming_language%29

 It sounds like there are people who would like to discard procedural APIs.
 PHP has born as procedural language. It will not happen in short term at
 least. We are far from having rich and good enough OO APIs sets to make
 PHP a pure OO languages.

 This leads to conclusion that we need to maintain/improve procedural APIs
 even if we are going to make PHP a pure OO language.

 I finally understand why some of us against this change and suggest OO APIs
 as alternative. It's reasonable making procedural APIs a
 legacy/unmaintained/
 messed up to discard  procedural APIs someday. I'm against it. PHP should
 be like Python in this regard. IMO.

 Regards,

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


Why not take advantage of namespaces and do the new API, building it up
version by version (sure it can't be done in one go), so probably the
extensions gonna follow too.
That allows you to use as OO interface, so do the functions. Well, yes, it
will be under a namespace, but at least new projects can be started that
way. And old code will be easy enough to port, it's mostly a question of
refactoring tools.

Aliasing is a stop-gap measure, isn't it? API's tend to get redesigned and
PHP's is due to a major makeover. So, why not embrace it? No one's forcing
to retire the old one any time soo, and I belive people understand it will
be a very long time before it is phased out, if ever (well, I think in like
20 years probably is doable). And if done right, it may be done in a way
that if you don't need it, you can leave out the old API on compile stage -
not sure if doable thought.

Arvids.

Re: [PHP-DEV] Consistent function names

[Arvids Godjuks]

2015-03-05 13:49 GMT+02:00 Pierre Joye pierre@gmail.com:


 I will say it again a last time, in my opinion only a clean API;
 object-like or real object as long as performance is not affected is
 the only way I could see to actually solve this problem.

 Changing the names, argument order (pointless once we will have named
 arguments, btw) and similar solutions are band aids solutions,
 confusing at best, terrible at worst. It is pointless to do it after
 almost two decades for some of them.

 --
 Pierre

 I'm with Pierre here.
Adding aliases is gonna mess up things even more. For example -
autocomplete will become hard to navigate. It's already quite lengthy list
a lot of the times and it's easier just to write the whole function name
sometimes by hand. Adding aliases will make it worse.

We really need a new API, that is not crossing paths with the old. That way
people can start building stuff on new API's and we could phase out the old
mess, for example: depricate in PHP8, remove in PHP9.
Stop-gap measures have created enough problems already, or did everyone
suddenly got an amnesia and forgot all the past lessons on the list?

Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)

[Arvids Godjuks]

2015-02-19 17:14 GMT+02:00 Pierre Joye pierre@gmail.com:

 On Thu, Feb 19, 2015 at 7:11 AM, Arvids Godjuks
 arvids.godj...@gmail.com wrote:

  I think this starts to go the route of putting things into absolute.
 Ideal
  things tend not to happen/work in the real world to the letter.
 
  Some things just don't work out by themselves. The Type Hinting RFC's
 are an
  anomaly in the regular PHP Core workflow and need some creative handling.

 No it is not an anomaly but a standard way for some since too long.
 And we need to fix this.


I meant it in a way that no other RFC has failed so many times or had so
much misunderstanding or divide.
Sometimes it is required to ditch the preferences of people and do stuff
for the greater good. Right now I see most people (not all) pushing their
own agendas not really giving a damn over the big picture, the timeline and
the fact that at this moment RFC already too late for 7.0 according to the
Release Process RFC - they cannot be discussed and voted before the feature
freeze. Yes, it can be pushed rather easily, but it means breaking the
release process RFC again. See the pattern here?

And we have the 0.4 version still being made, so it means it will be out
for discussion probably next week. Or may not.

Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)

[Arvids Godjuks]

2015-02-19 17:41 GMT+02:00 Anthony Ferrara ircmax...@gmail.com:

 Arvids,

  I meant it in a way that no other RFC has failed so many times or had so
  much misunderstanding or divide.

 No scalar type proposal has made it through a vote. So none of them
 have technically failed (all except the current one were withdrawn).



Technically - agreed, but overall you can see how it may be considered as
failed :)



  Sometimes it is required to ditch the preferences of people and do stuff
  for the greater good. Right now I see most people (not all) pushing their
  own agendas not really giving a damn over the big picture, the timeline
 and
  the fact that at this moment RFC already too late for 7.0 according to
 the
  Release Process RFC - they cannot be discussed and voted before the
 feature
  freeze. Yes, it can be pushed rather easily, but it means breaking the
  release process RFC again. See the pattern here?

 Well, 0.5, as a minor tweak on 0.3 *could* (by the RFC process) go to
 vote on the 25th. Which would end on the 11th. A full 4 days before
 freeze. Without breaking the release process.

 However, I would be happy to target 7.1 even if the vote passes prior
 to freeze (assuming an RFC to reserve the scalar type names is
 proposed and passes, otherwise 8.0).

 My reason for pushing for the vote is not to get it into 7, but to get
 it over with. We've been discussing these proposals for years. We have
 one that came extremely close to passing (save for a few minor issues
 people voted no to, which are now fixed). Let's get it behind us.


At this point my main concern is the fact that it's going to be rushed.
Rushed means mistakes, things overlooked and timeline getting shifted like
with 5.6. The overall picture (maybe i'm thinking like a RM here).



  And we have the 0.4 version still being made, so it means it will be out
  for discussion probably next week. Or may not.

 No, it's not being made. See the first post to this thread.

 Anthony


I read the mails and my feeling is that something is brewing between Sara,
Zeev and Francois. At least that's my impression, that people are working
and they will have something to show. I never saw a direct we are dropping
it, just a vague it's essentially dead addressed directly to me by
Francois and after that he started to be even more active. So, all
indications, something's happening :)

Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)

[Arvids Godjuks]

2015-02-19 16:51 GMT+02:00 Pierre Joye pierre@gmail.com:

 On Thu, Feb 19, 2015 at 6:33 AM, Zeev Suraski z...@zend.com wrote:
  -Original Message-
  From: Pierre Joye [mailto:pierre@gmail.com]
  Sent: Thursday, February 19, 2015 4:09 PM
  To: Zeev Suraski
  Cc: Anthony Ferrara; PHP internals
  Subject: Re: [PHP-DEV] Using Other Channels (was Scalar Type
 Declarations
  v0.5)
 
  We have seen off list discussions or pressures many times in the pasts.
 I
  have
  (other too but I can only talk for myself) been said an insane amount of
  times
  to stop private discussions, for anything related to php core. There is
 no
  exception to this rule. I repeat:
  There is NO exception to this rule.
 
  I disagree.  Completely.

 I did not expect you to agree. I would be surprised if you do.

  I think 1:1 or group discussions are completely legitimate, and they're
 not
  only legitimate - they can be very productive.
 
  There's a huge gap between making decisions in closed groups, or doing
 'arm
  bending' - and private discussions, which I repeat, are completely
  legitimate.
  Private discussions happen all the time, in countless mediums.
 Conferences,
  emails, IRC (public in theory, private in practice), Twitter DMs and
 more.
 
  There's absolutely nothing wrong with discussing an idea directly with
 one
  or more people before bugging thousands of people with it.  They'd all be
  better served if the idea presented to them already had a slightly more
 than
  just one person standing behind it (which is an inherent side effect of
  barring private discussions as you suggest), and had some of the initial
  issues weeded out.

 To discuss at an idea or concept at events and co? Indeed. We all do
 that. The difference is how to move it to a group discussions and grab
 other people thoughts to actually get it done, with consensus. The
 latter part is totally absent using your process.

 Discussing,  working, implementing something for weeks or months
 privately? NDA and all that? Sorry, this is not the PHP I want.

 Weeding out the initial issues? I wonder which magic you use to be
 able to figure out all issues based on the experiences or thoughts of
 a couple of people. It does not work. What you say is that a very
 small group is able to pin point the perfect proposal better than
 actually discussing it on the open channels. This is wrong in so many
 ways.

 Cheers,
 Pierre

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


I think this starts to go the route of putting things into absolute. Ideal
things tend not to happen/work in the real world to the letter.

Some things just don't work out by themselves. The Type Hinting RFC's are
an anomaly in the regular PHP Core workflow and need some creative
handling. My personal view is that the RFC requires a mediator - the
person. who is more or less impartial to what type of hints get into PHP
and is able to handle communications between groups and bring them
together. RFC needs a triage. It needs someone to make a game plan and
implement it. Not someone developing one or the other proposal, but a
strictly managing entity. Because the further we go, the more things are
need to be taken care of. I believe the Type Hint project reached the
point, where it can't be handled by a single person. It touches into some
other RFC's in one or the other way, sometimes maybe requiring some
adjustments in the related RFC or the type hints itself.

Also, whatever way it goes at this point, the RFC's are not going to make
into 7.0 if we follow the release process properly. So, there needs some
decision making to happen considering the PHP itself, like reserving
keywords for 7.0, doing typehints for 7.1 and stuff alike.

Maybe it does not look like I have described it from inside, but from the
side it looks like a disaster is brewing and it's gonna blow any second now
leading to rushed decisions that may screw up things. I saw similar
situations a few times in my carrier and I certainly have that feel right
now. I'd give it 50/50 chance that something will go wrong here.

Re: [PHP-DEV] Re: I quit.

[Arvids Godjuks]

2015-02-16 17:26 GMT+02:00 Daniel Lowrey rdlow...@php.net:

 On Mon, Feb 16, 2015 at 10:19 AM, Zeev Suraski z...@zend.com wrote:
 
   -Original Message-
   From: rdlow...@gmail.com [mailto:rdlow...@gmail.com] On Behalf Of
   Daniel Lowrey
   Sent: Monday, February 16, 2015 5:13 PM
   To: internals@lists.php.net
   Subject: [PHP-DEV] Re: I quit.
  
The 0.1 RFC version was mentioned a lot as a good compromise by many
people and had major support.
  
   Any proposal to the scalar hints problem that doesn't definitively
 error
   out in
   the `(int) apple` case is a non-starter for me; I believe such
 solutions
   are
   disingenuous at best and dangerous at worst.
 
  Weak type hints the way Andrea proposed them in v0.1 actually did not
 accept
  Apple as an int (wiki.php.net/rfc/scalar_type_hints?rev=1420209410):
 
  †Non-numeric strings not accepted. Numeric strings with trailing
 characters
  produce a notice.
 
  † applied to both int and float type hints in case of string inputs.
 
  Judging by both this and Anthony's message from a couple of days ago
 giving
  the same Apple example, perhaps v0.1 wasn't clearly understood.
 
  Zeev


 Perhaps I should've been more explicit: Numeric strings with trailing
 characters produce a notice. is also unacceptable.

 curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, true);


 ^ It's my own personal opinion, but as I said before and still believe,
 allowing such behavior is disingenuous at best and dangerous at worst.


This bickering already jeopardized the type hinting RFC's how many times? 3
as I recall?

Right now we need a breakthrough event - get type hints into the language
at all. The most sensible thing to do it is to add basic type hints that
work like the current conversion rules, maybe add some notices/warnings for
some cases. Or adjust the conversion rules themselves in line with the new
type hints.
Whatever type of typehints I like personally better does not matter, what
matters is what is fitting the language and is reasonable. And what leaves
improvement avenues for the future. It is better to make smaller changes,
than making a god type feature and then realizing that, if something got
messed up badly, you can't fix it, because it is already a BC issue.

I always liked the incremental nature of PHP maturing and adding features.
Just stick with it, do the typehints in increments. Be patient.

It's not like next release after 7.0 is going to take a years like before,
we have releases every year now.

[PHP-DEV] Re: Reviving scalar type hints

[Arvids Godjuks]

2015-02-16 18:42 GMT+02:00 François Laupretre franc...@php.net:

 Hi,
 
  De : Arvids Godjuks [mailto:arvids.godj...@gmail.com]
 
  The 0.1 RFC version was mentioned a lot as a good compromise by many
  people
  and had major support.
  Maybe someone competent could pick it up, make necessary adjustments
  that
  where required and let people vote on it? Start with small steps - get
 the
  weak type hints into the language first, see how it gets used and then we
  can always add strict type hints if there is a need/desire to do that.
 
  That way we finally get type hints into the language, and those wanting
 the
  strict variety have all the opportunities in the world to add them at a
  later release with proper discussion and development time.

 That's what I am planning. If I write an RFC, it will be based on Andrea's
 0.1/0.2 version, and won't propose different modes.

 The problem is that the previous controversial RFC focused people on weak
 vs strict typing, while we should have explored other technical concerns.
 Here are the main ones I see :

 - the fact that the RFC supports single types only, like the previous
 'return type' RFC. While it is easier to implement, it opens several issues
 as multiply-typed arguments are an integral part of the PHP language
 (mostly completeness and compatibility with internal function hinting). If
 we want to support multiple types the same way for internal and userspace
 functions, we must extend the ZPP layer to support it.

 - the mechanism to check for type hints on internal functions, while easy
 to implement, is not sufficient, as a lot of internal functions get a bare
 zval from the parsing system and then convert it by themselves. With the
 proposed mechanism, there's no possible hinting on such argument, which
 will make the implementation different from the documentation. Even if the
 check is done by the function body, it won't be done in a consistent way
 with type hinting checks and won't raise a similar error. As most cases are
 related to multiply-typed args, the solution is in adding multiply-typed
 support to ZPP. Multiply-typed support needs to redefine scalar conversion
 rules, to take care of the target type being a combination of single types.

 - We need to define the appropriate extension to Reflection
 parameters/return type. That's not complex, but it takes time.

 - Other changes I'd like to propose are exposed in Bob Weinand's article,
 at https://gist.github.com/bwoebi/b4c5564388ecd004ba96. The article
 explains how restricting weak conversion possibilities would make strict
 typing almost useless. Changes include forbidding bool to int/float or
 '7years' to int. This cannot be left for future additions as BC breaks will
 make it impossible. To remain consistent between userspace/internal
 functions, this must also be done at the ZPP level.

 - Using bare class names as type hints is a potential issue too, as it
 makes reserved keywords and class names share the same naming space. I
 think we should deprecate the use of class names as type hints in favor of
 'object(class-name)'. If we don't do that, every future addition of a type
 hint keyword will cause a BC break (and will be practically impossible).

 - Additional 'hybrid' types like 'numeric' and 'mixed' should be also
 provided.

 So, most features I have in mind are really 'now or never'.

 My main concern, anyway, is with March 15 announced feature freeze. If we
 need a vote by this date, it's impossible. And planning such BC for 7.1 is
 probably unrealistic because of the huge syntax additions and BC breaks it
 brings. So, if it's too late for an inclusion in 7.0, I think I'll give up.

 So, could someone confirm what 'feature freeze' exactly means ?

 Regards

 François








  The main issues are completeness (we can give hints for some cases, but
 not for others) and, more important, the compatibility with internal
 functions. As Andrea herself agreed, her mechanism for type hinting on
 internal functions is not sufficient. Just using the ZPP macros, as they
 exist today, won't work as a lot of internal functions get a bare zval and
 then convert it by themselves. So, in this case, we would check nothing.
 So, an argument described as 'string|array' in the documentation, wouldn't
 produce the same sort of error when sent an object, than its friend,
 described as 'string'. This is not consistent and will open a lot of side
 effects if it is left out of the type hint layer.


Sounds quite reasonable and level headed. I'm gonna contact you off-list to
assist in any way I can, i'll be damned if RFC fails 4th time...

Re: [PHP-DEV] Reviving scalar type hints

[Arvids Godjuks]

Might I remind everyone that time is not on our side here - feature freeze
is looming and actual work has to be done.
The part you must understand is: Strict type hints are possible if someone
cares to implement them with a next RFC. Be our guest. Right now we need to
sort out the basic stuff - the missing numeric/mixed/resource hints, the
ability to define mixed hints and make it all consistent. Maybe even
fix/change some of conversion rules as a result (i'm just giving an example
here).

Gives us some time to gather our thought, discuss stuff and do the update
to the RFC. Asuming stuff and pointing fingers before new version is out is
just distracting.

Re: [PHP-DEV] I quit.

[Arvids Godjuks]

The 0.1 RFC version was mentioned a lot as a good compromise by many people
and had major support.
Maybe someone competent could pick it up, make necessary adjustments that
where required and let people vote on it? Start with small steps - get the
weak type hints into the language first, see how it gets used and then we
can always add strict type hints if there is a need/desire to do that.

That way we finally get type hints into the language, and those wanting the
strict variety have all the opportunities in the world to add them at a
later release with proper discussion and development time.

Thanks,
Arvids.

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

[Arvids Godjuks]

I actually have a question, that Ferenc touched on, but it never got any
discussion.

How, actually, the declare will work with concatenated PHP files? It's
quite a common practice to put the files into packages, that require
minimal amounts of includes for performance reasons.
Declare is required to be a the top of a file as a first statement. So, if
I have like 10 packages from composer written in different styles, how
should I actually combine them? Stripping the declare from each file and
putting a single declare with the type hint level I want? What will happen
if a library is written for weak type hints ends up in strict type hint
mode? Or the other way around? Isn't it gonna be a mess?

Thanks,
Arvids.

Re: [PHP-DEV] What do we need strict scalar type hints for?

[Arvids Godjuks]

2015-02-02 11:12 GMT+02:00 Dmitry Stogov dmi...@zend.com:

 hi,

 could you please write down few use cases, when strict scalar type hints
 are really useful.

 Thanks. Dmitry.


Hello Dmitry,

At the moment, being a user-land dev for a little bit more than 10 years, I
just don't see the usage for the strict type hints at the moment. I just
can't imagine it actually being usefull for the masses. Yes, some deep core
library code may use them, wrapped in layers and layers of code, so deep,
that it actually works.

But on a day to day basis? No-no-no-no-n. I'll probably mess it all up
quite fast and end up just stripping those away. It's quite a foreign
concept for me for the PHP code (not that I haven't written in strict typed
languages, but I had to define all the variables up front in the program).
On a day to day basis I juggle a lot data back and forth - parsing an XML
document comes to mind immedeatly (because I have tons of them, with all
kinds of data), i handle a lot of JSON data (including input, that is
mostly strings, because it comes from forms in text form), memcached is
other example. CVS files. And so on. It's the little everyday stuff that
after years just feels natural to do that will be affected and cause grief,
and these days many liek to jump on the hype train without any regard for
the others.

So, for me, the first step is to get the converting, Weak or whatever
you call them, type hints into the language. And I have a perfect case of
why for it.
Just look back at how OOP arrived into PHP and how it evolved.
PHP 4 (yeah, I remember some from those days still) was very basic, and for
me that was a very short phase.
Them came PHP 5 with it's more serious OOP aproach and features. And in 10
years look what has become of the OOP feature set? And all of it really
fits. It started with the basics and ended-up in a very good state. And
most additions that came along had time to be understood and solidify
before more was added. People eased in into it naturally and many changed
their views on the subject with time.

So, I would recomend to start with a small step, see how it's gonna be used
and actually get feedback first. Because you can always go stricter if
needed, but removing such a major feature like strict typehints probably
gonna be messy as hell, if even possible if it does not work out. Get the
weak type hints in, wrote code, get a feeling for them, understand the
impact and then make an informed decision - do we actually need to go
stricter?

Thanks,
Arvids.

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

[Arvids Godjuks]

2015-01-21 19:21 GMT+02:00 Tony Marston tonymars...@hotmail.com:

 Kristopher  wrote in message news:CAF9U7z_BLDusnq7c0mVToxyJpqOpa+
 tmatgqrb7yqeips11...@mail.gmail.com...


 On Wed, Jan 21, 2015 at 9:50 AM, Tony Marston tonymars...@hotmail.com
 wrote:


 You are totally missing the point. It is the principle of having to spent
 unknown quantities of time in refactoring my code for nothing more than a
 frivolous and unnecessary break in BC. It does not fi a bug or a security
 issue, therefore it is frivolous and unnecessary


  Yet you seem to have no problem wasting loads of time arguing about it
 on
 the internet.


 Because I would rather fight for valid principles than give in. To quote
 Emiliano Zapata It is better to die on your feet than live on your knees.


 --
 Tony Marston


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


By this time, you could have opened your project/projects in any Regex
search and replace capable editor/IDE, wrote a pattern that matches class
name with a method name same as class name and replaces it with
__construct. Takes about 5-10 minutes for the first project to get it
right, ensures forward compatibility since 5.0.0 and saves your employer
all those hours that you just spend arguing.
Or just write a PHP script that does the same - even easier and faster...

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

[Arvids Godjuks]

2015-01-22 15:22 GMT+02:00 Arvids Godjuks arvids.godj...@gmail.com:

 2015-01-21 19:21 GMT+02:00 Tony Marston tonymars...@hotmail.com:

 Kristopher  wrote in message news:CAF9U7z_BLDusnq7c0mVToxyJpqOpa+
 tmatgqrb7yqeips11...@mail.gmail.com...


 On Wed, Jan 21, 2015 at 9:50 AM, Tony Marston tonymars...@hotmail.com
 wrote:


 You are totally missing the point. It is the principle of having to
 spent
 unknown quantities of time in refactoring my code for nothing more than
 a
 frivolous and unnecessary break in BC. It does not fi a bug or a
 security
 issue, therefore it is frivolous and unnecessary


  Yet you seem to have no problem wasting loads of time arguing about it
 on
 the internet.


 Because I would rather fight for valid principles than give in. To quote
 Emiliano Zapata It is better to die on your feet than live on your knees.


 --
 Tony Marston


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


 By this time, you could have opened your project/projects in any Regex
 search and replace capable editor/IDE, wrote a pattern that matches class
 name with a method name same as class name and replaces it with
 __construct. Takes about 5-10 minutes for the first project to get it
 right, ensures forward compatibility since 5.0.0 and saves your employer
 all those hours that you just spend arguing.
 Or just write a PHP script that does the same - even easier and faster...


Omg, a folowup.

I just found a gem in the docs:

As of PHP 5.3.3, methods with the same name as the last element of a
namespaced class name will no longer be treated as constructor. This change
doesn't affect non-namespaced classes.

Can be read here: http://lv.php.net/manual/en/language.oop5.decon.php

So, I think this seals the deal :)

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

[Arvids Godjuks]

On

15

Jan

2015,

at

0:33, Andrea Faulds a...@ajf.me:

Hi Marcio,

 On 14 Jan 2015, at 18:52, Marcio Almada marcio.w...@gmail.com wrote:

 We still have a BC break but now we also have code with **mutant**
behavior that might become buggy (do unexpected things) if a `declare` is
used. As a language user and a package maintainer it would be a huge
problem. Imagine how would be to maintain a package that can be used with
both strict and coercive type checking. We would have to write 2x more
tests and yet pollute code with manual type checks (is_string, is_integer)
for the non strict runtime mode when type check is necessary.

I don’t see why this would create “mutant” or “buggy” behaviour. You always
get the type you ask for: the weak behaviour is precisely the same as in
v0.1. The strict behaviour is fairly intuitive. In no case will you ever
receive the wrong type.

I don’t understand.
--
Andrea Fauld

s



 Hello Andrea!

Consider what a mess was register_globals and problems it had, but at least
it was a global setting. Declare will work on per file basis, and it will
end up even more of a mess.

I think PHP development community learned that lesson and that's why you
get pushback, and not only from internals, but also from the userland. Me
including.

Rergards,
Arvids.

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

[Arvids Godjuks]

2015-01-14 16:00 GMT+02:00 Pavel Kouřil pajou...@gmail.com:

 Hello,

 personally, as a language user, I really dislike the idea of both
 options for scalar type hinting to be the part of the language.
 Especially since you would have to declare the strict typing in each
 file (if you are going by 1 class per file in a bigger project, that's
 a LOT of declare directives to write in the long run) and if you'd
 forgot once, it would make the calling of methods somehow
 inconsistent.

 I wish there was just one way to do it; I don't care if the weak or
 strong variant is going to be accepted, IMHO most programmers will be
 able to adapt to either of them. The weak version makes probably more
 sense for PHP and how it handles scalar types (at least from userland
 developer's standpoint), but either of them is better than no
 typehints at all. :)

 PS: Personally, I find the scalar typehint idea useless and cannot
 find a real use case for it. Richard, would you mind giving an
 example?

 Regards
 Pavel Kouril


As a userland developer, have to agree with this message fully.

-1 on the v0.2 version, the declare() approach is gonna make our job
misserable after a few years when this gets adopted and misused by a lot of
people...

Re: [PHP-DEV] [PHP7] Remove the function keyword from class methods?

[Arvids Godjuks]

Hello internals.

I'm firmly against removing the function keyword. PHP is a dynamic
language, that means that even using the latest most functional IDE's out
there, finding the implementation is not always few clicks away (PhpStorm's
Find Usages) and you need to do a search in the project. And the only
thing, that makes it fast and easy, is the function keyword, because you
can do a search by function nameISearchFor and get a single hit.

I'm not even mentioning the code readability...

Re: [PHP-DEV] [PHP7] Remove the function keyword from class methods?

[Arvids Godjuks]

04 окт. 2014 г. 1:03 пользователь Kalle Sommer Nielsen ka...@php.net
написал:

 Hi

 2014-10-03 22:00 GMT+02:00 Arvids Godjuks arvids.godj...@gmail.com:
  Hello internals.
 
  I'm firmly against removing the function keyword. PHP is a dynamic
  language, that means that even using the latest most functional IDE's
out
  there, finding the implementation is not always few clicks away
(PhpStorm's
  Find Usages) and you need to do a search in the project. And the only
  thing, that makes it fast and easy, is the function keyword, because
you
  can do a search by function nameISearchFor and get a single hit.
 
  I'm not even mentioning the code readability...

 I highly doubt THAT many names properties or constants in paticular
 with the same name as a method, and honestly, is it that bad to get a
 few extra search results? I think that seems like a very thin argument
 against this.

 For readablity, the only situration I can think of that can create
 some fuzzy is something like this;

 abstract class A {
  b();
 }

 Abstract class with a method and the visibility modifier omitted,
 looks like a function call inside a block of code but that is pretty
 much about it, but in a non example type of context, even that would
 add more readability to that fuzzy example:

 abstract class Driver {
  connect($host, $username, $password, $database);
  close();
 }

 Thats for saying, I'm not against removing it, but I'm not in hugely
 favor for doing so either, lets call that neutral.



 --
 regards,

 Kalle Sommer Nielsen
 ka...@php.net

I really have to ask, did you work with really big projects? Like really
sizeable.

Re: [PHP-DEV] Some good analysis using PVS

[Arvids Godjuks]

2014-09-01 17:12 GMT+03:00 Lester Caine les...@lsces.co.uk:

 On 01/09/14 13:44, Pierre Joye wrote:
  A quick ping about some anaylise done by the PVS team:
 
  http://www.viva64.com/en/b/0277/
 
  The ones listed are all valid so far. We will fix some of them in the
  next days but feel free to go ahead, FIFC :)

 It's pleasing to see that there is nothing particularly 'nasty' only the
 sort of changes that do creep in when code gets re-factored? If that is
 all that comes up then it shows just what a good job is being done by
 the software crew!


There is the matter of checking the extensions... :)

Re: [PHP-DEV] Merges between PHP5 and PHP7

[Arvids Godjuks]

Just implement and show it working, then i'd say the guys will react.
28 авг. 2014 г. 18:24 пользователь Derick Rethans der...@php.net
написал:

 On Fri, 22 Aug 2014, Derick Rethans wrote:

  On Fri, 22 Aug 2014, Anatol Belski wrote:
 
   as there are many data type changes, here's an idea on how to
   simplify the merges. Git supports custom merge drivers which
   attracted my attention, so I've ended up with the following trick:
 
  As there are that many differences, does it still make sense to GIT
  merge PHP 5 changes up to 7 at all? Shouldn't we just do it by hand. I
  would expect that to have a much greater rate of success.

 Really, no comments about this at all?

 cheers,
 Derick

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

Re: [PHP-DEV] PHP Language Specification

[Arvids Godjuks]

I have a thought about the spec.

I work on Yii framework and the team building it has a great policy - if
your changes to the code require changes to the documentation - you are
required to update the docs. No docs changes - no merge.
The most up to date documentation I have ever seen.

Maybe for the PHP Spec to be relevant there needs to be a rule enforced
like in Yii?

Arvids.

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

[Arvids Godjuks]

Hello!

As a user land developer I do think that over thinking this is going to end
up in disaster.
We already have quite good implementation for the array and object hints,
they do their job and do it good. No need to change those at all - leave
them as is - no need to add magic with casts and all that. Function/method
requires an array? Make casts explicitly and pass it an array and not an
integer.

Primitive type hints are a little different - they are easily cast into
each other for the most part. The only edge case is when we loose data. In
this case we need a E_STRICT or something like that (I would vote for
E_TYPEHINT_CAST - because you will be able to disable only typehint
warnings/errors without disabling E_STRICT), so we can collect these errors
and fix our code by adding checks/casts/whatever. But this automatic
casting should work only between string, integer, float, bool and null
types and only between these. No automatic casting of these 5 to arrays or
objects.

PHP does not need a type hinting system forces you to first make a
prototype without any type hints because you get catchable errors - you can
handle them, but you can't actually just continue right where the error
occurred. You just need to get a warning, that you can disable via
error_reporting, and just make your prototype with all the type hints you
need and deal with the cast warnings in the type hints later on.

P.S. And on that var integer $variable in methods/functions. People, when
you have internal functions returning null|array, bool|array and so on -
this is pointless.

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

[Arvids Godjuks]

2014-07-14 14:19 GMT+03:00 Alain Williams a...@phcomp.co.uk:

 On Mon, Jul 14, 2014 at 01:09:42PM +0300, Arvids Godjuks wrote:

  PHP does not need a type hinting system forces you to first make a

 No one is 'forcing' anything. You use it where it is appropriate; that
 does not
 mean everywhere - there are plenty of places where I would not want to use
 it.


The trend I see in the messages is that people tend to drift to a
restrictive model of type hints - you pass the wrong type and get an
E_RECOVERABLE_ERROR, or add the warning to E_STRICT level (now I don't get
strict warnings at all) or something else comes up.
People forget the KISS, people forget that someone actually has to
implement all that and it's not easy by far. All that additional stuff is
going to take a lot of development time, will slow down the engine
(especially if we do array/object casts - what if someone passes a big
object collection to an array parameter or vice-verse?).
It just feels wrong and unnecessary. If you feel PHP does not provide you
with enough strictness - switch the language.



  P.S. And on that var integer $variable in methods/functions. People,
 when
  you have internal functions returning null|array, bool|array and so on -
  this is pointless.

 In that case you would declare var $variable to receive the value from
 such a function.

 The point of the use of var is to ensure that variables are declared
 before use.
 There is a whole set of errors that can be eliminated by this -- typeos
 where
 you assign to the 'wrong' variable.

 http://stackoverflow.com/questions/8023959/why-use-strict-and-warnings

 var integer $variable has a use where do you know they type, eg you got
 it
 from the typed function arguments.

 As with all of this: if you don't find it then don't use it, leave it for
 those
 who do understand the benefits.


And more pointless boilerplate code to write. If I need a variable
initialized - I just initialize it: $var = 0;
Any modern IDE and even some editors will show you uninitialized or/and
unused variables.
Renaming is for Refactor - Rename.

PHP team has enough on it's plate than writing a static analyzer into the
code parser, implementing over-complicated RFC's and so on. People on this
list have to start to think practically. Previous RFC's for the type hints
didn't got through because of people trying to get all the things into
them, agreeing to disagree and authors just got fed up and probably (I
guess here) when realizing into how big and complicated a peace of work the
RFC became just bailed out with FUA (I definitely would do exactly that,
of course never stating that directly in public, just would declare the
dropping of the RFC - but it would be what I felt internally).


So my proposal is to go the KISS way and make baby steps, see what fruit it
will spawn. Do the basic param hints, use leftover time to pick up the
Return type hints RFC. See how it all pans out in the real world and then
do improvements, if necessary. Basic type hints for scalar types with type
casting, don't touch array and object type hints, add
a E_TYPEHINT_CAST_WARNING warning level so you can generate them when data
loss occurs. And don't change explicit casting. Just to show what I mean:

function test(int $param) { };

// $_GET['id'] === '123a'

test($_GET['id']);
// Get a E_TYPEHINT_CAST_WARNING

test((int)$_GET['id'])
// Everything works like a charm

The last workflow, when I do an explicit cast, is kind'a what many are used
to with the PHP casting system. The difference with type hint is that I can
check where I forgot to make the explicit cast and PHP Engine, in the
future, can make use of explicit cast being made and optimize the $param
usage in the function as an integer. This also gives the ability to update
the code peace by peace and not suffer from tons of warnings/errors that
are generated by typehint casts that loose data that are disabled only with
some other type of errors/warnings that I would like to stay enabled (I run
my code in E_ALL | E_STRICT on production with display_errors = Off -
anything that get's into logs is being fixed ASAP).

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

[Arvids Godjuks]

2014-07-14 15:41 GMT+03:00 Rowan Collins rowan.coll...@gmail.com:

 Arvids Godjuks wrote (on 14/07/2014):

  We already have quite good implementation for the array and object hints,
 they do their job and do it good. No need to change those at all - leave
 them as is - no need to add magic with casts and all that. Function/method
 requires an array? Make casts explicitly and pass it an array and not an
 integer.


 Yes, I totally agree. What I don't think makes sense is for the keyword
 array in a function signature to mean error if a string is passed, but
 the keyword int in exactly the same place to mean happily accept any
 string (or even an array) and cast it to int, even if it's a lossy
 conversion.

 If there is to be a short-hand for casts in function signatures, it should
 not reuse the current syntax for type assertions, as they are not
 equivalent facilities.


  But this automatic
 casting should work only between string, integer, float, bool and null
 types and only between these. No automatic casting of these 5 to arrays or
 objects.


 Rather than special-casing this for static types (despite the fact that
 arrays *can* be cast from other types) I would prefer to see it only happen
 where it can be *lossless* (which is never the case for arrays, thus making
 the current logic consistent with the new rule). This is essentially what
 the current RFC proposes.

 I don't think that's actually overthinking it any more than the scalar vs
 non-scalar version would, as it's a pretty easy rule to express. Broadly,
 if (source_type)(target_type)$var == $var, that's a lossless cast. (There
 are a couple of odd exceptions with very specific values, such as
 (int)(array)1 == 1, but it's not too much of a stretch to say all array
 casts are considered lossy.)


There is no special casing, Array and Object type hints are already
implemented and are in the language for quite a long time. Just don't touch
them, that's all I ask. Implement scalar hints and because of the nature of
PHP - they need to have type casting built in. Otherwise you are forced to
typecast on your own everything that comes from the outside sources:
GET/POST/Databases/API's/REST/the whole lot. If it was a correct string
that was converted to an int/float without any data loss - keep calm and
carry on.

Re: [PHP-DEV] Wake up

[Arvids Godjuks]

Hello everyone.

I just want to point out one thing about all that internals stuff and
remind about a good idea that has been surfacing a few times through the
years, but now I think it can actually get traction because of recent
problems.
It is based on the fact that there are too many people writing to internals
and mailing lists are not actually manageable at this level. I stopped
following all the stuff around a year ago, when I started to get like 15 to
30 maillist threads in my inbox daily (hundreds of mails) and too much
noise.
So, I think, it's time to move to a forum. Actual forum, that can be
managed, can have sections dedicated to certain stuff and has user
management that allows to mute or actually ban people who are not able to
behave, troll and do other kind's of stupid stuff that disrupts the work.
Many devs are already just ignoring this mailing list, so what is the point
of having it if relevant people just don't read it?
The list should remain of course, just to be used as a notification tool
for new important forum threads, RFC's, daily/weekly digest so that those
who have less time can still follow all the stuff in a compact manner.

Hell, I even volunteer to do integration stuff with mailing list, wiki and
other, just don't give me too much frontend stuff to do.

Arvids.

Re: [PHP-DEV] Wake up

[Arvids Godjuks]

2013/9/11 Johannes Schlüter johan...@schlueters.de

 On Wed, 2013-09-11 at 13:59 +0300, Arvids Godjuks wrote:
  It is based on the fact that there are too many people writing to
 internals
  and mailing lists are not actually manageable at this level. I stopped
  following all the stuff around a year ago, when I started to get like 15
 to
  30 maillist threads in my inbox daily (hundreds of mails) and too much
  noise.

 Get a better mail client and better mail filters.


Gmail, the best there is on the WEB. I have a lots of filters and labels
setup. Even in this case following the internals is possible if you do it
like full time. Sure, there are quite days, but seriously - when it hits
the fan - it's a mess.



  So, I think, it's time to move to a forum.

 I hope this is a joke.


Why? At least you can just delete (or mark deleted with the ability to view
if needed)  the off topic stuff, move relevant discussions to other threads.
Mailing list will stay in place, it will just get cleaner and be used for,
as it states in the name, for internal stuff. Not discussing stuff that
does not belong in here.



   Actual forum, that can be
  managed, can have sections dedicated to certain stuff and has user

 We have multiple lists for different things.


I know, been here for a long time. See above.



  management that allows to mute or actually ban people who are not able to
  behave, troll and do other kind's of stupid stuff that disrupts the work.

 We can ban people and have done that twice or so. PHP is open. If people
 annoy you, you can filter them out.


If I would do that, I'll probably filter out like 70% to 90% of the mails
coming from this list: in the long history of this mailing list I think
it's hard to find someone, who has not gone off topic or posted an
occasional annoying e-mail. Even me - that time I was ashamed and if that
was a forum - I'd just delete (or ask to delete) that senseless stupid
message.



  Many devs are already just ignoring this mailing list, so what is the
 point
  of having it if relevant people just don't read it?

 People read what they consider interesting and ignore other threads, and
 I assume this here will end in many ignores.


I care for named params, type hinting and some other stuff. I just dropped
following it when there were like 3 threads going on at the same time,
messages were pouring like crazy and the amount of text just got so
ridiculously big, that I just didn't had the time, ability and will to read
it all. I'd say that that threadnaught, if made on a forum, could be edited
and shrinked like 7 or 8 times for people actually to read something
constructive instead of that monster.



  The list should remain of course, just to be used as a notification tool
  for new important forum threads, RFC's, daily/weekly digest so that those
  who have less time can still follow all the stuff in a compact manner.

 While loosing the structuring proper mail programs offer and having
 media breaks - switching between forums and mail.

 Just a simple examples what mail can do: I can write a mail to the list
 an CC the relevant maintainer to draw his attention and he can directly
 answer from there. Or I can xpost to bring a discussion from the CVS
 list, about some bad commit to internals. Mail is open, forums are
 locking in.

 I haven't seen any useful forum. If Google/Bing/duckduck send me to a
 forum it's always a pain to follow those completely unstructured
 discussions (mail has In-Reply-to headers allowing a proper client to
 sort/nest accordingly etc.)


Again, replacing the mailing list is not an option - it definitely has it's
uses. Also, it's a matter of integrating things and what people with
different rights are able to do.
What I'm saying here is that forum can, and if rules are enforced, will
decrease the mailing list noise a lot and push those senseless holy wars of
the mailing list. All the important stuff will still be here. Don't want to
read the forum - be my guest. Anything significant will be pushed into
internals anyway. All the raging and off topic will be left out on the
forum without disturbing your peace.
Forum also has the functionality to follow certain posts - meaning you will
get notifications, if you want to, about the stuff you want to follow.

I know, these are some big changes, need to get used to. But seriously, do
you really believe that going through hundreds of mails just to see what
points have been brought up is easy? People are loosing the context after
10-15 lengthy e-mails, just jump in without reading all the stuff (because
it's just back and forth most of the time with minor, sometimes important,
changes).


P.S. While I was writing this, 4 people posted. Only Patrick Schaaf posted
usefull information. If this would be a forum - those 3 posts should be
marked as off topic and hidden by default.

Re: [PHP-DEV] Wake up

[Arvids Godjuks]

2013/9/11 Johannes Schlüter johan...@schlueters.de

 On Wed, 2013-09-11 at 16:26 +0300, Arvids Godjuks wrote:
 
 
  P.S. While I was writing this, 4 people posted. Only Patrick Schaaf
  posted usefull information. If this would be a forum - those 3 posts
  should be marked as off topic and hidden by default.

 I read this as I want a censor
 Does this summarize what you want? - I'm clearly objecting to this.

 I also don't agree with your other points and to keep the list silent I
 won't further comment on that.

 johannes


Censorship is wrong word here even by a long shot. What community needs is
moderation. Now we have none here - anyone can derail any topic with ease
if he puts his mind to it. Been there, witnessed first hand.

Any big community needs moderation. Any big community needs a place where
all the off topic, holy wars and stuff like that can be directed to without
disturbing the peace. At least on the forum the topic started can aggregate
the feedback and put it into the first message, add changes over time.

I understand the negative moments about the forums, but that's the
management part. Communities manage their forums far better than companies,
it's just a matter of getting people involved, transparency and clear rules
defined.

Re: [PHP-DEV] Wake up

[Arvids Godjuks]

2013/9/11 Lester Caine les...@lsces.co.uk

 Arvids Godjuks wrote:

 P.S. While I was writing this, 4 people posted. Only Patrick Schaaf posted
 usefull information. If this would be a forum - those 3 posts should be
 marked as off topic and hidden by default.


 But who decides what is off topic.
 There are genuine disagreements as to how PHP should move forward, if
 someone has control of the communication channel they can influence what is
 seen.

 I agree with the general sentiment of what is being said, but I recall
 Rasmus saying he just wanted stability. I just want to get back to a system
 I can use ...


Well, I have to answer that, don't I? :)

As I see it, there never is a single moderator - it is usually a team. And
posts are never truly deleted, so if someone has done something bad, it can
be verified and action can be taken.
Off topic is when the content of the message does not relate to the initial
theme of the thread. I usually just go with my gut on these things - you
have to stop the derailment at some point, or you can be forced to clean up
quite a lot. Many times just a reminder to stay on track from the moderator
does the trick - you leave the messages where they are in that case and no
one is hurt.

It's not black and white of course, depends on the situation.

We all want stability, I for once want it badly, because I saw how decent
RFC's and proposals were just shredded to pieces and people just gone f**c
it, i'm out. We need a filter. That is what i'm proposing.

Re: [PHP-DEV] Wake up

[Arvids Godjuks]

2013/9/11 Terence Copestake terence.copest...@gmail.com

 In less than 10 posts, this thread descended into people bashing each
 other. Perhaps that's telling of something.

 I won't comment on the point about forums or anything else, but a concern
 brought up repeatedly both here and in various blogs is the lack of
 direction or vision. There's a conflict between people who want to keep PHP
 simple and accessible and people who want to make PHP into a professional
 programming tool/environment, complete with all bells and whistles. With
 everyone wanting something different and having different ideas on who the
 target users are, what PHP's responsibilities and concerns should be, etc.,
 it's going to be the classic struggle of trying to be everything for
 everybody all at once.

 Perhaps that issue really does need to be tackled head-on - and if a
 consensus can't be reached, maybe PHP should branch off, having one version
 (not necessarily a different codebase) for hobbyists, small sites and
 beginners, alongside a professional branch for production environments and
 developers who are willing and able to take off the training wheels and
 make use of more advanced features, stop relying on the engine to let them
 get away with bad habits, etc.

 The other classic problem is old-timers who get stuck in their ways and
 instantly reject the very notion of change because it will take them out of
 their comfort zone - and discourage newcomers who might oust them from
 their position of power. Perhaps there's a Machiavellian amongst us who can
 help out with that one.


Agree on all.
Especially on the last part, seems to me that I just hit that exact spot.
To me, as an observer mostly, something has to be done. Developers can't do
it all by themselves and I don't see that many people willing to step up
and do stuff. I'm not only proposing, but also willing to do my part - I'm
good with organizing stuff, coordinating and did my share of forum
moderation for years.

Re: [PHP-DEV] OPcache optimizer improvement in PHP-5.5?

[Arvids Godjuks]

2013/4/10 Dmitry Stogov dmi...@zend.com

 Hi,

 Recently, I've found that OPcache optimizer misses a lot of abilities,
 because it handles only one op_array at once. So it definitely can't
 perform any inter-function optimizations (e.g. inlining).

 Actually, it was not very difficult to switch to script at once approach.
 The attached patch demonstrates it and adds per script constants
 substitution explained in the following script

 ?php
 define(FOO, 1);
 function foo() {
 echo FOO . \n; // optimizer will replace it with: echo 1\n;
 }
 ?

 Of course, I ran the PHP test suite and it passed all the same tests.
 Personally, I think it's safe to include this patch into 5.5 and make a
 green light to some other advanced optimizations in 5.5. (e.g. conversion
 INIT_FCALL_BY_NAME into DO_FCALL).

 Any thoughts?

 Thanks. Dmitry.

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



Hi!

Many obvious optimizations are not used due to the fact, that script
translation into opcode state has to be fast. The nature of PHP dictated
that and this was re-iterated countless times on this mailing list by the
core developers.

To do advanced stuff, you have to create some sort of pre-compile or
storing that compiled code reliably on disk so that if memory cache is
dropped or restart is done, there is no significant preformance hit while
all the code compiles into optimized opcode again.

I would also imagine that good part of the optimizations would require
multiple files to be processed and optimized, but due to dynamic nature of
the PHP opcode compilation is done on per-file basis, so do the
optimizations.

It's very commendable that you want to push optimizations and stuff, but
there are some fundamental stuff that needs to be cared of to do some
really good stuff.

My 0.02$

Re: [PHP-DEV] OPcache optimizer improvement in PHP-5.5?

[Arvids Godjuks]

2013/4/10 Florin Patan florinpa...@gmail.com

 On Wed, Apr 10, 2013 at 4:07 PM, Arvids Godjuks arvids.godj...@gmail.com
 wrote:
  2013/4/10 Dmitry Stogov dmi...@zend.com
 
  Hi,
 
  Recently, I've found that OPcache optimizer misses a lot of abilities,
  because it handles only one op_array at once. So it definitely can't
  perform any inter-function optimizations (e.g. inlining).
 
  Actually, it was not very difficult to switch to script at once
 approach.
  The attached patch demonstrates it and adds per script constants
  substitution explained in the following script
 
  ?php
  define(FOO, 1);
  function foo() {
  echo FOO . \n; // optimizer will replace it with: echo 1\n;
  }
  ?
 
  Of course, I ran the PHP test suite and it passed all the same tests.
  Personally, I think it's safe to include this patch into 5.5 and make a
  green light to some other advanced optimizations in 5.5. (e.g.
 conversion
  INIT_FCALL_BY_NAME into DO_FCALL).
 
  Any thoughts?
 
  Thanks. Dmitry.
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 
 
 
  Hi!
 
  Many obvious optimizations are not used due to the fact, that script
  translation into opcode state has to be fast. The nature of PHP dictated
  that and this was re-iterated countless times on this mailing list by the
  core developers.
 
  To do advanced stuff, you have to create some sort of pre-compile or
  storing that compiled code reliably on disk so that if memory cache is
  dropped or restart is done, there is no significant preformance hit while
  all the code compiles into optimized opcode again.
 
  I would also imagine that good part of the optimizations would require
  multiple files to be processed and optimized, but due to dynamic nature
 of
  the PHP opcode compilation is done on per-file basis, so do the
  optimizations.
 
  It's very commendable that you want to push optimizations and stuff, but
  there are some fundamental stuff that needs to be cared of to do some
  really good stuff.
 
  My 0.02$

 Hello,


 If applying optimizations in multiple passes would be a problem for
 speed, especially on the first request, then maybe a way to solve this
 would be to have a configurable variable like: opcache.passes which is
 between 1 and 10 (lets say) and then have the engine do something like
 this:
 - load the file, compile it and apply a first round of 'quick'
 optimizations for the first time and mark it as passed once;
 - next request, load the compiled version, apply another round of
 optimization then mark it as a second pass
 - repeat the above step until the optimization passes in the said file
 = opcache.passes value

 This way only the initial requests will be affected by this but in a
 way that the hit on those requests is smaller that applying all the
 steps at once.
 I'm really not sure if it's that easy to implement but 'on paper' this
 could be the way to solve it imho.

 What do you think, does it make sense?



 Best regards
 
 Florin Patan
 https://github.com/dlsniper
 http://www.linkedin.com/in/florinpatan


It could be a way out for heavy optimizations. Question is - will there be
any? :)

Re: [PHP-DEV] OPcache optimizer improvement in PHP-5.5?

[Arvids Godjuks]

2013/4/10 Zeev Suraski z...@zend.com

  -Original Message-
  From: Arvids Godjuks [mailto:arvids.godj...@gmail.com]
  Sent: Wednesday, April 10, 2013 4:08 PM
  To: PHP Internals
  Subject: Re: [PHP-DEV] OPcache optimizer improvement in PHP-5.5?
 
  2013/4/10 Dmitry Stogov dmi...@zend.com
 
   Hi,
  
   Recently, I've found that OPcache optimizer misses a lot of abilities,
   because it handles only one op_array at once. So it definitely can't
   perform any inter-function optimizations (e.g. inlining).
  
   Actually, it was not very difficult to switch to script at once
   approach.
   The attached patch demonstrates it and adds per script constants
   substitution explained in the following script
  
   ?php
   define(FOO, 1);
   function foo() {
   echo FOO . \n; // optimizer will replace it with: echo 1\n; }
   ?
  
   Of course, I ran the PHP test suite and it passed all the same tests.
   Personally, I think it's safe to include this patch into 5.5 and make
   a green light to some other advanced optimizations in 5.5. (e.g.
   conversion INIT_FCALL_BY_NAME into DO_FCALL).
  
   Any thoughts?
  
   Thanks. Dmitry.
  
   --
   PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
   visit: http://www.php.net/unsub.php
  
 
 
  Hi!
 
  Many obvious optimizations are not used due to the fact, that script
  translation
  into opcode state has to be fast. The nature of PHP dictated that and
 this
  was re-
  iterated countless times on this mailing list by the core developers.
 
  To do advanced stuff, you have to create some sort of pre-compile or
  storing
  that compiled code reliably on disk so that if memory cache is dropped or
  restart
  is done, there is no significant preformance hit while all the code
  compiles into
  optimized opcode again.
 
  I would also imagine that good part of the optimizations would require
  multiple
  files to be processed and optimized, but due to dynamic nature of the PHP
  opcode compilation is done on per-file basis, so do the optimizations.
 
  It's very commendable that you want to push optimizations and stuff, but
  there
  are some fundamental stuff that needs to be cared of to do some really
  good
  stuff.

 I think it very much depends on the nature of the optimizations.  For the
 vast majority of optimizations we can apply to PHP's execution
 architecture,
 I actually don't think that we need to go back to the fundamentals and
 consider things like storing pre-compiled scripts on disk.  The compiler,
 even with optimization passes still takes split seconds to execute, which
 means a 'cold boot' (e.g. when doing a restart) won't be a noticeably
 painful process.  As long as you end up reusing the results of that process
 a lot more frequently than you have to recreate them - you're fine.

 Note that our experience was that reading binary serialized data from disk
 isn't significantly faster than invoking the compiler in the first place -
 you still have to read the data from disk, you still have to analyze it and
 backpatch addresses, etc.;  I know that some people here are revisiting
 that
 assertion - which is absolutely fine - but the assumption that saving
 precompiled files on disk eliminates compilation overhead is wrong.  If
 anything it gives a marginal benefit...

 From my POV I think we're fine with any optimization that does not break
 the
 single-file barrier (in other words, no cross-file optimizations).  The one
 Dmitry suggested falls in that category, so I think it's fine, and it's
 mostly a question of whether we want it in 5.5 or only in 5.6.

 Zeev


Yep, I have to agree here. It all depends on the optimizations in question,
the time it takes to preform them.

Regarding the storage if compiled opcode on disk - my thought was to read
from disk only if there are heavy enought optimizations present and be a
one-time thing to populate the RAM cache. Also it is right now that
invoking the compiler is not really slower than reading from disk, but in
the future, when there are numerous optimization passes and stuff - it can
become significant. Anyway - this is just my thoughts on the subject.

People are also asking for the ability to deploy already compiled scripts
(comercial software, faster deployment, etc), this maybe a part of a bigger
functionality for the future.

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Arvids Godjuks]

Hello, didn't read the whole thread, just a few messages at the start. But
because I'm replying to the starting message, it's not relevant :)

In principle, as a user-land developer, I agree with the motion. It's too
much fancy new shiny stuff lately and no actual improvement on the old
stuff that really needs fixing or updating/rewriting (PDO anyone? Years
behind every db driver extension there is in PHP, and as far as I'm
concerned - it should be dropped and concentrate on standardize the db
extension public API).
As far as I see, there is technical debt piling up and except the actual
core developers no one understands that - people just spawn RFC's like
crazy. As it was said countless times - PHP core team lacks resources to
fix many issues that are already there and new stuff just makes it worse.


Actually, if I was a core team member (sadly C is not my love and most of
the stuff I want to change requires actual coding), I would push a motion
to temporary suspend accepting RFC's that introduce new features and devote
release after 5.5 to fixing and rewriting the old stuff and bug fixing. And
that can prove to be a much more positive that just new features. I think
with last two releases there was ton of stuff added and it will take time
to actually grasp it and start using it. Hell, I like traits, but I can't
put a finger on how to use them at the moment. And it will take me some
considerable time to actually find a place for them and integrate them into
my work so that they fit just right. Late static binding? Hell, still
didn't use it at all. Anonymous functions - yeah, this one is all over my
code now (of course not just for the sake of it) and some other recent
stuff I use too.
Ok, I have to stop mumbling. What I wanted to say - it will take time for
developers, community, frameworks and hosting companies to catch up with
the stuff that was introduced in 5.3, 5.4 and will be in 5.5. To my opinion
there should be a pause in new additions and time taken to take care of the
old stuff that needs love, some need it desperately.

Thanks,
Arvids.

Re: [PHP-DEV] [RFC] Short syntax for anonymous functions

[Arvids Godjuks]

I also don't like the RFC proposed syntax. I have to say that I don't
really like those short magic-like syntax things in in other languages too.
If you work with them on the day-to-day basis and tools are built around
those concepts - it's one thing. In PHP syntax is mostly self-explanatory
and for the most part there is only one way to do it (or the differences in
syntax have their own uses - like for () {} is used in code and  for ():
endfor; is good for templates).

I like the current $x = function () {}. It's the same in JavaScript (and
because most of us use jQuery - we use it a lot) and realistically I don't
type it - IDE does auto-complete for me.

P.S. I want to tell all those syntax enhancement guys - don't push
syntax-sugar stuff into PHP for the sake of shorter syntax. First, for the
most part it looks alien in PHP. Second - it really depends on the
preception - I for example hate Ruby syntax, it's crap and unreadable -
this just illustrated that's one mans beauty is other mans ugly. PHP syntax
maybe not the most pretty out there, but it is sure as hell easy to read
even if coder makes a mess of it. I saw the opinion on the internet that
PHP is a scripted version of C in the sense of their positioning and usage.
And I totally agree with it, and I want it to stay that way. PHP should not
be the pretty one, or be on the feature edge. PHP needs to just walk with
time and adopt the good stuff fully integrating into itself, not just
patching the core and adding some half-weird syntax that just doesn't
really fit PHP.
You also have to remember that PHP is a WEB development script language,
not general purpose script language like Ruby or Python. Not all features,
that are good in general purpose languages, are good for WEB language. Some
of those features may bring performance hits that are not worth it.

My 0.02$,
Arvids.

Re: [PHP-DEV] [RFC] Improved Linux process title support in the CLI SAPI

[Arvids Godjuks]

Hello internals.

I'm actually using proctitle extension and it's very handy because we run
like 10+ daemons written in PHP that we manage. Without it we would be lost
:) But the actual awareness of the proctitle PECL extension is very low.
Also it does not work on windows.
I'm all over the idea to add it to the core and that will be better than
current proctitle extension. Also I don't see a major effort required to
keep this thing up to date. OS'es don't just change how process titles are
set overnight, I would imagine that being huge thing to do without a very
early notice.

The RFC is superior to proctitle in every way, so i'd say go for it.
Although small on the outside, it's actually a huge thing and will allow to
actually start building some serious stuff without using some half-baked
non-maintained extensions.

My 0.02$.

Arvids.

Re: [PHP-DEV] PHP is not ...

[Arvids Godjuks]

I have to agree with Lester.

It seems that there is a conspiracy to push annotations into PHP :D No,
really, it's like goons decided that PHP needs annotations no matter what
and just flooded the mailing list.
I think: The line must be drawn here, this far, no further! © Star Trek
Before adding more major stuff we should cope with what was already added
and get it into shape. Traits are getting a rewrite for the 5.5 release and
APC can't catch up because of the traits. This is the first big problem
that needs to be solved.

Unicode is the second big problem. As far as I know there was some work
done on mb_string like enabling func_overload by default, but there are
functions missing that are in standard string extension. Just continue on
course and get more people involved. Maybe make a roadmap and try to stick
with it.

3rd problem is PDO. It lags behind for years and as far as I know from the
words of Perrie, no one is willing to touch it and it's a mess. I will not
even start on the fact that it lacks tons of functionality and
is extremely limiting when you start to do some serious stuff. The fact
that virtually every framework bases it's DB layer on the PDO makes it even
worse - a fast comparison between PDO and mysqli shows how limiting the PDO
is.
Just an example, mysqli has mysqli_ping. You can't do that in PDO, so I had
to send a query SELECT NOW() every 10-15 seconds to the MySQL server to
keep the connection alive. Because when PDO looses connection, it gives you
an error and you can't just reconnect and continue.

Oh, the PHP function API issue, like array vs string. Huge amount of
improvements can be done here.

This is just what gets into mind and I stumble upon regularly. Maybe these
problems should be addressed first before adding more stuff?

Arvids.

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

[Arvids Godjuks]

2013/1/11 Clint Priest cpri...@zerocue.com

 
 Even so, C++ is not the only object oriented language out there.

 -Clint


I could not resist the urge to suggest D as an option :)  Sorry for this
troll attempt.

Well, there is Quercus out there in the wild, they did it. Sure a total
rewrite will give opportunity to correct many questionable choices and bad
implementations. But is it really feasible?

Arvids.

Re: [PHP-DEV] RFC: ext/mysql deprecation

[Arvids Godjuks]

Hello internals.

Sometimes I wonder if people even read the stuff that is written here. I
understand that this thread got long, but it's not that bad - most messages
are short and readable, easy to follow.
As with APOCALYPSE WILL HAPPEN style claims, that we see here, I just
don't understand your reasoning people. People said repeatedly, and RFC
too, that it's not going to be E_DEPRECATED on every function call in the
extension - it's only on mysql_connect  mysql_pconnect.
And seriously, guys, there are other places that throw E_WARNING, E_STIRICT
and E_DEPRECATED - ignoring those is a bad idea no matter how you put it .
E_DEPRECATED sends a clear message, that everyone understands. And docs are
not a best place for a warning of that kind - I now look into the docs a
few times a year for something specific, I just don't need to cause even I
just remember the stuff I use. And IDE helps to remember the things I
forgot on the fly. If I would not read this list I would know about
the deprecation when I would update my developer PHP to new release and get
E_DEPRECATED on my developer machine (I moved to mysqli like ages ago and
frameworks make me use PDO). That's just how a regular developer works -
this is an extension that like 100% of us (the guys that work with MySQL
for any time longer than half a year) know by heart, why da hell do I need
to read docs for that?

Deprecating stuff isn't a viral video or a funny picture that gets
spread virally. Yes, people write blogs, spread the word, but it's effect
is far from what you want and need.

I don't see how removing a whole extension is any kind of special case. You
deprecate it, give people a year or so to do something about it and move
the extension to PECL. It's not like you are just killing it without any
options to enable it. It is always painful to remove the stuff many people
use, but you just can't make it without someone realizing that stuff was
deprecated like 5 years ago, removed 4 years ago and he just installed that
old new version straight to the production server and it all just died.
You should know better how many idiots are out there in the wild, who never
learn from their mistakes. Even I make some repeated mistakes from time to
time, although I try to learn my lesson - stuff just happens.

Just handle it with as much noise coverage as you can - make an official
statement on php.net, get attention of *nix distros and framework/cms/cmf
developers, remind people on the conferences, blogs, etc. Include reasoning
why are you doing this, provide migration article in the docs (like
oracle's one). I never wanted to say it  would be easy, but it wasn't easy
to remove register_global, magic_quotes and other stuff (and it was written
in this thread that Wordpress still has emulation code for this). Just
prepare for it. 3-5 years should suffice for people to move to mysqli their
projects, that's the time frame majority of people will just start to use
versions after PHP 5.4

Arvids.

Re: [PHP-DEV] RFC: ext/mysql deprecation

[Arvids Godjuks]

2012/11/13 Anthony Ferrara ircmax...@gmail.com

 There's one important thing that I think you all are missing here. You keep
 bringing up that we should just use the normal deprecation process. The
 problem is that the deprecation process was never designed for a feature
 like this.

 Look at what was deprecated and removed so far. We deprecated register
 globals and magic quotes. The process worked there. But was it because of
 the process? Or was it because those features were already dead by that
 point. Think of this: when 5.3 shipped (introducing E_DEPRECATED for those
 features), how many current versions of open source tools relied on those
 features? None.

 Now, you could point to call-time-pass-by-reference as well. E_DEPRECATED
 was added in 5.3 for it. But most of the projects that used it only used it
 in a few minor places. The majority of usages were relatively isolated.

 Now, look at ext/mysql. The landscape is completely different. Major
 projects still rely on it in their most recent versions. Wordpress's latest
 trunk uses ext/mysql. And as was said here, it's not a trivial change to
 switch from mysql to mysqli or PDO. ext/mysql is still very heavily relied
 upon.

 What I would suggest, is not adding E_DEPRECATED for 5.5. Instead,
 officially deprecate it in the docs. Then start a PR campaign to get
 projects like WP to switch away from it. Get the word out there as much as
 possible. Then in 1 to 2 years when 5.6/6 is released, add E_DEPRECATED.

 Again, my $0.02...

 Anthony


It took me like 10 minutes of Search  Replace in my IDE to make a switch
to mysqli and a few more hours to validate that everything is ok and catch
places where search  replace failed. The amount of work is overestimated,
especially if you have a regexp capable search  replace.

Not being able to migrate to mysqli in a few days is a sign of project
messed up so badly, that just upgrading your PHP should break it every
time, and you are probably better off rewriting the whole thing. Or just
freeze the PHP version you are using and let it live until you are able to
rewrite it.

Unfortunately people need a kick in the nuts to start to act. And that old
project argument is exactly from the people that need that kick in the
first place.

I don't even wana start about using a VPS/virtualization and compiling the
damn thing --with-mysql and being happy that you don't have to do anything
to keep it running.

Re: [PHP-DEV] RFC: ext/mysql deprecation

[Arvids Godjuks]

Hello all!

Julien this weekend was at the conference in Riga and we talked with him
exactly about this, how it could be handled and stuff.
The bottom line of our discussion was that I expressed the opinion that
things should really start to move as of 5.5 - postponing it will not make
any difference, because people will start to move only when it starts to
generate some warnings and errors. Until then you can educate them as much
as you want - they just ignore it. Everyone who was susceptible to
education  is already educated :)

Just my 2 cents.

P.S. Kill the PDO too, this topic was also was discussed heavily.

Re: [PHP-DEV] 6.0 And Moving Forward

[Arvids Godjuks]

Hello internals!

After reading the discussion for some time and thinking through what has
been written, I came to the conclusion that something like legacy namespace
witch is enabled by default is required. Why? Because some projects are big
and you usually migrate them in chunks. So that way you can start the
conversion the day the new major version is released without a need to
rewrite the whole thing in one go. The hosters will be able to update their
instalations without the fear that their clients will be unable to run
their old code.

There should be the roadmap defined, where the steps of removing the old
API are described and publicly avaliable from the front page of the
php.netfor everyone to see.
I would imagine it something like this:
PHP next.y.z is released. Legacy API is imported to global space by
default, can be turned off via a flag. Optionaly E_STRICT can be emited (or
a special E_* introduced for for the move). Tool like pythons 2to3 could be
introduced (and I think should be) - it's development should not be
restricted to internals only - a github project would be great, so that the
whole community could help. A major effort should be made to spread the
word.
PHP next.x+1 is released. All legacy stuff starts to emit E_DEPRICATED.
PHP next.x+2 is released. Legacy API is not imported into global namespace
by default - the php.ini setting should be changed for that.
PHP next.x+3  _OR_ PHP next +1 is released. Legacy API is removed for good,
php.ini flag is removed - adapt or die.

Just my userland developers $0.02 :)

Thanks,
Arvids.

Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?

[Arvids Godjuks]

There are alternative opcode cachers besides APC. For example xcache, for
me, just works when APC is still catching up.
I remember someone writing about APC that it is overly compex internally
and due to that hard to keep up with the changes in the PHP, maybe that is
not the case now.
But looking at the xcache and using it in production for 5-6 years I see
that something is true in the previous statement, because when new version
is out - xcache is always up to date, witch can't be said about the APC.
Just say'n.

2012/7/3 Tom Boutell t...@punkave.com

 Given the impracticality of using PHP without APC, it would be nice if
 it were part of the main if these fail, it's not ready test suite.
 But I suppose that's just administering beatings until morale improves
 (:

Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?

[Arvids Godjuks]

One one side it's good to know i'm not wrong, on the other hand it's sad in
this case.
Sure about one thing - xcache is worth looking at and may be a better
choise than APC and has better potential.
One thing sure - I haven't heard anyone complaining about xcache.  And
heard many complains about APC.
03.07.2012 15:17 пользователь Pierre Joye pierre@gmail.com написал:

 hi,

 On Tue, Jul 3, 2012 at 5:12 PM, Arvids Godjuks arvids.godj...@gmail.com
 wrote:
  There are alternative opcode cachers besides APC. For example xcache, for
  me, just works when APC is still catching up.
  I remember someone writing about APC that it is overly compex internally
  and due to that hard to keep up with the changes in the PHP, maybe that
 is
  not the case now.

 It is still the case.

 I for one would like to kill all the legacy features or too specific
 features which are really unusable by any common developers.

 Other developers may disagree but it makes very hard to maintain APC.

 Cheers,

  2012/7/3 Tom Boutell t...@punkave.com
 
  Given the impracticality of using PHP without APC, it would be nice if
  it were part of the main if these fail, it's not ready test suite.
  But I suppose that's just administering beatings until morale improves
  (:



 --
 Pierre

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

Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?

[Arvids Godjuks]

Just to be clear - all 3 major opcode cachers i know (zend optimizer
excluded - have no idea what he has) have that shared memory cache with
almost identical API. Some have extended functionality (xcache has
xcache_isset(), haven't seen that in others, but have to confess i haven't
been looking for some time now), so they are easily swappable.
03.07.2012 15:54 пользователь Tom Boutell t...@punkave.com написал:

 The ability to store your own data in the APC cache is a feature that
 does get used a lot in the Symfony framework world because of the
 availability of the sfAPCCache and whatever its Symfony 2 equivalent
 is. It's popular with folks who haven't felt the need to set up Redis
 or some other external cache yet. I'm not sure whether this is
 something you consider a legacy feature.

 On Tue, Jul 3, 2012 at 11:17 AM, Pierre Joye pierre@gmail.com wrote:
  hi,
 
  On Tue, Jul 3, 2012 at 5:12 PM, Arvids Godjuks arvids.godj...@gmail.com
 wrote:
  There are alternative opcode cachers besides APC. For example xcache,
 for
  me, just works when APC is still catching up.
  I remember someone writing about APC that it is overly compex internally
  and due to that hard to keep up with the changes in the PHP, maybe that
 is
  not the case now.
 
  It is still the case.
 
  I for one would like to kill all the legacy features or too specific
  features which are really unusable by any common developers.
 
  Other developers may disagree but it makes very hard to maintain APC.
 
  Cheers,
 
  2012/7/3 Tom Boutell t...@punkave.com
 
  Given the impracticality of using PHP without APC, it would be nice if
  it were part of the main if these fail, it's not ready test suite.
  But I suppose that's just administering beatings until morale improves
  (:
 
 
 
  --
  Pierre
 
  @pierrejoye | http://blog.thepimp.net | http://www.libgd.org



 --
 Tom Boutell
 P'unk Avenue
 215 755 1330
 punkave.com
 window.punkave.com

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

Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?

[Arvids Godjuks]

Could be, xcache is definetly dummer in features and it is its feature. I
guess it helps it to keep up with releases. I will investigate this today,
maybe get some interesting results worth to share here.
03.07.2012 16:54 пользователь Rasmus Lerdorf ras...@lerdorf.com написал:

 On 07/03/2012 09:49 AM, Arvids Godjuks wrote:
  One one side it's good to know i'm not wrong, on the other hand it's sad
  in this case.
  Sure about one thing - xcache is worth looking at and may be a better
  choise than APC and has better potential.
  One thing sure - I haven't heard anyone complaining about xcache.  And
  heard many complains about APC.

 Well, that is simply not true. We get a lot of, I tried xcache, but it
 didn't work, so now I am trying APC type of messages and bug reports in
 the APC world.

 -Rasmus

Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API

[Arvids Godjuks]

Hello.

I personally think that using PASSWORD_DEFAULT for algorythm by default is
a bad idea. This should be defined by user in the code. Even worse if it is
defined by .ini setting - deploy to a remote server and realize that there
is a different .ini default that messes up everything. Lessons learned in
the past are forgetten fast?

And the thing I don't get is how do I verify a salted password? I have read
throught the RFC and what I know about the salts makes me wonder - how da
hell I will verify my salted hash if I can't pass the salt to
password_verify?

If there is some trick behind, it should be explained in the RFC (and in
the docs later, because otherwise it makes people WTF?! who are not into
cryptography).

Arvids.

Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API

[Arvids Godjuks]

On that note I have only one request - please point me to the good article
that describes how this thing works (I would prefer one that at least tries
to explain in simple words) because at the moment i do not understand how
salt stored in the hash itself makes hash more secure than an unsalted one.

Thank you :-)
27.06.2012 14:16 пользователь Anthony Ferrara ircmax...@gmail.com
написал:

 Arvids,

 On Wed, Jun 27, 2012 at 9:23 AM, Arvids Godjuks
 arvids.godj...@gmail.com wrote:
  Hello.
 
  I personally think that using PASSWORD_DEFAULT for algorythm by default
 is a
  bad idea. This should be defined by user in the code. Even worse if it is
  defined by .ini setting - deploy to a remote server and realize that
 there
  is a different .ini default that messes up everything. Lessons learned in
  the past are forgetten fast?

 It wouldn't mess up anything. All it would do is change the algorithm
 used by the library when creating new passwords. Existing ones will
 still validate. The new ones will validate on the old server as long
 as that algorithm is supported (could be an issue in a mixed
 environment where there are servers using an older version without
 support for the new method in crypt())...

  And the thing I don't get is how do I verify a salted password? I have
 read
  throught the RFC and what I know about the salts makes me wonder - how da
  hell I will verify my salted hash if I can't pass the salt to
  password_verify?

 Ah, I think I see the disconnect. crypt() returns the full salt
 information along with everything necessary to hash it (all settings).
 So the generated hash includes the salt, the method, and the cost
 parameter. For example:

 var_dump(crypt(rasmuslerdorf, $2a$07$usesomesillystringfor));

 string(60) $2a$07$usesomesillystringfore2uDLvp1Ii2e./U9C8sBjqp8I90dH6hi

 So just storing the hash is enough...

  If there is some trick behind, it should be explained in the RFC (and in
 the
  docs later, because otherwise it makes people WTF?! who are not into
  cryptography).

 That's completely fair. I'll add a section to the RFC about that...

 Thanks,

 Anthony

Re: [PHP-DEV] Adding a simple API for secure password hashing?

[Arvids Godjuks]

I would definetly like that a lot to be the case. bcrypt is kind'a cryptic
and information about cryptography on the internet is not so informative
and are not in abundance.

Re: [PHP-DEV] [off] PHP: a fractal of bad design

[Arvids Godjuks]

Hello internals,

I should voice my opinion that such things like comparing two strings
starting with numbers and that they resolve to actual integer/float for
comparation is bad, really bad. That just defies the logic and yealds
absolutly unexpected results. I pride myself that i know the juggling rules
well, but I'm shocked by this to say the least...
In my opinion this should change no matter the BC breaks it will create,
this one affects security big time. It's good I actually hash my passwords
in the MySQL and not on the PHP side, but I have seen hash comparations
with == all the time. And now that this has been discussed in detail I
expect this to be used as an attack method grow wide.
07.05.2012 5:32 пользователь Tjerk Anne Meesters datib...@php.net
написал:

 On Sun, May 6, 2012 at 12:17 AM, Richard Lynch c...@l-i-e.com wrote:
  What exactly valid points? == is a converting operator, === is a
  strict
  operator. OK, in his favorite language it is not. Where exactly the
  valid point is? Author goes at great lengths to refuse to make even a
  slight mental effort to understand how it works (really, it's not that
  hard) and then complains it's useless. Well, a lot of things would
  be
  useless if you don't want to know how to use them.
 
  He has a few valid points in the part I read before I got bored...
 
  $a = 123ABF453...; //a password
  $b = 123DFEABC...; //another one
  if ($a == $b){
   //you're in.
  }
 
  Yes, one should have validated the input...
 
  But you don't have to be THAT naive to think that the hashed value of
  an SQL injection attack just isn't going to work, so it's safe...
 
  I'll bet I have some of these in my (recent) code, for that matter.
 
  On the other hand, if you accept type juggling, you have to expect the
  other cases he has for == being a bit strange.

 Validated or not, why would type juggling even come into the picture
 if both variables are of the same type?

 123 == 123abc // sure, why not
 61529519452809720693702583126814 ==
 6152951945280972 // WAT?!

 In the above, only the first ~50% of an md5 hash has to be correct.
 This gets even worse for SHA256 hashes.

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

Re: [PHP-DEV] [off] PHP: a fractal of bad design

[Arvids Godjuks]

Easy - you see == everywhere and === is used rarely, in docs you see it in
some places like strpos(). This is one thing that has to be communicated
through every channel available (including docs) with clear examples that
show why it should be used instead of ==.
Take me for example, I never had any idea that comparing two hashes that
start with numbers can generate a logical truth despite the hashes being
different. I haven't seen anything related to this in docs and never
stumbled upon in the internet, ever. So I use == for comparing strings all
the time. Now I will change that because I have the knowledge why I should
use === instead of ==.
Well, now I do know, from this mailing list (witch is for PHP development)
- not many user-land developers read this list.

And in my previous message I said essentially the same as you did, just in
different words and style. English is not my native language and I have
been learning the British variant of it, so it's more formal that
American English :)

2012/5/7 Kris Craig kris.cr...@gmail.com



 On Mon, May 7, 2012 at 12:28 AM, Arvids Godjuks 
 arvids.godj...@gmail.comwrote:

 Hello internals,

 I should voice my opinion that such things like comparing two strings
 starting with numbers and that they resolve to actual integer/float for
 comparation is bad, really bad. That just defies the logic and yealds
 absolutly unexpected results. I pride myself that i know the juggling
 rules
 well, but I'm shocked by this to say the least...
 In my opinion this should change no matter the BC breaks it will create,
 this one affects security big time. It's good I actually hash my passwrds
 in the MySQL and not on the PHP side, but I have seen hash comparations
 with == all the time. And now that this has been discussed in detail I
 expect this to be used as an attack method grow wide.
 07.05.2012 5:32 пользователь Tjerk Anne Meesters datib...@php.net
 написал:


 Forgive me if I'm missing something, but why are people using == for
 security-sensitive string comparisons (like hashed passwords) in the first
 place?!  If you needs something that's safe, isn't that what strcmp() and
 strcasecmp() are for?  For my part, I pretty much never use == on string
 comparison, though admittedly that's probably just a matter of having
 having come from a C background before PHP.

 That being said, I agree that this *definitely* should be fixed if the
 examples cited are indeed accurate (I've been working with PHP for over 10
 years and I was never aware of this bizarre behavior, either).  I don't
 know the history of this, but I at least would consider it to be a bug.  A
 rather large one, in fact; though I think some of the fears expressed are a
 bit hyperbolic.  And if you're fixing a serious bug or security
 vulnerability, as a general rule of thumb, this automatically supercedes
 any concerns regarding BC breakage IMHO.  But if that really is a lingering
 concern, I'd suggest targetting the fix for PHP 6, since people would (or
 at least should) expect that some PHP 5 code may behave differently in PHP
 6 anyway given that it's a major release

 --Kris

Re: [PHP-DEV] [RFC] Pure PHP Scripts (Updated)

[Arvids Godjuks]

As far as I read there is no difference from the previous RFC - it
says essentially the same.

 The ?php tag, contained within one of these files, tells the webserver
to, in essence, “switch to PHP mode” and start parsing the data as PHP code.
When the ? tag is reached, the webserver “switches back” and resumes
parsing it as HTML. If no tags are given, the webserver will parse the file
data as HTML code until a ?php tag is reached. 

I'm I the only one who thinks that this is just plain wrong? I know for a
fact that there is no PHP mode on the WEB server level. I think I
understand what it tries to say, but I totally disagree with what is
written and don't want to guess anything.

24 апреля 2012 г. 22:52 пользователь Kris Craig kris.cr...@gmail.comнаписал:

 Hi all,

 I finally found some time today to update the RFC based on discussions
 here.  Please have a look and let me know if I missed anything or if
 there's anything else that needs clarifying:

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


 I also want to know if this is sufficient to satisfy some of the concerns
 that have been raised about being able to implement this into existing
 frameworks that use a more tangled architecture.

 Thanks!  =)

 --Kris

Re: [PHP-DEV] Complete case-sensitivity in PHP

[Arvids Godjuks]

In past years such switches where deprecated and removed (in 5.3 most of
them, in 5.4 finally all that stuff is gone for good). So any solution,
involving a switch that modifies how code is executed will hit a wall of
resistance. It's the lesson that was learned the hard way.

So it may be the case to make PHP case-sensetive. There will be code
broken, probably a lot. But that can be fixed, and I personally always
write with respect to char case, so that will be no problem for me.

20 апреля 2012 г. 13:20 пользователь C.Koy can5...@gmail.com написал:

 Hi,

 This post is about bug #18556 
 (https://bugs.php.net/bug.php?**id=18556https://bugs.php.net/bug.php?id=18556)
 which is a decade old.

 As the recent comments on that page indicate, there's not a deterministic
 way to resolve this issue, apart from eliminating tolower() calls for
 function/class names during lookup. Hence totally case-sensitive PHP.

 Before opposing with No, this will break a lot of existing code!, note
 that I'm not suggesting a static permanent change in the engine; rather a
 runtime option that will need to be enabled (cli option, INI setting),
 without which PHP will work as before.

 Since I'm not well versed in the workings of Zend engine, I solicit the
 wisdom/experience of people in this list: Is this doable in a practical
 way, without making grand changes in Zend?

 best regards,




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

Re: [PHP-DEV] Complete case-sensitivity in PHP

[Arvids Godjuks]

Because you can write a function name, say, in Cyrilic and it will just
work.

20 апреля 2012 г. 16:47 пользователь Nikita Popov nikita@googlemail.com
 написал:

 On Fri, Apr 20, 2012 at 12:20 PM, C.Koy can5...@gmail.com wrote:
  Hi,
 
  This post is about bug #18556 (https://bugs.php.net/bug.php?id=18556)
 which
  is a decade old.
 
  As the recent comments on that page indicate, there's not a deterministic
  way to resolve this issue, apart from eliminating tolower() calls for
  function/class names during lookup. Hence totally case-sensitive PHP.
 
  Before opposing with No, this will break a lot of existing code!, note
  that I'm not suggesting a static permanent change in the engine; rather a
  runtime option that will need to be enabled (cli option, INI setting),
  without which PHP will work as before.
 
  Since I'm not well versed in the workings of Zend engine, I solicit the
  wisdom/experience of people in this list: Is this doable in a practical
 way,
  without making grand changes in Zend?
 I'm not sure whether I really get the issue, but as it seems the
 problem seems to be that PHP is using locale-aware lowercasing
 functions in the core. Couldn't the issue be fixed by replacing those
 with local-unaware functions? Why does one have to change PHPs general
 case sensitivity handling for that?

 Nikita

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

Re: [PHP-DEV] Ability to assign new object to a class property.

[Arvids Godjuks]

I have to agree with Richard as a user-land developer. It looks nice, but
knowing how people can twist things I don't think I would like this feature
get implemented. It just add stuff that is crazy to debug.

Consider someone adds a property and initializes a user-land object. That
object has other object properties with are created and the chain goes on
for 2-3 more levels. Dealing with a __construct or a dedicated init method
is far easier and at least predictable stuff. I imagine someone initiating
objects at property declaration and then somewhere in the code assigning
the data they want the object to work with instead of just passing it in to
the constructor or calling a dedicated method to do that right after
creating an object.

19 апреля 2012 г. 0:31 пользователь Richard Lynch c...@l-i-e.com написал:

 On Sun, April 15, 2012 5:47 pm, Simon Schick wrote:
  Just to add a random thought 
  When do you expect this code to be executed?
 
  class Foo {
  static public $foo = new StdClass();
  }

 I may be too late to this party, but...

 For what it's worth, if the non-scalar initialization in class
 definition were to be implemented, I, the naive PHP developer, would
 expect the implementation to execute the new StdClass() exactly once
 (either at compile time or on the instantiation of the first instance)
 and Foo::$foo or whatever it is would be static in the sense that the
 same instance of a stdClass would be shared by all Foo instances.

 I'm with Stas on this one though.

 Yes, it would be nifty syntactic sugar, and I used to yearn for it.

 But complex initializations in the constructor is something I've grown
 used to, and now appreciate as a Feature.

 Trying to find all the little bits and pieces of non-scalar
 initializations up and down the chain of a complex class hierarchy is
 already difficult enough.

 Tossing in a bunch more places it can happen is Not Good (tm).

 --
 brain cancer update:
 http://richardlynch.blogspot.com/search/label/brain%20tumor
 Donate:

 https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE



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

Re: [PHP-DEV] [RFC] skipping optional parameters

[Arvids Godjuks]

I personally would vote for the default keyword if I want to skip the
param rather than just doing it with , - the keyword approach is much more
readable and error prone.

Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files

[Arvids Godjuks]

What happened with the proposal/RFC for expanding include/require with
additional optional second param to allow for developers to define in place
if he want's a pure PHP file to be included or a template file with direct
HTML output?
I like that proposal and take it over any other, because it gives developer
a choice. And if things do not go the right way and he ends up screwing up
somewhere - he is able to fall back to the old mode just by modifying the
include/require statement (and in a MVC framework with autoload usage that
would be 1-2 places in the whole project).
All that stuff with keywords, removing ?php tags and using special
extensions require a continuous effort from the developers, additional
support from the IDE/editors/other tools. Do we really need all that just
to give people the ability to load their scripts as a pure PHP code?
To my mind a modification to the include/require statements is all there is
required to add that extra thing that Kris want's so badly and does not
require to change your habbits, IDE templates, waiting for IDE/editors/WEB
source code highlight libraries/source analyzers/etc to catch up with the
change.
There is also a question I just raised that is not yet answered that the
keyword/extension thing can just break the valid performance tweak
technique, that is used extensively in any project with big code base.

Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts

[Arvids Godjuks]

16 апреля 2012 г. 2:52 пользователь Kris Craig kris.cr...@gmail.comнаписал:



 On Sun, Apr 15, 2012 at 2:30 PM, Arvids Godjuks 
 arvids.godj...@gmail.comwrote:

 I posted the bellow text in other thread, but i should have it post here,
 so i'm reposting it to this thread.

 Well, it's time for me to remind about the techique many use (and some
 frameworks provide it out of the box) - the application file concatination
 to speed up file loading.
 Yii framework provides a Yiilite.php file for this, that includes mostly
 used core classes in one big file.that loads much faster and is used for
 production. Any other framework has user extentions or other type of
 solutions for this to speed up the application, and it makes really big
 difference.
 So there is a good question - how the hell in a MVC framework would i
 combine my models, controllers, components and other stuff that will
 definetly be as in .php so in .pphp. And not every file will be cached
 like
 that - some will remain as distinct files even in production.

 The further discussion goes the more questions there is and less answers
 there are.


 My response is in the other thread.  But you're right, we should move the
 discussion back here, so please post your reply here.  Thanks!

 --Kris


The Kris response from the PHP-DEV Digest 13 Apr... response to my mail
quoted bellow:

 I'm not quite sure I understand your concern.  Are you saying that the
Yii framework wouldn't work with this because .phpp files would be cached
as .php??  If that's the case, what about .phpo?  Or, perhaps we should
name the extension .phpf instead, as in PHP Framework-includable.

What I'm saying that there is a widely used optimization technique -
concatenate the project files in one big massive chunk, enable an opcode
cache and things speed up big time. Almost any mid sized and above project
ends up doing that in one or the other way. Some even do that on
per-controller basis or otherwise - but the fact is - it's out there.
I just gave an example of the popular framework that has this
out-of-the-box as a feature. And I, for one, do not understand how this
should play with your proposal, because in that state clean source code
ends up with tainted source code in one big chunk of machine-generated
striped-out-everything string of epic proportions witch PHP chews with
happy face and damn fast (helps with response times a lot, up to the
tenfold).

Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts

[Arvids Godjuks]

I should say that I do not understand in full how it suppose to work. From
the RFC it is absolutely unclear how to deal with this and the mixed code
load approach is just dismissed as invalid concern, quoting from the RFC:

 Besides, such an allowance is completely unnecessary anyway, since using
non-horrible architecture can achieve the exact same result without having
to pollute your .phpp stack. Here's a screenshot from a recent Internals
thread where I illustrated this point a little more clearly:

You just dismiss a valid stack structure with the screenshot below that and
every PHP MVC framework I know of out there renders it's templates through
a controller call or invoking a template engine of some kind in the main
application and calling it's methods from controllers. Anyway the result is
obvious - you have to make a global stand-alone template engine object that
loads from index.php  and not inside the application itself. I'm not
willing to think how to couple them together and the difficulties with data
passing, calling widgets and other stuff that comes along - it's just
a stretch of epic proportions to radically alter the structure with unknown
result in the end.

So, since people write a lot about that RFC is not in sync with what you
are writing, you should really update the thing. I follow the thread as
much as I could, but lets be honest - following that wall of text posted
every 4-5 minutes (while I read one mail the phone notified I received 2
more in the thread at times) was just not happening. So I'm convinced I
skipped at least a half of the discussion just being humanly unable to read
it all.
The RFC should contain the solutions for the file template inclusion, 3rd
party library inclusion,dealing with valid optimization practices and other
related stuff.

16 апреля 2012 г. 11:09 пользователь Kris Craig kris.cr...@gmail.comнаписал:



 On Mon, Apr 16, 2012 at 12:57 AM, Arvids Godjuks arvids.godj...@gmail.com
  wrote:

 16 апреля 2012 г. 2:52 пользователь Kris Craig kris.cr...@gmail.comнаписал:



 On Sun, Apr 15, 2012 at 2:30 PM, Arvids Godjuks 
 arvids.godj...@gmail.com wrote:

 I posted the bellow text in other thread, but i should have it post
 here,
 so i'm reposting it to this thread.

 Well, it's time for me to remind about the techique many use (and some
 frameworks provide it out of the box) - the application file
 concatination
 to speed up file loading.
 Yii framework provides a Yiilite.php file for this, that includes mostly
 used core classes in one big file.that loads much faster and is used for
 production. Any other framework has user extentions or other type of
 solutions for this to speed up the application, and it makes really big
 difference.
 So there is a good question - how the hell in a MVC framework would i
 combine my models, controllers, components and other stuff that will
 definetly be as in .php so in .pphp. And not every file will be cached
 like
 that - some will remain as distinct files even in production.

 The further discussion goes the more questions there is and less answers
 there are.


 My response is in the other thread.  But you're right, we should move
 the discussion back here, so please post your reply here.  Thanks!

 --Kris


 The Kris response from the PHP-DEV Digest 13 Apr... response to my mail
 quoted bellow:

  I'm not quite sure I understand your concern.  Are you saying that the
 Yii framework wouldn't work with this because .phpp files would be cached
 as .php??  If that's the case, what about .phpo?  Or, perhaps we should
 name the extension .phpf instead, as in PHP Framework-includable.

 What I'm saying that there is a widely used optimization technique -
 concatenate the project files in one big massive chunk, enable an opcode
 cache and things speed up big time. Almost any mid sized and above project
 ends up doing that in one or the other way. Some even do that on
 per-controller basis or otherwise - but the fact is - it's out there.
 I just gave an example of the popular framework that has this
 out-of-the-box as a feature. And I, for one, do not understand how this
 should play with your proposal, because in that state clean source code
 ends up with tainted source code in one big chunk of machine-generated
 striped-out-everything string of epic proportions witch PHP chews with
 happy face and damn fast (helps with response times a lot, up to the
 tenfold).


 What about the per-file approach that's been suggested?  Would that work
 with your framework?

 The stricter per-stack approach might wind up being better suited for
 projects that are created from scratch with that architecture in mind.
  It's common enough that I believe there's a genuine use case for it.  If
 we then had a separate per-file approach designed to accommodate
 frameworks/libraries that by their nature might be a bit more tangled, I
 think we could get the best of both worlds with this.

 --Kris

Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files

[Arvids Godjuks]

16 апреля 2012 г. 11:24 пользователь Ferenc Kovacs tyr...@gmail.comнаписал:



 On Mon, Apr 16, 2012 at 9:46 AM, Arvids Godjuks 
 arvids.godj...@gmail.comwrote:

 What happened with the proposal/RFC for expanding include/require with
 additional optional second param to allow for developers to define in
 place
 if he want's a pure PHP file to be included or a template file with direct
 HTML output?
 I like that proposal and take it over any other, because it gives
 developer
 a choice.


 there is a valid issue which was discussed on irc yesterday:
 because include/require is a language construct, not a method,  one is
 allowed, even advised to write the include/require calls without putting
 out the parentheses.
 if we introduce additional arguments for include/require, the following
 code will break:
 echo include 'foo.bar', 'baz';
 as currently it was interpreted as
 echo include('foo.bar'), 'baz';
 ofc. we could make that the additional params to include, require would
 only used, if the parentheses are uses, but that would make require/include
 inconsistent with every other language construct, where the parentheses is
 optional.
 so we either accept this BC, or not pursue this option, but go with the
 new functions/opcodes like include_code/require_code or similar.

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


That's sad really, to be honest.
I wonder if people even use this:

 echo include 'foo.bar', 'baz';
 as currently it was interpreted as
 echo include('foo.bar'), 'baz';

I even didn't know it worked that way and if I saw code like this before
today I would consider it an error (I would discover that it actually
works, but I definitively would rewrite that part in two lines as distinct
operators them with ; instead of , between them)

Maybe it's not that big deal and a BC break would not impact things a lot.
What do you think?

Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts

[Arvids Godjuks]

16 апреля 2012 г. 16:09 пользователь Tom Boutell t...@punkave.com написал:

 These tools already strip ?php tags, they would need minimal changes to
 support rolling in a .phpp file unmodified. Unless I am missing something?

 Sent from my iPhone

 On Apr 15, 2012, at 5:30 PM, Arvids Godjuks arvids.godj...@gmail.com
 wrote:

  I posted the bellow text in other thread, but i should have it post here,
  so i'm reposting it to this thread.
 
  Well, it's time for me to remind about the techique many use (and some
  frameworks provide it out of the box) - the application file
 concatination
  to speed up file loading.
  Yii framework provides a Yiilite.php file for this, that includes mostly
  used core classes in one big file.that loads much faster and is used for
  production. Any other framework has user extentions or other type of
  solutions for this to speed up the application, and it makes really big
  difference.
  So there is a good question - how the hell in a MVC framework would i
  combine my models, controllers, components and other stuff that will
  definetly be as in .php so in .pphp. And not every file will be cached
 like
  that - some will remain as distinct files even in production.
 
  The further discussion goes the more questions there is and less answers
  there are.


Yes they obviously do, but that's not what I'm concerned about.
What I'm concerned is that code from .php and .pphp files get's mixed in
together - template engine related stuff is used as much, as do
controllers, session handling classes and bunch of other stuff that by
definition is .pphp stuff, but the template stuff is .php and it includes
templates. So basically everything just has to fall back to the embedded
PHP mode to work and we have no gain from the proposal what so ever - it
just becomes useless.

That's not counting other issues that people and I have been voicing and to
be honest, I never saw a reply to any of it. Maybe there is a reply to
all those questions, but they are under wall of text that usually goes in
reply - that just discourages to read it at all.

Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files

[Arvids Godjuks]

16 апреля 2012 г. 11:05 пользователь Kris Craig kris.cr...@gmail.comнаписал:

 Arvids,


 On Mon, Apr 16, 2012 at 12:46 AM, Arvids Godjuks arvids.godj...@gmail.com
  wrote:

 What happened with the proposal/RFC for expanding include/require with
 additional optional second param to allow for developers to define in place
 if he want's a pure PHP file to be included or a template file with direct
 HTML output?
 I like that proposal and take it over any other, because it gives
 developer a choice. And if things do not go the right way and he ends up
 screwing up somewhere - he is able to fall back to the old mode just by
 modifying the include/require statement (and in a MVC framework with
 autoload usage that would be 1-2 places in the whole project).
 All that stuff with keywords, removing ?php tags and using special
 extensions require a continuous effort from the developers, additional
 support from the IDE/editors/other tools. Do we really need all that just
 to give people the ability to load their scripts as a pure PHP code?
 To my mind a modification to the include/require statements is all there
 is required to add that extra thing that Kris want's so badly and does not
 require to change your habbits, IDE templates, waiting for IDE/editors/WEB
 source code highlight libraries/source analyzers/etc to catch up with the
 change.
 There is also a question I just raised that is not yet answered that the
 keyword/extension thing can just break the valid performance tweak
 technique, that is used extensively in any project with big code base.


 That may very well be the method proposed in my RFC, too.  I haven't made
 up my mind on that point as I'd like to cover the pros/cons a little more
 in depth (including the potential perf issue you just raised).  A handler
 approach or something similar will still be necessary as well, since one
 key reason for my RFC was to make it so that these scripts could be
 executed directly via the webserver.  But as for determining how PHP itself
 can identify a .phpp file, I think the three best options are:  Create new
 tags, create new keywords, or create new parameters to existing keywords.
  I keep bouncing back and forth on which one I think is best, which tells
 me that I need to hear more debate on that.  Thoughts?

 --Kris

 I would encourage you to take a deep look into modifying the
include/require statements, because for all the issues popped out with
.pphp and keywords they just don't exist with include/require. And there is
no need to remove the ?php tags in source files - just make sure they
start first thing in the file and there is no ? at the end and hey (for my
case - my IDE removes all leading and trailing spaces on file save), your
include 'file', PHP_SOURCE_ONLY; works fine, but including a template
fails  (as does an image with embedded ?php ? tags uploaded through a
security hole) .
It's clean (although some BC break would occur, but I think it's minor),
simple and 100% voluntary. Any decently written 3rd party library will work
without any modification (well, removing trailing ? is a matter of simple
script if required, but I haven't seen people putting ? in the end for
years).

Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files

[Arvids Godjuks]

16 апреля 2012 г. 22:02 пользователь Kris Craig kris.cr...@gmail.comнаписал:

 On Mon, Apr 16, 2012 at 10:31 AM, Rick WIdmer vch...@developersdesk.com
 wrote:

  On 4/16/2012 3:31 AM, Arvids Godjuks wrote:
 
  That's sad really, to be honest.
  I wonder if people even use this:
 
   echo include 'foo.bar', 'baz';
 
 
  Probably not,  Try it!  you get:
 
  1baz
 
  It actually works more like
 
echo (include foo.bar), 'baz';
 
  than
 
 
echo include( foo.bar), 'baz';
 
 
 
  More important include doesn't currently allow multiple parms:
 
include foo.bar, 'baz';
 
  Parse error: syntax error, unexpected ',' in bla.php on line xx
 
 
 
 
  Rick
 
 
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 
 
 I'll reiterate my position that I'm not ready to bring my RFC to a vote;
 and even if I was, the rules wouldn't allow it.  In fact, unless I'm
 mistaken, none of the RFCs have met the 2-week minimum requirement yet, so
 no vote can take place at this time.  But I do think we're making progress,
 so I would ask for a little extra patience from the peanut gallery for
 now.  =)

 To Arvids' point, I'm definitely leaning in that direction, but I'd like to
 hear a little bit more from anyone who believes a different approach would
 be better.  If nobody speaks-up, I'll just assume that we have consensus on
 that point and add it to the RFC.

 Regarding include/require, I agree that any BC break would be extremely
 minimal.  In the 10+ years I've been developing PHP, I don't think I've
 ever once seen somebody include multiple scripts on a single line (I wasn't
 even aware that such a thing was allowed).  So if it does pose a change,
 I'd be surprised if any existing scripts would be affected.  And since this
 is a major version increment we're talking about here, I think a small
 amount of allowance can be made for low-impact BC breakage IMHO.

 How about we just keep the parentheses optional and comma-seperate the
 arguments?  For example, the require syntax could look like this:

 require[(] $script_filename, $script_type = PHP_SCRIPT_TYPE_NORMAL [)];

 Possible values for $script_type:

 PHP_SCRIPT_TYPE_NORMAL (0x01)

   - If the included file contains PHP code, parse it.


 PHP_SCRIPT_TYPE_TAGLESS (0x02)

   - Code is assumed to be PHP throughout the script.  The ?php tag throws
   E_NOTICE and the ? tag throws E_RECOVERABLE_ERROR.


 PHP_SCRIPT_TYPE_STACK (0x04)

   - The $script_type is applied to all child scripts of the one being
   included.
   - Question : Would anyone see value in adding an override constant that,
   while not recommended, allows the developer to apply a different
   $script_type somewhere deeper in the stack?  Personally this doesn't
 sound
   useful to me, but I'd be willing to put it in if enough of you wanted it.


 PHP_SCRIPT_TYPE_CODE_FILE (PHP_SCRIPT_TYPE_NORMAL 
 PHP_SCRIPT_TYPE_TAGLESS)

   - The entire script is assumed to be PHP code and is parsed accordingly.


 PHP_SCRIPT_TYPE_CODE_STACK (PHP_SCRIPT_TYPE_NORMAL 
 PHP_SCRIPT_TYPE_TAGLESS  PHP_SCRIPT_TYPE_STACK)

   - The entire script and all its child scripts (i.e. its stack) are
   assumed to be PHP code and parsed accordingly.


 What do you think?

 --Kris


I think there is no need for that many constants and types of inclusion.
Just a PHP_SCRIPT_TYPE_NORMAL and PHP_SCRIPT_TYPE_CODE will suffice (the
later just expects the ?php at the very beginning of the file, like a
header, and no other ? or ?= or ?php through the file). The KISS
principle still applies, and it should be kept that way. Too many options
and you end up with people abusing that on purpose with reasoning Because
I can, f**k everybody else! (it's a pleasure to work with such people).
I don't like the idea of removing the ?php tag at all, because it will
mess up the syntax highlighting everywhere and annoy people that copy the
plain code without the ?php and get it not recognized as a valid source
code.

Re: [PHP-DEV] Re: internals Digest 13 Apr 2012 01:23:19 -0000 Issue 2650

[Arvids Godjuks]

Well, it's time for me to remind about the techique many use (and some
frameworks provide it out of the box) - the application file concatination
to speed up file loading.
Yii framework provides a Yiilite.php file for this, that includes mostly
used core classes in one big file.that loads much faster and is used for
production. Any other framework has user extentions or other type of
solutions for this to speed up the application, and it makes really big
difference.
So there is a good question - how the hell in a MVC framework would i
combine my models, controllers, components and other stuff that will
definetly be as in .php so in .pphp. And not every file will be cached like
that - some will remain as distinct files even in production.

The further discussion goes the more questions there is and less answers
there are.

Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts

[Arvids Godjuks]

I posted the bellow text in other thread, but i should have it post here,
so i'm reposting it to this thread.

Well, it's time for me to remind about the techique many use (and some
frameworks provide it out of the box) - the application file concatination
to speed up file loading.
Yii framework provides a Yiilite.php file for this, that includes mostly
used core classes in one big file.that loads much faster and is used for
production. Any other framework has user extentions or other type of
solutions for this to speed up the application, and it makes really big
difference.
So there is a good question - how the hell in a MVC framework would i
combine my models, controllers, components and other stuff that will
definetly be as in .php so in .pphp. And not every file will be cached like
that - some will remain as distinct files even in production.

The further discussion goes the more questions there is and less answers
there are.

Re: [PHP-DEV] PHP class files without ?php at the top

[Arvids Godjuks]

And you get same issues that existed with magic quotes, register variables,
safe mode and other optional stuff that was required to run application
when set specificaly and it would break if something set differently. PHP
just got rid of it and you want to introduce a new optional feature that
will change how PHP behaves.
09.04.2012 9:03 пользователь Yasuo Ohgaki yohg...@ohgaki.net написал:

 Hi,

 2012/4/9 Tom Boutell t...@punkave.com:
  Vulnerabilities in include/require should be fixed there, IMHO, not by
  limiting the feature set of the language.

 I'm not insisting to remove embed feature, but give a option
 for programmers/administrators for better security.

 If one is comfortable with current behavior, they can keep
 using embed feature by default. Others who care security
 may disable embed feature by optional php.ini setting or CLI
 option.

 Half of Morihoshi's RFC was joke, but it's a serious proposal
 for people who persist  better security. IMHO.

 Regards,

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


 
  On Sun, Apr 8, 2012 at 5:34 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
  Hi,
 
  2012/4/9 Arvids Godjuks arvids.godj...@gmail.com:
  8 апреля 2012 г. 8:16 пользователь Yasuo Ohgaki yohg...@ohgaki.net
 написал:
 
  2012/4/8 Ángel González keis...@gmail.com:
   On 07/04/12 22:48, Yasuo Ohgaki wrote:
   Hi,
  
   The only valid reason for removing ?php from PHP script would be
   security.
  
   Since the null byte detection for fopen, remote/local script
 inclusion
   became much harder than before. However, it's still possible and
 very
   easy compare to other languages. Script execution is critical
 security
   problem and it's worth to make it better.
  
   If there is a switch that turns off PHP's template engine nature,
 PHP
   could be more secure than now.
  
   php.ini
   template_mode = on   ; INI_ALL On by default
  
   php -t foo.php   # template mode by default
   php -T foo.php  # template mode off
  
   People has option to make their code a little secure than now
   or stick with current behavior.
  
   Regards,
   How does it help security?
   If any, requiring '?php' before executable code makes easier to
 filter
   out malicious files on apps with uploads in case there's a local
   inclusion vulnerability somewhere.
  
 
  Attackers may inject PHP script almost anything/anywhere since
  PHP code may be embed anywhere in a file.
 
  For example, malicious PHP script may be in GIF something like
 
  gif89a ...any data.. ?php exec('rm -rf /') ?
 
  and all attacker have to do is include/require the data somehow.
  Attacker cannot do that this for other languages, since they are
  not a embedded language. I know case that attackers may inject
  malicious perl/ruby script in data files, but PHP is too easy
  compare to these languages.
 
  Regards,
 
  --
  Yasuo Ohgaki
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 
 
  Improperly configured WEB server is not the reason to change the most
 basic
  part of the language that will break every damn application out there.
 
  This is not an configuration issue, but a security vulnerability that
  can simply closed by disabling embed mode.
 
  As I mentioned already, injecting malformed PHP scripts into files
  is too easy compare to other languages. This could be improved
  by simple modification and we can maintain compatibility with it.
 
  I don't see anything wrong here.
 
  Yet another PHP script injection example.
  There are many applications that store user inputs in $_SESSION.
  Attacker can inject PHP script into $_SESSION, then locally include
  it. This is easy since attacker knew their session ID and path to
  session file is can be guessed easily. All attacker has to do is
  finding a vulnerable include()/require() to attack.
 
  Regards,
 
  --
  Yasuo Ohgaki
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 
 
 
 
  --
  Tom Boutell
  P'unk Avenue
  215 755 1330
  punkave.com
  window.punkave.com
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 

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

Re: [PHP-DEV] PHP class files without ?php at the top

[Arvids Godjuks]

8 апреля 2012 г. 8:16 пользователь Yasuo Ohgaki yohg...@ohgaki.netнаписал:

 2012/4/8 Ángel González keis...@gmail.com:
  On 07/04/12 22:48, Yasuo Ohgaki wrote:
  Hi,
 
  The only valid reason for removing ?php from PHP script would be
  security.
 
  Since the null byte detection for fopen, remote/local script inclusion
  became much harder than before. However, it's still possible and very
  easy compare to other languages. Script execution is critical security
  problem and it's worth to make it better.
 
  If there is a switch that turns off PHP's template engine nature, PHP
  could be more secure than now.
 
  php.ini
  template_mode = on   ; INI_ALL On by default
 
  php -t foo.php   # template mode by default
  php -T foo.php  # template mode off
 
  People has option to make their code a little secure than now
  or stick with current behavior.
 
  Regards,
  How does it help security?
  If any, requiring '?php' before executable code makes easier to filter
  out malicious files on apps with uploads in case there's a local
  inclusion vulnerability somewhere.
 

 Attackers may inject PHP script almost anything/anywhere since
 PHP code may be embed anywhere in a file.

 For example, malicious PHP script may be in GIF something like

 gif89a ...any data.. ?php exec('rm -rf /') ?

 and all attacker have to do is include/require the data somehow.
 Attacker cannot do that this for other languages, since they are
 not a embedded language. I know case that attackers may inject
 malicious perl/ruby script in data files, but PHP is too easy
 compare to these languages.

 Regards,

 --
 Yasuo Ohgaki

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


Improperly configured WEB server is not the reason to change the most basic
part of the language that will break every damn application out there.

Re: [PHP-DEV] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters

[Arvids Godjuks]

I should point out that returning false on param parsing failure on the
language level is one thing (not to mention it's not ok to do that in the
first place by my taste), but forcing that behavior on the user-land level
is kind'a too much.

Consider how the code will become much more complicated - now you have to
not only to check what you pass to the functions, but you have to check
what it returns every single time (do I have to mention that false can be
never returned by the function at all except when the param parsing fails?).

What is consistent and exists on the internal language layer
not necessarily good for the user-land. I'm kind'a surprised no one thought
of that.
As I said I can live with the throwing notices and warnings (and not
E_RECOVERABLE_ERROR as I personally wanted), but returning false even not
trying to run the function is just a bad idea all over the place.

2012/3/12 Anthony Ferrara ircmax...@gmail.com

 Ok, so it looks like we've had some decent conversation, but it has
 started to tail off a bit.  I'd normally draft an RFC at this point,
 but it seems there's still some contention on how exactly the
 implementation should work.

 Personally, if we're going to go for any form of strict checking
 (meaning not blind-conversion), I will not support these hint rules
 diverging from zend_parse_parameters (internal functions).  It just
 creates a new layer of inconvenience and confusion for not a whole lot
 of gain.  When I say divergence from ZPP, I'm talking about the same
 behavior when ZPP returns SUCCESS, and a E_RECOVERABLE_ERROR when ZPP
 returns FAILURE...

 Now, with that said, I'd be all for making sane changes to ZPP to
 bring both inline with a common goal.  Think that passing 1abc to an
 int type hinted parameter (which currently raises a notice) is
 unacceptable?  Then my opinion is that it should be tightened in both
 places at the same time.  But they should stay connected as closely as
 possible for consistency...

 So, with that said, let me ask this question:  What needs to change
 from the current POC before it can be formalized into an RFC?  Do we
 need to tighten the conversions?  Or are they OK as-is?

 Thoughts?

 Anthony

 On Sat, Mar 10, 2012 at 2:45 AM, Tjerk Meesters
 tjerk.meest...@gmail.com wrote:
 
  On 9 Mar, 2012, at 11:20 PM, Lazare Inepologlou linep...@gmail.com
 wrote:
 
  Type casting combined with passing by reference is problematic in many
  ways. Just an example:
 
  fuction foo( string  $buffer) { ... }
  foo( $my_buffer );
 
  Here, $my_buffer has just been declared, so it is null. Should this be
 an
  error? I don't know! So, I think that that passing by reference should
 not
  be (immediately) supported.
 
 
  Strictly speaking, if you add a type to a referenced variable in that
 way it's only logical that you expect it to have a proper value when the
 function is called. After all, it's not an output type declaration :)
 

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

Re: [PHP-DEV] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters

[Arvids Godjuks]

  What is consistent and exists on the internal language layer
  not necessarily good for the user-land. I'm kind'a surprised no one
 thought
  of that.
  As I said I can live with the throwing notices and warnings (and not
  E_RECOVERABLE_ERROR as I personally wanted), but returning false even not
  trying to run the function is just a bad idea all over the place.

 I'm confused.  Do you not want E_RECOVERABLE_ERROR for parameter
 failures?  Or do you, but could live with lesser as well?  I didn't
 quite get that part...

 Anthony

Hi Anthony.

Yea, that part looks confusing.
What I wanted to say is that I would like to get E_RECOVERABLE_ERROR and I
was voicing my opinion on that earlier in the threads. But I could live
with E_WARNING and E_NOTICE if community decides it to be less strict - I
will clean up my code not to throw a single notice (and because I use Yii -
it's by default converts any E_* raised to a fatal error and throws HTTP
500 error via exceptions).

In my 8 years of active PHP development I learned that some strictness in
deep core code of the project is a good thing and erroring the hell out
there makes perfect sense. It's a delicate balance and I never apply it to
the level that does actual communication with the outside world.

Re: [PHP-DEV] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters

[Arvids Godjuks]

I think that the null issue is not an issue. Strictly speaking if you
want null or an int - leave out the type hint and use generic argument that
will accept anything.
I think it's over-engineering to try and push a special treatment for the
null. If function/method argument accepts anything but a single type -
it's type-less and does not need a type hint.

Developers should not abuse type hints and adding a special case for
handling null will make many start to request things like this:
function foo(string|array $data)
function foo(bool|int $flag)
function foo(mixed $someVar)
etc.

I'm not sure about you, but I don't wanna see that kind of thing eventually
making it's way into the language (believe me - even I considered that at
some point, but i'm more mature now and more settled in my wishes :))

Re: [PHP-DEV] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters

[Arvids Godjuks]

2012/3/12 Lazare Inepologlou linep...@gmail.com

  I'm not sure about you, but I don't wanna see that kind of thing
 eventually making it's way into the language

 Me neither. All I am saying is that, since int|null is already here from
 the back door, I think it should be properly supported.


There is no int|null at the moment, and should not be. You can pass
anything  - object, array, string, bool, int, float resource, callable -
they all are accepted and are checked in function body if it's writer wrote
that code.
Hint should provide a hint for a single type, or hint doesn't belong there.

Re: [PHP-DEV] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters

[Arvids Godjuks]

Overall good job. I would prefer it a little stricter like people already
mention, but it's a step forward definitively with witch I'm totally fine
to live with.

Re: [PHP-DEV] Scalar Type Hinting

[Arvids Godjuks]

Hi Simon!

2012/3/8 Simon Schick simonsimc...@googlemail.com:
 Hi Arvids,

 I pretty much like this idea as it's more strict. Let me say something
 to the questions you pointed out here.

 2012/3/7 Arvids Godjuks arvids.godj...@gmail.com:
 I realize that with scalars it's not that straight forward, but
 complicating things by adding an auto-cast syntax and so on is just
 ridiculous. Hints should stay, well, hints. The only problem we have
 is complications of accepting numerical strings or numbers as strings.
 And what to do with null.

 I'd like to handle it the same way as it's handled with the classes
 right now. If null is not the default-value you'll get an error when
 you pass null in there.
 One thing I'd like opened here: If you define a default-value
 different than null, should you be able to pass null as well and the
 compiler will use the default-value?

 function a(bool $bool) {}
 a(10); // Kill your self against the wall - write a(true);
 If you define bool - use the damn bool!

 I like that. What should we do if this appears? As it's now - just
 throw an Catchable fatal error and let the script blow-up? I would
 go this far.

I think Catchable fatal error should be fine and users are familiar
with such mechanic because it already exists. Consistency, man,
consistency :)


 I consider interchangeable only three cases:
 1. Numerical string.
 2. Integers and floats as strings.
 3. Integer and string  0 1 as bool.

 Any other cases should error out.

 Until now I thought about the weak variable-types as a order ...
 string, float, integer, Boolean.
 All Boolean values are compatible be an integer (0 or 1) and all
 integer are compatible to a float and so on. Do you think it's good to
 have it this way? This would mean that you could also get a Boolean
 true as string 1 ... I personally don't like that ... but I don't
 know where to draw the strict-line.
 Now think about that backwards. Can a 1 be passed as a parameter
 that expects Boolean? If yes, I'd keep it consistent in both ways.

 Bye
 Simon

That's a good tricky question, I like it.
Well, I think the lower should work just fine.
function a(bool $int) {};
a(1);

Because it's conversion to bool is straight forward. What of the
integer values [-∞, -1] and [2, +∞]? Really tricky question. From one
point of view they are a valid boolean true in the expressions. But
the question here is not if it's a valid boolean, but the fact that we
want our function to be passed with valid data and be more strict that
usual on what is passed to the function/method. So I would like to see
valid boolean values for a hinted argument these:

true
false
1
0
1
0

Simple and clear.




2012/3/8 Simon Schick simonsimc...@googlemail.com:
 Hi,

 Just a small addition to what I wrote about handling null ...

 function foo(array $d = array()) { var_dump($d); }
 foo(null); // This fails with the message: Argument 1 passed to foo()
 must be an array, null given

 As this code fails I'd not expect to change this behavior for the weak-types.

 function foo(int $d = 20) { var_dump($d); }
 foo(null); // This should then also fail. Don't care about what's the
 default-value.

 Bye
 Simon


Totally agree here.
 I would even say that if you need a null as default value - that
can't be a type hinted argument, because it already has to accept two
different types of data and code inside has to handle that anyway. The
type hint is essentially useless in this situation. Adding something
like function a(null|string $a = null) kind'a silly and again is
adding unneeded complexity.





2012/3/8 Simon Schick simonsimc...@googlemail.com:
 2012/3/8 John Crenshaw johncrens...@priacta.com:

 Conversion the other way is essential. Consider the following URL:

 http://example.com?foo=1

 In your PHP script $_GET['foo'] === '1' (a string).

 In fact, nearly every input to PHP is a string. This is why PHP was designed 
 with some seriously robust type juggling on scalars. Any typing proposal 
 that wants to actually pass a vote is going to have to allow appropriate 
 implicit conversions from string to other types.

 John Crenshaw
 Priacta, Inc.

 Hi, John

 Ok .. the example with the get-parameter is quite good.
 You'll often have the case that you submit a string 0 or 1 and
 want to have it as boolean (f.e. if you have a dropdown with two
 options).
 Please keep in mind not to mix it up with checkboxes as unchecked
 checkboxes won't be sent back to your webserver :)

 Bye
 Simon

This is exactly the example for witch type hinting should not be used.
$_GET and $_POST data can be anything - string, number, array (lord,
how many scripts break into fatal errors when you just pass an array
instead of simple string). And passing data from these sources as
params to type hinted functions is a suicide. Type hints are meant to
filter input from external sources - that data should be passed
through filtering and validating layer - only after this you can work
with the data and passing it to type

Re: [PHP-DEV] Scalar Type Hinting

[Arvids Godjuks]

 Type hints are meant to
 filter input from external sources

Correction, it should read like this:
Type hints are _not_ meant to filter input from external sources

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

Re: [PHP-DEV] Scalar Type Hinting

[Arvids Godjuks]

2012/3/8 John Crenshaw johncrens...@priacta.com:
 From: Arvids Godjuks [mailto:arvids.godj...@gmail.com]

  I like that. What should we do if this appears? As it's now - just
  throw an Catchable fatal error and let the script blow-up? I would
  go this far.

 I think Catchable fatal error should be fine and users are familiar with 
 such mechanic because it already exists. Consistency, man, consistency :)

 Yeah, I was a huge advocate of this too until recently. I've changed my mind 
 though, ironically enough to ensure better consistency.

 PHP since 5.3 gives an E_WARNING if you pass poorly-converting scalar data to 
 an internal function (For example, substr('foo', 'bar');) This changed my 
 mind about the level of error to raise here. I think there's still a good 
 argument for E_CATCHABLE_FATAL if you pass something retarded (like a 
 resource, or possibly even an array), but I think we should strive as far as 
 possible to be consistent with the behavior of scalars passed to internal 
 functions. This would allow us to repaint the entire proposal as bringing to 
 the language level the same level of scalar typing available internally, 
 using the same syntax as the docs (which sounds much more reasonable and less 
 politically charged than Please add scalar typing...again.)

 See Ferenc's reply about 30 seconds ago for more details on this...

Well, it may be that way too, but I have to point out that language
level functions are built in and you can't add or remove a type hint
for them. It expects integer and does it's best to make it an integer,
even if it gives some weird result. And backwards compability is an
issue here - _the_  _main_  _issue_. At the language level you have to
maintain that BC and sure if you make zend_parse_params reject strings
where an in should be without any warning - you sure have a rage storm
on the internet that will crush you to peaces.

Adding optional type hinting isn't bound to that BC, because we have
no scalar type hints at all. In 5.3 they added E_NOTICE and E_WARNING
to zend_parse_params. Are you sure they would not change the E_WARNING
to  E_ERROR in say PHP 6? Or bump E_NOTICE to E_WARNING? What if
type-juggling rules change? If that will happen - you will have your
type hint behavior change between versions and I think that's not
really a good idea.
So from one point of view it's a nice idea to tie that to
zend_param_parse, but from the other side that does not look like a
good idea. Internals of the engine tend to change more often than the
external syntax and behavior.


  Type hints are meant to
  filter input from external sources

 Correction, it should read like this:
 Type hints are _not_ meant to filter input from external sources

 That's not really the point though. The issues with external sources 
 providing strings comes into play regardless of whether people validated 
 their inputs. For example, if (is_numeric($priority)  $priority = 0  
 $priority = 3) will pass and still leaves you with a string, and that string 
 currently works just fine everywhere as if it were an integer. What's more, 
 the folks that will be voting on this have made it clear in the past that 
 failure to account for type juggling in any such proposal is a deal breaker. 
 For many users these inputs can and will trickle down through the code and 
 eventually cause frustrating failures if not handled intelligently. You don't 
 have to love it, but basically if you want a typing proposal to have any 
 chance I think you'll have to support it.

 John Crenshaw
 Priacta, Inc.

That's why I described the rules when type juggling comes into play.
If you send a string number, it is converted from string to number by
the type hint. If you send a string of characters and pass it to a int
type hinted function - sorry, but it's you who shout yourself with a
shotgun, not someone else.
I have to repeat it again - type hinting is not for converting and
filtering data. It is not meant to be used in code witch deals with
user input.
You will never write a code like this in 5.3 or 5.4
?php
function processArray(array $data) {
foreach ($data as $k = $v) {
// Do something
}
}

processArray($_POST['some_var']);
?
Should I tell you why? I think you know. Same goes for hinting
integer, string, float, bool or any other type. To convert data we
have conversion operators and functions like settype. Hints only
should take into account that a validated param can be a number in
string representation and change the type accordingly. But if passed
something different than a number - fail.

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

Re: [PHP-DEV] Scalar Type Hinting

[Arvids Godjuks]

2012/3/8 John Crenshaw johncrens...@priacta.com:
 From: Arvids Godjuks [mailto:arvids.godj...@gmail.com]
 That's why I described the rules when type juggling comes into play.
 If you send a string number, it is converted from string to number by the 
 type hint. If you send a string of characters and pass it to a int type 
 hinted function - sorry, but it's you who shout yourself with a shotgun, not 
 someone else.

 If you are determined to have it this way and cannot yield, then you are off 
 topic. This thread was built around the explicit premise that any scalar type 
 hint MUST be more forgiving than that, and if we take that away there's quite 
 literally nothing more to talk about. Regardless of how anyone feels about 
 it, the core devs will never accept what you are insisting on above. (If you 
 want proof, look at the prior debates on this issue.) This discussion has no 
 purpose unless it can actually accomplish something meaningful, so it started 
 by accepting this as a fundamental requirement. Allowing strings to be 
 implicitly converted to lower types when possible, regardless of whether the 
 reason offends your sense of how code should have been written, is a vital 
 compromise in the process of improving the typing in PHP.

 John Crenshaw
 Priacta, Inc.

Well, if your type hints gets more forgiving, than it's the same that
was proposed by this
function a((int) $arg) {}
And in this case hints have no meaning at all - it's just other syntax
to do the conversion that now looks like this
function a($arg) { $arg = (int)$arg; }

And please give an answer to this question: If we make hints forgiving
(like type casting), then what we have to do with current array type
hints - it gives error on anything but arrays? Change it back so it
does a conversion to array? Sorry, but it will make a mess in my code,
because I already use hints for arrays and objects and changing their
behavior is just out of the question.

I do not remember devs explicitly saying that something like I
proposed will not be accepted. They said there will be no strict type
hinting or strict variable typing. And they do not want to add another
syntax for type juggling functionality. So, if only i'm not mistaken,
my idea is somewhere in between and doesn't look weird or
extraordinary. It just adds ability to make arguments of the
function/method be more picky about what they can receive.

Maybe i'm mistaken, but I have a distinct impression that many of the
posters will use type hints all over the place if and when they will
be added and base their ideas on that. Don't get me wrong, but the
auto-casting type hints are really needed only when you really write
all the code with type hints in every function/method you define and
you don't want to do manual conversions all the time.
Maybe this is that case when people tend to get min-max and do not
consider the average use? My average use of currently available type
hints is low in WEB environment and only in internal stuff where user
input doesn't make in unchecked. And I had quite a good use of them in
a console daemon where there is no user input at all (only working
with database).

As to breaking some BC when making keywords such as string, int,
float - that's what the major releases are for. When you introduce
ANY keyword there is a possibility that someone is using it and it
will break his application. It's a risk, yes. But now days refactoring
instruments are very good and changing class name thought out the
project is no big deal really - just make sure people are informed.

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

Re: [PHP-DEV] consider reverting E_ALL with E_STRICT

[Arvids Godjuks]

Alan Knowles

You should consider the fact that some E_STRICT stuff can one day
become E_WARNING or E_FATAL. For example calling a static method
dynamically - I would bet that someday this thing will be moved to be
a run-time fatal error and fix those if I make a mistake of doing
that.
Or not setting the timezone in php.ini or in the code. If I'm not
mistaken the TZ guessing code was removed and now UTC time is used by
default despite the server TZ set. Some unexpected results can and
will come out of this. And it's a E_STRICT warning.

So really, consider kicking developer buts to fix the issues, or one
day you will find that app will not work with the new version of PHP
until it's fixed.

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

Re: [PHP-DEV] Scalar Type Hinting

[Arvids Godjuks]

I, for one, decided not to participate in the discussions any more
because they always change to something different in a few hours of
discussion. I'm surprised how people tend to complicate the feature
into something weird and ugly. I now understand why core team just
ignores some discussions.

I don't like the function a( (int) $int) syntax and approach - it's
not type hinting, it's auto-converting arguments. And adding function
a( (array) $array) is just, well, pointless. Why? Because if you have
a conversion from scalar to array - you definitely have something
wrong in the code that needs fixing, not converting and continue to
run the code like it's OK. It should come like a barrier, not a
filter. And current array and object type hinting does just that. The
(object) is also pointless for type hinting. Why? Because you usually
expect not any damn object, but an object of certain type and it's
children. That works now just fine and errors the hell out if
something isn't right.

I realize that with scalars it's not that straight forward, but
complicating things by adding an auto-cast syntax and so on is just
ridiculous. Hints should stay, well, hints. The only problem we have
is complications of accepting numerical strings or numbers as strings.
And what to do with null. Everything else is irrelevant.
function a(bool $bool) {}
a(10); // Kill your self against the wall - write a(true);
If you define bool - use the damn bool! It's not an if or switch
statement where auto-converting is usually used. It's a function call,
you should pass to it correct arguments. Type hinting is working only
for more internal API's - the data filtering and validating layer
using type hints will generate errors all over the place. We all know
how many security hole scanners out there that scan sites and pass all
kind of data to our scripts to break them and try exploiting that.

I consider interchangeable only three cases:
1. Numerical string.
2. Integers and floats as strings.
3. Integer and string  0 1 as bool.

Any other cases should error out.

Type hinting is not for using it all over the place - it should be
used in places it is really needed. And it should define the expected
type with some auto-converting limited special cases like I have
written above. That is really all it needs. No
super-duper-auto-converting type-hints, no variable type hinting and
other wild stuff I have seen during last 2-3 weeks.

Anything more complicated than that and count a -1 vote from me.

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

RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)

[Arvids Godjuks]

Secure code is not about the instrument, it's about how you write it.
Insecure spagetti code can be written in any language.

Re: [PHP-DEV] Scalar type hinting

[Arvids Godjuks]

Combining different things into one big RFC is not a good idea. It's
hard to develop and test the work it it's in one big chunk.
Decomposition makes it much easier. Type hinting has to have it's own
RFC.
Besides - someone can be willing to do type hinting patch and don't
want to do the object_cast_magic one.

And thanks for the support :)

2012/2/29 Simon Schick simonsimc...@googlemail.com:
 Hi,

 We could even combine this with the following RFC:
 https://wiki.php.net/rfc/object_cast_magic

 If an integer is required and you pass an object, it first checks if this
 object is castable to integer ;)

 Bye
 Simon

 2012/2/29 Simon Schick simonsimc...@googlemail.com

 Hi, John

 I personally do not care about weak or strong variables at all ... I only
 want what Arvids suggested last time:


  test(1, 2); // 2;
  test(1, 2); // 2
  test(1aaa, 2); // E_NOTICE or E_TYPE and result 2
  test(array(2), 2); // E_RECOVERABLE_ERROR - just like with array type
 hint now.
 
  It's really what the most people want. Simple, easy to pick up (object
  and array already have this) and is just optional.

 I count myself as a part of *most people* in this statement ;)
 I'm also quite fine with the current type-hints as you'd anyways get an
 error if you try something like this:

 function foo(SimpleClass $a) {
   $a-getName();
 }

 foo(Test);

 If you now get *method called from an non-object* or a message that you
 have passed a value that's not compatible with *SimpleClass* ...

 I'd like to split this discussion in parts:

    - just type-hint in functions (as we have it with classes and arrays)
    or bind a variable to a strict type?
       - should it then also be possible bind variables to a specific
       class or interface?
    - should we go for weak or strong types?
       - the type-hint is also weak in one way because it accepts all
       that's compatible with the given type.

 Bye
 Simon


 2012/2/29 John Crenshaw johncrens...@priacta.com

 I would personally be inclined towards something simpler like E_NOTICE or
 E_WARNING, but current type hints all raise E_RECOVERABLE_ERROR. I think we
 should be consistent, and the consistency argument may make the difference.

 There may be a strong case for changing the error level on all type hints
 to something simpler (or new, like E_TYPE), but I think that might be
 better to tackle that in a separate discussion.

 John Crenshaw
 Priacta, Inc.

 From: Kris Craig [mailto:kris.cr...@gmail.com]
 Sent: Tuesday, February 28, 2012 8:40 PM
 To: John Crenshaw
 Cc: Rick WIdmer; internals@lists.php.net
 Subject: Re: [PHP-DEV] Scalar type hinting

 I wouldn't mind that, though I'm concerned that it may not be sellable
 because some people on here have expressed a strong opinion that this
 shouldn't throw anything more than a notice or a warning at most, something
 that I and others strongly disagree with.  The logical approach, to me at
 least, is to follow the example of include() and require(); i.e. they're
 both identical except that one throws a scary error while the other one is
 just a warning.

 I'm fine with just throwing E_RECOVERABLE_ERROR, though I fear that may
 alienate too many people for us to be able to get this through.  Though
 it's possible I might be overestimating that factor.

 --Kris

 On Tue, Feb 28, 2012 at 5:17 PM, John Crenshaw johncrens...@priacta.com
 mailto:johncrens...@priacta.com wrote:
  On Tue, Feb 28, 2012 at 3:03 PM, Rick WIdmer vch...@developersdesk.com
 mailto:vch...@developersdesk.comwrote:
 
   On 2/28/2012 2:58 PM, Kris Craig wrote:
  
    strong int $a = 1; // Converts to 1.  May or may not throw an error
   (I'm
   still on the fence).
  
  
   It this is an error, it is no longer PHP.
  
 
  @Rick Though I'm not sure I'd agree with the overly broad it is no
 longer PHP hyperbole, I think the basic point that it would be a
 significant departure from the current model has merit.  So ok, you've
 convinced me.
 That example should not throw any errors.  I'm officially no longer on
 the fence with that.  =)
 
  --Kris
 OK, if we're all on the same page there, I think this means that there is
 no significant difference between the strong int and weak int in your
 proposal (the only remaining difference being the level of error raised
 when it cannot be converted, which IMO is not substantial enough to deserve
 a keyword.) I'd prefer to just pick one error level to use
 (E_RECOVERABLE_ERROR would be the most consistent) and keep everything
 simple.

 John Crenshaw
 Priacta, Inc.




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

Re: [PHP-DEV] Scalar type hinting

[Arvids Godjuks]

Guys, you probably are too deep into the discussion that you haven't
noticed an elephant Zeev has put into the room. When the RFC procces was
put in place there was a rule outlined - if core devs decide to reject,
it's rejected. And as Zeev said last time core dev team decided that there
will be no strict typing in PHP, period (btw, Zeev thanks for reminding
that). It's open source - if you want it badly, fork, patch and have your
party with black jack and girls.

Zeev i have just have one question - is it worth trying to get the type
hinting the PHP way (that converting thing that errors only on really bad
missmatches like asking for int and getting an array or object)? I
understand the argument that if rules of conversion are not changed, then
basically not much is changed. But from the code writing prespective it
becomes easier, because with converting type hint you do not need to make
explict conversions all over the code - it's done at calll time and that
simplifies things, sometimes a lot. Second - the reflection then does not
rely on phpdoc to get the types (and i remember there was an issue with
opcode caching and phpdoc being stripped and so not avaliable).
It good to have array and object hints, but i miss the
integer/string/boolean/double hints more times than i want to admit really
:-)

Re: [PHP-DEV] Scalar type hinting

[Arvids Godjuks]

Kris i have a question for you - who will implement a test patch? Previous
tries failed not because no one wanted, but because it was damn hard and
tricky. And ofcourse there was resistance against strict type hinting. Mine
included. I doubt any of the last timeinvolved will be willing to do that
again. So that is it: who has the skill, knowlage and will to do that
knowing there is very big chance it will be rejected?