Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

[David Muir]

> On 4 Sep 2016, at 6:48 PM, Lester Caine  wrote:
> 
>> On 03/09/16 22:53, Rowan Collins wrote:
>> I guess we could have a philosophical debate about what it means for
>> something to be "the standard" rather than "a standard", and whether
>> PEAR was "more official" than PHP-FIG, and just who gets to decide what
>> PHP is.
>> 
>> But once again, I find myself being drawn into an off-topic debate about
>> coding styles, and I would like to apologise to Davey as it has nothing
>> to do with his RFC.
> 
> I think that what is missing is a discussion on just where one should
> start these days in terms of a basic framework for beginners. That there
> are so many competing "standards" that in many cases do not play well
> together is MY problem. That my key libraries ARE moving to a different
> style and have different ways of loading is a pull one way, and my web
> side interface has other loaders handling javascript and css packages
> which adds to the complexity.
> 
> But perhaps we don't bother about the novice PHP user and just assume
> they are all simply using third party frameworks already so all that
> needs to be looked at is improving the library/framework developer
> experience. It would be nice to get back to some BASIC functionality
> such as loading a form, validating it's content, and string the results
> without having a dozen ways of filtering the inputs and a dozen ways of
> accessing the database.
> 
> -- 
> 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
> 


How many competing autoloading standards are there? PSR-0 (PEAR, Zend, etc) and 
PSR-4 are the two main ones I know of. Symphony used to have their own style 
back in the day, but swapped to PSR-0 with Symfony2 8? years ago. I suppose you 
could also work with just a class map, which I've seen some libs use (eg 
TCPDF)... That said if you've got some other style, just register a loader for 
it and get on with it. Sounds to me like your problem isn't with Composer per 
se, but autoloading in general?

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

Re: [PHP-DEV] New escaped output operator

[David Muir]

> On 19 Jun 2016, at 7:57 PM, Rasmus Schultz  wrote:
> 
> I am well familiar with this approach, and it does not scale - not
> only would you be aggressively loading every installed view-helper
> anytime you render a view, you would even be loading them when you're
> *not* rendering a view.
> 
> I'm afraid the best we could do at this point, without changing the
> language, is a establish a convention for autoloading functions
> (and/or namespaces of functions) from files, based on static analysis
> of template files.
> 
> But that is pretty complex - on the organizational side, it requires
> developers to agree on and adopt a convention, and on the technical
> side, you need static analysis and thereby most likely a cache layer
> as well.
> 
> It's all possible, but most people aren't going to put up with this
> much complexity for something this simple.
> 
> Hmm. What if we could import static methods into file scope and use
> them as functions?
> 
> use My\Namespace::my_function;
> 
> my_function(); // <-- effectively My\Namespace::my_function()
> 
> This would leverage auto-loading at least... I mean, it's still
> effectively just abusing classes as pseudo-namespaces, so there is
> that - but it would work with e.g. Composer right away, and probably
> with many existing static classes?
> 
> Yeah, it's still ugly...
> 
> 

Ugly, but brilliant! +1

David

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

Re: [PHP-DEV] Re: Voting choice for language changes (Was: "Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count")

[David Muir]

> On 24 Jul 2015, at 2:33 am, "S.A.N"  wrote:
> 
> 2015-07-23 18:10 GMT+03:00 Marcio Almada :
>> Hi, you replied to the wrong thread ;)
>> 
>> 2015-07-22 19:38 GMT-03:00 S.A.N :
>>> I am satisfied, the possibility of group declarations, but the that lack:
>>> 
>>> >> 
>>> use App\RestException\   // name "RestException", not imported to
>>> current namespace :(
>>> {
>>>Gone,
>>>NotFound,
>>>BadRequest
>>> };
>>> 
>>> ?>
>>> 
>>> Unfortunately have to write so:
>>> 
>>> >> 
>>> use App\RestException;
>>> use App\RestException\{Gone, NotFound, BadRequest};
>>> 
>>> ?>
>>> 
>>> It looks ugly and very strange.
>> 
>> There is nothing strange on it (except, possibly, the trailing `\`
>> which was discussed to death and voted).
>> 
>> Even if we had no trailing '\' it wouldn't make any sense to import
>> "App\RestException" when "use App\RestException{Gone, NotFound,
>> BadRequest};" is used.
>> 
>>> My proposition, the imported end name, if end of without slash.
>>> 
>>> Like this:
>>> 
>>> >> 
>>> use App\RestException
>>> {
>>>Gone,
>>>NotFound,
>>>BadRequest
>>> };
>>> 
>>> echo RestException::class; // App\RestException
>>> 
>>> ?>
>> 
>> Importing from within a namespace is not the same thing as importing a
>> class. I'd be against it.
>> 
>> My 2 cents: why do you have "RestException" with "Exception" suffix
>> and then don't have the same suffix on the other exception names? This
>> unpredictable exception hierarchy is the "ugly" part and subtle
>> alternative syntax won't make it better, IMMO.
>> 
>> Marcio
> 
> RestException is the base class for classes Gone, NotFound, BadRequest...
> He needed to catch all RestExceptions class.
> 
> We do not use suffixes for names of exception classes, simple clear
> named classes of exceptions, this is our agreement.
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

Then why not put the base class in the namespace of which it is a base class 
for?

Cheers,
David


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

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

[David Muir]

> On 14 May 2015, at 9:27 pm, Yasuo Ohgaki  wrote:
> 
> Hi Arvids,
> 
> On Mon, May 11, 2015 at 8:01 PM, Arvids Godjuks 
> wrote:
> 
>> 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...
> 
> 
> Too large value raise typeException (Thanks Nikita)
> DoS is easy on 32 bit CPU machines, but it's possible on 64 bit machines
> also.
> 
> Simplest scenario would be client side DoS. Many IoT devices will remain 32
> bits and if it
> gets result value larger than 2 billions, execution may stopped by
> unhandled exception
> sudduly. Library/framework uses basic type hint may harm system like this.
> 
> Some databases support unsigned INT8. Most databases support NUMERIC/DECIMAL
> which can have value larger signed 64 bit int. If attacker find way to
> store too large ID
> somewhere (e.g. as JSON/XML text that queries database), then system may
> use the
> value against type hinted functions/methods.
> 
> Without basic type hints, these concerns weren't existed.
> 
> Regards,
> 
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net


Yasuo,

I still don’t see how you can put the blame for the unhanded exception on type 
hints. The problem you’re describing is not new and exists today with libraries 
using code like this:

function foo($int) {
if(!is_int($int)) {
throw new InvalidArgumentException(‘Parameter must be of type int’);
}
//… do something with $int
}

Cheers,
David


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

Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5

[David Muir]

> On 18 Mar 2015, at 3:44 pm, Yasuo Ohgaki  wrote:
> 
> Hi Pierre,
> 
>> On Wed, Mar 18, 2015 at 1:35 PM, Pierre Joye  wrote:
>> 
>>> On Mar 18, 2015 11:26 AM, "Yasuo Ohgaki"  wrote:
>>> 
>>> I didn't have my time to spent for the patch. So I don't verify this
>>> by myself, but it seems common sense for this RFC.
>> 
>> So you voted against it without knowing how it actually works or aims to
>> work? I suggest you to do it now then, before going further with this
>> discussion :)
> I know we are better to play with patch before vote.
> I played with Zeev's patch and I was sure it's better ;)
> 
> How many of voters spend enough time for both patches before vote?
> 
> The reason I admit that I didn't spent time to play with the patch is
> following behavior does not make sense to me much and I have
> doubt for it.
> 
> lib.php:
> declare(strict_types = 1);
>function foo(int $a) {
>// no function call here
>}
> ?>
> The declare here does just nothing.

Correct. There are no function calls in the file, so there's nothing for 
declare strict to act on.

> 
> require "lib.php";
>foo("123"); // will work
> ?>
> 
> declare(strict_types = 1);
>require "lib.php";
>foo("123"); // will give an error
> ?>
> 
> Could someone knowledgeable shed light on this?
> 
> Regards,
> 
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net

Shed light on what exactly? Why it behaves this way?

The second file passes because it is in the default weak mode, so it will 
coerce to an int, so the type hint is satisfied.

The third file will error because you have asked it to error when you pass the 
wrong scalar type to a function.

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

Re: [PHP-DEV] STH and the 3 RFCs

[David Muir]

> On 17 Mar 2015, at 1:33 am, Thomas Punt  wrote:
> 
> Hey David,
>> A library written in weak or strict mode will have no bearing on its public 
>> API.
> 
> Strictly speaking (pun intended), this is not true. A library can easily 
> expose a
> facade that enforces a user of that library (who is in weak mode) to have to 
> write
> in strict mode [1]. Once more, this can be done unintentionally [2] because 
> of the
> caller-deciding semantics. These examples can be further extended into wrapper
> classes, nested library dependencies, etc.
> 
> Sure, you could argue that this could easily be turned off by simply removing 
> the
> top declare() statement of that library, but modifying the library in itself 
> introduces
> complications - especially when using dependency managers like Composer.
> 
> [1] https://gist.github.com/tpunt/4830d18d47e2df021c2f
> [2] https://gist.github.com/tpunt/eecfed2495bdccb73632
> 
> -Tom   

No, your example would blow up regardless of the caller being in strict mode or 
weak mode. The calls made in the library are strict, and will always fail with 
bad input. All you've shown is that poor code will blow up with poor input 
validation.

If you had:
test('1');

It would still error just as before.

Cheers,
David

Re: [PHP-DEV] About declare(strict_types = 1)

[David Muir]

>> On 16 Mar 2015, at 11:16 pm, Pavel Kouřil  wrote:
>> 
>> On Mon, Mar 16, 2015 at 1:04 PM, Dan Ackroyd  wrote:
>>> On 16 March 2015 at 11:49, Pavel Kouřil  wrote:
>>> 
>>> Seriously, think about it for a while - when some setting that changes
>>> how code behaves was a good idea?
>> 
>> 
>> The problem is that there are two irreconcilable camps - some people
>> want weak STHs, other people want strict STHs.
>> 
>> This RFC gives both camps what they want, at the cost of having the dual 
>> mode.
>> 
>> I personally would prefer a single mode, with strict STHs but I can
>> see that would piss off the other camp. And so to me, this RFC even
>> with the ickiness of the setting, is an an acceptable cost to giving
>> both sides what they want. Oh, and people who don't want to use scalar
>> type hints at all, can still continue to not use scalar type hints,
>> and their code will continue to keep working.
>> 
>> Anyone who is voting no, isn't doing so because they are missing out
>> on a feature, they're doing it to block other people from getting what
>> they want in PHP, which is just a terrible way to vote.
>> 
>> And if the strict camp are wrong and strict scalars are just not used
>> by a large proportion of the PHP community, it would be trivial to
>> remove support for the strict mode in a future version of PHP, as all
>> code that runs in strict mode, will automatically work in weak mode.
>> 
>> cheers
>> Dan
> 
> I can't speak for anyone who voted, but personally, if I could vote, I
> would voted "no" - not because "I don't want to block people from
> getting what they want", but because I sincerely think that having ANY
> setting that changes code's behavior is bad in the long run (and that

Do you use an error handler that converts notices into exceptions? By your 
statement, I'm guessing no, and that you think error handlers should not be 
used that way as they change the code's behavior in almost exactly the same 
manner?

> removing the feature might not be really easy, once people realize
> that the feature is really bad, as people realized with safe_mode and
> register_globals after few years).


Removing the feature is trivial! A search / replace across the code base can do 
it, and it could be disabled at the engine level. For working code, nobody 
would notice the difference because strict code works in weak mode. In other 
words, there are no BC issues with removing the strict portion. 

Can people stop comparing it to register globals? Have you ever tried to fix a 
codebase that relied on it? It is impossible to detect! You really don't have 
many options but to step through and manually run through every single entry 
point into your application and test/audit every code path, and the hope you 
catch everything. It was a global setting, removing it was a *huge* BC break, 
and its use was undetectable. None of which is the case with dual mode. There's 
no global setting, there's no BC with removing it, and it's use is *extremely* 
easy to detect! 

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

Re: [PHP-DEV] STH and the 3 RFCs

[David Muir]

>> On 14 Mar 2015, at 6:41 am, Lester Caine  wrote:
>> 
>> On 13/03/15 18:53, guilhermebla...@gmail.com wrote:
>> By considering PHP's nature, having a dual mode is a WTF. I can see myself
>> asking multiple times a day "is this file strict or not?" to trace
>> potential bugs or type juggling. I do want strict, but I don't think it's
>> the right time for PHP to make this move. Userland would have strictness,
>> but all internal functions are a weird WTF type juggling mode. I originally
>> switched my vote many times in the v3 of the RFC, mainly because PHP
>> developers are the ones that would suffer by these configurability on a
>> daily basis. I ended up with a YES vote because when considering STH or
>> nothing at all, I prefer to have some.
> 
> The bigger WTF is perhaps that moving forward one has no idea just what
> a third party library is using internally. A case has been made that
> this does not matter since calling that library from a non-strict site
> will simply work as now, but in that case the library is not designed to
> handle non-strict input. It assumes that the strict check happens, where
> a well designed 'weak' library will be handling the edge cases properly.
> It not simply a matter of "is this file strict or not?" but rather "what
> happens when I pass the wrong data?".

If I've understood the RFC's correctly, your point is moot. With any scalar 
type hints, a library will not be able to tell how it is being called. All it 
knows is that it has received an int, string, float, or boolean where it has 
asked for one. A library written in weak or strict mode will have no bearing on 
its public API. This is the case with all of the STH RFCs. 

So no, a weak mode library is not better off. It is actually worse off because 
it has more edge cases where things could go wrong (internally), while a strict 
library will not function at all until the edge cases are actually taken care 
of.

As far as being a user of the library itself, the strictness or weakness of the 
library code is irrelevant. You can use a weak library in strict mode, and the 
library would never know or care.

if you decide to make all your own code strict, you're not changing the 
behavior of the library. If you make all your own code weak, you're not 
changing the behavior of the library. Even if you strips out all the declare 
strict statements, it will not change the behavior of the library (except in 
the case where the code was broken and wasn't even working previously!).

I think the best way to explain the dual mode RFC is to think of it like this:
Imagine PHP threw a COERCIBLE_TYPE_MISMATCH notice whenever you pass the wrong 
type to a function. In weak mode, the type gets coerced, the notice is ignored, 
and we truck along as if nothing happened. Strict mode is basically where 
you've set up a custom, per-file error handler where COERCIBLE_TYPE_MISMATCH 
notices are turned into fatal errors. It is your code that decides which error 
handler to use.

Cheers,
David



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

Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions

[David Muir]

> On 10 Feb 2015, at 9:29 am, "Anatol Belski"  wrote:
> 
> Hi,
> 
> the voting on the removals in PHP7 in hereby finished. The results are
> 
> 
> item   yes:no
> 
> sapi/aolserver 32:0
> sapi/apache32:0
> sapi/apache_hooks  31:0
> sapi/apache2filter 23:1
> sapi/caudium   30:0
> sapi/continuity28:0
> sapi/isapi 28:0
> sapi/milter10:9
> sapi/phttpd26:0
> sapi/pi3web24:0
> sapi/roxen 23:0
> sapi/thttpd25:0
> sapi/tux   25:0
> sapi/webjames  25:0
> ext/imap   14:19
> ext/mcrypt 15:18
> ext/mssql  17:13
> ext/pdo_dblib  4:18
> ext/sybase_ct  17:1
> 
> As most of the items are considered to be removed, the ones to stay
> untouched by the 50%+1 requirement are
> 
> ext/imap
> ext/mcrypt
> ext/pdo_dblib
> 
> I'm going to implement and tag the changes considered ASAP. Regarding the
> stuff to considered to be removed from the core - if there are some
> supporters, the sources will be made available in the git tag. They can be
> anytime ported to PHP7 and possibly resurrected.
> 
> Regards
> 
> Anatol
> 
> 
> 
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

Does this mean PHP will be taking on the role of maintaining libmcrypt as well? 
If a security issue is found, what is the course of action?

Cheers,
David

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

Re: [PHP-DEV] [VOTE] Add is_cacheable() stream-wrapper operation

[David Muir]

> On 3 Feb 2015, at 3:49 am, Rasmus Lerdorf  wrote:
> 
>> On 02/02/2015 08:38 AM, François Laupretre wrote:
>> Hi,
>> 
>> Opening the vote for :
>> 
>> https://wiki.php.net/rfc/streams-is-cacheable
>> 
>> This RFC proposes a generic way for opcode caches to decide if a given URI
>> is cacheable or not.
> 
> Doesn't this imply that "path" is the one true cache key? There are some
> issues with that which we will have to address at some point. For
> example, when running fpm chrooted you need more than the path. We'll
> likely need a more APC-like option here to use the device+inode for the
> key. It seems like a generic mechanism like you are proposing needs to
> take this into account and provide some mechanism that tells the opcode
> cache how to determine uniqueness. Perhaps that is simply encoded into
> the path parameter, but then maybe it should have a more appropriate name.
> 
> -Rasmus
> 
> 

Don't we already have this problem with chrooted FPM? I haven't tested it more 
recently, but last time I tried, opcache would fail to invalidate the cache 
after updating the file. Worked fine with a non-chroot environment. Not sure if 
this is related to the issues you mean here...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Revert "Disable PEAR by default": configure.in

[David Muir]

> On 28 Jan 2015, at 8:58 pm, Ralf Lang  wrote:
> 
>> On 28.01.2015 10:46, Tony Marston wrote:
>> "Sebastian Bergmann"  wrote in message news:54c75d9e.8090...@php.net...
>>> 
 Am 27.01.2015 um 10:00 schrieb Lester Caine:
 composer has not even managed to get added to some distributions yet
>>> 
>>> This is not about PEAR Installer vs. Composer or something else. This
>>> is about the PHP core getting untangled from third-party software that
>>> impedes the development of PHP itself.
>>> 
>>> As a sidenote, to most (if not all) PHP developers that I have met
>>> since PHP 5 came out there is nothing of value in PEAR (as in the
>>> packages hosted on pear.php.net).
>> 
>> How about those applications which still user the MAIL functions in
>> PEAR? How about some of the 3rd party applications, such as SVNManager
>> which still require some PEAR functions?
> 
> When an application uses a library which is broken under new php versions
> 
> * fix the library
> * exchange the library, use a mail component from horde, roundcube,
> zend... don't know
> * keep the old PHP version.
> 
> So much for MAIL - it's been like that for years with other bc breaks.
> 
> For pear, you can probably
> * install PEAR separately from PHP
> (which might be healthy for PEAR itself)
> * use pyrus instead
> * get the MAIL package from another source than pear, like composer or
> distribution RPMs.
> 
> 
> @sebastian:
> 
> pear.php.net still has some valuable things like Date_Holidays, but most
> of it is not desirable anymore. This is not necessarily the case for all
> those 3rd party channels around. I know some of them have been removed,
> but that's another point.
> 
> 
> -- 
> Ralf Lang
> Linux Consultant / Developer
> Tel.: +49-170-6381563
> Mail: l...@b1-systems.de
> B1 Systems GmbH
> Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
> GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
> 


Are we discussing the PEAR installer or everything related to PEAR? 

I see no reason to include the PEAR installer by default. Heck, on most distros 
it's already split out into a separate package. 

If I already have to install a package installer (php-pear) to install 
extensions using pecl, then I see no reason why we can't say "install this 
other installer instead".

If PEAR works with php7, then great, you can use that as your installer. If 
not, use pickle, your distro's package manager, or download a precompiled 
binary.

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

Re: [PHP-DEV] PHP 5.3 windows binaries

[David Muir]

> On 4 Jan 2015, at 12:34 pm, Thomas Hruska  wrote:
> 
>> On 1/3/2015 4:56 PM, David Muir wrote:
>> Shouldn't this be directed to the webmaster mailing list? 
>> php-webmas...@lists.php.net
> 
> See below.  They said that they don't have access to that server.  :)
> 
> 

Ah, missed that part. So who's in charge of the windows sub domain?

Sent from my iPhone


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

Re: [PHP-DEV] PHP 5.3 windows binaries

[David Muir]

Shouldn't this be directed to the webmaster mailing list? 
php-webmas...@lists.php.net

Sent from my iPhone

> On 4 Jan 2015, at 4:45 am, Thomas Hruska  wrote:
> 
>> On 12/28/2014 4:47 PM, Thomas Hruska wrote:
>>> On 12/7/2014 10:52 PM, Thomas Hruska wrote:
 On 11/29/2014 6:27 AM, Thomas Hruska wrote:
> On 11/15/2014 12:13 AM, Pierre Joye wrote:
> Good point. They will remain in the archives part. We kept them after
> eol
> just in case there was a last min critical update (we had one
> actually :)
> 
> I will remove them asap.
 
 Bump.
>>> 
>>> 5.3 binaries still on the site:
>>> 
>>> http://windows.php.net/download/
>>> 
>>> 
>>> (Keeping them in archives is fine by me.)
>> 
>> Bump.
> 
> Just a friendly reminder that this hasn't been done yet.
> 
> 
> On Nov 15, 2014 1:45 PM, "Thomas Hruska" 
> wrote:
> 
>> PHP 5.3 was removed from the website earlier today (a good thing).
>> However, the Windows binaries remain:
>> 
>> http://windows.php.net/download/
>> 
>> Oddly, the webmaster group claims to not have access to that
>> section of
>> the website:
>> 
>> http://news.php.net/php.webmaster/20275
>> 
>> Possibly consider granting access to one or two people in that group?
>> The
>> access would be for special situations such as removing EOL'ed
>> versions
>> when they come down from the main website.  PHP 5.2 Windows binaries
>> stuck
>> around for a very long time after 5.2 sources were removed from the
>> main
>> downloads page - most likely for the same reason of not having
>> access to
>> make those changes.
> 
> 
> -- 
> Thomas Hruska
> CubicleSoft President
> 
> I've got great, time saving software that you will find useful.
> 
> http://cubiclesoft.com/
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

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

[David Muir]

> On 21 Dec 2014, at 10:32 am, Kevin Israel  wrote:
> 
>> On 12/20/2014 05:16 PM, Paul Dragoonis wrote:
>> It's too big of a BC change firstly.
>> 
>> Secondly it has no language benefit or developer benefit.
> 
> Are you sure? Autoloading schemes such as PSR-4 derive pathnames from
> class names without converting them to lowercase. If case mismatches go
> undetected and unreported, a project might work on a developer's Windows
> desktop (case-insensitive) yet not when uploaded to a Linux web server
> (case-sensitive). Or when an object instantiation or a static method
> call using the correct case is removed from the code, a later call using
> the incorrect case might break.
> 
> Backward compatibility is perhaps a good reason to not make this change.
> However, I would like to see at least an option to report case
> mismatches in class names as E_STRICT errors and possibly a way to
> disable that for specific files or classes when necessary.
> 
>> On 20 Dec 2014 22:01, "F & N Laupretre"  wrote:
> 
>>> I would like to propose that namespaces, functions, and classes become
>>> case-sensitive (constants are already case-sensitive). Actually, I never
>>> understood why they are case-insensitive. Even if the performance gain is
>>> negligible, I think it could be the right time to question this.
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


+1 on E_STRICT warning for case mismatch on class names. Also +1 on eventual 
case sensitivity for userland class names. Not convinced the rest is worth it.

The insensitivity makes code brittle. Sometimes the same code will run fine, 
and other times it breaks depending on what lines triggered the auto loader. If 
you instantiate a Foo instance first, then instantiate a new foo, the code runs 
fine, but if you try to instantiate a new foo first, we get a fatal error.

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

Re: [PHP-DEV] [VOTE][RFC] Safe Casting Functions

[David Muir]

Not a voter, but I don't really see the usefulness of this in core either. 

Sent from my iPhone

> On 21 Nov 2014, at 11:45 am, Adam Harvey  wrote:
> 
> My -1 is pretty much the same as Levi's:
> 
>> On 19 November 2014 13:57, Levi Morrison  wrote:
>>  - The RFC does not address how this is different from
>> FILTER_VALIDATE_* from ext/filter. I know there was a mention of this
>> on the mailing list, but the RFC should say why a tool that already
>> exists to solve this kind of problem is insufficient, especially when
>> it is enabled by default.
> 
> I'm also somewhat concerned that these functions are conflating two
> concerns (validation and conversion).
> 
>>  - PHP suffers a lot from function bloat and this RFC provides
>> multiple functions that do the same thing but differ only in how they
>> handle errors. A simple validation of "can this be safely cast to an
>> integer without dataloss?" avoid the issue entirely and would be fewer
>> functions.
> 
> +1: the idea of adding two sets of identical functions except for how
> they signal errors isn't one I like.
> 
> Derick raised a good point elsethread: this is really tied into how we
> want to signal errors in PHP 7. If we switch to exceptions, then let's
> figure out a plan of attack and switch to exceptions everywhere, not
> just in the odd function here and there. If we don't, then the to_*
> functions shouldn't be added.
> 
>> To summarize: I like the idea of having tools that helps us convert
>> between types in a lossless way, but I don't think this proposal is
>> what is best for PHP. -1 for me but I hope to see this revisited.
> 
> I don't know that I'd ever be a strong +1 on this (adding more type
> conversion matrices to PHP doesn't seem like a good idea to me,
> whether it's in the language itself or in the standard library, and I
> feel like we have the validation part of this already in filter and
> ctype), but if we figured out the error handling situation and had
> only one set of functions, I could probably grit my teeth and abstain,
> at least.
> 
> Adam
> 
> -- 
> 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] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)

[David Muir]

On 29/10/2014, at 12:43 AM, Julien Pauli  wrote:

> On Mon, Oct 27, 2014 at 6:27 PM, David Soria Parra  wrote:
>> On 2014-10-26, Bob Weinand  wrote:
 Am 26.10.2014 um 17:23 schrieb Lester Caine :
 
 On 26/10/14 15:41, Bob Weinand wrote:
> Ask them at PhpStorm. They were pleased to not have to use DBGp for it.
> They just initially requested it because they didn’t knew any better 
> protocol. That’s all.
 
 PHPStorm like PHP-FIG have their own agendas which do not play well with
 other groups of developers. Just because one thinks an idea is good does
 not mean that everybody else has to adopt it. So what becomes 'main
 stream' has to have common consensus and the voting rules provide that.
 
 When was the vote on this rework taken?
 
 --
 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
>>> 
>>> There wasn’t any vote and there won’t.
>>> 
>>> /dev/null likes to listen to your complaints why we should have voted on it.
>> 
>> step back a bit here, stay professional, there is no need for passive
>> aggressiveness.
>>> 
>>> But now it’s in, let’s rather try to improve what’s there than screaming 
>>> for a vote - it won’t help anyone and hinder possible work on improving the 
>>> current thing.
>> 
>> From what I see, the complan is about the initial protocol and not about
>> how to improve it or not. This whole protocol business needed an RFC,
>> which I haven't seen. So we should come up with a good way of deciding
>> which protocol to use and how to implement it. Before this, I would strongly
>> vote to not incldue the current verison in PHP 7 at all. Also let me point
>> out that the code belogns to everyone and everyone will have to deal with it
>> so we better make an informed decision now.
> 
> Hello people.
> 
> When PHP 5.6 has been released, few weeks/months ago, I explicitely
> stated Ferenc (RMing 5.6 together with me), that *it is not a normal
> thing to have an external domain for phpdbg*
> 
> This has never happened before, FWIR

FYI, PHP-FPM still has a separate website.

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

Re: [PHP-DEV] crypt() BC issue

[David Muir]

On 21/07/2014, at 10:04 AM, Yasuo Ohgaki  wrote:

> Hi Anthony,
> 
> I want to finish and close this issue.
> 
> On Sun, Jul 20, 2014 at 9:33 AM, Yasuo Ohgaki  wrote:
> 
>> Also, Deprecating crypt() without first discussing it (and having an
>>> RFC to vote on) is not cool (and has been reverted):
>>> 
>>> http://svn.php.net/viewvc/phpdoc/en/trunk/reference/strings/functions/crypt.xml?r1=333973&r2=334296
> I wrote
> 
> "Use of crypt is deprecated."
> 
> not
> 
> "crypt() is deprecated". I didn't mean crypt() function deprecation. If
> it's confusing, I don't mind at all to rewrite it.
> BTW, what part is wrong?
> 
> It seems we have misunderstanding each other, but the basis is the same, I
> suppose.
> 
> - crypt() will remain
> - User/developer should use password_*()
> - It's not good idea to have PHP own crypt()
> 
> The differences are E_NOTICE and workaround, it seems.
> IMO, password_hash() must raise E_NOTICE for too long password. Truncation
> without error is
> not an option for me. People write stupid code without internal knowledge.
> Adding fixed salt was
> common since crypt() was not good enough used to be. In addition, maximum
> password length
> is not decided by us, but decided by app developers. Therefore, we are
> better to provide/explain
> workaround for password_hash() limitation.
> 
> Prehash in PHP is not an option as we don't want PHP only crypt(). Prehash
> by developer is
> acceptable workaround for me. As you know, chars that are used in password
> is limited. Some
> developers even allow UTF-8 for password, structured encoding could reduce
> total number of bits
> in password hash with limited password length. Prehash with raw SHA512 will
> give us adequate
> data for PASSWORD_BCRYPT hashing regardless of password length.
> 
> Prehash ruins password_*() flexibility for sure, but there is workaround
> also. Developer may use
> timestamp to check new hash (e.g. 1024 bits hash, etc) should be used or
> not.
> 
> If we don't want such workarounds, we may enable SHA512 hash for
> password_hash() for those
> who don't want password length limit.
> 
> Regards,
> 
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net


Yasuo, 

Prehashing with sha512 means it is no longer blowfish. It is now a non-vetted 
DIY algorithm. The whole point of password_hash is to avoid this type of thing, 
and should be clearly discouraged in the documentation.

It's a classic example of what not to do.

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

Re: [PHP-DEV] Automatic Property Initialization

[David Muir]

On 09/10/13 07:39, Nikita Popov wrote:

On Mon, Oct 7, 2013 at 11:53 AM, Gordon Oheim  wrote:


Since the feedback so far was few but positive, I'll advance the RFC to
the next stage. Apart from this, any feedback is still welcome.

Thanks and Regards, Gordon


For the lazy folks, this is the RFC Gordon is talking about:
https://wiki.php.net/rfc/automatic_property_initialization

Nikita



Thanks Gordon and Nikita,

I like the General Automatic Assignement idea. It does start getting 
into accessor territory (which I think is a better solution overall), 
but allows for writing a bit less boilerplate code.


Would fluid interfaces still be possible?

public function setFoo($this->foo) { return $this; }

Cheers,
David

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

Re: [PHP-DEV] Request #65501 uniqid(): More entropy parameter should be true by default

[David Muir]

On 23/08/2013, at 11:24 AM, Yasuo Ohgaki  wrote:

> On Fri, Aug 23, 2013 at 9:32 AM, Yasuo Ohgaki  wrote:
> 
>> We need better function as basic feature of PHP. unique_hash() or
>> hash_unique() might be good. UUID works and is much better but generating
>> unique hash just like session ID is trivial to implement.
> 
> 
> Any one working on UUID module?
> Fedora uses OSSP's UUID lib. I would like to create UUID module if no one
> is working on it. It relies on external lib, so I think we need something
> like hash_unique() regardless of UUID module.
> 
> Regards,
> 
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net


Well, there's this:

http://pecl.php.net/package/uuid


David

Re: [PHP-DEV] Functionality updates to array_column()

[David Muir]

On 23/04/13 14:50, David Muir wrote:

On 23/04/13 07:35, Sherif Ramadan wrote:

On Mon, Apr 22, 2013 at 1:35 PM, Ben Ramsey  wrote:


I've just submitted the following pull request for updates to the
array_column() function:

https://github.com/php/php-**src/pull/331<https://github.com/php/php-src/pull/331> 



I asked about these changes on the #php.pecl IRC channel a few weeks 
ago,
and others on the channel agreed that it was best to go ahead and 
submit
these changes while PHP 5.5 is still in beta, since these would 
potentially

create BC breaks once 5.5 is in RC or GA stages.


I might be wrong here, but I thought beta was a feature freeze. Is it 
not?




First Beta is slated for tomorrow, isn't it?

David



Haha, oops. Just noticed that the 3rd beta is already out.

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

Re: [PHP-DEV] Functionality updates to array_column()

[David Muir]

On 23/04/13 07:35, Sherif Ramadan wrote:

On Mon, Apr 22, 2013 at 1:35 PM, Ben Ramsey  wrote:


I've just submitted the following pull request for updates to the
array_column() function:

https://github.com/php/php-**src/pull/331

I asked about these changes on the #php.pecl IRC channel a few weeks ago,
and others on the channel agreed that it was best to go ahead and submit
these changes while PHP 5.5 is still in beta, since these would potentially
create BC breaks once 5.5 is in RC or GA stages.



I might be wrong here, but I thought beta was a feature freeze. Is it not?



First Beta is slated for tomorrow, isn't it?

David

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

Re: [PHP-DEV] [RFC] Class instances counter

[David Muir]

On 09/04/13 10:29, Joe Watkins wrote:

On 04/08/2013 09:07 PM, Madara Uchiha wrote:

I'm with Morrison, I see no actual use for this.

It's "cool", but what would you use it for?

On Mon, Apr 8, 2013 at 10:47 PM, Levi Morrison 
 wrote:

I see little value in having a function that tells me how many objects
of any kind I have instantiated. Mostly, I see it as a way to help
teach people about assignment of objects works in PHP:

 $a = new MyClass();
 $b = $a;
 var_dump(get_object_count());

And that's about the sum of how useful I think this is.

If it were to be able to narrow it to a specific class then it *might*
be a little more useful.

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



I see some merit in the idea that during development of an application 
it could be useful to get a profile view of the object store, without 
affecting those objects or introducing new objects in order to provide 
that view.


There are other run-time use cases, but for me, mostly development and 
debugging, without being intrusive or having any real impact on the 
application or object store.




Isn't that what a debugger is for?

Cheers,
David

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

Re: [PHP-DEV] Re: [lists.php] Re: [PHP-DEV] a couple of thoughts on the DateTime type debate

[David Muir]

On 06/04/2013, at 1:40 AM, Rasmus Schultz  wrote:

>> why not make struct almost like a class except
>> that $this is a copy (on write) - modifying and returning $this would
>> be a new instance of that struct/class. That would give you
>> public/private/static/variables/methods/interfaces/..., but it would
>> lead to another type.
> 
> As said, I don't know the innards of the codebase, but that sounds more
> "hacky" to me somehow? - other value-types in PHP such as array already
> have the semantics we're looking for in value-types, whereas
> classes/objects do not. I don't know how it's implemented though.
> 
>> Or use a keyword to the class, e.g. "autoclone class Color {...", and
>> not the new name struct -> it would be clear that struct/classes use
>> the same namespace.
> 
> Other languages use the term "struct" - I don't think there's any reason to
> invent new terminology for something that is already well-known and has
> established terminology?
> 
> 
> 
> On Fri, Apr 5, 2013 at 10:00 AM, ALeX  wrote:
> 
>>> I imagine the implementation could be something along the lines of
>> checking
>>> for the '__struct' key when somebody attempts to use method-call syntax
>> on
>>> an array, invoking the appropriate method with $this referencing the
>> array
>>> you were using.
>>> 
>>> The rest of the time, a struct, for all intents and purposes, is just an
>>> array.
>> 
>> One thing I do not like about the "struct as array" is that you can
>> create "invalid" structs, in classes you could have all variables
>> private and check during set, but not here: "$array = ['r'=>1,
>> 'b'=>'yes', '__struct'=>'Color'];".
>> 
>> Hmm... just an thought: why not make struct almost like a class except
>> that $this is a copy (on write) - modifying and returning $this would
>> be a new instance of that struct/class. That would give you
>> public/private/static/variables/methods/interfaces/..., but it would
>> lead to another type.
>> Or use a keyword to the class, e.g. "autoclone class Color {...", and
>> not the new name struct -> it would be clear that struct/classes use
>> the same namespace.
>> You maybe even could do "autoclone class DateTimeImmutable extends
>> DateTime {}" to create the immutable version. (I see no reason why an
>> "normal" class could not be extended into autoclone, but useless in
>> most cases though)
>> 
>> On the other hand, I would just use an array. (without any "magic"
>> like methods on structs, yes you would have to write plain functions
>> and not use OOP like methods).
>> 

Isn't this basically the way classes were originally implemented in php4?

Cheers,
David

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

Re: [PHP-DEV] Continuous Integration Atomic Deploys and PHP 5.5

[David Muir]

On 24/03/13 09:26, Rasmus Lerdorf wrote:
> On 03/23/2013 03:01 PM, Ferenc Kovacs wrote:
>> realpath the document root(which is a symlink to the actual release
>> directory) from your index.php/bootstrap file and use that as a base
>> path for making absolute paths everywhere?
>> that way the requests started before the symlink switch will continue
>> with the old version but requests started after the switch will use the
>> files from the new revision.
>> ofc. you can still have issues like an ajax request from the old version
>> gets served by the new version, and if you have more than one server
>> sooner or later you will/have to sacrifice something from the CAP trio.
> Well, solving the multi-request/multi-server ajax scenario is a bit of a
> different problem. You'd need to version those requests to handle that.
> The scope I am concerned with here is per-server deploy atomicity.
>
> But yes, some way to have a 2-docroot scenario where all requests
> started on one via the docroot symlink stays on that one would be a good
> approach but it would take a lot of discipline at the userspace level to
> enforce that across a large and diverse codebase with autoloaders and
> actual realpath calls all over the place.
>
> -Rasmus
>

Are you saying that to allow atomic deploys with O+ you need to make
sure that all files are either autoloaded with a full realpath, or
manually included/required by the realpath?

You mentioned that O+ does not use inodes as cache keys like APC, but
what does it use instead? Just the file path?

Cheers,
David

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

Re: [PHP-DEV] __invokeStatic() method

[David Muir]

On 18/03/2013, at 6:07 PM, Matīss Roberts Treinis  wrote:

> Not only that. This potentially might break compatibility with many
> software products already out there. Also, this might lead to many
> misunderstandings and, in fact, ambiguous code. Consider the sample.
> 
> $name = 'something';
> $something = $name(); // What is this - a function call or object?
> 
> Fact is, we can not know that unless a) do a search in code b) var_dump?
> 
> 
> 2013/3/18 Pierre du Plessis 
> 
>> On Mar 18, 2013 2:41 AM, "Thomas Bley"  wrote:
>>> 
>>> On Sat, Mar 16, 2013 at 9:33 PM, Pierre du Plessis
>>>  wrote:
 On Mar 16, 2013 9:35 PM, "Daniele Orlando"  wrote:
> 
> Hi List,
> 
> I'm interested in proposing an RFC and I would know your opinion.
> 
> === Current Situation ===
> Since PHP 5.3 we can use an object instance, who defines the
>> __invoke()
> method, as a callable object.
> Example:
> 
> // PHP Code.
> class Runnable
> {
>public function __invoke()
>{
>echo "Runned";
>}
> }
> 
> $r = new Runnable();
> $r();
> 
> // Output
> Runned
> 
> === The Idea ===
> In Python, when you construct an object, you don't need to use the
>> "new"
> keyword but you just invoke the class name followed by "()", like the
 class
> is a function.
> Example:
> 
> // Python Code.
> class A:
>pass
> 
> A()
> 
> // Output.
> <__main__.A instance at %address>
> 
> Now, would be interesting to extend the PHP __invoke() method adding
>> an
> __invokeStatic() method, like happens with __call() and __callStatic()
> methods.
> In this way could be possible to use a class name to invoke the
> __invokeStatic() method.
> Example:
> 
> // PHP Code.
> class TrueRunnable
> {
>public static function __invokeStatic()
>{
>echo "Runned";
>}
> }
> 
> TrueRunnable();
> 
> // Output.
> Runned
> 
> But the possibility are endless:
> 
> class A
> {
>public static function __invokeStatic()
>{
>return new A();
>}
>public method m() {}
> }
> 
> A()->m();
> 
> // or
> 
> class A
> {
>private $_instance;
>public static function __invokeStatic()
>{
>// Singleton pattern.
>if (self::$_instance) {
>return self::$_instance;
>}
> 
>return self::$_instance = new A();
>}
>public method m() {}
> }
> 
> A()->m();
> 
> 
> === Conclusion ===
> This feature makes the __invoke() method consistent with the __call()
>> and
> __callStatic() methods,
> and opens the door to many cool stuff.
> 
> Any feedback is appreciated.
> 
> Daniele Orlando
 
 I don't really see a use case for this, as you can already use the
>> syntax
 A::method();
 
 E.G class A { public static function invoke() { return new A; }
 
 public function m() { echo 'Runned'; }
 
 A::invoke()->m();
 
 Your example above only saves a few characters to type and can lead to
>> a
 lot of problems if you have a function with the same name as the class.
>>> 
>>> Using A::invoke(), you need to know the name of "invoke()" and it's
>>> hard to force users always to use the invoke() function.
>>> Using A() would be more clean since all the static init(), factory(),
>>> invoke(), getInstance() are gone.
>>> Having __call(), __callStatic(), __invoke() and invokeStatic() would
>>> make the overloading concept more consistent.
>>> 
>>> Regards,
>>> Thomas
>>> 
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>> 
>> Using A() looks too much like a function call. And there is still the issue
>> with having a function name the same as the class name.
>> 

This works well in languages like JavaScript where functions are objects.
As much as I like the feature there, I'm not sure it's a great fit for PHP.

David

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

Re: [PHP-DEV] PHP User Survey

[David Muir]

When do you upgrade to a new release of php e.g. 5.3 -> 5.4
  - As soon as released
  - wait for the x.1 release
  - Once our OpCode cache supports it
  - When previous version hits EOL
  - When a new feature warrants the upgrade
  - When my Framework (Zend/Symfony/cake) or Software (Wordpress, Gallery,
etc) requires it


You should add:
When my distro/hosting company upgrades.


Cheers,
David

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

Re: [PHP-DEV] Include XDebug and Suhosin Patch in Core for 5.5

[David Muir]

On 01/03/2013, at 7:00 AM, Anthony Ferrara  wrote:

> Hey all,
> 
> Based off of the recent discussion around pulling in ZO+ into core, I've
> come to the conclusion that we should also pull in XDebug and Suhosin into
> core at the same time.
> 
> 1. It has integration issues with ZO+ in that it has to be included in a
> specific order (specifically around ini declarations). If it was included
> into core, this could be accounted for allowing for more robust behavior.
> 
> 2. Both to be maintained for each new language feature as well as
> opcode-caches. This will have the same benefit as integrating ZO+, as it
> can be maintained inline with the engine.
> 
> 3. Both stand as a barrier to adoption as many will not run PHP in
> development without XDebug, and they won't run it in production without the
> Suhosin patch.
> 
> Since both of these are vital to PHP's uptake and adoption of new versions,
> I feel it's important to delay 5.5 until we can get both in. I can draft up
> the RFC if necessary...
> 
> Anthony


Nice :-P 

Seriously though, what's the deal with the Suhosin patch? I use it because it's 
included by default on Ubuntu... Didn't know about the huge performance impact. 
Their website seems to imply that PHP has security holes that have never been 
patched, and are only closed by using Suhosin. I find that hard to believe. Is 
PHP really *that* vulnerable without it? The site 
(http://www.hardened-php.net/suhosin/) is somewhat light on details.

Cheers,
David

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

[David Muir]

On 01/03/2013, at 9:22 AM, Jan Ehrhardt  wrote:

> Raymond Irving in php.internals (Thu, 28 Feb 2013 13:56:11 -0500):
>> I'm very sure users will not complain if 5.5 is delayed for a few months.
>> Most websites will not be installing 5.5 immediately after it has been
>> released.
> 
> On the contrary: many users will welcome it because it delays the EOL of
> PHP 5.3 as well. The outcome of a previous vote was that PHP 5.3 would
> become unsupported within, say, 14 months from now. An unbelievable
> short time frame given the fact that many sites did not even migrate to
> PHP 5.3.
> 
> JAn
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


There's all this talk about the lack of 5.4 adoption being related to the lack 
of an opcode cache. I think that's ridiculous. Most shared hosts that I know 
about do not even offer opcode caching, so that can't be the reason why they 
haven't upgraded.

I know of one host that said it was because Zend Guard no longer supported BSD 
after 5.2 (don't know if it has since been added back in because that host has 
since upgraded to 5.3). Others work with LTS distro releases like Ubuntu and 
Red Hat, neither of which are on 5.4 either. The next Ubuntu LTS release won't 
be out until April 2014, so don't expect a surge in 5.4 adoption (or whatever 
version 14.04 comes with) for at least another year.

For me personally, I'm running sites on 5.2 and 5.3. I am unable to upgrade to 
5.4 and beyond because of the removal of register_globals and magic_quotes_gpc. 
I am not complaining that they were removed. Those two settings have been a 
huge pain in the backside for years, and I'm glad they're gone. But the legacy 
software I have to maintain was written assuming they were available and on. It 
will take a *very* long time to fix and update all that code to run on 5.4.

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

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

[David Muir]

On 21/02/2013, at 6:12 AM, Lazare Inepologlou  wrote:

> 2013/2/20 Sanford Whiteman 
> 
>>> It still looks like some random characters bashed together by a monkey
>>> with a keyboard.
>> 
>> +1, I am a fiend for ternary expressions and crazy one-liners, but
>> this makes me want to go back and unroll everything I've ever done
>> into readable code. :)
>> 
>> -- S.
> 
> 
> Long code is not always equivalent to readable code. A shorter syntax could
> improve readability in *some* cases.
> 
> Long:
> $users->OrderBy( function( $x ){ return $x->Surname; } );
> 
> Short:
> $users->OrderBy( $x ==> $x->Surname );
> 
> 
> 
> Lazare INEPOLOGLOU
> Ingénieur Logiciel


I think your example proves the opposite. The fist example was much easier to 
read and understand than the second.

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

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

[David Muir]

On 20/02/2013, at 10:47 PM, Alain Williams  wrote:

> On Wed, Feb 20, 2013 at 03:26:26AM -0800, Sara Golemon wrote:
>> On Tue, Feb 19, 2013 at 4:06 AM, Sara Golemon  wrote:
>>> Opening RFC to allow trailing comma in function call argument lists
>>> 
>>> https://wiki.php.net/rfc/trailing-comma-function-args
>> For the record, I've updated the RFC just now to include
>> function/method/closure declarations as well:
>> 
>> function foo(
>>  $bar,
>>  $baz,
>> ) {
>> 
>> }
>> 
>> Not a pattern I see as much, but for the sake of consistency, it
>> doesn't hurt to put it on the table for discussion.
> 
> I would argue against the RFC.
> 
> The trailing comma is useful with arrays since it is not uncommon that members
> need to be added to an array over time. This is often as a result of changes
> outside of the program (eg: another user added to an ACL). Such a change does
> not alter the purpose or functionality that is represented by the array, it 
> just
> does it for more somethings (users in my example).
> 
> Much source/version control is line based and so trailing commas helps keep
> differences short.
> 
> With functions: I do not see arguments being added in the same way, ie you are
> getting the function to do more of the same by adding an extra argument. If an
> extra argument is added it is because what the function does has changed in 
> some way.
> This is very different from the just-a-bit-more scenario that you have with 
> arrays.
> 
> If a function has a list of arguments that is expected to change, many
> programmers would do that by passing an array to the function and arrays can
> already have trailing commands 
> 
> Also: many other languages (eg C, Perl) allow a trailing comma in arrays, but
> not to function arguments. This change would make PHP different from what many
> programmers might expect.
> 
> -- 
> Alain Williams
> Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
> Lecturer.
> +44 (0) 787 668 0256  http://www.phcomp.co.uk/
> Parliament Hill Computers Ltd. Registration Information: 
> http://www.phcomp.co.uk/contact.php
> #include 
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


The one place I would find this to be super handy would be when specifying 
arguments to sprintf(), and other variable argument functions.

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

Re: [PHP-DEV] Questioning the future of PHP

[David Muir]

We still don't have a way to auto load non class entities. Other than that, 
PSR-0 does solve the majority of autoload use cases.

Cheers, 
David

Sent from my iPhone

On 04/02/2013, at 5:18 PM, Larry Garfield  wrote:

> On 02/03/2013 08:51 PM, Matt Wilson wrote:
>> Hello all. I'd like to start by saying that I am by no means an expert on 
>> the subject at hand, and my knowledge is limited to pretty much basic C/C++. 
>> I have done little more than patch and write ad hoc extensions for PHP in 
>> the past. I'm not looking to criticize so much, as I'm just interested in an 
>> honest discussion, for my own sake and understanding.
>> 
>> Many years ago I was on this internals list lamenting that PHP lacked 
>> namespaces. I was passionate in my conviction that it couldn't be a true 
>> language if it lacked them. But it wasn't until they were finally being 
>> considered that I realized the one weakness in PHP that prevented a proper 
>> namespace system. The autoload problem. Since PHP lacks an inherent style of 
>> code importation, it is a decision largely left up to the developer. This of 
>> course causes an order of precedence problem.
>> 
>> Now, I won't lie, some of my beef with namespaces as they stand is the \. 
>> What can I say, I like a certain feng shui in my code. I understand the 
>> technical limitations (or at least think I do) and the problem of ambiguity 
>> with other operators, however I feel more effort might have been made.
>> 
>> If I were to pull some examples out of my ass, and feel free to rebuke me if 
>> I'm missing something obvious,
>> 
>> [namespace foo.bar]
>> 
>> new [foo.bar.SomeClass]()
>> 
>> Would that be so hard to distinguish in the parser? If it is, I'd be 
>> grateful to know why.
> 
> Maybe it would work, maybe it wouldn't, I don't know.  But that ship sailed a 
> long time ago and it cannot be changed now without breaking a few million 
> lines of code.  Please let that issue die.
> 
>> Touching back on what I mentioned earlier about PHP not having an inherent 
>> way to load files, and in daily use it's somewhat arbitrary. I share the 
>> philosophy that the programmer should tell the code what to do, and not the 
>> other way around; however, I think some enforced structure can be good. This 
>> is something of a wet dream of mine and one I highly doubt will come true, 
>> but to get rid of __autoload (or at least supplant it with a default loader) 
>> would be a dream. I think it's something that PHP needs, to complete some 
>> one of advances its made in recent years.
>> 
>> Thanks,
>> Matt
> 
> "The autoload problem" has already been solved by PSR-0.  If you're not using 
> it yet, you should.  All the cool kids are.
> 
> http://www.php-fig.org/
> 
> If you're using Composer to manage dependencies, it includes a fully capable 
> PSR-0 autoloader that "just works", as well as a classmap-based option.  If 
> you're not using it yet, you should.  All the cool kids are.
> 
> http://getcomposer.org/
> 
> --Larry Garfield
> 
> -- 
> 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] New operator for htmlspecialchars

[David Muir]

On 16/01/13 08:22, Thomas Bley wrote:

Hello,

I created a small ticket to propose a shorter syntax for htmlspecialchars:

old:


new:

or:


any comments, pros and cons?

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

Best regards,
Thomas



The problem here is that htmlspecialchars only covers html body, and not 
html attributes, or other contexts (eg js, css, urls).


You're better off using something like Zend\Escaper, or Symfony's escaper.

The escaper RFC also gives a good amount of detail:
https://wiki.php.net/rfc/escaper

As for the shorter syntax with automatic output, I think it makes the 
code harder to read.


Cheers,
David

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

Re: [PHP-DEV] Extension for str_replace / preg_replace with arrays

[David Muir]

On 21/12/12 10:34, Christopher Jones wrote:



On 12/20/2012 08:31 AM, Larry Garfield wrote:

On 12/19/12 10:30 PM, Christopher Jones wrote:



On 12/19/2012 03:18 PM, Larry Garfield wrote:

You could likely simplify the code even further using an infinite
iterator:

http://us1.php.net/infiniteiterator

$result = preg_replace_callback(
 '/word/',
 function($matches) use (&$replacements_iterator) {
 return $replacements->next();
 },
 'word word word word word'
);

--Larry Garfield



What am I missing that causes the first call to
$replacements_iterator->current() to return NULL
unless the iterator is rewound before use?


Eh, nothing.  You're right, next() doesn't return an element, it just 
advances, so you still need the current() call.  Which seems kinda 
silly to me, but whatev.


That is documented, so it's OK.  The curiosity (bug?) is the need to 
call rewind():


$replacements_iterator = new InfiniteIterator(new 
ArrayIterator($replacements));

$replacements_iterator->rewind();  // why is the rewind needed?

$result = preg_replace_callback(
'/word/',
function($matches) use ($replacements_iterator) {
$r = $replacements_iterator->current();
$replacements_iterator->next();
return $r;
},
'word word word word word word word word'
);

In other (simple) scripts using InfiniteIterator the rewind wasn't 
needed.






What happens if you do:
$replacements_iterator = new InfiniteIterator(new 
ArrayIterator($replacements));

var_dump($replacements_iterator->current());

If I remember correctly, when you pass a traversable into foreach, under 
the hood, it basically calls:


$iterator->rewind();
while($iterator->valid()){
$value = $iterator->current();
(foreach block)
$iterator->next();
}

So that might explain why it works in "(simple) scripts".

It does seem like a bug that the rewind is required though. A newly 
created iterator should already be in a rewound state so the call 
shouldn't be needed.


Cheers,
David

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

Re: [PHP-DEV] DateTime improvement

[David Muir]

On 11/12/12 06:59, Herman Radtke wrote:

On Mon, Dec 10, 2012 at 11:39 AM, Ángel González  wrote:

On 10/12/12 16:18, Nikita Nefedov wrote:

So there had been at least two or three messages (subjects) about
DateTime object and everytime there was this problem - people tend to
take DateTime object as mutable object and it really is.
As long as we know, it's not so good - date is immutable by nature. I
don't want to write here why it's so, I will just throw this link:
http://www.ibm.com/developerworks/java/library/j-jtp02183/index.html

I don't want to change any existing functionality, because some people
already use it, but I just wanted to point out that current DateTime
class is forcing people to think about it as mutable.
My main concerns are DateTime#add() and DateTime#sub(). The problem is
- they both change current object and return it.
I think we could add methods to DateTime like add() and sub(), let's
say plus() and minus(), but they would behave differently in the way
that they would return new DateTime objects and won't change current
object.

That will make it even more inconsistent.
You have add() and plus() but one changes the object and the other doesn't.

If we were going to rewrite php or the DateTime class, it could be a
good idea to make those methods  (or its equivalents) not modify the object.
But I don't think it'd be a win to do such thing now.


Another option is to make an ImmutableDateTime class. The DateTime
class could actually be changed to inherit the ImmutableDateTime
class. The only extensions on the DateTime class would be the mutable
methods.




Would love to see ImmutableDateTime!

David

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

Re: [PHP-DEV] ext/mysql in PECL and E_DEPRECATED

[David Muir]

On 30/11/12 05:25, Ángel González wrote:
> On 29/11/12 18:17, Anthony Ferrara wrote:
>> Just pointing this out: that's NOT what this RFC recommends, and is
>> NOT what's being voted on. This RFC is talking about ONLY adding
>> E_DEPRECATED to core. And the way it's proposed to be done, the
>> "moves-to-PECL" couldn't happen, since it's hard-coded into the core
>> extension...
>>
>> So be careful what you're voting for...
> The RFC doesn't state if/when ext/mysql should be moved to pecl or if it
> should or not throw E_DEPRECATED there.
> It was stated in one of the previous threads that:
> - The extension would be moved to PECL when removed from core.
> - It's ok if you want to use ext/mysql from pecl as it's "unsupported"
> and your own problem, not one of php developers.
>
> There were also concerns that throwing E_DEPRECATED didn't allow to
> cleanly use it (if you really wanted to) as if it was simply moved to pecl.
>
> I was presenting a way to throw E_DEPRECATED (assuming that option wins
> in the RFC) while also allowing an extension (typically hosted on PECL)
> to “provide” the non-E_DEPRECATED extension.
>
> If you take a closer look, you will see that it can happen, as long as
> the core deprecation is done in that way, anticipating usage of that
> pecl extension. (Note that it is a variable which could only be changed
> by another extension, I wasn't proposing the ini_set mentioned by Alan,
> IMHO that's an uglier solution, since everybody would end up setting it).
>
> You are of course welcome to point out any failures in the pseudo-code I
> presented. :)
> There would be a dependency on ELF-like binaries if using weak symbols.
> But the version removing ext/mysql will likely have a different ABI
> anyway, so it's not a big problem to require a recompile of pecl/mysql
> for the different php version.
>

This is exactly why it doesn't make sense to have a vote on E_DEPRECATED
without understanding what the future action will be.

I might have missed some as there was no summary of the discussion in
the RFC, or a summary of the various positions. This should have been
added before calling a vote. Combined with future action, the various
positions as I've read them are:

1. Throw E_DEPRECATED in 5.5. Move to PECL in 5.NEXT and stop throwing
E_DEPRECATED
2. Throw E_DEPRECATED in 5.5. Move to PECL in 5.NEXT and continue
throwing E_DEPRECATED
3. Move to PECL in 5.5 or 5.NEXT, and not throw E_DEPRECATED
4. Throw E_DEPRECATED in 5.5. Remove from core and PECL in 5.NEXT

#1 means it's not really being deprecated
#2 kind of makes sense, but then why even move it to PECL?
#3 is consistent with current release RFC process
#4 is the type of case E_DEPRECATED is meant to handle (or has handled
thus far)

The current release process RFC states:

  *
*x.y.z to x.y+1.z*
  o
Bugfixes
  o
New features
  o
*Extensions support can be ended (moved to pecl)*
  o
Backward compatibility must be kept
  o
API compatibility must be kept (userland)
  o
ABI and API can be broken (internals), src compatibility
should be kept if possible, while breakages are allowed

[emphasis mine]

Some are saying that that E_DEPRECATED can/should be used for entire
extensions. That's fine and dandy if said extension is actually going to
be removed (not just retired to PECL, but dropped completely), but
somehow I think a lot more people would object to the current RFC if
that were the plan.

Cheers,
David

Re: [PHP-DEV] Re: [VOTE] ext/mysql deprecation in 5.5

[David Muir]

On 29/11/12 07:33, Kris Craig wrote:

On Wed, Nov 28, 2012 at 8:43 AM, Anthony Ferrara wrote:


Patrick,


Sorry, but removing the E_DEPRECATED notice when moved to PECL is not

part of the proposed RFC and should certainly not happen.


The proposal doesn't actually propose anything about a move to PECL. It's
listed in the "possible future actions" section exactly once. But the RFC
doesn't take a stand on it in either direction. So I'm not sure that you
can make that argument.


Adding it in one location and not the other does

not make sense.

Absolutely! There is no reason to remove that kind of notice in the

future.
That's your opinion. Please realize it as such and that other viewpoints
also exist.

For example, I have the viewpoint that deprecation applies to the LANGUAGE.
The inclusion of the extension in the language is what's being deprecated.
Even after it's pulled, someone else can maintain it. We can say that you
should avoid it, but there's nothing stoping someone else from continuing
maintenance of it as a fork. And adding in the other missing functionality
(possibly breaking BC, possibly not, whatever).

Therefore, in my viewpoint, the deprecation notices only apply to the
inclusion of the extension in the core language distribution. Not to the
extension itself.

I'm not saying that either one of us is right or wrong, just that there are
other opinions. To keep this discussion productive, please refrain from
using absolutes like that...

Thanks

Anthony


I think we're over-complicating this a bit.  The whole point of
E_DEPRECATED is to get people to stop using an obsolete feature before it's
removed (or moved to PECL or whatever; neither of which is in the scope of
this RFC anyway).  Documentation and whatnot can only accomplish so much.

We also know that E_DEPRECATED works when other approaches do not.  I would
point you all to the famous example of Drupal 7, which would break
completely due to a flurry of E_DEPRECATED warnings (if display_errors was
set to on) being triggered as of 5.3 due to their continued use of
magic_quotes_gpc and magic_quotes_runtime.  When Drupal 8 was released some
time later, the code was fixed so that it no longer used those out-dated
functions.

That's why I voted yes.

--Kris



Kris,

There was no "ext/magic_quotes" that was retired to PECL. You're 
comparing apples with oranges.


David


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

Re: [PHP-DEV] ext/mysql in PECL and E_DEPRECATED

[David Muir]

On 29/11/12 10:11, Mailing list wrote:

.. annoying top posting...

This is getting close to a good solution.

ini option  mysql_is_deprecated - can not be set in .ini/htaccess etc, 
only by ini_set() - so hosters/distros can not fix it...


Normally added just before mysql_connect...

ini_set('mysql_is_deprecated', "I WILL NOT USE IT IN THE FUTURE");
mysql_connect(..)

if the ini value is not set, then mysql_connect() can issue a 
E_DEPRECATED warning


"Mysql is deprecated, use mysqli or PDO, to remove this warning you 
can set mysql_is_deprecated"


They then have to google mysql_is_deprecated, which tells them to use 
the magic string...


Solves:
- Users will get warnings on upgrading - it can not be hidden by 
hosters/distros etc.
- Users can easily disable the warning, however they will be 
explicitly aware of the problem.


Backwards/forward compatible

Regards
Alan





That is indeed a better solution, but again, what happens after moving 
to PECL? Is this how we want to be deprecating extensions in the future?


As mentioned several times in this discussion, this is the first time 
we're trying to put a whole extension through a language 
feature/function deprecation process. To me, it's like putting a square 
through a round hole. Alan's suggestion makes the hole a bit more square.


Instead of this being a vote on throwing E_DEPRECATED in ext/mysql, what 
we really should have is a vote on an RFC on "How to deprecate and 
remove an extension from core". We can then apply that RFC to any 
extension we want removed from core. Up until now the process has been 
to just move it to PECL. Now we're voting to use a different process 
specifically for ext/mysql because of reasons unknown. I understand the 
reasons for encouraging people to move to other maintained extensions, 
but what is the rationale for using a different process specifically for 
ext/mysql than what we've used in the past?


The fact of the matter is, it's not an extension that will be removed. 
It's an extension that will be *retired from core*. It will continue to 
be available from PECL. Magic quotes and most of the other examples of 
"successful" use of deprecation were actually removed from the language. 
They are no longer available and you can't get them from PECL either.


IMHO there shouldn't be a vote on E_DEPRECATED without including future 
removal plans.


Cheers,
David





On Thursday, November 29, 2012 07:00 AM, David Muir wrote:

On 29/11/12 05:09, Ángel González wrote:
I see it as simple to show E_DEPRECATED but not when installed from 
PECL.


1) Add a
int mysql_extension_triggers_deprecated_warning = 1;

And use it as a conditional for triggering the warning.

2) Copy the extension code to PECL

3) Add these changes in PECL
- If the mysql functions are not already registered,
register them with the bundled code.
- Set mysql_extension_triggers_deprecated_warning = 0;

4) That's it.




Then people (distros, hosts, etc) will just install it from PECL 
instead to avoid all the E_DEPRECATED mess.


David








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

Re: [PHP-DEV] ext/mysql in PECL and E_DEPRECATED

[David Muir]

On 29/11/12 05:09, Ángel González wrote:

I see it as simple to show E_DEPRECATED but not when installed from PECL.

1) Add a
int mysql_extension_triggers_deprecated_warning = 1;

And use it as a conditional for triggering the warning.

2) Copy the extension code to PECL

3) Add these changes in PECL
- If the mysql functions are not already registered,
register them with the bundled code.
- Set mysql_extension_triggers_deprecated_warning = 0;

4) That's it.




Then people (distros, hosts, etc) will just install it from PECL instead 
to avoid all the E_DEPRECATED mess.


David


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

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

[David Muir]

On 21/11/12 16:08, Adam Harvey wrote:

On 21 November 2012 13:03, David Muir  wrote:

On 21/11/12 15:47, Adam Harvey wrote:

2. If we decide not to generate E_DEPRECATED notices in PHP 5.5, what
should the next course of action be:
(a) Enhance the manual text to make the soft deprecation clearer,
and generate E_DEPRECATED notices in PHP 5.6
(b) Enhance the manual text to make the soft deprecation clearer,
but take no further action in terms of E_DEPRECATED for the forseeable
future
(c) Remove the warnings from the manual and undeprecate ext/mysql
entirely

Has 2(c) been even suggested?

Not that I've seen, but having a "none of the above, I want none of
this" option seems prudent.


Except it's "lets reverse the changes already made", not "none of the 
above".





I take at that 2(b) is for those advocating "Move to PECL with no
E_DEPRECATED notices being thrown"?

Not really. We can't really unbundle and move to PECL without
deprecating first anyway, IMO. It's basically the option for no real
change but clarifying the manual wording, since nobody seems satisfied
with it.


No other extension was deprecated before moving to PECL, so why the 
extra hurt for ext/mysql? As I've said before, it doesn't makes sense to 
have it throw notices while it's in core, then no longer throw notices 
once moved to PECL. If the plan is to drop it completely, and not move 
it to PECL, then deprecation notices do make sense as there's no other 
recourse once the extension is removed.


In that case we really should have 3 questions:

Should ext/mysql generate E_DEPRECATED notices in PHP 5.5? (yes/no)
Should ext/mysql be moved to PECL or dropped completely in the future 
(PECL/dropped)

Should the manual text be changed to make soft deprecation clearer? (yes/no)




Or, to put it another way from where I sit: the "too hard, let's make
a decision after stringing people along longer" option.

Adam


Cheers,
David

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

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

[David Muir]

On 21/11/12 15:47, Adam Harvey wrote:

On 19 November 2012 20:44, Anthony Ferrara  wrote:

My intention at this stage is to call a vote next Monday: it feels
like the discussion has mostly died down now (which isn't to say I
think we're at a consensus necessarily — it just feels as though the
flurry of opinions have been made and argued either way), and I'm
hoping that everyone can have a think about where and how they'd like
to see this move forward (if at all) between now and then. Given we've
only just hit alpha 1, I don't think we need to rush into a decision
right now for the sake of one.


I completely agree.

I would suggest one thing though. When it comes up for a vote, please either
make 2 questions:

1. Should ext/mysql be hard-deprecated in 5.5
2. Should ext/mysql be soft-deprecated in 5.5 and hard-deprecated in NEXT

Or 4 options to deprecation:

1. Hard-deprecated in 5.5
2. Soft-deprecated in 5.5 and hard-deprecated in NEXT
3. Either
4. Neither

That way both viewpoints can be voted on in one vote. And we can get an
accurate count of the thoughts...

I've been mulling this for a couple of days, and Anthony and I have
talked about this on IRC, and I'd prefer to have two questions:

1. Should ext/mysql generate E_DEPRECATED notices in PHP 5.5? (yes/no)

2. If we decide not to generate E_DEPRECATED notices in PHP 5.5, what
should the next course of action be:
   (a) Enhance the manual text to make the soft deprecation clearer,
and generate E_DEPRECATED notices in PHP 5.6
   (b) Enhance the manual text to make the soft deprecation clearer,
but take no further action in terms of E_DEPRECATED for the forseeable
future
   (c) Remove the warnings from the manual and undeprecate ext/mysql entirely

The reason for this is that I'd like to make the vote about the actual
RFC (E_DEPRECATED in 5.5) as clear as possible. I'm worried that a 3
or 4 option vote there could easily lead to a split decision, which
will make it very difficult to take any sort of decisive action. I'd
rather make a decision there, then we can look at what action would be
preferred if the RFC itself fails.

Just to be clear: I don't think that "do nothing" is a very useful
option for the second question, which is why I've omitted it — it
doesn't seem like anyone's particularly satisfied with the current
state of affairs.

Thoughts?

Adam



Has 2(c) been even suggested?

I take at that 2(b) is for those advocating "Move to PECL with no 
E_DEPRECATED notices being thrown"?


Cheers,
David


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

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

[David Muir]

On 20/11/12 21:22, Lester Caine wrote:

Ulf Wendel wrote:

   1. Add this link to the RFC?:
>> https://wikis.oracle.com/display/mysql/Converting+to+MySQLi

As the author I cannot recommend materials created in 2006 and not
updated since then for inclusion into a RFC.


At the end of the day this is the problem all around. There needs 
sufficient volume of mysqli examples and tutorials to at least get 
some on a search for 'mysql php tutorial'.


This IS all about education carrots rather than irritating sticks. 
Perhaps there needs to be a concerted campaign to get the key 
tutorials such as at http://www.w3schools.com updated to a much more 
modern format?





There was a concerted campaign to get w3schools updated, but as far as I 
know, it's fallen on deaf ears. And it's not just their PHP info that's 
outdated.


See w3fools.com


Cheers,
David

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

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

[David Muir]

On 14/11/12 03:17, Adam Harvey wrote:
> On 14 November 2012 00:07, Anthony Ferrara  wrote:
>> 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.
> Serious question: what was it designed for, then? This (along with
> magic quotes, and register globals) was always what I had in the back
> of my mind when it was being discussed.
>
> 

There are two big differences here.

The first is that ext/mysql is still *very* widely used.

Secondly, the deprecation process (throwing deprecation warnings, then
removal) should not be applied to *extensions* anyway. Magic quotes and
register globals were PHP engine features. There was no other "user
friendly" way to get rid of them, because once gone, it's gone. (Ok,
they could have maybe been made into an extension, but nobody wanted
that anyway...).

The deprecation process here should similar to the process used for
other extensions that have been retired/removed from core (Crack, mhash,
sybase, ming, msql, fdf, fbsql, dbase, filePro, Hyperwave, etc)

1. Add "remove from core" status in documentation with notice about
maintenance dropping after 5.next
2. Remove it from core (those who still need it can pull from PECL)
3. If the community needs it after 5.next, then they'll have to step up
and maintain it themselves.

The point is, an extension should never be throwing deprecation warnings
for a planned migration to PECL.

Cheers,
David

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

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable"

[David Muir]

On 29/10/12 03:02, Clint Priest wrote:

So... to be explicit here, you think in this situation:

class a {
  public $b {
 set($x) { $this->b = $x; }
  }
}

$o = new a();

if(!isset($o->b)) {
  /* delete files */
}
echo (int)isset($o->b);  /* This should return false and not emit any 
sort of warning/notice? */


I mean specifically, there is no getter defined, therefore the result 
if isset is indeterminate and while I can see it not causing execution 
to stop I don't see it being a good idea to not warn the developer 
that what they've attempted is not correct. Without a getter, isset() 
is not a legal call (since the value cannot be retrieved).




I agree with Pierre, isset() should never throw a warning/notice. The 
primary use of isset (that I've seen in various code-bases) is to avoid 
warnings/notices. Only rarely do I see it used in an expression to 
control application logic. The above example should not give a warning, 
and should return false. As far as an application is concerned, $o->b 
doesn't exist because it can't be read.


David



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

Re: [PHP-DEV] [RFC] Socket activation support for PHP-FPM

[David Muir]

On 19/10/12 07:41, David Strauss wrote:
> The full RFC, including initial patches, is here:
> https://wiki.php.net/rfc/socketactivation
>
> In short, this allows spawning a PHP-FPM pool on-demand with systemd
> initializing the main socket.
>

Upstart support would be good to have too.

I take it that this would allow restarting specific pools? That would be
a really nice to have.

Cheers,
David

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

Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces

[David Muir]

On 16/10/12 22:34, Clint Priest wrote:



-Original Message-
From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
Sent: Tuesday, October 16, 2012 6:06 AM
To: Clint Priest
Cc: Nikita Popov (nikita@gmail.com); internals@lists.php.net
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces

Hi!


that supports properties in interfaces.  Again, not exhaustive either
but there is one language that does support accessors in interfaces
and that's C#.

So what C# does when mixing regular properties and accessorized properties?

I'd have to do some research to know for sure, but it's highly likely that they 
cannot be mixed.

Think about it, if you allowed an outside caller of your class to
modify your internal state, any time you needed to use that internal
state you would have to validate it before you could rely upon its
value to be set correctly.  No such issue exists with accessors in an

I do not see why this assumption is made that I need to do some special 
validation each time state is changed. In fact, in 99% of
existing code it is not happening, and I assume this ratio will be kept even 
when accessors are available. Most code will be very
straightforward, not doing anything complex with the state.

If you have a public property $a which internally can only deal with it being 
set to 2 or 3 and someone external to the class sets it to 4, your class either 
has to check that it's 2 or 3 and deal with the fact that it is now 4 or have 
indeterminate results when it is set to 4.


Now, I think the bigger question is: what exactly you want to say/require when 
you write:

interface a { public $xyz { get; } }

and what is the use case for this requirement?

The use case is that you are declaring that interface a must allow a property 
$xyz to be readable and *not* writable.


Just to be a bit more concrete here, as the code is presently written
and because I have strongly separated the concept of a property vs an
accessor, this code:

interface a { public $xyz { get; } }

class b implements a { public $xyz; }

Produces the following error: Fatal error: Class b contains 3 abstract
accessors and must be declared abstract or implement the remaining
accessors (get a::$xyz, isset a::$xyz, ...) in %s on line %d

I think this is wrong. 3 abstract accessors is especially wrong since it 
doesn't match the direct interface definition and is very
confusing (see my earlier point about isset/unset always having fallback 
defaults) but even with get as abstract I do not see a valid
use case that would require such behavior. What you want is for any $foo that 
is instanceof a to be able to respond to read request
to $foo->xyz, right? Class b satisfies this requirement, why you reject it then?
Also, if you reject it - how I should fix it to make it work? Would I have to 
implement a bolierplate getter/setter just to make
interface work? Doesn't look like a good proposition to me.

Class b does not satisfy the requirement because you are missing the fact that 
public $xyz { get; } forbids setting of $xyz, only reading it.



That doesn't make sense. An implementation has to have the same or less 
restricted visibility, so the above should work. The inverse however 
should not:


interface a { public $xyz; }

class b implements a { public $xyz { get; }}


Daivd

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

Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces

[David Muir]

On 16/10/12 14:55, Jazzer Dane wrote:
I'm going to agree with David here. It is most sensible to either 
allow properties AND accessors in interfaces, or don't allow either of 
them. __get/__set is a different subject that I'd rather not dig into 
while discussing this RFC.


I tossed in the __get/__set because they satisfy the interface. The 
problem with them it is that they would satisfy the interface at runtime 
rather than compile time, and thus would be unsafe to use. Kind of 
defeats the point of an interface... ;-)


Cheers,
David

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

Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces

[David Muir]

On 16/10/12 13:37, Clint Priest wrote:

On Mon, Oct 15, 2012 at 6:02 PM, Clint Priest  wrote:

> >Because fundamentally interfaces are designed to explain a way of 
communicating and properties are symmetrical and non-

>observable.

> >
> >The implementing class cannot "know" when a property has changed.

>
>Do you agree that there is nothing that distinguishes
>
>class A {
> public $v;
>}
>
>from
>
>class B {
>private $_v;
>public $v { get { return $this->v; }; set($n) { $this->v = $n; }} }
>
>when it comes to a client of B reading and writing to $b->v ? That's the 
entire point of accessors: being able to seamlessly intercept
>usages of properties with custom code.
>
>If you define an interface saying interface A { public $v { get;set;} } you 
are only saying to the user: objects of type A will have a
>property $v that you can read and write to.
>Whether it is a set of accessors or a property belongs to the implementation 
detail of the class implementing A, the user should not
>be able to see a difference when interacting with the class, as he will do it 
through $obj->v and $obj->v = ...;
>
>I can understand why we might not want that in PHP in order to simplify the 
implementation, but it we follow logical reasoning I
>can't see why we shouldn't implement that.
>

I'm not sure I understand what you're getting at here Etienne, this thread was 
about interfaces but now you're talking about two classes...



From an interface standpoint, both classes implement the same property. 
One as a literal property, the other as an accessor. The point being, 
from the code consuming the class, a property and accessor are the same 
thing. Interfaces are about contracts between an implementation and a 
consumer, so the actual implementation is irrelevant. What matters is 
how the implementation is accessed by the consumer. If it is via 
property syntax, then it *is* a property, even though the actual 
implementation might be a property, an accessor or (in theory) even 
__get/__set.


Cheers,
David

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

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

[David Muir]

On 10/10/12 21:41, Jazzer Dane wrote:

Here's my feedback on some current outstanding issues/suggestions:

1) Default value: I think having functionality for a default value is
necessary, but I'm also thinking it may already be implementable within the
current syntax.


class Test {
 private $seconds;
 public $hours {
 get() {
 if(!is_null($this->seconds)) {
 return $this->seconds;
 } else {
 return 10; // 10 is default
 }
 }
 }
}


The above should work fine in many scenarios, right?
We could perhaps then claim that the issue may rather be that we need
access to the variable *$hours* itself inside of the get/set/etc functions,
which I think has been brought up before - though I'm not so sure how
sensible that is. Whether we need that or not is up in the air.



I think the syntax for defaults would be:

class UsingInitialValue {
private $seconds = 36000;
public $hours {
get() { return $this->seconds/3600;}
}
}

class UsingLazyLoad {
public $seconds {
get() { return $this->seconds = 36000;}
set($value) {$this->seconds = (int) $value;}
}
}

class UsingConstructor {
public $seconds {
set($value) {$this->seconds = (int) $value;}
}
public function __construct(){
$this->seconds = 36000;
}
}


I think I've got those all right...

Cheers,
David

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

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

[David Muir]

On 09/10/12 19:20, Jazzer Dane wrote:

- "If we ever get return type hinting/checks then we needn't consider how
the syntax has to look" From what I know, this isn't planned for PHP 5.5
and any proposals for it have been largely ignored. Return type hinting
won't help when setting either, although it would help with getting. All
that being said, type hinting aside, the syntax I proposed is, in my
opinion, the most consistent out of any other proposal thus far (arguably
aside from yours, I'll go over that momentarily).


Excellent point. Return type-hints only affect the getter, and even then 
it could be a moot point if the property itself could be bound to a 
particular type. It would actually be a much cleaner solution, and 
wouldn't require any superfluous parens in the declaration:


class MyClass{

public SomeClass $property {
get {...}
set {...}
}
}

$foo = new MyClass;
$bar = new SomeClass;
$foo->property = $bar; //ok
$foo->property = new StdClass; //type mismatch

Heck, half the time setters and getters are implemented specifically for 
this purpose. If the property itself could be typed, then 90% of the 
time we wouldn't even need to specify get/set. Just give the property a 
type and be done with it.


That said, it wouldn't help for scalar values, and that leads to a 
problem with the current syntax (AFAICS). You can't specify the initial 
value for a property:


eg:
class MyClass{

public $property = 5//?can we do this?
{
set($value){
if(!is_int($value)){
throw new InvalidArgumentException('value of wrong type');
}
$this->__property = $value;
}
}
}

Or would that have to happen in the constructor?

class MyClass{

public $property
{
set($value){
if(!is_int($value)){
throw new InvalidArgumentException('value of wrong type');
}
$this->__property = $value;
}
}

public function __construct(){
$this->property = 5;
}
}


Cheers,
David

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

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

[David Muir]

On 20/09/12 07:48, Michael Shadle wrote:

On Tue, Sep 18, 2012 at 10:32 AM, Pádraic Brady  wrote:

Hi Michael,

See the link near the bottom of the RFC - even htmlspecialchars() has
unusual behaviour that's potentially insecure. I have no objections to
there being functions, of course, and the RFC makes that clear.
However, many programmers like me are obsessed are objects so having
an SPL class will obviously be near and dear to my design patterned
heart ;).

After looking over the RFC finally, would it be that crazy to consider
this an extension of the standard string functions?

str_escape($string, $encoding, $flags) or probably better
str_escape($string, $flags, $encoding) - since encoding could be
defaulted to UTF-8, but flags are really what differentiate the
behavior...

Then there is not a handful of functions but rather one that can be
used as the abstraction point and the flags passed to it will change
it's behavior, much like the filter functions.

(I just see this falling under one solid defacto escape function
standard, and it could live by itself as "escape" or something, or as
it operates on strings, prefix it as such)

I'm on the fence with a default encoding. I tend to always use UTF-8, so 
would probably just use the default. But that means I become less aware 
of encoding being central to the issue, and therefore much easier to 
accidentally leave it as UTF-8 when it should be something else.


-1 on the flag based api, though. Would much rather have dedicated 
functions. It's easier to read, and less verbose.


























escapeHtml($foo)?>
escapeHtml($bar)?>



I prefer the OO API since it's succinct, but if we are to have a 
procedural API as well, lets make it concise and clear. The last thing 
we want for solving the no 1 security threat to web-apps is a confusing 
and hard-to-use API like the filter extension.


Cheers,
David

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

Re: [PHP-DEV] Download PHP binaries

[David Muir]

On 15/09/2012, at 8:38 PM, Lester Caine  wrote:

> Remi Collet wrote:
>>> >Last night I spent a couple of hours again trying to find an 'off the
>>> >shelf' distribution that even had PHP5.4 and Apache2.4 ...
>> Fedora 18 have httpd 2.4.3 and php 5.4.7;)
>> (I have backports for f17)
> 18 is downloading at the moment, but I could not find on the Fedora site any 
> reference to which versions of PHP and Apache were included ...
> It's the same with most distributions :)
> I'm not sure if Fedora even has a current Firebird ...

Checked distrowatch? 

David

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

Re: [PHP-DEV] Combined assignment operator for short ternary

[David Muir]

On 26/08/2012, at 4:09 AM, Ferenc Kovacs  wrote:

> 2012.08.25. 19:50, "Sebastian Krebs"  ezt írta:
>> 
>> Am 25.08.2012 18:38, schrieb Ferenc Kovacs:
>> 
>>> 
>>>would this trigger a notice if $foo is not defined?
>>>if yes, then it would be different from the current behavior of
> the
>>>ternary operator.
>>> 
>>> 
>>>Couldn't believe it, thus I tested it myself
>>> 
>>> 
>>> snip
>>> 
>>>Don't know, what you are talking about, but the notice _is_ the
>>>current behaiour and therefore: No difference.
>>> 
>>> 
>>> Sorry, I messed up that email. What I wanted to say:
>>> If it accepts unset variable, then I could see usecases for it, but then
>>> it would behave differently than the current ternary.
>>> If it doesn't accept unset variable then it would in line with what we
>>> have, but I don't see any usecase for it, because I would have to set it
>>> before checking that it is falsely or not, in which case I would set it
>>> to the default if not set already.
>>> 
>>> 
>>> 
>>>if no, then I would never use this.
>>>I mean if I have to set the variable before the check, then I
>>>would put
>>>the check into the assignment.
>>> 
>>> 
>>>The main thought about it was
>>> 
>>>function foo ($bar = null) {
>>> $bar = $bar ?: 'default';
>>>}
>>> 
>>> 
>>> If you wanted to enforce the 'default' value to be the default if no
>>> argument passed, then you could use $bar = 'default' in the method
>>> signature.
>>> So I guess that you use that construct to handle when the argument is
>>> passed, but it contains a falsely value ("0", array(), 0, etc.).
>>> I agree that this can be useful in some cases.
>>> 
>>> 
>>>I _always_ use 'null' as default
>>> 
>>> 
>>> For me, it isn't always null, sometimes it is boolean true/false, or an
>>> empty array.
>>> 
>>> 
>>>- If you want to omit a parameter, but want to set one after that,
>>>you don't need to look whats the default: It's 'null'
>>> 
>>> 
>>> my IDE takes care of that problem for me.
>> 
>> 
>> Only works on the green field ;) And/or if you are alone ...
>> 
>> 
>>> 
>>>- Ive often enough seen something like
>>> 
>>>function foo ($limit = 10) { /* code */ }
>>>// Somewhere else
>>>function bar ($limit = 50) { /* code */ $foo($limit); /* code */}
>>>// Even somewhere else
>>>bar();
>>> 
>>> 
>>> same here.
>> 
>> 
>> Same here :p
>> 
>> 
>>> 
>>> --
>>> Ferenc Kovács
>>> @Tyr43l - http://tyrael.hu
>> 
>> 
>> 
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>> 
> 
> So you are saying that your (teams) IDE doesn't tell you the method
> signature which contains also the default values?
> I guess that the fact that many of the php core functions have optional
> arguments and non null defaults must be really a PITA for you.

I think what he was alluding to is the problem where one changes the default. 
All usages of the method/function then need to be updated. Using null today is 
very much like using the proposed 'default' parameter skipping RFC.

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

Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)

[David Muir]

On 20/07/12 09:38, Andrew Faulds wrote:
> I'm curious, how do I make my objects have scalar passing semantics, then?
> On Jul 20, 2012 12:35 AM, "Sara Golemon"  wrote:
>

How about this?

class String {

protected $string='';
   
public function __construct($string){
$this->string = $string;
}

public function toUpper(){
$string = clone $this;
$string->string = strtoupper($this->string);
return $string;
}

public function __toString(){
return $this->string;
}

}

$foo = new String('foo');
$bar = $foo->toUpper();
echo $foo; //foo
echo $bar; //FOO

So far we only have the toString magic method. If we had the others, you
could conceivably do this all in userland (at a fairly high performance
cost I would assume).

Cheers,
David

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

Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)

[David Muir]

On 19/07/12 04:49, Rasmus Lerdorf wrote:

On 07/18/2012 01:02 AM, Pierre Joye wrote:

hi,

On Wed, Jul 18, 2012 at 9:35 AM, Stas Malyshev  wrote:

Hi!


See the other answers, clear APIs, no more argument mess, cleanness.

Cleanness has nothing to do with pseudo-objects.You don't have to use
-> to have clean APIs, and using -> doesn't automatically make your APIs
clean.

I really do not want to have a semantic discussion here.

This syntax is sexy, allows us to clean our APIs, and is amazingly handy.

This makes no sense to me either. How does it let us clean the APIs? Can
you give an example? I have one:

$a = -5;
$b = "-5";

echo $a->abs();  // Outputs 5
echo $b->abs();  // should still output 5

What has been cleaned here over:

echo abs($a);
echo abs($b);

other than being 2 characters longer to type? It's not like you can
remove abs() from the string pseudo-object, so you are essentially just
taking all the functions in the global namespace and attaching them as a
method to every pseudo-object. Is that clean?

I think there is something we can do around this, but an argument of "it
is sexy and clean" needs to be backed up with some actual implementation
details that make sense.

-Rasmus



Which is the needle, and which is the haystack?
$pos = strpos($string, 'a');
$pos = strpos('a', $string);

vs
$pos = $string->pos('a');
$pos = 'a'->pos($string);

I'm not proposing to use pos() as the method name, just showing an 
example that this syntax can be cleaner.


David

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

Re: [PHP-DEV] 6.0 And Moving Forward

[David Muir]

Took the words from my mouth. Removing legacy support is a terrible idea 
for PHP6. It makes it impossible to write forwards compatible code that 
currently runs in PHP5. Even having it optional is a bad idea IMO since 
it will fragment PHP hosting. Some will be able to run PHP6 only (no 
legacy), some will be able to run PHP5+ but will still be marketed as 
PHP6. Makes it that much harder to know if your code will run on a 
client's server.


David

On 18/07/12 00:04, Anthony Ferrara wrote:

I dislike this idea from the ground up.

While I think having a legacy implementation is definitely worth while, it
needs to be in core. So PHP6 would introduce the new syntax, and include
the legacy functionality in as close to 100% backwards compatible way as
possible. From there, we'd only remove the legacy functionality from core
in 7 (which could be 4 or 5 years out).

We don't want to be in the same situation with 6 that python was in with 3,
and perl was in 5. We want to encourage adoption. Having a PECL extension
needed for adoption is not going to fly too well. But if we can add the new
functionality and give people an easy migration path, adoption will be
easier. It still may take years, but it will at least be fairly smooth as
the majority of existing code will still work. Of course some BC breaks may
be necessary (a-la what happened with PHP5), but they should be fairly
localized and pretty easy to handle... And they should be justified
(breaking BC for the sake of it, as with these legacy functions, would be a
mistake)...

My $0.02 at least.

Anthony

On Tue, Jul 17, 2012 at 9:41 AM, Andrew Faulds wrote:


This is an excellent idea. Full BC yet without legacy cruft. Old code runs
on legacy support extensions, new code doesn't need it.
On Jul 17, 2012 1:51 PM, "Leigh"  wrote:


Basically, the current function library is moved to the legacy
namespace.  The default setting is import the functions of the legacy
namespace into the root namespace for BC.  But with that setting
turned off all the existing functions go away to be replaced with a
designed API, instead of a grown one, correcting the mistakes that
have accumulated over the years.

Is there any reason why this cannot / should not be implemented as a
PHP 5 compatibility extension?

I think those who never want to use it (PHP 6 purists) shouldn't have
to have their binaries bloated by legacy code. It would also mean that
the legacy implementation can be developed away from the new core, and
not have any (negative) influence on it.

--
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] 6.0 And Moving Forward

[David Muir]

On 14/07/12 01:33, Anthony Ferrara wrote:

Hey all,

I know that 6.0 was originally supposed to be the unicode conversion of the
engine. However it appears that all progress on that has stopped for quite
some time.

So, I was curious if we could start a conversation around what 6.0 would
look like if we didn't go the unicode route. What would be the major
changes that we'd base it on.

Here are a few of the ideas that have been floating around in my head.

1. Change the error handling system from the current E_* system to typed
exceptions for everything but advisory errors (E_STRICT, E_NOTICE,
E_DEPRECATED). Why? Because the current error system encourages ignoring or
not checking what the error was, and it makes defensive programming quite
difficult. This is arguable and preference for sure, but it's a major
change that could have large benefits.

2. Make namespaces first-class meta-objects. That way, you could have
namespace private and protected classes, functions, variables, etc. This
would allow for better scoping of modules...

3. Make all zval types pseudo-objects. Basically enabling something akin to
auto-boxing allowing a significant amount of the standard library to be
eventually deprecated in favor of acting on methods (not initially, but
opens the door).

4. Rewrite the entire parser completely. I keep hearing about how bad PHP's
parser is, and how it's growing out of control. Perhaps this is a good time
to rewrite it (perhaps changing semantics slightly) to be better adapted
towards future changes...

I'm not saying all of them are solid. I'm not saying any of them are solid.
But hopefully this can spark a discussion around it...

Thoughts?

Anthony



I'd *really* like to see the following being possible:

$array = array('foo' => 'bar');
$object = (object) $array;

echo $array['foo']; //bar
echo $array->foo; //bar

echo $object['foo']; //bar
echo $object->foo; //bar

Is there a technical reason for the difference that currently exists?

Cheers,
David

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

Re: [PHP-DEV] Internal iteration API

[David Muir]

On 13/07/12 01:04, Matthew Weier O'Phinney wrote:
> On 2012-07-12, Sara Golemon  wrote:
>> --e89a8f235453d7a80104c4975c55
>> On Wed, Jul 11, 2012 at 5:39 PM, Anthony Ferrara wrote:
>>> One thing to keep in mind when doing this is to think about consistency.
>>> I think that's a huge point not to be taken lightly. For that reason, I
>>> think that this API should not be used for any of the array_* functions.
>>> Meaning that array_sum(), etc should all take arrays only.
>>>
>>> Then, other non-array functions (such as str_replace, etc) can be modified
>>> to use this new method.
>>>
>>> Just my $0.02 anyway...
>>>
>> Sounds like everyone agrees the API is useful, just question marks over
>> which existing methods should profit by it.
>>
>> To add my $0.02, it'd be nice to work in a zend_parse_parameters() type for
>> this.  Keep extension code clean and ensures any temporary iterators get
>> destructed.
> Another note: if this comes to fruition, since arrays and traversable objects
> would in many cases be interchangeable, it would be nice to have a type-hint 
> for
> "array-like" behavior:
>
> function doSomething (ArrayLike $options) { ... }
>
> A better name could likely be used, but you get the idea.
>

What about extending the array typehint include ArrayAccess, and extend
the Traversable typehint to include arrays?


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

Re: [PHP-DEV] array_shift() and reindexing

[David Muir]

What about replacing the existing array with array_slice?

David

On 12/07/2012, at 9:43 PM, Jille Timmermans  wrote:

> Hello,
> 
> array_shift() currently reindexes the array after shifting one element. The 
> reindexing has quite some impact on it's performance. I would like to suggest 
> an extra parameter to array_shift() which can be used to prevent reindexing.
> 
> From a few quick (and sloppy!) tests I get these results:
>  `reset($array); list($key, $value) = each($array); unset($array[$key]);` is 
> ~50-150 times faster than array_shift().
>  Calling array_reverse() and using array_pop() is ~2000-5000 times faster.
> 
> If you agree this would be an useful addition I will create a patch.
> 
> -- Jille
> 
> -- 
> 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] List comprehensions and generator expressions for PHP

[David Muir]

On 28/06/12 23:45, Sebastian Krebs wrote:
> Hi,
>
> 2012/6/28 David Muir 
>
>> I'd assume that array_map() only works with arrays, while list
>> comprehension should work with anything traversable.
>>
> That sounds more like a "bug" (better: "Missing feature") in array_map()
> and less a missing language feature...

All the array_* functions only work with arrays, and don't allow
objects, even ones implementing ArrayAccess.

It's been there as a feature request since 2007:
https://bugs.php.net/bug.php?id=43650

Cheers,
David

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

Re: [PHP-DEV] Re:[PHP-DEV] List comprehens​ions and generator expression​s for PHP

[David Muir]

On 29/06/12 14:06, minwei zhou wrote:
> On Thu, Jun 28, 2012 at 6:48 PM, Nikita Popov  wrote:
>> Hi internals!
>>
>> Python and several other languages include support for list
>> comprehensions and generator expressions and I'd like to see something
> why PHP should going to like other language?

Pretty much everything in PHP was "borrowed" from another language. This
is nothing new.


>> So, what do you think? Do we want something like this in PHP?
> NO!!!
>
> PHP is not python  please do not make PHP worse
>
> if you like python just go to use python
>

Try again, this time with less knee-jerk and more brain:

Why is this a bad feature?
How will it make PHP worse?
What is so bad about it that it outweigh the benefits?
Is it the syntax you don't like, or the concept?

Cheers,
David




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

Re: [PHP-DEV] List comprehensions and generator expressions for PHP

[David Muir]

I'd assume that array_map() only works with arrays, while list comprehension 
should work with anything traversable.

David


On 28/06/2012, at 10:43 PM, Sebastian Krebs  wrote:

> Hi,
> 
> Whats the difference to the (already existing) function array_map() (except
> the syntax and one more new keyword)?
> 
>> $firstNames = array_map(function($user){return $user->firstname;},
> $users);
> 
> Don't want to rewrite every example you gave, but you probably see my point.
> 
> Regards,
> Sebastian
> 
> 2012/6/28 Nikita Popov 
> 
>> Hi internals!
>> 
>> Python and several other languages include support for list
>> comprehensions and generator expressions and I'd like to see something
>> similar in PHP too.
>> 
>> I created a hacky proof of concept implementation here:
>> https://github.com/nikic/php-src/tree/addListComprehensions. It's
>> really dirty, but it implements both features in about ~150 lines of
>> code.
>> 
>> Currently I'm using the following syntax:
>> 
>>   $firstNames = [foreach ($users as $user) yield $user->firstName];
>> 
>> This code is roughly equivalent to writing:
>> 
>>   $firstNames = [];
>>   foreach ($users as $user) {
>>   $firstNames[] = $user->firstName;
>>   }
>> 
>> You may notice that this particular list comprehension provides the
>> same functionality as array_column(), just in a little more
>> generalized way. E.g. you could use all of the following without
>> having special functions for them all:
>> 
>>   $firstNames = [foreach ($users as $user) yield $user->firstName];
>> 
>>   $firstNames = [foreach ($users as $user) yield $user->getFirstName()];
>> 
>>   $firstNames = [foreach ($users as $user) yield $user['firstName']];
>> 
>> It's also possible to explicitly specify a key:
>> 
>>   $firstNames = [foreach ($users as $user) yield $user->id =>
>> $user->firstName];
>> 
>> It is also possible to filter elements using list comprehensions:
>> 
>>   $underageUsers = [foreach ($users as $user) if ($user->age < 18)
>> yield $user];
>>   // or just the names
>>   $underageUserNames = [foreach ($users as $user) if ($user->age <
>> 18) yield $user->firstName];
>> 
>> It is also possible to nest multiple foreach loops:
>> 
>>   $aList = ['A', 'B'];
>>   $bList = [1, 2];
>>   $combinations = [foreach ($aList as $a) foreach ($bList as $b)
>> yield [$a, $b]];
>>   // gives: [ ['A', 1], ['A', 2], ['B', 1], ['B', 2] ]
>> 
>> All the above are list comprehensions (or in PHP rather array
>> comprehensions), i.e. they create an array as the result.
>> 
>> If this is not needed it is also possible to compute the values lazily
>> using generator expressions, which use () instead of [].
>> 
>>   $firstNames = (foreach ($users as $user) yield $user->firstName);
>> 
>> In this case $firstNames will no longer be an array of first names,
>> but instead will be a generator producing first names.
>> 
>> This is handy if you only need to iterate the resulting "list" only
>> once as it saves you holding the whole list in memory.
>> 
>> Also it allows you to work with infinite lists easily:
>> 
>>   function *naturalNumbers() {
>>   for ($i = 0; ; ++$i) {
>>   yield $i;
>>   }
>>   }
>> 
>>   // all natural numbers
>>   $numbers = naturalNumbers();
>>   // only the odd ones
>>   $oddNumbers = (foreach ($numbers as $n) if ($n % 2) yield $n);
>>   // ...
>> 
>> (At this point I wonder whether one should include support for
>> for-loops in list comprehensions. So the naturalNumbers() function
>> could be replaced with (for ($i = 0;; ++$i) yield $i), etc)
>> 
>> So, what do you think? Do we want something like this in PHP?
>> 
>> Nikita
>> 
>> --
>> 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] BreakIterator

[David Muir]

Coming from a "pleb", my only concern is the name if the class is in the
global scope. A "BreakIterator" to me sounds like something related to
breaking out of a looping structure, and not something used for
iterating over various language structure boundaries.
If it's in a ICU namespace, then it's not a problem, as it's clearly
related to Unicode.

Cheers,
David

On 31/05/12 21:21, Gustavo Lopes wrote:
> Hi
>
> I've wrapped ICU's BreakIterator and RuleBasedBreakIterator. I stopped
> short of adding a procedural interface. I think there's a larger
> expectation of a having an OOP interface when working with iterators.
> What do you think? If there's no procedural interface, I'll change the
> instances of zend_parse_methods to zpp for performance.
>
> Now I'll copy the commit message here if someone want to comment on a
> specific point inline:
>
> 
> BreakIterator and RuleBasedBreakiterator added
> This commit adds wrappers for the classes BreakIterator and
> RuleBasedbreakIterator. The C++ ICU classes are described here:
> 
> 
>
> Additionally, a tutorial is available at:
> 
>
> This implementation wraps UTF-8 text in a UText. The text is
> iterated without any copying or conversion to UTF-16. There is
> also no validation that the input is actually UTF-8; where there
> are malformed sequences, the UText will simply U+FFFD.
>
> The class BreakIterator cannot be instantiated directly (has a
> private constructor). It provides the interface exposed by the ICU
> abstract class with the same name. The PHP class is not abstract
> because we may use it to wrap native subclasses of BreakIterator
> that we don't know how to wrap. This class includes methods to
> move the iterator position to the beginning (first()), to the
> end (last()), forward (next()), backwards (previous()), to the
> boundary preceding a certain position (preceding()) and following
> a certain position (following()) and to obtain the current position
> (current()). next() can also be used to advance or recede an
> arbitrary number of positions.
>
> BreakIterator also exposes other native methods:
> getAvailableLocales(), getLocale() and factory methods to build
> several predefined types of BreakIterators: createWordInstance()
> for word boundaries, createCharacterInstance() for locale
> dependent notions of "characters", createSentenceInstance() for
> sentences, createLineInstance() and createTitleInstance() -- for
> title casing breaks. These factories currently return
> RuleBasedbreakIterators where the names of the rule sets are found
> in the ICU data, observing the passed locale (although the locale
> is taken into considering there are very few exceptions to the
> root rules).
>
> The clone and compare_object PHP object handlers are also
> implemented, though the comparison does not yield meaningful results
> when used with >, <, >= and <=.
>
> Note that BreakIterator is an iterator only in the sense of the
> first 'Iterator' in 'IteratorIterator', i.e., it does not
> implement the Iterator interface. The reason is that there is
> no sensible implementation for Iterator::key(). Using it for
> an ordinal of the current boundary is not feasible because
> we are allowed to move to any boundary at any time. It we were
> to determine the current ordinal when last() is called we'd
> have to traverse the whole input text to find out how many
> breaks there were before. Therefore, BreakIterator implements
> only Traversable. It can be wrapped in an IteratorIterator,
> but the usual warnings apply.
>
> Finally, I added a convenience method to BreakIterator:
> getPartsIterator(). This provides an IntlIterator, backed
> by the BreakIterator PHP object (i.e. moving the pointer or
> changing the text in BreakIterator affects the iterator
> and also moving the iterator affects the backing BreakIterator),
> which allows traversing the text between each boundary.
> This iterator uses the original text to retrieve the text
> between two positions, not the code points returned by the
> wrapping UText. Therefore, if the text includes invalid code
> unit sequences, these invalid sequences will be in the output
> of this iterator, not U+FFFD code points.
>
> The class RuleBasedIterator exposes a constructor that allows
> building an iterator from arbitrary compiled or non-compiled
> rules. The form of these rules in described in the tutorial linked
> above. The rest of the methods allow retrieving the rules --
> getRules() and getCompiledRules() --, a hash code of the rule set
> (hashCode()) and the rules statuses (getRuleStatus() and
> getRuleStatusVec()).
>
> Because the RuleBasedBreakIterator constructor may return parse
> errors, I reuse the UParseError to text function that was in the
> transliterator files. Therefore, I move that function to
> intl_error.c.
>
> commo

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

[David Muir]

On 15/04/12 16:29, Kris Craig wrote:
> On Sat, Apr 14, 2012 at 11:20 PM, John LeSueur wrote:
>
>
> The second thing that still needs nailing down as far as implementation is
> how to determine parsing mode. If it has to be specified at include time,
> then we're putting the burden on whoever writes the autoloader to know what
> kind of file it is. If it has to be specified in php.ini, or in the sapi
> configuration, then I'm putting the burden on the administrator. I want to
> allow the developer who writes the file to specify its parsing mode.
>
> The two ways I see for developers to do so is to use variations on the
>   order to work, so involves admins in the decision of how to parse the php
> files that I write.
>
>  , and error if there is anything before the
> header. The RFC specifies an additional restriction, throw error if I
> include file with   ?>, and error if there is anything before the header.
>
> Hmm as in "PHP Open?"  That could work.
>
> This goes back to the question of whether to do a tag, an INI setting, or a
> keyword.  I'd already discounted an INI setting before I started the RFC,
> but I'm still on the fence regarding the other two.  I was hoping the
> discussion could first focus on that question, since there's a lot of
> complexity involved and it'll take some rigorous back-and-forth for us to
> weigh all the pros and cons of each.  But I do feel like we're starting to
> get back on track at least.  =)
>
> --Kris
>
>

The point of contention on my part has been on the restriction of the
types of files that can be included from .phpp files. Even with the
compromise per-file basis, I wouldn't approve, as it makes an
unnecessary restrictions that require workarounds for .phpp files to
play nice. For example, you wouldn't be able to write a universal
autoloader in .phpp, as it would not be unable to include .php files.
But then you wouldn't be able to include the autoloader in a .phpp file
if the loader is defined in a .php file. Yes, there are workarounds, but
it's this kind of WTF factor that will just end up annoying anyone
trying to use .phpp files in their application.

INI settings that dictate parsing rules are a non-starter in my opinion,
so that just leaves the keyword solution, which I think is the direction
the discussions of both Yasuo and Tom's RFCs were heading.

>From a technical standpoint, I can see that as being acceptable (using
keywords and removing include restrictions), but from a practical
standpoint, I'm still not seeing the benefits. The problems that the RFC
is supposed to solve (except the include restrictions) can already be
solved in userland.

Cheers,
David

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

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

[David Muir]

On 14/04/12 03:41, Kris Craig wrote:
>
>
> On Thu, Apr 12, 2012 at 11:37 PM, David Muir  <mailto:davidkm...@gmail.com>> wrote:
>
> On 13/04/12 15:13, Kris Craig wrote:
> > Again, the controller should NOT be a .phpp file.  Likewise,
> your model
> > should NOT be hooking directly to the view.  The controller
> hooks to the
> > model.  The controller then sanitizes that and returns it to the
> view.
> >  Alternatively, if you're not conforming to a pure MVC standard, the
> > controller can also hook to a regular .php file in the model and
> pass the
> > data to that.  Either way, it all passes through the controller.
>  The model
> > and view should never be interacting directly.  MVC or not,
> that's just bad
> > architecture and there are zero advantages to using such an ad
> hoc approach.
> >
> > If a developer insists on using such a broken model, however,
> they're more
>
> MVC is a broken model/bad architecture?
>
>
> Arrooo?  Not sure where you got /that/ from, as it's basically the
> exact opposite of what I said
>  

That was me being snarky. I understood what you were trying to say, but
you were trumpeting the superiority of MVC, while deriding architecture
that conforms to common MVC patterns.

>
> > than welcome to!  That's what people love (and hate) about PHP.
>  It's
> > flexible.  They just won't be able to use a .phpp file upstream
> from that,
> > as it is by its very nature inherently incompatible with such a
> broken
> > model.  The only way to force it to be compatible would be to
> make the
> > .phpp file essentially meaningless.
> >
> > So if you're writing good code structure, a .phpp file will help
> you make
> > it even better.  If you're writing bad architecture, then just
> keep doing
> > what you're already doing and don't worry about using a .phpp
> file!  This
> > will in no way stop you from being able to do what you can
> already do in
> > PHP.  You're just insisting on wanting to use a pure code file for
> > something that it's not intended to be used for.  Just like
> having object
> > orientation added in PHP 5 didn't stop you from writing
> procedural code if
> > you want to, introducing this in PHP 6 won't stop you from writing
> > disorganized code if you still want to.  What this will do is
> provide a
> > valuable option for people who do feel that writing clean,
> role-segregated
> > code is important.
>
> So basically, the only parts that might be ok to write as .phpp
> are some
> model and utility classes?
>
>
> Essentially, yes.  Despite your implication, often times these
> components make up the vast majority of a modern PHP application.

It's also the portion that is typically not provided by frameworks and
libraries. If you're extending or implementing anything from those
libraries, and they're provided as .php (as most things would be), then
you won't be able to use them in your .phpp classes (unless you
explicitly include them from a .php file further up the chain). You end
up losing a lot of flexibility, with no perceivable gain.

Cheers,
David

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

[David Muir]

On 13/04/12 15:13, Kris Craig wrote:
> Again, the controller should NOT be a .phpp file.  Likewise, your model
> should NOT be hooking directly to the view.  The controller hooks to the
> model.  The controller then sanitizes that and returns it to the view.
>  Alternatively, if you're not conforming to a pure MVC standard, the
> controller can also hook to a regular .php file in the model and pass the
> data to that.  Either way, it all passes through the controller.  The model
> and view should never be interacting directly.  MVC or not, that's just bad
> architecture and there are zero advantages to using such an ad hoc approach.
>
> If a developer insists on using such a broken model, however, they're more

MVC is a broken model/bad architecture?

> than welcome to!  That's what people love (and hate) about PHP.  It's
> flexible.  They just won't be able to use a .phpp file upstream from that,
> as it is by its very nature inherently incompatible with such a broken
> model.  The only way to force it to be compatible would be to make the
> .phpp file essentially meaningless.
>
> So if you're writing good code structure, a .phpp file will help you make
> it even better.  If you're writing bad architecture, then just keep doing
> what you're already doing and don't worry about using a .phpp file!  This
> will in no way stop you from being able to do what you can already do in
> PHP.  You're just insisting on wanting to use a pure code file for
> something that it's not intended to be used for.  Just like having object
> orientation added in PHP 5 didn't stop you from writing procedural code if
> you want to, introducing this in PHP 6 won't stop you from writing
> disorganized code if you still want to.  What this will do is provide a
> valuable option for people who do feel that writing clean, role-segregated
> code is important.

So basically, the only parts that might be ok to write as .phpp are some
model and utility classes?

David

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

Re: [PHP-DEV] Re: Disabling PHP tags by php.ini and CLI options

[David Muir]

On 13/04/12 14:55, Stas Malyshev wrote:
> Hi!
>
>> If this is a pecl module library developers cannot use it and trust
>> that on php 5.n, it just works. That would fork the language in an
>> undesirable way. It should be a core feature, no ini flag, no
>> sometimes-there module.
> PHP 5.n is at least a year away, wide adoption of it - more like 5 years
> away. So if you want to write code that would run anywhere (as opposed
> on systems you control) you'd have to wait minimum 5 years. Wouldn't it
> better to have it earlier?
> OTOH, requiring extensions is a common thing for applications, and any
> pecl extension is one command away for most setups, or one download away
> for others. And can be made work even in 5.2 if desired.

Can't it also be handled using streams to inject a leading http://www.php.net/unsub.php

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

[David Muir]

On 13/04/12 11:03, Kris Craig wrote:
>
>
> On Thu, Apr 12, 2012 at 5:46 PM, David Muir  <mailto:davidkm...@gmail.com>> wrote:
>
> On 13/04/12 10:04, Kris Craig wrote:
>>
>>
>>     On Thu, Apr 12, 2012 at 4:46 PM, David Muir > <mailto:davidkm...@gmail.com>> wrote:
>>
>> On 13/04/12 09:38, Yasuo Ohgaki wrote:
>> > Hi,
>> >
>> > 2012/4/13 Kris Craig > <mailto:kris.cr...@gmail.com>>:
>> >> Per recent discussions, I have drafted an RFC for this.
>>  This proposal
>> >> offers what I believe to be a more sane and realistic
>> approach to
>> >> addressing the question of incorporating a new breed of
>> tag-less PHP
>> >> scripts.
>> >>
>> >> https://wiki.php.net/rfc/phpp
>> > This may work for LFI issue for new codes.
>> > Few questions.
>> >
>> > CLI may use .phpp as PHP script always. (i.e. execute w/o
>> > > It's like DOS, though.
>> >
>> > How do you enforce .phpp as script only for Web?
>> > Is it a rule for configuration? or .phpp just never
>> supposed to locate
>> > under docroot?
>> > It relates previous question. How about bootstrap script
>> for frameworks?
>> >
>> >> A regular .php script cannot be included from a .phpp
>> script. An E_WARNING will be thrown for include and an
>> E_RECOVERABLE_ERROR will be thrown for require; in both
>> instances, the included file will be ignored.
>> > Some people may try to make .phpp handled by web.
>> > I cannot tell if this setting is going to be popular, but if it
>> > does, isn't it the end of embedded PHP?
>> > It might be good if PHP is more tolerant for this usage.
>> >
>> > Regards,
>> >
>> > --
>> > Yasuo Ohgaki
>> > yohg...@ohgaki.net <mailto:yohg...@ohgaki.net>
>> >
>>
>> That's a huge WTF that a templating library can't be written
>> as .phpp,
>> because it then won't be able to load a template.
>>
>>
>> That's actually not true.  Please refer to the diagram embedded
>> in the RFC.
>>
>> Basically, you can load a template just fine-- you just can't do
>> it directly from a .phpp file, which you shouldn't be doing,
>> anyway.  The .phpp file is, at least for the most part, intended
>> to be included from a regular .php file, which also would include
>> whatever you're using for your templates.  In other words, they
>> can interact just fine; you just can't put the template upstream
>> from a .phpp file in the include stack-- which, again, you really
>> shouldn't be doing, anyway, as it's just bad architecture.
>>  
>
> How is this bad architecture? Every framework I've seen that has
> some kind of templating layer that handles the scope and inclusion
> of the template, and it happens further down the chain from the
> controlling code.
>
> Zend_View, Twig or Smarty would have to remain as .php and not
> .phpp, otherwise they wouldn't be able to render the templates.
>
> In the case of Zend Framwork, which I'm most familiar with, the
> application, front controller, dispatcher, and action controllers,
> and some services would have to remain as .php so that templates
> could be executed.
>
> Oh, and the autoloader can't be .phpp either. But then if it's
> .php, then the autoloader can't be called from .phpp files to
> include .php files.
>
> Cheers,
> David
>
>
> It's been awhile since I've used Smarty, but unless my memory is
> failing me, I'm pretty sure it's not restricted to being several
> points removed upstream as you described.  I'm not familiar with
> Zend_View or Twig so I can't comment on those.
>
> Thing is, there's no reason why you can't hook any framework into
> this.  Worst-case scenario, if the library you're hooking into has a
> rigid structure, just write a simple controller class layer to operate
> on top of it, then use that same controller class to interface with
> the .phpp stack.  Problem so

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

[David Muir]

On 13/04/12 10:04, Kris Craig wrote:
>
>
> On Thu, Apr 12, 2012 at 4:46 PM, David Muir  <mailto:davidkm...@gmail.com>> wrote:
>
> On 13/04/12 09:38, Yasuo Ohgaki wrote:
> > Hi,
> >
> > 2012/4/13 Kris Craig  <mailto:kris.cr...@gmail.com>>:
> >> Per recent discussions, I have drafted an RFC for this.  This
> proposal
> >> offers what I believe to be a more sane and realistic approach to
> >> addressing the question of incorporating a new breed of
> tag-less PHP
> >> scripts.
> >>
> >> https://wiki.php.net/rfc/phpp
> > This may work for LFI issue for new codes.
> > Few questions.
> >
> > CLI may use .phpp as PHP script always. (i.e. execute w/o  or else)
> > It's like DOS, though.
> >
> > How do you enforce .phpp as script only for Web?
> > Is it a rule for configuration? or .phpp just never supposed to
> locate
> > under docroot?
> > It relates previous question. How about bootstrap script for
> frameworks?
> >
> >> A regular .php script cannot be included from a .phpp script.
> An E_WARNING will be thrown for include and an E_RECOVERABLE_ERROR
> will be thrown for require; in both instances, the included file
> will be ignored.
> > Some people may try to make .phpp handled by web.
> > I cannot tell if this setting is going to be popular, but if it
> > does, isn't it the end of embedded PHP?
> > It might be good if PHP is more tolerant for this usage.
> >
> > Regards,
> >
> > --
> > Yasuo Ohgaki
> > yohg...@ohgaki.net <mailto:yohg...@ohgaki.net>
> >
>
> That's a huge WTF that a templating library can't be written as .phpp,
> because it then won't be able to load a template.
>
>
> That's actually not true.  Please refer to the diagram embedded in the
> RFC.
>
> Basically, you can load a template just fine-- you just can't do it
> directly from a .phpp file, which you shouldn't be doing, anyway.  The
> .phpp file is, at least for the most part, intended to be included
> from a regular .php file, which also would include whatever you're
> using for your templates.  In other words, they can interact just
> fine; you just can't put the template upstream from a .phpp file in
> the include stack-- which, again, you really shouldn't be doing,
> anyway, as it's just bad architecture.
>  

How is this bad architecture? Every framework I've seen that has some
kind of templating layer that handles the scope and inclusion of the
template, and it happens further down the chain from the controlling code.

Zend_View, Twig or Smarty would have to remain as .php and not .phpp,
otherwise they wouldn't be able to render the templates.

In the case of Zend Framwork, which I'm most familiar with, the
application, front controller, dispatcher, and action controllers, and
some services would have to remain as .php so that templates could be
executed.

Oh, and the autoloader can't be .phpp either. But then if it's .php,
then the autoloader can't be called from .phpp files to include .php files.

Cheers,
David

Re: [PHP-DEV] Re: Disabling PHP tags by php.ini and CLI options

[David Muir]

On 13/04/12 10:02, Arvids Godjuks wrote:
> It will never get adopted, too many legacy stuff, to many external tools.
> And php native templates? I dont neet any twig, smarty or any other stuff.
> And guess what - most template engines cache compiled templates, and they
> are - ta-daa - PHP EMBEDDED IN HTML CODE!
>

I was wondering when someone was going to point that out. ;-)

David

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

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

[David Muir]

On 13/04/12 09:38, Yasuo Ohgaki wrote:
> Hi,
>
> 2012/4/13 Kris Craig :
>> Per recent discussions, I have drafted an RFC for this.  This proposal
>> offers what I believe to be a more sane and realistic approach to
>> addressing the question of incorporating a new breed of tag-less PHP
>> scripts.
>>
>> https://wiki.php.net/rfc/phpp
> This may work for LFI issue for new codes.
> Few questions.
>
> CLI may use .phpp as PHP script always. (i.e. execute w/o  It's like DOS, though.
>
> How do you enforce .phpp as script only for Web?
> Is it a rule for configuration? or .phpp just never supposed to locate
> under docroot?
> It relates previous question. How about bootstrap script for frameworks?
>
>> A regular .php script cannot be included from a .phpp script. An E_WARNING 
>> will be thrown for include and an E_RECOVERABLE_ERROR will be thrown for 
>> require; in both instances, the included file will be ignored.
> Some people may try to make .phpp handled by web.
> I cannot tell if this setting is going to be popular, but if it
> does, isn't it the end of embedded PHP?
> It might be good if PHP is more tolerant for this usage.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>

That's a huge WTF that a templating library can't be written as .phpp,
because it then won't be able to load a template.

David

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

Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept

[David Muir]

I can't comment on the internal implementation, but I like the use of
the casting syntax. It's not as pretty, but make the intent clear, and
there's not BC issues with class names.

David

On 02/03/12 14:48, Anthony Ferrara wrote:
> Hey all,
>
> I know given all the discussion about this topic lately, this is a hot
> topic.  But I whipped together a quick POC patch to implement scalar
> type casting for function parameters.  Let me describe it:
>
> Patch: https://gist.github.com/1947259
>
> Example:
>
> function foo( (int) $bar ) {
> var_dump($bar);
> }
>
> foo(1); // int(1)
> foo("1"); // int(1)
> foo(1.5); // int(1)
> foo("foo"); // E_RECOVERABLE_ERROR - Expected integer
> foo(array()); // E_RECOVERABLE_ERROR
>
> Right now, I only implemented the checks for (int), but I add the
> parser constructs for (int), (float), (bool), (string) and (object)...
>
> Now, let's talk why I did what I did:
>
> Why did I use cast syntax?  Well, there are really three main reasons.
>  First off, to indicate that a cast may happen.  Second, to prevent
> needing new tokens (and hence reserved words).  And third to provide a
> distinction between a string class type hint and a string scalar type
> hint.
>
> Why did I only implement (int)?  Well, because I just wanted to build
> a quick dirty POC that can be executed to see the semantics of
> operation.  There are issues with it now, so rather than doing all the
> work to re-do it later, I just implemented int...
>
> Why implement (object)?  Because right now, there's no way to say you
> want to accept a generic object without caring about type.  So the
> (object) cast/hint would then provide that ability to accept a generic
> object.
>
> Why not implement (resource)?  Because that would require a new parser
> token, as it's not available now...
>
> How does the casting work?  Right now, it's using a copy of the same
> rules that internal functions use with zend_parse_parameters.  That
> way, it brings the operating semantics of internal functions and
> userland functions more inline with each other.
>
>
>
> So with that said, there are some (significant) issues with the patch:
>
> 1. First off, the arg checks happen before separation of the zval on
> non-referenced calls.  So that means the cast effects the original
> zval AND the argument.  Which is a no-go for a production patch.  So
> that means that the cast logic would need to be put after the zval
> split.  But we'd still want the checks first, so it's not too
> difficult to segregate, just requires deeper changes.  It's not
> difficult (that I can see yet), just more work...  Example of the
> problem:
>
> # sapi/cli/php -r 'function foo((int) $bar) { var_dump($bar); } $a =
> "1"; foo($a); var_dump($a);'
> int(1)
> int(1)
>
> 2.  Right now, the zend_aprse_arg_impl (
> http://lxr.php.net/xref/PHP_5_4/Zend/zend_API.c#zend_parse_arg_impl )
> that's used by internal functions is defined as static.  So we'd be
> copying a lot of the code back and forth.  In the production patch,
> I'd also want to re-factor that out a bit into either functions or
> macros to handle the type conversion and casting in both places.  That
> way, both systems would behave identical (or as close as possible).
>
>
> So, with that said, what do you think?  Is this something worth
> pursuing?  Are there any fundamental issues that I'm missing?  What
> else would we need to cover in a production patch and RFC?
>
> Thanks,
>
> Anthony
>


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

Re: [PHP-DEV] PHP 5.4.0 released!

[David Muir]

Ah, cool. That explains it. I noticed I was on the Australian mirror,
but then thought, "nah, can't be because of that..." ;-)

Cheers,
David

On 02/03/12 11:26, Philip Olson wrote:
> The mirrors have not yet updated, which is why the announcement
> linked specifically to docs.php.net (which builds the docs
> 4x daily[1]) for several entries.
>
> So while not perfect… the mirrors will update tomorrow, and
> will include additional information. Also, a few people are 
> making migration54 commits while I type this message. :)
>
> Regards,
> Philip
>
> [1] https://wiki.php.net/doc/builds
>
> On Mar 1, 2012, at 4:18 PM, David Muir wrote:
>
>> I noticed that too.
>>
>> The migration guide is also missing a lot of stuff.
>>
>> A quick overview:
>>
>> http://au.php.net/manual/en/migration54.changes.php:
>> content missing
>>
>> http://au.php.net/manual/en/migration54.new-features.php:
>> missing a lot of new features listed elsewhere
>>
>> http://au.php.net/manual/en/migration54.functions.php:
>> missing links and documentation for several functions
>>
>> http://au.php.net/manual/en/migration54.class-constants.php:
>> claims that there are several new class constants, but none are listed
>>
>> http://au.php.net/manual/en/migration54.methods.php
>> missing links and documentation for several methods
>>
>> http://au.php.net/manual/en/migration54.new-extensions.php
>> nothing listed
>>
>> http://au.php.net/manual/en/migration54.extensions-other.php
>> "The following extensions can no longer be disabled during build
>> configuration: " but only one empty list element
>>
>> Cheers,
>> David
>>
>>
>>
>>
>>
>>
>>
>>
>> On 02/03/12 11:00, Simon Schick wrote:
>>> Hi, all
>>>
>>> When will the documentation be ready?
>>>
>>> For example you wrote that something has changed to the keywords *continue 
>>> *and
>>> *break *- but I dont get what and it's not defined in here:
>>> http://www.php.net/manual/en/control-structures.continue.php
>>>
>>> Bye
>>> Simon
>>>
>>> 2012/3/2 Kris Craig 
>>>
>>>> Lol agreed.  I typically just build manually off the latest release
>>>> anyway.  But not everybody does that.  There are a lot of servers out there
>>>> running on PHP 5.1.x right now.
>>>>
>>>> --Kris
>>>>
>>>>
>>>> On Thu, Mar 1, 2012 at 3:52 PM, Reindl Harald >>>> wrote:
>>>>>
>>>>> Am 02.03.2012 00:46, schrieb Kris Craig:
>>>>>> LOL tell me about it!  The default PHP repos for many OSes are still
>>>>> using
>>>>>> 5.1.x
>>>>> so what
>>>>>
>>>>> using 5.3.x in production since 3 months after release everywhere
>>>>> learning to build packages for your OS is the key
>>>>>
>>>>>
>>
>> -- 
>> 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 5.4.0 released!

[David Muir]

I noticed that too.

The migration guide is also missing a lot of stuff.

A quick overview:

http://au.php.net/manual/en/migration54.changes.php:
content missing

http://au.php.net/manual/en/migration54.new-features.php:
missing a lot of new features listed elsewhere

http://au.php.net/manual/en/migration54.functions.php:
missing links and documentation for several functions

http://au.php.net/manual/en/migration54.class-constants.php:
claims that there are several new class constants, but none are listed

http://au.php.net/manual/en/migration54.methods.php
missing links and documentation for several methods

http://au.php.net/manual/en/migration54.new-extensions.php
nothing listed

http://au.php.net/manual/en/migration54.extensions-other.php
"The following extensions can no longer be disabled during build
configuration: " but only one empty list element

Cheers,
David








On 02/03/12 11:00, Simon Schick wrote:
> Hi, all
>
> When will the documentation be ready?
>
> For example you wrote that something has changed to the keywords *continue 
> *and
> *break *- but I dont get what and it's not defined in here:
> http://www.php.net/manual/en/control-structures.continue.php
>
> Bye
> Simon
>
> 2012/3/2 Kris Craig 
>
>> Lol agreed.  I typically just build manually off the latest release
>> anyway.  But not everybody does that.  There are a lot of servers out there
>> running on PHP 5.1.x right now.
>>
>> --Kris
>>
>>
>> On Thu, Mar 1, 2012 at 3:52 PM, Reindl Harald >> wrote:
>>>
>>> Am 02.03.2012 00:46, schrieb Kris Craig:
 LOL tell me about it!  The default PHP repos for many OSes are still
>>> using
 5.1.x
>>> so what
>>>
>>> using 5.3.x in production since 3 months after release everywhere
>>> learning to build packages for your OS is the key
>>>
>>>


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

Re: [PHP-DEV] PHP 5.4.0 released!

[David Muir]

Wohoo!!! Congrats everyone!

Bye bye magic quotes!

David

ps. Now to get my host to upgrade to 5.3 grumble grumble!

On 02/03/12 10:29, David Soria Parra wrote:
> Hello!
>
> The PHP Development Team would like to announce the immediate
> availability of PHP 5.4.0. This release is a major leap forward in the
> 5.x series, and includes a large number of new features and bug fixes.
>
> Release Announcement: http://www.php.net/releases/5_4_0.php
> Downloads:http://php.net/downloads.php#v5.4.0
> ChangeLog:http://www.php.net/ChangeLog-5.php#5.4.0
>
> regards,
>   Stas and David
>


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

Re: [PHP-DEV] Constant arrays

[David Muir]

On 12/21/2011 03:37 AM, jpauli wrote:
> I guess constant array would mean that all the variables inside the array
> dimensions should not change.
> Just saying that, is a nonsense.
>
> If a constant could be an array, then that array could not contain
> variables, if not it wouldn't be constant any more as a change to one
> variable inside it would change its own meaning value.
>
> Julien.P
>
>

A constant can only contain static values. There was no mention of
variables.

Isn't a "constant" array basically the same as an Enum?

David

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

Re: [PHP-DEV] Local time zone

[David Muir]

On 15/12/11 21:17, Pierre Joye wrote:
> On Wed, Dec 14, 2011 at 11:14 PM, Stas Malyshev  
> wrote:
>> Hi!
>>
>>
>>> I believe he's referring to sys/time.h, but this introduces
>>> portability issues.  If it were just unix, that would be one thing.
>>> But maintaining this and a Windows alternative, and I have no idea
>>> what that is, is not worth it IMO.
>>
>> Yes, portability is questionable. Though if we had a good patch that allows
>> to do it, I don't think it would be too bad to have it. Even Unix-only might
>> be (again, if enough people need it) fine, if we could use the data properly
>> in timelib functions.
> By portability it is not (only) about APIs, APIs wrapping is easy
> these days, even on Windows.
>
> But the actual problem is to get a consistent and constantly updated
> set of data, reliable data. Data that applications can use blindly on
> any platforms without having to worry about bad information, as long
> as they use the latest PHP or timezone release (via PECL for example).
>
> And that, as stated earlier, is why we should not provide any
> alternative as any other solutions failed so far. It is also even less
> important as Oleg's target is the developer environment. If a
> developer cannot set his TZ correctly in a php.ini or in his
> application on his development box, then something is wrong there, but
> not in php :)
>
> For production server, I would never ever suggest to use the system's
> TZ, no matter the OS/distros/etc..
>
> Cheers,

Isn't this whole thread about client-side apps, not server-side. For
client-side stuff it doesn't make sense to use anything but the system
tz. Should we be expecting users to have to edit php.ini files every
time they hop on a plane or drive across a tz border? And what about
non-developers?

Keeping the tz database up to date is a very annoying issue. System tz
data is typically more up-to-date as it's pushed to the user, while with
php, you need to have admin rights to install an updated tz database, or
hope that the packager for your distro (or your web-host) does it for
you. As far as I can tell, most hosts do not update timezone data from
PECL. I just checked one host that is still on 5.2:

date/time support enabled
"Olson" Timezone Database Version 2010.9
Timezone Database internal
Default timezone UTC

Sigh...

Ubuntu however reports 0.system as the tz version. Does that mean that
PHP there is using the system's tz database instead?

Cheers
David

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

Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values

[David Muir]

On 24/11/11 12:44, Ferenc Kovacs wrote:
>
>
> On Thu, Nov 24, 2011 at 1:38 AM, David Muir  <mailto:davidkm...@gmail.com>> wrote:
>
> Just to clarify, the changes introduced in 5.4 will result in the
> following:
>
> 
> $string = 'foo';
> $array = array(
>'foo' => array(
>'bar' => 'baz',
>//expected structure
>//'bar' => array('baz' => array('values'))
> ));
>
> var_dump(
>isset($string['foo']), //true
>isset($string[0][0]), //false, true in 5.4
>isset($array['foo']['bar'][0]), //true
>isset($array['foo']['bar']['baz']), //true
>isset($array['foo']['bar']['baz']['0']) //false, true as of 5.4
>isset($string['foo']['bar']['baz']['0']) //false, true as of 5.4
> );
>
>
> you are missing a comma from the end of the
> isset($array['foo']['bar']['baz']['0']) //false, true as of 5.4
> line

Yeah, I added that one at the last minute. That's what I get for a quick
copy/paste...

>
> isset($string['foo']['bar']['baz']['0']) //false, true as of 5.4
> gives me a fatal error on 5.3 ("PHP Fatal error:  Cannot use string
> offset as an array" as you can't "chain" string offsets before 5.4)
>

It gives me false in 5.3.6. Using it outside of isset() results in the
fatal error.

>  
>
>
> What used to be a one-liner, now effectively needs a crapload of
> boilerplate code.
>
>
> yeah, if you can't trust the data structures in your code, then you
> have to validate it.
> don't forget that this bug could also bite you with 5.3:

True, it does fail in 5.3 in some places, but it now fails in more
places with 5.4. Maybe what's triggering the hostile reaction to this
change is that people incorrectly assumed that they were validating it
in a valid manner. The docs for isset states that it works for array
keys, but there's no mention about the string offset gotcha, and it's a
much more convenient option that using array_key_exists + is_array for
each level.

Can we add the lines:

var_dump(isset($a['pie']['a'][0]));// TRUE
var_dump(isset($a['pie']['a']['b']));// TRUE

to the isset docs? At least then the current behaviour would be
documented. And maybe add Anthony Ferrera's tip that only the last
element needs an array check?


> Personally I think that the main issue is that we silently convert
> $foo['bar'] to $foo[0] for strings, which imo rarely the intended
> behavior and doesn't really makes much sense (except that the offset
> expects the index to be int, and this is how we type juggle between
> string and int), so I think it would be a good idea to raise a notice
> here, so the developer can fix his code, or add some input validation.

That would be a help.


Cheers,
David

Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values

[David Muir]

On 24/11/11 11:42, Stas Malyshev wrote:
> Hi!
>
>> If you want this fix to be palatable, we'll need a new language
>> construct that effectively runs a series of is_array&&  array_key_exists
>> with a final !== null check.
>
> I'm not sure RC time is a good place for introducing new language
> constructs. Actually, I'm pretty sure it's not.

And I believe you're missing the point. I'm not suggesting it for 5.4,
but illustrating that until something like it (or better) exists, the
"bug fix" should wait until such a solution exists.

David





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

Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values

[David Muir]

On 24/11/11 06:25, Stas Malyshev wrote:
> Hi!
>
>> The only case where the 5.4 branch works differently as before if you
>> reference a string type(int, float, etc. won't trigger this) variable
>> using an associative index and you expect it that to be undefined
>> variable even though that the documentation explicitly states that the
>
> Actually, the only change 5.4 did was to make $a['foo']['bar'] work
> like ($a['foo'])['bar'] - i.e. chained offsets work the same way as if
> they were applied separately. That's it. All the rest has been there
> since forever. I can't see how one could argue it should stay this way.
>
> Now I'm sorry somebody used the fact that chained offsets didn't work
> to do a check "do we have any strings there" but that's not how PHP is
> supposed to work and it's clearly a side-effect of a bug.

One thing that I wasn't aware of was the string to int conversion for
string offsets. IMO, that should trigger a notice or something. Good to
be reminded of though.

Just to clarify, the changes introduced in 5.4 will result in the following:

 array(
'bar' => 'baz',
//expected structure
//'bar' => array('baz' => array('values'))
));

var_dump(
isset($string['foo']), //true
isset($string[0][0]), //false, true in 5.4
isset($array['foo']['bar'][0]), //true
isset($array['foo']['bar']['baz']), //true
isset($array['foo']['bar']['baz']['0']) //false, true as of 5.4
isset($string['foo']['bar']['baz']['0']) //false, true as of 5.4
);

If so, then it's a major BC break.
Maybe it's a bugfix, but it's a bugfix that allows for behaviour that
1. doesn't really make sense
2. has little to no practical benefit (when are you ever going to be
chaining offsets on strings?)
3. introduces new, hard-to-detect bugs in live code.

What used to be a one-liner, now effectively needs a crapload of
boilerplate code.
If you want this fix to be palatable, we'll need a new language
construct that effectively runs a series of is_array && array_key_exists
with a final !== null check.

array_isset($string['foo']['bar']) //false (not an array)
array_isset($array['foo']['bar']) //true, 'foo' is an array, and 'bar'
is not null
array_isset($array['foo']['bar'][0]) //false, $array['foo']['bar'] is
not an array
array_isset($array['foo']['bar']['baz']) //false, $array['foo']['bar']
is not an array

Behaviour is different from 5.3's isset, but is more in-line with what I
and I believe most PHP programmers would expect isset to behave when
checking multi-dimensional arrays, and has the features, that
array_key_exists is missing.

Anybody got a better idea?

Cheers,
David

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

Re: [PHP-DEV] Re: SPLClassLoader RFC Thoughts And Improvements

[David Muir]

On 11/11/2011 01:31 PM, guilhermebla...@gmail.com wrote:
> Hi Anthony,
>
> Thanks immensely for your input.
> Without such action, it's extremely hard to improve the RFC. =)
> Awesome action from your side.
> I'll place my comments inline.
>
> On Thu, Nov 10, 2011 at 1:26 PM, Anthony Ferrara  wrote:
>

...snip...

>>  b) The code that includes the file should be changed to require_once
>> to eliminate including the same file twice when different classes map
>> to the same file.  For example, this should not fail (assuming both
>> classes are not in the same file):
>>
>>new \Foo\Bar\Baz;
>>new \Foo\Bar_Baz;
>>
>>Both map to the same file, but are distinct classes in PHP.
>> By changing it to require_once, it'll realize it already included the
>> file and then skip over that and let another class have its shot.
>>
> Actually they do not map the same file. Here is the path of each one:
> new \Foo\Bar\Baz; => [path]/Foo/Bar/Baz.php
> new \Foo\Bar_Baz; => [path]/Foo/Bar_Baz.php
>
> You may now be in doubt if PEAR1 style is supported. Yes, it is. The
> point is that code detects for the presence of namespace separator and
> if it is found, it considers the namespace separator as directory
> separator; if not, it considers the "_" char as directory separator.
> We decided that because PEAR1/Zend1/Doctrine1/Symfony1 (and many
> others) would not be supported if we didn't do that way. It's the
> solution for BC. Since most of the mentioned ones are already in
> another major version, consuming PHP 5.3 namespaces, then the default
> behavior would work nifty. =)

This is news to me, and even the RFC states:
Each “_” character in the CLASS NAME is converted to a
DIRECTORY_SEPARATOR. The “_” character has no special meaning in the
namespace.

I believe you're confusing it with the namespace portion:
new \Foo_Bar\Baz; => [path] /Foo_Bar/Baz.php
in which case the _ is retained.
Otherwise:
new \Foo\Bar_Baz; => [path] /Foo/Bar/Baz.php
new \Foo_Bar\Baz_Waz => [path] /Foo_Bar/Baz/Waz.php

If what you are saying is true, then the RFC is incorrect, and should be
updated to included the correct rules.

>
> Regarding the require_once change, it's not really needed. The reason
> is because class loading would never be triggered again if the
> class/trait/interface is already loaded. The require_once is extremely
> slow than require due to this check.
> But I really don't have strong feelings to change that is many people
> find it necessary.

That was true 6 years ago. Benchmarks from 4 years ago, it was the other
way around. Has it flipped back again?

...snip...

>> 4. The RFC should avoid implementing any pattern or style that may
>> make future feature addition difficult or pose risks towards such.  An
>> example would be implementing an interface for the autoloader which
>> defines something like load($class).  The problem there is that if
>> function autoloading is added, the interface won't be able to support
>> it.  So it's stuck in a hard place between changing an implemented
>> interface (which will bork code significantly on update) and adding a
>> new interface (which would be the lesser of evils, but would just add
>> to the deprecated cruft).
> OO theory defines that whenever you want to have a contract to be
> followed by any implementation, an interface is required.
> The contract is something useful that enforces that way you receive
> would have at least what it was expected/used internally.
> So, if we agree in the future that the chosen implementation would not
> contain the methods ->register/->unregister, and spl_autoload_register
> would accept SplAutoload instances, then the contract is more than
> required.
> Regarding the function autoloading, as I discussed previously, it is
> invalid in this paradigm.
> I don't see how the contract would change in the future.

But the only contract that is needed by spl_autoload_register is the
load method.

The register and unregister methods are not needed by any other entity
that I am aware of, and are only there as convenience methods for the
user, and therefore don't belong in the interface for a generic
autoloader. A second interface could be added for self-registering
autoloaders, but that begs the question, why should an autoloader know
how to register itself with a particular loading stack (sure the spl
autoloading stack is the only one we have, but still...)? There's no
discussion in the RFC showing why those methods should be part of an
autoloader interface.
The same applies to the setMode() and add() methods. What contract are
they fulfilling?

Cheers,
David

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

Re: [PHP-DEV] SPLClassLoader RFC Thoughts And Improvements

[David Muir]

Surprised to say that I agree on just about everything you mentioned. I
would however love to see a useful autoloader included in core. I have
only one comment below.
> 4. The RFC should avoid implementing any pattern or style that may
> make future feature addition difficult or pose risks towards such.  An
> example would be implementing an interface for the autoloader which
> defines something like load($class).  The problem there is that if
> function autoloading is added, the interface won't be able to support
> it.  So it's stuck in a hard place between changing an implemented
> interface (which will bork code significantly on update) and adding a
> new interface (which would be the lesser of evils, but would just add
> to the deprecated cruft).

IMO, the interface should just define loadClass($class). It means that
spl_autoload_register has a fixed target for loading classes, and if we
want to support autoloading functions or whatever else later on, a new
interface can be added that would define the appropriate method eg.
loadFunction($function).

Cheers,
David


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

Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP

[David Muir]

On 08/26/2011 04:12 AM, Kalle Sommer Nielsen wrote:
> 2011/8/24 David Soria Parra :
>> Hi Internals,,
>>
>> after 3 weeks of discussion, I think we are ready to start voting on
>> the DVCS RFC.  If you think something is missing or should be explained
>> in more detail, let me know.
> I won't transfer the discussion over here but; I don't want to move to
> a new system we we did it just a few years ago, as Rasmus said long
> before we moved was that we want to find a solid system that could
> hold out just as long as the old setup. I don't have a problem by
> using SVN, nor merge as we have been good at keeping files in sync so
> its easy to merge patches, much easier than the old unicode-trunk.
>
> That being said; I agree with Stas that having a vote is not a good
> way to actually make a choice here, but it gives a hint of those that
> voted, as I'm sure that there are many more actively working on the
> project like PEAR. PECL and Doc guys thats not gonna vote because they
> don't follow Internals.
>
> But -1 from me.
>
>

FWIW, PEAR is already moving to GitHub.

David



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

Re: [PHP-DEV] Activation of IGBinary serialization extension in 5.4 by default

[David Muir]

The gain is that those without the extension can still unserialize the
data and read it. It solves the problem discussed where older versions
of PHP without IGBinary built in would be locked out from being able to
unserialise data.

Didn't realise the reply was private. I did a reply-to-list, but
Thunderbird picks up your address instead of internals.

David

On 23/08/11 09:52, Pierre Joye wrote:
> then the gain will be zero. By the way, no need to go private to reply :)
>
> On Tue, Aug 23, 2011 at 1:29 AM, David Muir  wrote:
>> That still requires the extension. I was referring to a userland
>> implementation written in PHP, not C.
>>
>> Cheers,
>> David
>>
>> On 22/08/11 17:21, Pierre Joye wrote:
>>>   PHP_FE(igbinary_serialize,arginfo_igbinary_serialize)
>>>   PHP_FE(igbinary_unserialize,  
>>> arginfo_igbinary_unserialize)
>>>
>>> On Mon, Aug 22, 2011 at 2:18 AM, David Muir  wrote:
>>>> On 08/22/2011 10:07 AM, Pierre Joye wrote:
>>>>> On Mon, Aug 22, 2011 at 1:49 AM, David Muir  wrote:
>>>>>
>>>>>> Why not provide a userland fallback?
>>>>>>
>>>>>> eg: /IGBinary/unserialize()
>>>>>>
>>>>>> It could unserialize the string, albeit slowly, but still give you
>>>>>> access to the data without needing the extension. At least that way you
>>>>>> have something rather than nothing.
>>>>> igbinary has functions for that already.
>>>>>
>>>> It does? I didn't see it in the docs, or in the git tree.
>>>>
>>>> Cheers,
>>>> David
>>>>
>>>
>>
>
>


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

Re: [PHP-DEV] Choosing a distributed version control system for PHP - problems

[David Muir]

On 22/08/11 17:44, Lester Caine wrote:
> Lester Caine wrote:
>> Just for the record ... the libreoffice clone I started 9 hours ago is
>> still going strong, and I'm estimating that it will finish some time
>> tomorrow afternoon, another 20 hours or so. A single huge repo is going
>> to take time to handle? Or am I doing something wrong? All I've done at
>> the moment is followed the instructions Pierre directed me to ... they
>> were not on the original notes I looked at.
>
> I've been away from home over the weekend stuck in an exhibition hall,
> so I left the libreoffice clone via hggit running ... It's still
> running this morning 4 days later. I'll leave it to finish now. The
> straight git clone did run in under an hour, but obviously the cross
> DVCS processes need a lot more work :( The other git hosted projects I
> am working with work with a modular setup using submodule, and this
> does not present the same problem, creating hg clones reasonably quickly.
>
> So is the current question one of better making the case for one over
> the other? On the existing RFC there is little detail which covers the
> reasons that people who are working cross platform DO have a problem
> with git, and why currently hg is providing a clean transparent
> platform. Both will do the job that it seems is being targeted, even
> if I disagree that it's the right target, but neither are clear front
> runners? It would seem however that a hybrid system supporting both is
> probably still some way off :(
>

There's something weird in HG's network stack. I tried doing grabbing an
svn repository with hg, and it took over an hour to get part of the way
through. Bazaar was able to grab the whole repo in 2-3 minutes. Haven't
tried with git though.

David

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

Re: [PHP-DEV] Activation of IGBinary serialization extension in 5.4 by default

[David Muir]

On 08/19/2011 10:54 PM, Ferenc Kovacs wrote:
> On Fri, Aug 19, 2011 at 2:47 PM, Arpad Ray  wrote:
>> On Fri, Aug 19, 2011 at 1:40 PM, Ferenc Kovacs  wrote:
>>> On Fri, Aug 19, 2011 at 2:31 PM, Arpad Ray  wrote:
 On Fri, Aug 19, 2011 at 1:04 PM, Ferenc Kovacs  wrote:
> the downside would be that if you want to serialize/unserialize the
> data outside of php, your implementation should take care of this
> prefix.
> just a wild idea, but maybe useful:
> instead of creating a prefix, we could serialize the passed data with
> the given(php, igbinary, etc.) handler, then wrap the whole stuff into
> an array which holds the name of the used handler and the serialized
> data, and serialize this array with the old(php) serialize method.
> this way the datablob would be always a valid serialized string, and
> would be easier to get the serialize method than with the prefixing.
 If my old app couldn't read some newly serialized string, I'd rather
 it failed hard than apparently succeed but have the wrong data.

>>> http://php.net/unserialize
>>> In case the passed string is not unserializeable, FALSE is returned
>>> and E_NOTICE is issued.
>>> so if you unserialize from php, my suggestion would fail harder.
>>> when you unserialize it from another mean (parsing it on your own, or
>>> from a different language), you are right, it would produce a valid
>>> but different result what you would expect, but this could be
>>> documented, and I don't think that that many users do this, and maybe
>>> they are using json/bson/igbinary already.
>> I'm talking about unserialize() in an old (well, current) version of
>> PHP - if it unserializes what is apparently a valid array there would
>> be nothing to indicate it's actually a new version which it can't
>> read.
>>
> I see, yeah, "old" clienst would still suffer from this, they would
> get an array from unserialize what they didn't expect, and maybe some
> data, what they cannot unpack (if it was packed with a method other
> than the current)
> the pro side is that it would be possible to handle this situation (if
> you cannot upgrade a php instance for example for some reason) as you
> could handle those situations (unserialize the data field to get the
> original data, or use igbinary from pecl to decompress it, etc.)
> I didn't feel too strong about this, just throwing ideas around.
>
Why not provide a userland fallback?

eg: /IGBinary/unserialize()

It could unserialize the string, albeit slowly, but still give you
access to the data without needing the extension. At least that way you
have something rather than nothing.

David

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

Re: [PHP-DEV] [RFC] Choosing a distributed version control system for PHP (or not). Call for Participation.

[David Muir]

On 09/08/11 01:07, Lester Caine wrote:
> David Muir wrote:
>> John Szakmeister, who is a Subversion developer himself, has a good
>> comparison of svn, hg, bzr and git:
>> http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/
>>
>>
>> Long story short, his company went with git.
>
> Makes good reading ... many other comparisons are now getting long in
> the tooth, and so don't cover the current playing field. Still it
> looks like 'best of a bad job' rather than 'this wins hands down' and
> does make a fair comparison of all the current problems, but I think
> the fact that he has not investigated submodules may actually negate
> their final results :( This was the main area that I needed to work
> well, but is still work in progress everywhere?
>

He did mention submodules as a Pro for git, but you're right, he didn't
compare it with Hg's subrepos and subhg and Bzr's nested trees,
bzr-externals and scmproj. I have a feeling that git's native support
for it is much more mature than the others. That said, it's not a
feature I've looked into myself as it's not something I've actually needed.

Cheers,
David

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

Re: [PHP-DEV] [RFC] Choosing a distributed version control system for PHP (or not). Call for Participation.

[David Muir]

On 08/08/11 07:37, Richard Riley wrote:
> David Soria Parra  writes:
>
>> On 2011-08-07, Stas Malyshev  wrote:
>>> Hi!
>>>
>>> As somebody that have seen reasonably big project switch from SVN to git 
>>> and worked quite actively with git since then, I think describing my 
>>> experience might be useful for those that never tried it.
>>>
>>> 1. git is much better than svn especially as applied to complex projects 
>>> with multiple participants which need to accept outside patches, 
>>> maintain multiple branches and port fixes between branches. You never 
>>> know how much you needed cheap branching/merging until you worked with 
>>> it some.
>>>
>>> 2. Switching from svn to git requires one to undergo some mental shift, 
>>> and for the first couple of weeks you may be confused and somewhat 
>>> frustrated by too many things that look like but not exactly like the 
>>> old system. It would appear too complex and unnecessarily complicating 
>>> workflows. However, as you develop new routines, you'll find out how it 
>>> makes sense and will become more effective than with svn. Note that git 
>>> IS much more complex conceptually than SVN and allows to do much more 
>>> crazy things - including rewriting history in all kinds of weird ways - 
>>> so while I don't think I had to ask SVN question in forums for years - I 
>>> still have to google "how to do this in git" and ask around for some of 
>>> the more complex things. I think it's still worth it. Don't know if it 
>>> makes me a fanboy :)
>>>
>>> 3. Having system like github around it adds a lot - maintaining multiple 
>>> repositories, forks and pull requests is a real boon. I'm not sure if it 
>>> would make sense for php, all things considered, but there are very 
>>> significant benefits of using such a system where many workflows are 
>>> already built-in.
>> having a dvcs will enable us to use pull requests in github. (maybe
>> you will not able to use the big merge button but rather do it yourself,
>> but still it's a huge improvement).
>
> Its really simple.
>
> Use git.
>
> It works, is fast and is rapidly becoming the industry standard. Do not
> sue something for "moral grounds" like the awful bzr used for emacs.
>
> Its designed as a fast, efficient DVCS.
>

It's not bzr's fault that someone had the bright idea of setting up the
server to serve the emacs' repo via a slow "dumb" protocol (sftp).

I've been using mercurial for the past 2 months and Bazaar for the past
4 years. My personal preference is Bazaar as it handles my workflow much
better than Mercurial does. Mercurial seems to encourage a "commit
everything to trunk in a linear fashion" like svn. Named branches seem
to be the only way to ensure that a merge comes in as a single commit
rather than a "fast-forward merge", but they're discouraged for some odd
reason. Maybe there are some extensions that make mercurial easier to
use in this regard, but I haven't looked too hard. Maybe that's not a
big problem for some projects, but for me, I like to know when a
particular feature was landed in trunk, and what commits are related to
it, so when I revert a change, I'm only reverting a single commit rather
than having to weed through the tree to find all the commits that need
to be reversed. And if I'm "doing it wrong™", please let me know off
list how I can improve things.

I have not used git yet, so I can't comment much there other than that
the impression I get is that it's probably the most capable system out
there, but where it still has a ways to go is usability. I hear that's
getting better too, but this git-cheatsheet
(http://www.ndpsoftware.com/git-cheatsheet.html) still confuses me.

John Szakmeister, who is a Subversion developer himself, has a good
comparison of svn, hg, bzr and git:
http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/

Long story short, his company went with git.

Cheers,
David

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

Re: [PHP-DEV] Fix for #53727 (is_subclass_of resolution with interfaces)

[David Muir]

On 30/06/11 15:01, Matt Pelmear wrote:
> Not like class_implements(), since that requires processing the returned
> array... Rather something that would function similarly to is_subclass_of()
> (in that it returns a bool, not an array), but for interfaces.
> I seem to run into a need for that on a fairly regular basis. (when I first
> found class_implements() this is what I thought it did before reading the
> docs)
>
> -matt

Oops. My bad. Missed the array_key_exists() part in the example.

David


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

Re: [PHP-DEV] Fix for #53727 (is_subclass_of resolution with interfaces)

[David Muir]

On 30/06/11 11:13, Matt Pelmear wrote:
> Seems odd to me that is_subclass_of returns true for interfaces... I never
> realized that before.
>
> Personally I would prefer a separate method to check for interfaces, since
> they aren't really classes (at least in my head), but I suppose that would
> break BC. (I've always wanted a method for checking if a class implements an
> interface.)
> So, maybe this patch makes sense to me, and some additional method for
> checking only interfaces would be nice? (I can't think of a good name for
> such a method.) Thoughts?
>
> -Matt
> On Jun 29, 2011 5:26 PM, "Ralph Schindler"  wrote:
>

As in class_implements() (shown in Ralph's example)?

David

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

Re: [PHP-DEV] Variable scopes for language constructs (foreach, ...)

[David Muir]

>> personally I find that weird, and unintuitive, but changin that in a major
>> or minor version could be changed if we chose to.
> I think it's a behaviour that could be changed in some step like from
> 5.3 to 5.4 or so. Personally I don't think it would influence existing
> implementations much (who uses the key/value of a foreach after the
> loop?) or could easily be changed.

I do, and I've seen the construct used many times. It would be a major
pain to track down and fix if this behaviour changes.

Cheers,
David

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

Re: [PHP-DEV] [PATCH] unregister_shutdown_function()

[David Muir]

On 21/06/11 07:41, Arpad Ray wrote:
>
 I also think once that functionality is there the next request will be

get_registered_shutdown_functions()

 or something along the lines.
>>> I don't see of what use that could be.
>> Completeness? "Has that stupid shutdown func been registered?"
> Fair enough, although I should point out that
> unregister_shutdown_function() returns false if the function hadn't
> been registered, so if the aim of checking whether it's registered is
> to remove it then that's unnecessary.
>
> Regards,
>
> Arpad
>

Unless you want to check if a shutdown function has been registered, and
adjust certain behaviour accordingly.
eg, you might want to make sure you exit gracefully prior to doing
something that might trigger a fatal error.

Cheers,
David

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

Re: [PHP-DEV] Bundling "modern" extensions

[David Muir]

On 07/06/11 18:40, Reindl Harald wrote:
>
> Am 07.06.2011 11:32, schrieb David Muir:
>> On 07/06/11 15:49, Reindl Harald wrote:
>>> Am 07.06.2011 04:42, schrieb Martin Scotta:
>>>> On Mon, Jun 6, 2011 at 8:15 PM, Reindl Harald 
>>>> wrote:
>>>>
>>>>> Am 06.06.2011 23:40, schrieb Martin Scotta:
>>>>>
>>>>>> It'd be very nice if some extension could be enabled just by dropping the
>>>>>> "extension file" on the path.
>>>>>> So developers can check what they have using phpinfo, and then upload the
>>>>>> needed extension using ftp. Is it possible?
>>>>> if a "developer" only would try such idiotic action
>>>>> he would lost his accounts forever and get fired from
>>>>> one day to the next!
>>>>>
>>>>> WTF how can anybody have the idea that it would be a good
>>>>> idea to let non-sysadmins uplod and execute binaries on a
>>>>> server?
>>>>>
>>>>>
>>>> Thanks you for all yours responses.
>>>> Now it's clear what the issue is... the usage of compiled "libraries".
>>>>
>>>> We need some middleware between the core and PHP.
>>>> That way extensions could be written in PHP, compiled and distributed in
>>>> some "library" format.
>>>> Library users just add them into their path, include them, and use the
>>>> classes/functions as usual.
>>>>
>>>> - No OS dependence
>>>> - minimum dependence with core version
>>>> - size of core will reduce drastically
>>>> - faster runtime, include only what libs you use, as you need them
>>> what are you speaking about and since how long you are working
>>> with PHP that you never heard about PEAR, ZendFramework?
>>>
>> And you should know that PEAR and ZF are user-land libraries, not
>> compiled libraries.
> i know that
>
>> I think Martin is wishing for is the PHP Native Interface:
>> https://wiki.php.net/rfc/php_native_interface
> where is the real difference to a userland-library as PEAR
> and the thousand other which exists and will we ever see
> a solution for extensions wich is SECURE?
>
> there is a reason for example to disallow many functions
> on a webserver - so every API has to make sure they
> can not be bypassed
>
> "because we can" is no valid reason for everything because
> we can install binary extension as they exist now and
> if you can not you are missing the permissions for some
> good reasons
>

So you're saying that PECL, PNI or FFI should should be actively
discouraged because of security concerns?

Python has ctypes. How did it solve the security problems?

What exactly are the security issues?

I'm really trying to figure out where you're coming from.

Cheers,
David

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

Re: [PHP-DEV] Bundling "modern" extensions

[David Muir]

On 07/06/11 15:49, Reindl Harald wrote:
>
> Am 07.06.2011 04:42, schrieb Martin Scotta:
>> On Mon, Jun 6, 2011 at 8:15 PM, Reindl Harald wrote:
>>
>>> Am 06.06.2011 23:40, schrieb Martin Scotta:
>>>
 It'd be very nice if some extension could be enabled just by dropping the
 "extension file" on the path.
 So developers can check what they have using phpinfo, and then upload the
 needed extension using ftp. Is it possible?
>>> if a "developer" only would try such idiotic action
>>> he would lost his accounts forever and get fired from
>>> one day to the next!
>>>
>>> WTF how can anybody have the idea that it would be a good
>>> idea to let non-sysadmins uplod and execute binaries on a
>>> server?
>>>
>>>
>> Thanks you for all yours responses.
>> Now it's clear what the issue is... the usage of compiled "libraries".
>>
>> We need some middleware between the core and PHP.
>> That way extensions could be written in PHP, compiled and distributed in
>> some "library" format.
>> Library users just add them into their path, include them, and use the
>> classes/functions as usual.
>>
>> - No OS dependence
>> - minimum dependence with core version
>> - size of core will reduce drastically
>> - faster runtime, include only what libs you use, as you need them
> what are you speaking about and since how long you are working
> with PHP that you never heard about PEAR, ZendFramework?
>

And you should know that PEAR and ZF are user-land libraries, not
compiled libraries.

I think Martin is wishing for is the PHP Native Interface:
https://wiki.php.net/rfc/php_native_interface

Either that, or a PHP equivalent of Cython or Pyrex.

Cheers,
David

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

Re: [PHP-DEV] 5.4 moving forward

[David Muir]

On 07/06/11 01:49, Stas Malyshev wrote:
> Hi!
>
>> Currently off the shelf, 5.2.17 is the 'old stable' but for some
>> windows users
>> it IS the only available version. Changing the rest of the
>> infrastructure to
>
> 5.2.17 is unsupported. It is announced on php.net. Now, some Windows
> users, due to certain choices, may have to run this version - but this
> doesn't change the fact it's officially unsupported. So I don't see
> how it supports viability of LTS idea.

Yes, and one week after support ending with announcement of 5.2.15,
5.2.16 was released again claiming that support has ended. And then a
month later 5.2.17 was released, but no longer mentions that support has
ended. Not too surprising then if people incorrectly assume that
critical issues will continue to be fixed for 5.2.

>
>> package! So while PHP may have washed it's hands of the problem,
>> those users who
>> are stuck in the hole still need to be supported in some way. But all
>> that is
>
> There's nothing to prevent anybody willing to do it from providing
> this support. However, the question is not if there are users with
> some special needs. The question is LTS, specifically:
> 1. Will PHP group ever willing to support a version in LTS timeframe -
> so far it never happened

5.2 was supported for about 5 years, which is what one would expect from
an LTS release, so yes. It has effectively already happened.

> 2. How we know we'd need to support such version UPFRONT - before it's
> released?

Because you say upfront how long the release will be supported. This is
fairly straight-forward for any project using timed releases, which by
the looks of it, is what the RFC is suggesting.
How does Canonical know which Ubuntu release will be LTS? Because they
decided every 4th release will be LTS. It's really not any more
complicated than that.
Maybe confusion is because in the past PHP has not followed timed
releases, so there's no knowing how long it will be until the next
version comes out. The best you can do then is promise x months of
support after the next version is released.

>
>> being asked for is security fixes which seem to be a LOT less of a
>> problem
>> nowadays anyway? So support IS just a matter of maintaining
>> availability to it
>> and the correct builds of extensions that go with it.
>
> It looks to me you are confusing the question of "is LTS a viable
> model for PHP development" with "if we had LTS 5 years ago, would
> somebody benefit from it now". These are two different questions, and
> the second one is pure theoretical since we didn't and still haven't
> and I for one still don't understand how we could have it.

Not intentionally, but 5.2 was supported for the time-frame expected
from an LTS release. That may have given the impression that 5.3 will be
supported for 5 years too, and therefore hosts can upgrade within a year
or two after the release and still expect to get updates for the next
3-4 years.

One thing that I think would help drive adoption of newer versions is
EOL being very clearly stated. As it stands we don't know if 5.3 will
continue to be supported for the next 5 years, or if it will be EOL next
year. All we have to go on is what's happened in the past, and although
5.2's lifetime was an anomaly, it seems it's what people have come to
expect.

Cheers,
David

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

Re: [PHP-DEV] 5.4 moving forward

[David Muir]

On 06/06/11 07:27, Stas Malyshev wrote:
> Hi!
>
>> On 2011-06-05, Pierre Joye  wrote:
>>> On Sun, Jun 5, 2011 at 5:52 PM, Philip Olson 
>>> wrote:
> I'd to say that I'm very happy to finally see such discussions
> happening, let sort the base (99% is done by our existing RFC about
> release process, let adopt it already!) and move on with 5.4.


 This is a prime example of what we're talking about. Several have
 expressed a desire to follow an Ubuntu style of branching instead
 of the style proposed in said RFC. This is a core issue, so the RFC
 is certainly not ready to adopt.

 So does this require a new RFC, or do the RFC proposers feel this
 is a key concept?
>
> I think that this RFC does not contain Ubuntu-style LTS and it doesn't
> look like it's author(s) support it, so it should be some different
> point, which may be RFCed and voted on if we see substantial support
> for it.
>
> Speaking of which, I personally don't understand how LTS thing would
> work in PHP. Does it mean we'd decide out of the blue that some
> version would have extended support, upfront? Like, say, we now say
> "5.5 would have extended support"? Why would we want to do this, how
> would we know it? E.g., I understand if we had an option of extending
> support for some version post-factum, e.g., somewhere in 2015 we'd say
> "5.4 is so damn good and 5.5 has so many substantial changes that now
> we want 5.4 support to be extended another couple of years, and we
> feel we have people that are willing to do it". We could then talk on
> it and decide it, nothing prevents it. But as I understand LTS model
> means we'd have to decide it now, in 2011, and I don't see how it
> works. Could some of the proponents on this model explain it?

Theoretical benefits of LTS:
1. You have a version that is supported for an extended period of time.
Possibly useful for Ubuntu LTS releases and RHEL and other distros that
have a >3 year lifetime.
2. Keeps disruptive changes coming in on an LTS release. The goal is
that LTS is the polished result of the prior non-LTS releases.
3. Makes hosting companies feel safer offering an LTS release as it
means less disruption for their users.
4. Businesses like it because it's less work for them to upgrade every
3-5 years instead of every 6-18 months.

Those are the ones I can think of.
Although I appreciate the model with my OS, I don't think it would work
well on the application/component level.

Cheers,
David



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

Re: [PHP-DEV] 5.4 moving forward

[David Muir]

On 06/06/11 17:48, Tom Samplonius wrote:
>> Currently - A lot of ISP's are 'stuck' with PHP5.2 or earlier simply
>   I don't know if this is really the case.  I work in this industry, and most 
> of the small to mid hosting company's use cPanel or Plesk, and both include 
> PHP 5.3.  I've personally seen very few issues moving from older PHP 5.x 
> versions to PHP 5.3 (over about 2,000 sites, mainly small business sites).  
> And Plesk and cPanel do not appear to have perpetual licenses available 
> anymore, so ISPs that use these products are basically forced to update at 
> minimum once a year, when their license expires.  I guess they could still 
> technically skip upgrades, when they are prompted, but major updates are 
> available to them.
>
>   A real issue is RHEL (and CentOS).  RHEL locks the PHP major version to 
> whatever it is when they release their major version.  But they also maintain 
> their own patches, and release their own updates, which slightly makes up for 
> it.  So RHEL6 will have whatever PHP that was around, then, which I hope is 
> PHP 5.3 (I don't have any RHEL6 servers yet).  So RHEL6 will always be 
> PHP5.3.x based.
>
>   But the update pipeline is still a few months, so it is important that each 
> release is a good release.  Plus, don't worry about the Non-Updating ISP.  
> That is less of an issue that it once was.  
>
>
> Tom
>

Quite a few Australian hosts are on 5.2. One host that a client uses
runs off of H-Sphere (last release was on the 25th of May), where PHP
was upgraded to 5.2.17. Another host that I talked to had no ETA on when
they'd upgrade to 5.3.

>From what I've heard, part of the slow uptake is because a lot of
hosting companies run FreeBSD, and they can't upgrade to 5.3 unless they
either drop support for Zend Optimizer, or swap to a different platform.

Cheers,
David

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

Re: [PHP-DEV] Final version, RFC release process

[David Muir]

On 02/06/11 17:23, Pierre Joye wrote:
> On Thu, Jun 2, 2011 at 7:32 AM, Peter Lind  wrote:
>
>> Sorry for jumping into the thread, but I couldn't help noting that you seem
>> confused about the distro suggestion. I think Ubuntu was the example, and
>> there's nothing random at all about their release process. There are fixed
>> timelines and life cycles in Ubuntu - having less branches does not in any
>> way stop them from having a fixed release process and schedule.
> It is about "random" release being chosen as LTS. For many users, it
> will preventing migration until a given feature is part of a LTS
> release.
>
> Our proposal to have fixed life time and release cycles does not have
> this random effect and each x.y release is equally supported for the
> same duration. The amount of branches can be reduced easily and even
> if we may have many at one point, it will be only about sec fixes,
> that's really not a problem (a bit of automated tasked will help here
> too).
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>

Johannes said:

Every n-th "current" release will be a long term supported (LTS) release


That doesn't sound very random to me if n is constant.

That said, I'm not sure if an LTS is a good idea. One of the biggest
frustrations for me as a developer is hosts taking forever to upgrade to
newer versions of PHP. Most hosts I've seen are still on 5.2, and some
don't seem to have plans of upgrading to 5.3 any time soon. To me, an
LTS release would just make this situation worse, although the upside is
that at least we'd still be getting security fixes.

If however the LTS release lifetime is similar to the current y release
(x.y.z) then maybe it won't be so bad as it would grant earlier and
stable access to new features for those who have control over their php
installs, while retain a more long term supported release that hosts
would be happy with.

Cheers,
David

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

Re: [PHP-DEV] Porting PECL to userspace

[David Muir]

On 21/05/11 01:15, Larry Garfield wrote:
> Hi all.
>
> I'm working with a fellow developer on an experimental project.  There
> are some PECL modules that we want to try and use in an open source
> project where we cannot guarantee that PECL modules will be available,
> since it's intended for widespread distribution on both shared hosts
> and custom hosting. The thought we had was to do a user-space port of
> the PECL module to include in the project and rely on that.  Then if
> the PECL module is installed, we don't include the library (either via
> an extension_loaded() check or just relying on autoload) and the PECL
> implementation gets used instead.  Poof, nice speed boost.
>
> The questions I have are:
>
> 1) Is this even a viable approach?  It seems like it, but to my
> knowledge no one else has done this to any serious extent which makes
> me wonder if there's a reason the road less traveled is less traveled.

One reason would be because it requires fixing bugs and implementing
features twice, so it effectively doubles the required work.

>
> 2) Is anyone else doing this?  No sense doing it ourselves if someone
> else already is.

There's a Drupal extension that does something like this, but in reverse:
http://drupal.org/project/drupal_php_ext

Cheers,
David

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

Re: [PHP-DEV] Call non-static method staticly raise E_STRICT, but why call a static method instancely won't

[David Muir]

On 26/04/11 09:37, Ben Schmidt wrote:
>> Back in PHP4 it was the only way to "simulate" an static call, but
>> nowadays it really don't make sense at all.
>>
>> class Foo {
>>   static function toString(Bar $bar) {
>>return 'Foo::toString($bar)';
>>   }
>>   function toString() {
>>return '$this->toString()';
>>   }
>> }
>>
>> $foo = new Foo();
>> echo $foo->toString(); // instance
>> echo Foo::toString(); // class
>>
>> PHP will complain about the 2nd method (can't redefine function) but
>> for me
>> are 2 completely different methods.
>> I belive the current Object Model could be improved. isn't?
>
> I agree. Backward compatibility is the only reason to keep this. It's a
> pretty compelling reason, though. It's hard to know how to phase it out
> "non-invasively", too.
>
> Ben.
>
>

Why not just deprecate it, and throw a E_STRICT warning? That's how
we're dealing with all other future BC breaks.

David

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

Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator

[David Muir]

On 21/04/11 08:56, Arpad Ray wrote:
> On Thu, Apr 14, 2011 at 3:05 PM, Hannes Landeholm  wrote:
>> Some suggested that the ternary if comparison should suppress the notice
>> automatically. This would break existing code and also be confusing since
>> people expect a ternary if and normal if to work the same way.
>>
>> Some suggested ?? as an array access operator that suppresses the notice and
>> has 3 variants: A: nothing specified - uses null as default, B: has default
>> specified, C: returns X if index exists or Y if index doesn't exist. This
>> effectively solves the code duplication problem and is a shortcut for saying
>> "the array index may or may not exist".
>>
>> One person said that the relation between ? and ?? and == and === would make
>> the operator non-intuitive. Other people disagreed and claimed the opposite.
>>
>> So basically the discussion now is what exact characters that should be used
>> to represent this operator? I really hope we can get this implemented
>> quickly... I worked with $_POST yesterday and I could really use that ??
>> operator.
> Hi,
>
> I must say that the prospect of yet more new syntax is scary. It
> really looks like Perl, and I wouldn't have the slightest clue what it
> meant if I'd missed the release notes.
>
> I've pined for something like coalesce($_GET['foo'], $defaults['foo'],
> 42) for years, and I think that style is far more in keeping with the
> PHP ethos, and far more readily understandable than this suggested new
> syntax.
>
> If I've missed some argument against this then please correct me.
>
> Regards,
>
> Arpad
>

What does coalesce() do?
If I'm guessing correctly, would  proposal #2 that Rune Kaagaard put up
solve that for you?
https://gist.github.com/909711

Cheers,
David

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