Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

2017-09-14 Thread Daniel Morris 
On Thu, 14 Sep 2017, at 02:48 PM, Tony Marston wrote: 
> Because the English-speaking world invented both computers and the
> languages used to program them.

It was a German that invented binary, so my suggestion is to devolve all
future decisions to the Germans.

On Thu, 14 Sep 2017, at 02:36 PM, Tony Marston wrote:
> The number of people in the world who use character sets which do
> not have this problem far outnumber those who use character sets
> which do have this problem. People without this problem far
> outnumber the others, so it would not be a good idea to
> inconvenience the many just to satisfy the few.

You are nearly always a minority opinion, the irony of you writing this
whilst at the same time asking the world to slow down so that your
stubborn fourteen year old framework can catch up beggars belief.

--
Daniel Morris
dan...@honestempire.com


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

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

2017-09-14 Thread Daniel Morris 
On Thu, 14 Sep 2017, at 10:20 AM, Tony Marston wrote:
> If the first programming languages in the first computers were case 
> insensitive, then that should be the standard. Those who introduced case 
> sensitive languages at a later date should be forced to justify that 
> decision.

If the first vehicles had two wheels, then that should be the standard.
Those who introduced cars with four wheels should be forced to justify
that decision.

If the first television was black and white, then that should be the
standard. Those who introduced televisions with colour should be forced
to justify that decision.

If the first living organisms had single cells, then that should be the
standard. Evolution should be forced to justify the decision to move to
multiple cells.

If light exists as a wave, then that should be the standard. When an
observer collapses the wave function, then they should be forced to
justify that decision.

--
Daniel Morris
dan...@honestempire.com

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

[PHP-DEV] Improvements to the PHP test suite

2016-12-07 Thread Daniel Morris 
Since around 2011 there's been an item on the ideas list on php.net:
(https://wiki.php.net/ideas/runtests) to improve the PHP test suite, I
was thinking as one of my first major contributions I would like to take
a stab at this, there's no upwards of 11,000 tests as compared to the
8000 or so when the idea was originally proposed, and it looks like some
work was initially started but it's likely now outdated and I think it
would be better to start from a blank sheet.

Would this be of interest for 7.2? My main goals would be to maintain
backwards compatibility with all the existing tests, allow it to be run
on the existing CI infrastructure, be cross-platform, and for it to be
part of the internals repository, with initial work being done outside
of the repository with a view to merging for the 7.2 release.

A question I have is that is it better that it continues to be a written
in PHP, or is the internals team open to perhaps writing the test runner
in another language, keeping the same flags that run-tests.php currently
uses, but choosing a language which could improve the performance of the
suite.

Thoughts appreciated always.
Daniel Morris.

--
Daniel Morris
dan...@honestempire.com

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

Re: [PHP-DEV] Countable Type Hint

2016-11-23 Thread Daniel Morris 
If somehow the Countable type-hint can absorb primitives, another
example I would like to see with similar behaviour is Serializable, the
type-hint currently allows classes implementing the Serializable
interface to be serialized, but primitives (which are serializeable) can
not be serialized when passed to the same method or function. I'm sure
there are more edge-cases like this also...

--
Daniel Morris
dan...@honestempire.com

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

Re: [PHP-DEV] [RFC] Parameter No Type Variance

2016-11-21 Thread Daniel Morris 
What happens if the method signature is defined within an interface? I
would consider that method signature a contract and one that should not
be able to be overwritten.

--
Daniel Morris
dan...@honestempire.com

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

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

2016-11-20 Thread Daniel Morris 
On Sun, 20 Nov 2016, at 10:42 PM, Derick Rethans wrote:
> __autoload is one of group (2). I think this is used a lot, and would 
> *not* want to deprecate this until PHP 8.

Agreed, I still think this is used widely, it would be fine to have it
throw an E_DEPRECATED in 7.2 and removed in 8.0. Upgrading to not use
__autoload would be trivial.

On Sun, 20 Nov 2016, at 10:42 PM, Derick Rethans wrote:
> I also do not see why (binary) should be removed, as it fits in category 
> 3.

Whilst (binary) may be harmless, it's also pointless, since it's just an
alias for (string) – I don't think it has wide-enough usage to worry
about deprecating it sooner rather than later.

--
Daniel Morris
dan...@honestempire.com


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

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

2016-11-19 Thread Daniel Morris 
If every language is the same then what's the point of different
languages? People use Scala and PHP for different things, if your
developers are considering walking for that reason then they should
evaluate whether they want to build things or whether they want to be
trendy. Good (heck, great) developers will put to best use the tools
they have available. Migrate to Go, and watch every one of them
eventually complain about how they're having to check for err against
every function call since functions return multiple values, have them
migrate to Scala and watch their frustration as the time to change
visibility is dropped significantly; if you've hired developers that
care more about trends than your application then you've hired the wrong
developers.

--
Daniel Morris
dan...@honestempire.com

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

Re: [PHP-DEV] Declare directive to change engine version basis

2016-11-18 Thread Daniel Morris 
I think this would create a lot of additional work for internals
maintainers, and the current system of throwing an E_DEPRECATED already
allows for developers to prepare their applications for future versions
by turning on error reporting and checking their logs.

--
Daniel Morris
dan...@honestempire.com

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

Re: [PHP-DEV] Type locked variables

2016-11-15 Thread Daniel Morris 
On Tue, 15 Nov 2016, at 11:44 PM, Michael Morris wrote:
> Note this would simplify one of the use cases of setters - insuring the
> class member is of a valid type.

It's already possible to ensure within a setter that the variable is of
a specified type, you only need to make the instance variable private
and scalar type hint the method arguments within the setter (provided
that strict_types is set), I think this would be more likely to lead to
code littered with calls to unset rather than to provide much benefit,
and as far as I'm aware, there's no real performance benefit that can be
gained from this as of yet since the variables will still be a zval
internally.

--
Daniel Morris
dan...@honestempire.com

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

Re: [PHP-DEV] Intention to move mcrypt to PECL

2016-10-21 Thread Daniel Morris 
On Thu, 6 Oct 2016, at 11:41 AM, Lester Caine wrote:
> It is already an established component in PHP and while it's use has
> been discouraged for a long time, simply switching it off will break a
> lot of legacy applications.

How many applications that are not following standard security
guidelines are not following basic security principles? It doesn't
matter if it's an established component, a vulnerability is a
vulnerability. BC shouldn't matter; especially for those who are not
willing to patch their applications to use the latest information we
have available to us.

You either keep up with changes; or you don't. New majors, and even
minors (if we're ignoring semantic versioning) should be able to change
something, it should be up to the maintainers of an application to
decide whether it's time to upgrade or not, internals shouldn't manage
that for you.

If you're using Composer, you can lock your dependencies to prevent your
application from breaking. If you're up to date with the latest
information, you can choose to evolve.

Mcrypt, now (I think) belongs in PECL, I will be looking at (a major)
code repository over the next few weeks and looking to provide a simple
upgrade path.

DM

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

Re: [PHP-DEV] [RFC] OpenSSL BigNum support

2016-10-18 Thread Daniel Morris 
And sorry for the  spam (this should have been mentioned in the last
email), as far as I can tell, there is no-way to say "I want a either a
signed or unsigned integer with an N bits", I've come across this
recently whilst trying to implement Murmur3 (128-bit) in PHP, I can
of-course binary AND into
0b111 (e.g.
$x & 0b11...) and it will yield result of 9,223,372,036,854,775,807
((2^63)- 1 (PHP_INT_MAX)) but adding an additional 1 (radix 10) will
yield a double(9.2233720368548E+18) and it's at that point it becomes
incredibly difficult to work with to work with natural numbers.

(Unrelated to Sara's RFC, just a thought I'd mention incase someone is
interested...)

I personally think this RFC is fine despite the existing libraries that
do similar (BCMath and GMP), it's more of an interface to the lower
layer (and OpenSSL specific) rather than an implementation. We're just
keeping up with existing implementations.

Sara, I'm happy to implement additional tests and look at fast ZPP for
methods tomorrow if you're too busy and think this is going somewhere...

DM

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

Re: [PHP-DEV] [RFC] OpenSSL BigNum support

2016-10-18 Thread Daniel Morris 
On Tue, 18 Oct 2016, at 09:22 AM, Nikita Popov wrote:
> On Tue, Oct 18, 2016 at 3:35 AM, Sara Golemon  wrote:
> 
> > As it says on the tin: Wrap the BN (BigNumber) library in OpenSSL.

Why do we need GMP when we have BCMath? GMP is faster (from what I've
seen so far from various tests and blog posts) – whilst they do similar
ops, they are chosen for specific reasons, all this does is expose the
existing interfaces for arbitrary precision arithmetic made available
with the OpenSSL layer, and I think anyone implementing them would want
the API there, it requires minimal maintenance. Sara, I think the best
route is too match the method names within OpenSSL, it will avoid some
initial confusion, unless people want to change libraries, but I think
that is probably less likely.

DM

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

Re: [PHP-DEV] [RFC] OpenSSL BigNum support

2016-10-17 Thread Daniel Morris 
I realise this is only exposing functionality already available with
OpenSSL but is it worth adding tests that cover some arbitrary precision
arithmetic? The tests at the moment cover integers that PHP already
handles natively without requiring either GMP or BCMath.

There's usage of zend_parse_parameters_throw, is it possible to change
this to use the fast parameter parsing API within PHP_METHOD or is that
reserved only for PHP_FUNCTION at the moment?

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

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

2016-09-08 Thread Daniel Morris 
On Thu, 8 Sep 2016, at 05:21 PM, Lester Caine wrote:
> Another couple of hours wasted, but I understand where things are now,
> and basically the simple fact is that composer global mode is nothing of
> the sort. The PHP_CodeSniffer composer install does not work and I
> understand NOW why the Smarty one also failed. I was expecting the files
> to be available to the nginx server but they were hidden away in my home
> directory. I still have to work out just how to reset things to move the
> code to /usr/shared/phpx/composer to parallel the PEAR version.

PHP_CodeSniffer should not be run by the web server, it's a command-line
development tool, it should be run by the developer, or as part of a
build (e.g. Travis, Ant, etcetera)

Composer allows you to separate the dependencies, for example, in your
case; Smarty is a production and development dependency, and PHPCS is a
development dependency only, your `composer.json` should have  something
similar to the following:

```
{
"require": {
"smarty/smarty": "~3.1"
},
"require-dev": {
"squizlabs/php_codesniffer": "^2.7"
}
}
```

That way, anytime someone runs `composer install` from your project
directory (or wherever the composer.json dependency is contained), it
will create a `vendor` directory with your dependencies, if you haven't
used the `--no-dev` flag when running `composer install`, you will have
PHPCS ready and waiting in `vendor/bin`, others will have the same
toolset you're using, so discrepancies between environments will have
been reduced.

--
Daniel Morris
dan...@honestempire.com

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

Re: [PHP-DEV] Single Point of Entry Apps.

2016-09-08 Thread Daniel Morris 
On Mon, 5 Sep 2016, at 06:47 PM, Andrea Faulds wrote:
> Hi Michael,
> 
> Have you looked into PHP application servers, where the PHP code itself 
> acts as the web (or FastCGI) server, and so can keep the whole framework 
> etc. initialised in memory between requests?
> 
> This is how other (non-PHP) web stacks avoid “installing the application 
> on every single request”, and it can also be applied to PHP, it's just 
> not very common.
> 
> One example is Aerys (https://github.com/amphp/aerys), but it's hardly 
> the first or the last example of this approach.
> 
> Thanks.

I'm sure I remember reading somewhere that fabpot was working on one in
Golang? Something similar to Unicorn or Puma from the Ruby ecosystem
would be a boon.

--
Daniel Morris
dan...@honestempire.com

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

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

2016-09-08 Thread Daniel Morris 
On Thu, 8 Sep 2016, at 01:13 PM, Lester Caine wrote:
> That is the chicken ... if you ARE already composer user then it will
> make some sense, but pear gives a phpcs -h which works out of the box.
> ./vendor/bin/phpcs -h does not sound right as an alternative? And I
> would expect different installations of composer will affect that
> installation?

If I run `composer global require "squizlabs/php_codesniffer=*"`, I get:

```
Changed current directory to /Users/dmorris/.composer
./composer.json has been created
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Installing squizlabs/php_codesniffer (2.7.0)
Downloading: 100% 

Writing lock file
Generating autoload files
```

Composer has indicated in its output where the executables have been
downloaded to, I could just add `~/.composer/vendor/bin` to my `$PATH`
and then it essentially works the same way as PEAR. I generally prefer
to have project specific dependencies though, as do most others, I
believe.

This thread has turned into a Composer help/support thread now, which
I'm sure is not the original intention. I'd like to see the deprecation
of PEAR, it served many well for a long time, but Composer has made life
much easier for the majority.

--
Daniel Morris
dan...@honestempire.com

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

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

2016-09-08 Thread Daniel Morris 
On Thu, 8 Sep 2016, at 11:35 AM, Lester Caine wrote:
> I know this is a problem for PHP_CodeSniffer to rework it's
> documentation, but it is a chicken and egg. PEAR provides a framework to
> store things like PHP_CodeSniffer in the common area away from our web
> folders. A similar set of guidelines to install via composer are needed
> as an alternative and those are not currently in place? The point I
> think here is that removing the built in installer for one off users is
> what is being discussed and that should only happen if there is an
> alternative. While composer can be used as an alternative, is it really
> the best alternative for a simple built in loader?

Most people develop and host in different environments, when installing
a package via composer for development purposes, you simply add it to
the require-dev section of composer.json and run: "composer install",
when it's time to deploy to the production environment, do "composer
install --no-dev" and it will not install development dependencies, so
PHP_CodeSniffer will not exist in any of your web folders. It wouldn't
even matter for most if they didn't skip the development dependencies in
production, since the vendor directory should live outside of the web
root.

Most packages that are actively maintained would have moved to
Composer/Packagist by now, those that are still requiring installation
via PEAR are probably not updated as frequently, and likely are still
using styles and patterns from the PHP 4 era.

--
Daniel Morris
dan...@honestempire.com

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

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

2016-09-08 Thread Daniel Morris 
On Thu, 8 Sep 2016, at 08:43 AM, Tony Marston wrote:
> Perhaps users could be prevented from making such basic mistakes if they
> had 
> a 21st century web interface instead of the archaic command line.

Why don't you make one?

--
Daniel Morris
dan...@honestempire.com

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

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

2016-09-08 Thread Daniel Morris 
On Thu, 8 Sep 2016, at 09:07 AM, Lester Caine wrote:
> I've just been through an exercise to give PHP_CodeSniffer a go on my
> code base. I've not worried too much about that in the past since
> Eclipse in general flags style problems as well as simple errors. This
> is a package that SUSE does not support, so the current install path is
> just PEAR. I don't see packages like this as a library that my sites
> use. It is a stand alone tool ( and a command line one at that :) ) so
> how would loading that be managed if PEAR is not available?

PHP_CodeSniffer is already compatible with Composer, and Composer has
the ability to specify dependencies, and dependencies intended for
development. After running composer install you can execute
`vendor/bin/phpcs`, and if you were working collaboratively,
collaborators would all have the same toolset that you have.

--
Daniel Morris
dan...@honestempire.com

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

Re: [PHP-DEV] [RFC] orphan extensions cleanup

2016-08-18 Thread Daniel Morris 
On Thu, 18 Aug 2016, at 06:58 AM, Lester Caine wrote:
> Can you justify that statement!

A quick comparison on Google Trends will show this, since the beginning
of 2013 Couchbase has been more popular, GitHub also has more PHP
projects for Couchbase than Interbase.

On Thu, 18 Aug 2016, at 06:58 AM, Lester Caine wrote:
> I'd add that PHP5.2/3 is more widely used that PHP7 ...

Interbase will continue to exist 5.{2,3,4,5,6}, and as you're not really
keen to upgrade (30% of your clients are still on 5.2, despite it
reaching end of life over five years ago, and 5.3 reached end of life 2
years ago), removing it from PHP7 shouldn't cause you too much concern,
since (based on your current pace of upgrading) you won't be switching
to PHP7 until 2024.

--
Daniel Morris
dan...@honestempire.com

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

Re: [PHP-DEV] [RFC] orphan extensions cleanup

2016-08-17 Thread Daniel Morris 
Interbase would be much better existing in PECL, since there is no
interest in supporting it by internals. Couchbase and Cassandra both
exist in PECL and both of those are likely more widely used by the
community than Interbase, and both are also still maintained (with
commits as recently as this month.)

--
Daniel Morris
dan...@honestempire.com

On Thu, 18 Aug 2016, at 12:32 AM, Kalle Sommer Nielsen wrote:
> Hi
> 
> 2016-08-15 7:53 GMT+02:00 Stanislav Malyshev <smalys...@gmail.com>:
> > Please comment and discuss!
> 
> What about adding the following:
> ext/dba
> ext/interbase
> ext/recode
> 
> I tried to look for anything recode, but it seems far gone, although I
> did not do an extensive search for it. I'm unsure about the usage
> though, but I doubt it can be much, considering we got iconv.
> 
> As for DBA, this extension have not really seen any major updates or
> anything since 2009 when the Tokyo Cabinet support was added (PHP
> 5.3), is this still used largely or?
> 
> Interbase have already been discussed a fair bit in this thread, and
> it does not seem Leister is going to contribute despite being the only
> one around interested in this one, at least here on internals@.
> 
> -- 
> regards,
> 
> Kalle Sommer Nielsen
> ka...@php.net
> 
> -- 
> 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