[PHP-DEV] PHP Modules

[Michael Morris]

This will be long. I've read over the Future Stability thread and taken it
in, and decided to mull over an idea I touched on over a decade ago that I
think might help. Also, in the interceding years the JavaScript community
has overcome a compatibility issue using this technique, so we might do the
same.

The crux of the stability problem is the need to update functions without
introducing a BC break. Adding in new features without removing old ones
also makes it confusing to incoming programmers as to what to use.

I propose PHP Modules to hold new features. The existing namespace and
functions would be left alone. Existing files would also not be affected -
the behavior of PHP modules would be entirely opt in.

They would work similar JavaScript modules - they would use the import
keyword and the include, require, include_once and require_once directives
would pitch an error if used in a PHP module.  PHP Modules also would not
parse as templates at all - no opening 

Re: [PHP-DEV] Re: Removal of ${} string interpolation in PHP 9

[Michael Morris]

I can understand removing this feature since it is a bit confusing, but are
there any plans to replace it - say with the template literal syntax of
JavaScript? For those needing to refactor having something to switch to
would be preferable than having the feature dropped.  Or does PHP have some
goofy use for backtick that would prevent this from happening?

On Mon, May 23, 2022 at 6:59 AM Robert Landers 
wrote:

> On Mon, May 23, 2022 at 12:46 AM Mark Randall  wrote:
> >
> > On 20/05/2022 10:05, Ilija Tovilo wrote:
> > > So unless there are concerns I will amend that in the RFC.
> >
> > Erroring it out makes sense to me.
> >
> > As we don't include any target version specification in PHP files, the
> > safest bet it so prevent the silent change from potentially leaking
> > through the introduction of a parser error.
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
>
>
> Ilija,
>
> It might be a good idea to do up another RFC to make it easy to vote.
> I suspect it won't be unanimous.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

[Michael Morris]

On Wed, Mar 2, 2022 at 3:31 AM Victor Bolshov  wrote:

> Hello internals.
>
> In these dark days for humanity, we as people of civilization, people
> of sanity, kind and caring people with children and families - we have
> to speak up, loud and clear, in support for Ukraine. To stop Russian
> aggression.
>
> I suggest to add Ukranian flag and a supportive anti-war disclaimer to
> the header of php.net website.
>
> Why is this important? There are a lot of PHP developers in Russia. A
> lot of them, sadly, have been brainwashed by Putin's propaganda. They
> still must have a lot of respect to PHP authors and creators. Seeing
> that these people, who have their respect, are against the war and for
> the freedom of Ukraine, might have an impact.
>
> This is not the time to "stay away from politics", we are experiencing
> an attack on humanity itself. Take example from
>  and their clear statement.
>
> Say NO to war!
>

This original post has been met with some controversy. I don't know how
much my voice counts, but I will say this.

The occasions in history where one side is utterly and completely in the
wrong are rare, but they do occur. Russia had no right to invade - period.
Attempts on this list have been made to justify Russia's actions, but they
are logically tortured as the Nazi justifications for invading Poland or
Soviet Russia.

Speaking of the Nazis, even Hitler didn't stoop so low as to send in troops
utterly unprepared for what they were about to face while lying to them
that they'd be lauded as heroes. Neither did Stalin.  Putin has done that.

Now, you can try to justify certain things. You can try to justify Putin's
War, but you will never convince anyone of your position - you can only
succeed in proving yourself to be evil. Evil is the complete absence of
compassion for the suffering of others, and only someone who is evil can
advocate for Putin's War or try to justify it in any measure.

Evil is a powerful word - one I do not use lightly. When one side calls
another evil they say that there can be no more dialog, no more compromise,
no more cooperation. The only correct response to evil is opposition.

Re: [PHP-DEV] RFC [Discussion]: Redacting parameters in back traces

[Michael Morris]

On Mon, Jan 10, 2022 at 8:05 AM Tim Düsterhus, WoltLab GmbH <
duester...@woltlab.com> wrote:

> Hi Internals!
>
> this is a follow-up for my "Pre-RFC" email from last Friday, January, 7th.
>
> Christoph Becker granted me RFC editing permissions and I've now written
> up our proposal as a proper RFC:
>
> https://wiki.php.net/rfc/redact_parameters_in_back_traces
>
> I recommend also taking a look at my previous email:
>
> https://externals.io/message/116847
>
> It contains some additional context that did not really fit within the
> language of a "neutral" RFC that will remain as the permanent record.
>
> - As indicated within the RFC and my previous email we still need a more
> experienced developer for the final implementation, as I have next to no
> experience with PHP's implementation.
>
> Specifically adding this attribute to existing functions is not clear to
> me. It is probably required to update the stub parser/generator to add
> support for attributes? If someone creates an example implementation for
> one function, I'll likely be able to apply this to other functions myself.
> - The RFC Impact to Opcache is not clear to me. I don't believe there is
> any, but I am not sure. So if someone knows, I'm happy to update that
> section.
>
>
>
If someone can inject a debug_backtrace into your code and get it executed
you have bigger problems than a parameter being exposed. And if you
configure your prod servers to be all chatty Kathy to the world on error,
you need to learn how to do better. A change to the language is not in
order here.

Re: [PHP-DEV] RFC: Stop to automatically cast numeric-string to int when using them as array-key

[Michael Morris]

On Sat, Jan 1, 2022 at 10:47 PM Kirill Nesmeyanov  wrote:

>
> >Суббота, 1 января 2022, 17:41 +03:00 от Rowan Tommins <
> rowan.coll...@gmail.com>:
> >
> >On 31/12/2021 00:21, Kirill Nesmeyanov wrote:
> >> I support this behavior fix because in its current form, due to a
> similar problem (almost?), all PSR-7 implementations contain bugs that
> violate RFC7230 (section 3.2:
> https://datatracker.ietf.org/doc/html/rfc7230#section-3.2 ). Thus,
> physically, by the standard, all headers can have the name "0" (like «0:
> value»), but when stored inside implementations, it is converted to a
> string and a problem arises ($message->getHeaders() //
> returns array instead of array).
> >
> >You appear to be technically correct - the RFC defines a header name
> >only as "token", which implies the following would all be valid HTTP
> >headers:
> >
> >42: The Answer
> >!: Bang
> >^_^: Surprised
> >
> >In practice, it would be a bad idea to use any of these.
> >
> >Every single one of the field names registered with IANA [1] starts with
> >a letter, and proceeds with only letters, digits, and hyphen ('-'). [The
> >exception is "*", listed there as "reserved" to specifically prevent its
> >use conflicting with the wild-card value in "Vary" lists.]
> >
> >I'm actually surprised this definition hasn't been updated with
> >interoperability advice in recent revisions of the standard. I did find
> >this general advice for internet message headers in RFC 3864 [2]:
> >
> > > Thus, for maximum flexibility, header field names SHOULD further be
> > >  restricted to just letters, digits, hyphen ('-') and underscore ('_')
> > >  characters, with the first character being a letter or underscore.
> >
> >The additional restriction on underscore ('_') in HTTP arises from CGI,
> >which maps headers to environment variables. For instance, Apache httpd
> >silently drops headers with anything other than letters, digits, and
> >hyphen [3] to avoid security issues caused by environment manipulation.
> >
> >If I was developing a PSR-7 or similar library, I would be inclined to
> >drop any header composed only of digits, and issue a diagnostic warning,
> >so that it wouldn't escalate to a type error later. It certainly doesn't
> >seem reasonable to change the entire language to work around that
> >inconvenience.
> >
> >[1]  https://www.iana.org/assignments/http-fields/http-fields.xhtml
> >[2]  https://datatracker.ietf.org/doc/html/rfc3864#section-4.1
> >[3]  https://httpd.apache.org/docs/trunk/env.html#setting
> >
> >Regards,
> >
> >--
> >Rowan Tommins
> >[IMSoP]
> >
> >--
> >PHP Internals - PHP Runtime Development Mailing List
> >To unsubscribe, visit:  https://www.php.net/unsub.php
>
> I just gave an example of what at the moment can cause an exception in any
> application that is based on the PSR. It is enough to send the header "0:
> Farewell to the server". In some cases (for example, as is the case with
> RoadRunner) - this can cause a physical stop and restart of the server.
>
> Just in case, I will repeat my thesis: I cannot imagine that anyone is
> using this functionality consciously and that it is part of the real logic
> of the application.


You don't have a lot of experience with legacy code then. PHP, particularly
old PHP (like 4, 5.1 era) was used by a lot of idiots.

I was one of those idiots (Perhaps I still am an idiot - jury is
deliberating on that but I digress).

Snark aside though, PHP has more than its fair share of self taught
programmers (again, not trying to be insulting as I am one myself), and
they do things with the code that veterans and formally trained programmers
would never think to try, let alone implement.

I guarantee fixing how key handling is done will break something - either
in the form of code exploiting the weird behavior, or code that is guarding
against the weird behavior; not to mention any tests that might be written
- though amateurs rarely write test code (again, speaking from past
experience I've grown beyond).



> And fixing this behavior, I believe, will automatically fix many libraries
> (not necessarily PSR) that do not take this behavior into account.
>
>

And blow up who knows how many old code bases - many of which don't have
unit test suites to discover if there is a break ahead of time.  This is
the sort of BC break that would cause a cliff of users unable to migrate to
the major version that implements it.  A Python 2 vs. 3 style of break.

Even with that all said it may indeed be worth fixing - but this will
require the same sort of kid gloves approach removing register globals had
(for the newer folks, there was a time when $_REQUEST["var"] would auto
populate $var with lovely security snarls).  IIRC PHP 3 had register
globals always on, 4 created a config toggle to turn them off, and PHP 5.0
turned that toggle off by default, finally PHP 5.3 (6 without unicode more
or less) removed support for register globals entirely (My memory could be
off - it's in the changelogs for the 

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Michael Morris]

If this list has ever had a "bike shed" issue, this would be it.

https://en.wikipedia.org/wiki/Law_of_triviality



On Tue, May 11, 2021 at 10:01 AM Mel Dafert  wrote:

> >> This plaintext reply sent via Gmail web client. I don't know what Mel is
> >> talking about either.
> >>
> >>
> >Gmail's web client is what I normally use, and have never had an issue
> with
> >it.
>
> Sorry for being unclear - I meant the Gmail android app.
>
> If the app does have an option for plaintext emails, I am not able to find
> it.
> If it does, that might also be useful to document somewhere, so people
> like me can actually use it :)
>
> Even then, I also don't think it offers an option to bottom-post by
> default - which K-9 and Thunderbird do.
> (No idea about the Gmail web client - I don't use it regularly.)
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Inline conditional that returns null if falsy

[Michael Morris]

Javascript has this now though support isn't widespread.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining

The most similar way to do it in PHP would be ?->

On Fri, Feb 12, 2021 at 1:46 PM Ben Ramsey  wrote:

> > The => is just a suggestion, other options using existing keywords is:
> > return expr() then output();
> > return expr(): output();
> >
> > I do not know if other languages support something like that.
>
>
> I think it might be a good idea to check other languages to see if they
> support something like this. We could use their examples as points of
> reference for discussing whether to include this functionality in PHP.
>
> Cheers,
> Ben
>
>
>

Re: [PHP-DEV] Abusive emails was: silly question : what is more secure at the moment, php7, php8, or plain .sh shell scripts?

[Michael Morris]

I so rarely post to the list that when I got this tripe I figured the
problem had to be pretty widespread which is why I posted a reply to the
list.

On Thu, Jan 14, 2021 at 3:05 PM Stanislav Malyshev 
wrote:

> Hi!
>
> > He's also apparently has been emailing people individually off-list
> > according to: https://news-web.php.net/php.internals/112833
> >
> > If anyone else receives unpleasant emails from him (or from anyone
> > else), please either:
> >
> > * forward them to the list for all to see.
> > * forward them to myself, if you'd prefer to not have it dealt with in
> public.
>
> I have received some less-than-polite emails from Reindl Harald, but I
> don't think I'll bother finding them and forwarding them, because I
> think there's no point (unless somebody can convince me there is). I am
> a big boy and I can deal with it (mostly by ignoring the person being
> rude, email is excellent this way - I don't ever have to read a message
> from somebody who I know is not able to behave in a civilized way). And
> if it were about me that would be the end of it, however, this seems to
> be widespread both in time and in number of people affected, so I think
> it is about time to take action and remain without further contributions
> from Harald in the future.
> I am the last person to propose silencing somebody for expressing
> unpopular thoughts or ideas, but there's a difference between thinking
> outside the box, right or wrong, and just being rude. The latter helps
> no one.
>
> Thanks,
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] silly question : what is more secure at the moment, php7, php8, or plain .sh shell scripts?

[Michael Morris]

I didn't say "best practice."  I said "common practice". It has it's time
and place, but it's beyond the scope of this thread and outside the purpose
of this listserv.

Your abuse of me is also a direct violation of the the TOS of this list. I
formally request the moderators issue a ban to you, and I will be blocking
your email address.

On Sun, Jan 10, 2021, 9:30 AM Reindl Harald (privat) 
wrote:

>
>
> Am 10.01.21 um 16:11 schrieb Michael Morris:
> > Owning and managing the silicon directly isn't
> > advised anymore and hasn't been common practice for at least a decade
>
> what a silly bullshit
>
> just because you ar enot capable to setup and properly maintain a
> webserver it's not "best practice" to outsource it into the cloud and
> hope everything is magically fine
>
> it's likely the best answer for a clueless guy like the OP but not a
> "best practice" in general
>

Re: [PHP-DEV] silly question : what is more secure at the moment, php7, php8, or plain .sh shell scripts?

[Michael Morris]

The most secure setup possible is to use a static site generator and upload
it's output to a static server with no server side parsing enabled. In
my opinion Hugo is the best of these which is written in Go, and that's
it's largest drawback - written in a language I'm not too familiar with.
Jigsaw is a PHP implementation of the same concept, but I haven't had a
chance to try it out. There are a lot of sites out there using WordPress
and Drupal which are so small and so infrequently uploaded that, frankly,
the owners could do themselves a huge favor by switching over.

If your problem scope still requires server side scripting you'd be better
served leaving the server security to the experts.  Look into AWS,
Microsoft's Azure at a start, and there are also more PHP centric providers
like Aquina or Pantheon.  Owning and managing the silicon directly isn't
advised anymore and hasn't been common practice for at least a decade.

On Sun, Jan 10, 2021 at 2:10 AM Rene Veerman <
rene.veerman.netherla...@gmail.com> wrote:

> hi.
>
> i run a website which i want to harden against hacking by 3rd parties.
>
> i wrote this website back in 2002-2010, and then built apps on top of the
> base code.
>
> now i want to upgrade the entire thing to the latest css3 standards and
> also include anti-hacking measures, because at one point i got kicked off
> the internet by my ISP because they detected the thing had indeed been
> hacked, and someone installed phishing software on my site.
>
> i want to employ cron jobs that run regularly, to do checksum testing of
> vital parts of my operating system.
>
> ideally, i could have a script run indefinitely or every 2 seconds, as
> root, from cron, to test for changes to my filesystem (well, the part that
> is governed by Directory section in
> /etc/apache2/sites-enabled/001-localhost.conf) and vital OS config files.
> but i do wonder if this is going to wear out the SSD where the OS and
> webserver files are stored on.
> and i wonder if i should be writing this script as some sort of shell
> script (bash? /bin/sh? i dunno (i run ubuntu 20.04)), or if i could be
> using the convenient php for it.
>
> and i would like to know if as far as exploits go, it's better to stay
> (currently) on php7.4, or move my entire setup to php8.
>
> thanks for your attention and any help you might provide me. :)
>

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

[Michael Morris]

This sort of thing would be useful. Drupal and Symfony both mark methods in
their libraries that aren't supposed to be used externally, but people do
anyway and then they get mad at the framework developers when they decide
to rearrange what are supposed to be internal methods.

I wrote a userland assertion to enforce just this sort of thing - enforcing
Java's notion of protected on methods otherwise marked as public. It worked
by looking up the caller in the debug_backtrace and checking to see if the
namespaces matched. To keep the impact of this check minimal I used
assert() for the check so that it wouldn't bog down production (where,
presumably, no new code would be written).

Now, the above worked, but you could hack in by lying about your namespace
in your file declaration.  Since, at the end of the day, PHP's notion of
namespace is entirely a string replace with no other enforcement there's no
way I can see of changing this short of fundamentally changing how PHP
handles namespaces.  But I wonder if that should be bothered with since
someone would have to go considerably out of their way to make a call to a
method they weren't supposed to, and they only have themselves to blame if
this sort of solution becomes unstable.

Next thing to consider - we have the problem of having already used the
protected keyword in PHP, and honestly I prefer PHP's interpretation of the
word. However, PHP doesn't have class scope at this time, so one
possibility is to allow class scope to set a default scope of the unscoped
methods and members of the class. So...

public class A {
  function foo () {} // Callable from anywhere.
}

protected class B {
  function foo () {} // Callable only from current namespace, or any child
namespace.
  public function moo() {} // Callable anywhere. In effect the method
specific scope overrides class scope.
}

private class C {
  function foo () {} // Callable only from the same namespace, no children
can access. This includes a extending child function from another namespace
  protected function moo () {} // Callable from any child class regardless
of that child's namespace.
}

That could work. Feel free to poke holes in this - I'm sure I've missed
something.

On Sat, Sep 19, 2020 at 7:43 AM Rowan Tommins 
wrote:

> On 17/09/2020 13:28, Olle Härstedt wrote:
> > We have public, protected and private. Since PHP has no module system, we
> > have no qualifier to mark a class property as "private for this module".
> > One solution to this could be to add a new qualifier "internal", to make
> > properties public within the current namespace.
>
>
> As well as the implementation details of doing this at run-time (which
> is where PHP does all its access checks right now) the mapping of
> "namespace" to "module" is not necessarily the most useful one.
>
> For instance, if you define an "internal" property in a class called
> Acme\Frobulator\Handlers\TextFile\Format\CSV, it would be accessible in
> other classes in namespace Acme\Frobulator\Handlers\TextFile\Format\ and
> possibly also sub-namespaces like
> Acme\Frobulator\Handlers\TextFile\Format\Exceptions, but not in other
> parts of Acme\Frobulator\Handlers\TextFile or Acme\Frobulator as a whole.
>
> If Acme\Frobulator was the root of the Composer package, the only way to
> make something internal to the package as a whole would be to flatten
> everything into that root namespace, like
> Acme\Frobulator\Handler_TextFile_Format_CSV
>
> That leads me to think that if we do want "module"-level features - be
> it internal classes, internal properties, or module-level declare()
> settings - we need a way for the user to define that separately from the
> fully-qualified namespace.
>
> Regards,
>
> --
> Rowan Tommins (né Collins)
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Proposal: php.ini environment variable fallback value

[Michael Morris]

On Mon, Jul 27, 2020 at 12:18 AM Michał Marcin Brzuchalski <
michal.brzuchal...@gmail.com> wrote:

> Hi Michael,
>
> niedz., 26 lip 2020, 06:22 użytkownik Michael Morris 
> napisał:
>
>> PHP's ini values are already a bit of a mess.  You have a global php.ini
>> file, and then most PHP ini directives can be set per directory using the
>> .htaccess file.  About a third can be set at runtime. This makes tracking
>> down where a setting came from a bit of a headache unless care is taken.
>> This proposal promises to make the situation even more complicated.
>>
>> Also, what would this solve that using .htaccess files to override the
>> default values not solve aside from the rare settings that cannot be set
>> per directory?
>>
>
> Bear in mind that .htaccess has a very narrow use and it's kind oh thing
> Apache2 related and not PHP specific!
>

Most major webserver applications have an equivalent to .htaccess. Indeed,
IIS can bind PHP flags and values to environment values already if I recall
correctly, and has been able to do so for a very long time (though I
haven't played with IIS in over a decade so my memory could be wrong on
this).

You mention Docker - usually I've seen it used alongside Ansible, Chef or
Puppet. Each of these provisioning programs can modify the php.ini file
used on the container at deploy time without necessitating a change to PHP
itself.  What advantage does the community gain from moving these decisions
from the provision files to the php.ini file?


>

Re: [PHP-DEV] Proposal: php.ini environment variable fallback value

[Michael Morris]

PHP's ini values are already a bit of a mess.  You have a global php.ini
file, and then most PHP ini directives can be set per directory using the
.htaccess file.  About a third can be set at runtime. This makes tracking
down where a setting came from a bit of a headache unless care is taken.
This proposal promises to make the situation even more complicated.

Also, what would this solve that using .htaccess files to override the
default values not solve aside from the rare settings that cannot be set
per directory?

On Fri, Jul 24, 2020 at 3:54 PM Derek Bonner  wrote:

> Currently an environment variable can be specified in the php.ini file.
> This is useful if you want tune one or two settings in your runtime
> environment. Where this runs into issues is if you want to do something
> similar to Juan Terminio[1][2].
>
> I'm proposing a change the php.ini parser that would allow for an extended
> syntax for environment variables in the php.ini. In this syntax when
> checking for an environment variable if it is empty the fallback value
> would be used instead. The original environment variable syntax would
> remain valid as well.
>
> Possible syntax options. I currently do not have a very deep understanding
> of the current .ini parser so this may make invalid assumptions.
>
> * memory_limit = ${PHP_MEMORY_LIMIT:-"default value"}
> * memory_limit = ${PHP_MEMORY_LIMIT::"default value"}
> * memory_limit = ${PHP_MEMORY_LIMIT:="default value"}
> * memory_limit = ${PHP_MEMORY_LIMIT=="default value"}
>
> * Potential issue: Adopting a bash-ism
>
> This type of environment fallback is common in bash. If adopted it could
> lead users to think other bash features are also available. To dissuade
> this I would suggest that the fallback value syntax not appear in any of
> the default php.ini files. Users must read the documentation and decide if
> it works for them and add it in their php.ini file.
>
> Changes needed in the code
>
> Digging through the code I find that two sections would need to be changed,
> both in Zend/zend_ini_parser.y. I hope to be able to write this code myself
> but would gladly accept some guidance.
>
> 1. cfg_var_ref: Currently TC_DOLLAR_CURLY TC_VARNAME '} would need to be
> changed to something like TC_DOLLAR_CURLY TC_VARNAME ':-' TC_FALLBACK '}'
> 2. zend_ini_get_var: I imagine this would require adding a third parameter
> to the function signature that would be used in the event of a null value
> when checking the environment.
>
> [1]
> https://jtreminio.com/blog/php-modules-toggled-via-environment-variables/
> [2]
>
> https://jtreminio.com/blog/docker-php/php-fpm-configuration-via-environment-variables/
>
> I look forward to your feedback.
>
> Derek
>

Re: [PHP-DEV] [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

[Michael Morris]

What other language allows this? None that I can think of. Do we want PHP
doing something it's most closely related languages do not allow?  Why
don't they allow this? What problems are we creating by allowing this? I
can imagine this would make autoloading functions and constants by
namespace more complicated, but I'm not sure.

On Tue, Jun 16, 2020 at 3:52 AM Nikita Popov  wrote:

> Hi internals,
>
> Inspired by the recent discussion on reserved keyword reservation, I'd like
> to propose the following RFC:
>
> https://wiki.php.net/rfc/namespaced_names_as_token
>
> This RFC makes two related changes: Treat namespaced names as a single
> token, which enables use of reserved keywords inside them. And remove
> reserved keyword restrictions from various declarations.
>
> The RFC comes with a small backwards compatibility break related to names
> that include whitespace, but will hopefully reduce the backwards
> compatibility impact of future reserved keyword additions.
>
> Regards,
> Nikita
>

Re: [PHP-DEV] RFC: separate inheritance from subtyping (PHP v8)

[Michael Morris]

PHP's notion of "implements" is identical to that of Java and C#. This is
not by accident, many programmers have to work in multiple programming
languages. The less a language does things "differently" the better.

And honestly, the upsides of this proposal are not worth the BC breaks
created with the new keywords.

On Wed, Jun 10, 2020 at 11:16 AM Doug Wilbourne 
wrote:

> I propose the following language additions:
>
>
>
> 1) add three new keywords to the available syntax for class declarations:
> 'inherits' and 'subtypes' and 'patterns'.
>
>
>
> Currently the 'extends' keyword means both inherits and subtypes,
> which leads to unnecessarily restrictive typing problems in order to
> satisfy the Liskov substitution principle.  'Inherits' would mean that
> class A inherits B's properties and methods but is not a subtype of B and
> cannot be substituted for B.  And just as A can override/overload B's
> methods, the method signatures would not be subject to the parameter
> widening / return-type restricting principle necessary for substitution.
> Conversely, the 'subtypes' keyword indicates that if A subtypes B then A
> can be substituted anywhere B can be used but 'subtypes' does not imply
> that A inherits any of B's methods and properties - simply that it has
> signatures that conform to the parameter widening and return-type
> restricting principles of substitution.  Lastly 'patterns' complements the
> 'implements' keyword.  A class 'patterns' an interface if it conforms to
> the declared signature of the interface but it does not imply that the
> concrete class can be substituted for any other object which either
> implements or patterns the interface.
>
>
>
> It should be possible to write 'A inherits, subtypes B' and this should
> have the same effect as 'A extends B'.
>
>
>
> 2) Add two new operators: 'descendentof' and 'subtypeof' that would augment
> 'instanceof'.  Semantics parallel the class declaration keywords described
> above.
>
>
>
>
>
> Benefits:
>
>
>
> It would then be possible to write something like the following:
>
>
>
> interface ValidatorInterface
>
> {
>
> public function validate($x) : bool;
>
> public function getErrmsg() : string;
>
> }
>
>
>
> abstract class Validator patterns ValidatorInterface
>
> {
>
> abstract public function validate($x) : bool;
>
>
>
> public function getErrmsg() : string
>
> {
>
> return $this->errmsg;
>
> }
>
> }
>
>
>
> class ValidatorNonNegativeInteger inherits Validator patterns
> ValidatorInterface
>
> {
>
> public function validate(int $x) : bool { return 0 <= $x; }
>
> }
>
>
>
> class ValidatorAlphaText(string $x) inherits Validator patterns
> ValidatorInterface : bool
>
> {
>
> return 1 == preg_match('/^[a-zA-Z]+$/', $x);
>
> }
>
>
>
> ValidatorNonNegativeInteger and ValidatorAlphaText cannot be substituted
> for each other or Validator or ValidatorInterface.  Explicitly trying to
> upcast ValidatorNonNegativeInteger should produce a compiler error (e.g.
> (Validator) new ValidatorNonNegativeInteger() is not legal).
>
>
>
> If you adopt the data type 'mixed' and use it as in "public function
> validate(mixed $x)", it makes it even clearer that the syntax permits
> covariant parameters.
>
>
>
> Currently the compiler allows contradictory parameter declaration between
> parent and descendant (using 'extends') but produces a runtime error
> indicating that the child method's parameter must conform to that of the
> parent.  Because substitution is not an issue when A inherits B (using
> ‘inherits’ as above, not ‘extends’), a parent declaring "function foo(int
> $bar)" and a descendant declaring "function foo(string $bar)" has no
> theoretical problem as far as I can tell and should not produce an error.
>
>
>
> Along with generics (already being suggested / discussed I think - and
> thank you for unions), this approach should lead to DRYer code and cleaner
> abstractions.  In the example above, ValidatorNonNegativeInteger and
> ValidatorAlphaText can leverage common code in the parent class.  And it is
> not necessary to write two separate interfaces in order to handle the two
> different data types.  Essentially, it creates a bridge between the old
> 'untyped' Zvals and the tightly typed C derivatives.
>
>
>
>
>
> Who Is Going To Write This?
>
>
>
> I am relatively new to the PHP community and have never once glanced at the
> internals of PHP.  As much as I would love to do it, my learning curve will
> be quite some time before I would be ready to tackle something like this.
> And I think the time for this idea is now while there is so much momentum
> in the community on type-safety.  I am considering getting involved in the
> community per the guidance (test writing, documentation, etc) but have not
> plucked up the courage to make the commitment yet.  And my C is super
> rusty.  If this falls on deaf ears, I am afraid the idea will never bear
> fruit. If everyone thinks it is a good idea, then I am 

Re: [PHP-DEV] Re: [RFC] PHP Namespace Policy

[Michael Morris]

On Sat, Apr 25, 2020 at 3:28 AM Rowan Tommins 
wrote:

> Hi Michael,
>
> On 25 April 2020 00:00:32 BST, Michael Morris  wrote:
> >Changing function names and argument orders would lead to BC breaks so
> >massive people would move away without a transition plan that was
> >sustainable long term.  Namespaces give that opportunity, I think.
>
>
> You're not the first person to suggest this, indeed I've thought of trying
> to write an FAQ for the list, and this would be on it.
>
> There is some merit to the idea, but there's a snag: just using new names
> for new versions of things (which is what a new namespace would be) helps
> *machines* know which is which, but it doesn't help *humans* know which is
> which. Instead of "Does strpos take needle or haystack first?" the user
> would now have to think "Is this file using the old or new functions? Is
> one of them called str_pos and the other strpos, and do they take arguments
> in a different order?"
>

I'm aware of this pain point, but I have to deal with it when moving
between languages anyway.  A project that uses both older and newer
versions of the same function is going to happen regardless of the
namespace it is placed in, and if namespaces aren't used then the names
just keep getting longer and longer.


>
> The general consensus is that the long-term solution is to add new
> object-oriented APIs, including "scalar objects" (syntax to call methods in
> strings, integers, etc). That's not necessarily because OO is better, but
> because it's sufficiently different that it can comfortably sit side by
> side with the current functions. We might have
> $haystack->positionOf($needle) or $needle->positionIn($haystack) or both,
> and strpos would still be available to all programs with the same arguments
> it's had for 20 years.


>
Similarly, an OO-based file handling API would give us a chance to design
> in better error handling so there was no need for the @ operator and lots
> of ===false checks. That new API is the kind of thing that could live under
> the \PHP namespace, but the old functions wouldn't need to move anywhere.
>
>
I like these ideas, but they don't address the point I was making

I would like the old "throw it all in" approach to be moved out of \ and
into \PHP\Legacy.
Why? I want \ to be empty. Long term I feel this is the best approach
because it matches nearly all other languages.
Wouldn't that break everything?  Yes, which is the reason for a mechanism
to allow the user to configure which namespaces are loaded onto the root.
By default, this will be /PHP/Legacy so that Legacy code will be able to
run unimpeded.

Or is \ itself just going to be legacy? I suppose that could be done, but
functions without a namespace at all irks me.

>
>

Re: [PHP-DEV] Re: [RFC] PHP Namespace Policy

[Michael Morris]

On Fri, Apr 24, 2020 at 6:09 PM Mark Randall  wrote:

> On 25/04/2020 00:00, Michael Morris wrote:
> > So, in steps:
> >
> > 1. Take the current function roster - all of it - and put it in
> > \PHP\Legacy\.  So the formal name of strpos would become
> > \PHP\Legacy\strpos.
> > 2. The root namespace would be empty BUT...
> > 3. An INI directive set globally or per directory can set which namespace
> > is bound to root.  Initially this would be "\PHP\Legacy", so all legacy
> > code would not have to change - it would run in the new version and find
> > all of its functionality without incident.  This is critical - as this
> > directive would likely need to stay as is for two majors minimum,
> possibly
> > more.
>
> Thank you for the contribution.
>
> However, such a change would never, ever be accepted. With good reason.
>
> Mark Randall
> marand...@php.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
What good reason? Because it is hard?

Re: [PHP-DEV] Re: [RFC] PHP Namespace Policy

[Michael Morris]

On Thu, Apr 23, 2020 at 9:48 AM Mark Randall  wrote:

> On 15/04/2020 12:21, Mark Randall wrote:
> > https://wiki.php.net/rfc/php_namespace_policy
>
> Just an update in light of the two different RFCs.
>
> Having chatted with the other RFC authors in R11, rather than racing to
> see who can get their RFC to vote first, it seems like there's room for
> both.
>
> Vote 1 would be the other RFC which would be something along the lines of:
>
> "Mandate the use of \PHP for future internal tightly-bound components"
>
> If vote 1 were passed, the next vote would be on this RFC, and would
> cover policy on namespace usage and would be something like:
>
> "The \PHP namespace must remain empty, except for child namespaces".
>
> This would be to prevent the problem of colliding internals symbols
> throughout the rest of PHP's maintained lifespan (such as what if there
> was something else added to core called Token).
>
> Vote 3 would mandate only autoloadable classes / interfaces / traits etc
> etc were used, allowing userland polyfills (where sensible) to provide a
> route for users to begin using newer API functionality without an
> immediate upgrade.
>
> Votes 1 and 2 passing would put us on a pretty good course for long-term
> sanity.
>
> Vote 1 passing and 2 failing would result in part of the problem just
> being moved to \PHP and exposing us to symbol collision further down the
> line.
>
> If vote 1 failed, we would have to consider if this RFC would pass with
> its tigher constraints.
>
> The question is, how would we vote on extra uses for PHP.
>
> While the alternative RFC mandates its use for tightly coupled, I think
> it makes a lot of sense to add extra things to it, such as re-designed
> collections (borg Ds?) in \PHP\Collections in a similar fashion to:
>
>
> https://docs.microsoft.com/en-us/dotnet/api/system.collections?view=netframework-4.8
>
>
> Mark Randall
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I would like to submit from the peanut gallery of user land. My perspective
here is as a user, not as an internals writer. I also have no formal
training so I can bring that perspective to the table for consideration.
That said, I don't represent anyone but myself.

I've read the talk of how the \PHP namespace should be used and not be
used. I personally think we should slow down and carefully consider what we
can do here, because active assignment of the namespace will have
ramifications for the rest of PHP's life. We have the opportunity to make a
course change, but it won't be easy. And we only really get one good shot
at this.

All of PHP's core functionality is currently in \.  All of it. That makes
the language easy to pick up and learn, but the functions in that namespace
are, well, idiosyncratic.  Are the arguments in (haystack, needle) order or
(needle, haystack).  Is the function camelCase or underscore_delimited or
neitherone?

Changing function names and argument orders would lead to BC breaks so
massive people would move away without a transition plan that was
sustainable long term.  Namespaces give that opportunity, I think.

So, in steps:

1. Take the current function roster - all of it - and put it in
\PHP\Legacy\.  So the formal name of strpos would become
\PHP\Legacy\strpos.
2. The root namespace would be empty BUT...
3. An INI directive set globally or per directory can set which namespace
is bound to root.  Initially this would be "\PHP\Legacy", so all legacy
code would not have to change - it would run in the new version and find
all of its functionality without incident.  This is critical - as this
directive would likely need to stay as is for two majors minimum, possibly
more.

And yes, I'm keenly aware of the scope of this.  The RFC system itself
would need to be changed to allow this to be possible since this approach
demands a design be submitted, approved and THEN an implementation written
and approved. Difficult, but not impossible - the W3C does this all the
time. Even with a Design, then implement RFC system in place, I imagine a
full year would be needed just to get the designs down and agreed upon.
The best PHP 8 could do is just lay the foundation for transition outlined
above and not actually include any alternative to \PHP\Legacy

The rest of \PHP\ would be the replacements for the legacy pieces.  It
needs to be a designed library with a consistent naming schema and argument
orders, at a minimum. It also needs to be broken up so as not to overwhelm
the developers doing the implementation. We might even end up with some
duplication to satisfy the procedural vs. object oriented camps. The new
functions would also have a freer hand since they are opted into.

Beyond that though I don't really think it's helpful for me to go into more
detail because I'm not a language designer. I know enough to know I don't
know enough to give this subject a thorough vetting at this time (I could
certainly learn). 

[PHP-DEV] Thoughts on adopting Python's for/foreach else construct.

[Michael Morris]

I don't remember if this has been discussed before, but I've been working
with some listing code and wishing for a cleaner way to do this

 $value) {
  // code for iteration
}
  }
?>

How difficult would it be to make the following work in the interpreter?

 $value) {
// code for iteration
  }
  else {
// code for no results
  }
?>

The code of the else clause executes if the foreach is never entered
regardless of the reason (provided the code didn't outright crash)

Thoughts.

Re: [PHP-DEV][DISCUSSION] Multilingual PHP

[Michael Morris]

The replies so far have been excellent and I do appreciate the time given
to write them. Being a lazy one-language American (I tried to learn Spanish
but I've forgotten most of what I learned out of lack of use) I'm not
familiar with the obstacles to learning English beyond "gittin rid my
accint" when I was real little.

Several of you brought up a counterpoint Wired hadn't considered - that
having a common language facilitates cooperation around the globe. Some
large projects like Drupal, WordPress, and PHP itself couldn't be
undertaken without a common tongue.

A colleague of mine at word pointed out that there are preprocessors out
there such as antlr that can translate the language of a file into the
tokens the compiler will recognize. It seems an adequate solution, but I
don't know for sure.

Still, an interesting discussion overall. Thanks.

[PHP-DEV][DISCUSSION] Multilingual PHP

[Michael Morris]

Submitted to the floor is a Wired article from 2 days ago I came across

https://www.wired.com/story/coding-is-for-everyoneas-long-as-you-speak-english/

The manual of PHP is translated into multiple languages - but what are the
development hurdles of the language itself being multilingual?

>From what I understand of the compiler - maybe not that much.  The language
requires an opening tag, so we could hook into that like this example for
Japanese

Re: [PHP-DEV] Unifying logical operators

[Michael Morris]

On Mon, Jul 9, 2018 at 10:03 PM Ryan  wrote:

> Hello all!  Longtime PHP user, first-time contributor to internals (sorry
> if I screw anything up)!
>
> I'd like to propose either the deprecation (7.next - likely 7.4 at this
> point) and removal (8.0) of the T_LOGICAL_OR (or), T_LOGICAL_AND (and), and
> T_LOGICAL_XOR (xor) tokens, or aliasing them to ||, &&, and !=
> respectively.
>

While having these behave they do is unfortunate, it is hardly the only one
of PHP's quirks.  Ever looked at the ramifications of loose typing with
comparison? http://phpsadness.com/sad/52


> defined("SOME_CONSTANT") or die("SOME_CONSTANT was not defined");
>

> However, this behaviour has nothing to do with the difference of precedence
> - rather this is due to short circuiting.


 True, but that's still a lot of code to break. A *lot* of code.  Far too
much to consider changing this even at a major level I would think.

PHP if anything, is too pragmatic a language for this change.

Re: [PHP-DEV] PHP 8 next?

[Michael Morris]

On Mon, Jun 25, 2018 at 2:55 PM Zeev Suraski  wrote:

> On Mon, Jun 25, 2018 at 8:40 PM Chase Peeler 
> wrote:
>
> > 1.) Old code breaks during minor updates. We upgraded to 7.0 AFTER 7.1
> was
> > released, because we had already made major updates to upgrade to 7.0,
> and
> > 7.1 introduced a few things that would have broken our code - we didn't
> > have time to fix those by that point. "Throw on passing too few function
> > arguments" would actually break more stuff in our legacy code than all of
> > the 7.0 changes combined.
> >
>
> I agree.  It was a bad decision on our part to do it in 7.1 - this bit a
> lot of users.
>
>
> > Finally, I personally see the idea of a deprecation only release to be
> kind
> > of silly. I don't work for a software company. It's tough enough for me
> to
> > make a case for upgrading using the "increase performance" and "new
> > features" argument. There is no way I'd get the go-ahead to do an upgrade
> > that would just make additional features deprecated. It would be a better
> > use of my time to look for and fix the deprecated features as part of the
> > 8.0 upgrade prep, than to upgrade to 7.4. Maybe look at at backporting
> some
> > of the new 8.0 features that aren't really dependent on the major things
> > like JIT, async, etc., as part of the 7.4 release.
> >
> > Fair enough, and I think there'll likely be a lot of folks that would see
> no point in going through such a 7.4.  However, I think that folks working
> in more agile companies, or even developers that want to get a head start
> on preparing for 8.0 - will find value in such a release.  TBH, the vast
> majority of users don't upgrade to our minor versions even when they bring
> new features and capabilities.
>

So, about that Ternary operator?

My understanding is that major releases are the only ones allowed to have
breaking changes. Correcting the ternary operator to work like it does in
all other languages is a small example. Merging the symbol tables is
another.

5.3 had namespaces - 5.4 made APC core - these were major changes but not
breaking ones.

Breaking changes need significant notice as Levi points out.

>
>

Re: [PHP-DEV] PHP 8 next?

[Michael Morris]

On Sat, Jun 23, 2018 at 6:39 PM Alice Wonder  wrote:

> On 06/23/2018 03:11 PM, Zeev Suraski wrote:
> >
> >
> >> -Original Message-
> >> From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara
> >> Golemon
> >> Sent: Sunday, June 24, 2018 1:07 AM
> >> To: Nikita Popov 
> >> Cc: PHP internals 
> >> Subject: Re: [PHP-DEV] PHP 8 next?
> >>
> >> On Sat, Jun 23, 2018 at 4:22 PM, Nikita Popov 
> wrote:
> >>> Based on some recent conversations, I'm getting the impression that
> >>> after PHP 7.3, we might want to go for PHP 8 next.
> >>>
> >>> I'd like to discuss and possibility decide this now, as that would
> >>> make PHP
> >>> 7.3 the last chance to get in deprecations.
> >>>
> >> Would you mind elaborating on your motivations for a major version
> bump.  I'm
> >> not saying I disagree in principle, I'm just curious what you're seeing
> the drivers
> >> as.
> >
> > This is slightly earlier than I intended to bring it up but I do too
> think that the next version beyond 7.3 should be 8.
>
> I disagree.
>
> I'm mostly a user, not a PHP developer.
>
> RHEL 7.5, the latest version of RHEL, still ships 5.4.
>
> Other LTS distributions also probably ship 5.x.
>
> So a major version bump now would mean three major versions of PHP that
> web applications intended to "just work" on enterprise *nix would have
> to support.
>
> If there was a major design flaw in PHP that can only truly be fixed by
> an incompatible version bump past 7 then do it but otherwise, I think it
> would be better to wait until the most recent versions of enterprise
> distributions have moved to php 7.
>
> I'm hoping RHEL 8 does, the benefits are tremendous of 7 over 6.x, but...
>
> The issue is some customers of enterprise linux specifically don't want
> frankenstein systems and want to use vendor supported packages only, and
> I can see their point of view because they pay a lot of money for that
> support.
>
> That being said, I try to get everyone running old PHP up to 7.1 or 7.2
> even if it means frankenstein systems. But some think the benefit of
> enterprise vendor support outweighs the improvements in PHP.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/ 

unsub.php 



If we’re going to 8 can we please fix the ternary operator now???

> 
>
>

Re: [PHP-DEV] Better types without runtime checking

[Michael Morris]

On Tue, Jun 5, 2018 at 2:22 AM Rudolph Gottesheim 
wrote:

> There's always a lot of talk about types in the PHP community.
> Specifically, many developers want property types, generics, function
> signature types, union and intersection types, and more. Those talks
> (and RFCs) always end with the same result: "We can't do it because
> performance issues."
>
> Has there ever been a discussion about adding some of those features
> syntactically, but ignoring them during runtime? At least until someone
> finds a performant way to check them at runtime. That way we could have
> advanced type checking in our editors at least.
>
> The idea will sound familiar to TypeScript users. It works great for
> that language.
>

It's an interesting compromise, but I worry about the confusion it may sow,
particularly for incoming programmers from languages that do enforce such
things - such as Java.

Re: [PHP-DEV] About assert()

[Michael Morris]

My earlier reply was through my phone. I've since read the bug report and
saw your note where you couldn't reproduce it.

Assert is a statement in PHP 7.  Try this code

function foo() {
  debug_print_backtrace();
  return true;
}

assert(foo());

In PHP 7 only foo() will be in the backtrace.  In PHP 5 assert will be
listed as well.

What you are proposing has already been done.  It's also why
zend.assertions has three settings: 1: on, -1: off, 0: emulate PHP 5.
Unless you have code on your hands that is breaking when the -1 setting is
used, the 0 setting should never be used.

On Wed, Feb 14, 2018 at 7:43 AM, Pedro Lacerda <pslace...@gmail.com> wrote:

> The same beharviour, but `assert` as statement also uses 1 character less.
>
>
> Em 14 de fev de 2018 10:13 AM, "Michael Morris" <tendo...@gmail.com>
> escreveu:
>
>
> On Wed, Feb 14, 2018 at 1:16 AM Pedro Lacerda <pslace...@gmail.com> wrote:
>
> > Hi developers,
> >
> > Trying to resolve the bug #75950 (that after long hours I found that I
> > couldn't reproduce), I observed that if `zend.assertions >= 0` the
> > generated code inside `assert()` was indeed executed even if
> `assert.active
> > = off`. Naturally the function arguments were evaluated before entering
> > into the `assert()` function.
> >
> > https://bugs.php.net/bug.php?id=75950
> >
> > The point is that will be possible to fully disable assertions setting
> > `assert.active = false` after initialization if we turn `assert` into a
> > statement. This can mantain fully backward compatibility. Calling
> > `assert_options(ASSERT_ACTIVE, true)` or `false` after initialization
> would
> > fully enable or disable the functionality. It seems the most sensible
> thing
> > to do.
> >
> > By the way `assert` in Java and Python is an statement, and in C it
> isn't a
> > function.
> >
> > So my question is what is the purpose of mantaining `assert()` a
> function,
> > there are any drawbacks of fully disabling it when `zend.assertions >=
> 0`?
> >
> >
> > PS: Strange that nobody cared in recent emails about the proposal to a
> > small increase of the testing coverage by doubling the testing time
> > duration, was somewhat interesting.
> >
>
>
> Assert.active is the legacy PHP 5 control. Don’t use it.
>
> zend.assertions -1 has the behavior you want. 0 emulates PHP 5 and
> earlier’s broken implementation of assert. If you don’t have legacy
> software to babysit, don’t use it.
>
> >
> >
>

Re: [PHP-DEV] About assert()

[Michael Morris]

On Wed, Feb 14, 2018 at 1:16 AM Pedro Lacerda  wrote:

> Hi developers,
>
> Trying to resolve the bug #75950 (that after long hours I found that I
> couldn't reproduce), I observed that if `zend.assertions >= 0` the
> generated code inside `assert()` was indeed executed even if `assert.active
> = off`. Naturally the function arguments were evaluated before entering
> into the `assert()` function.
>
> https://bugs.php.net/bug.php?id=75950
>
> The point is that will be possible to fully disable assertions setting
> `assert.active = false` after initialization if we turn `assert` into a
> statement. This can mantain fully backward compatibility. Calling
> `assert_options(ASSERT_ACTIVE, true)` or `false` after initialization would
> fully enable or disable the functionality. It seems the most sensible thing
> to do.
>
> By the way `assert` in Java and Python is an statement, and in C it isn't a
> function.
>
> So my question is what is the purpose of mantaining `assert()` a function,
> there are any drawbacks of fully disabling it when `zend.assertions >= 0`?
>
>
> PS: Strange that nobody cared in recent emails about the proposal to a
> small increase of the testing coverage by doubling the testing time
> duration, was somewhat interesting.
>


Assert.active is the legacy PHP 5 control. Don’t use it.

zend.assertions -1 has the behavior you want. 0 emulates PHP 5 and
earlier’s broken implementation of assert. If you don’t have legacy
software to babysit, don’t use it.

>
>

Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator

[Michael Morris]

On Mon, Feb 12, 2018 at 1:43 PM, Wes  wrote:

> Again, the reason is: in case in future PHP wants to use backticks for
> unicode strings, like javascript.
> If the community think it's feasible, in PHP 9, 10, whatever, it must be
> deprecated asap.
> If you think PHP should use a different syntax for unicode strings in
> future, you vote no.
> It's as simple as that. I am asking to reserve a particular syntax for
> something that could be needed in some years.
>

Any particular reason why "`unicode string `" wouldn't work?

Trust me, everyone here has at least one feature or operator they would
like to see done differently (cough - namespace operator -  \ - cough) but
the proverbial train left the station a long time ago.

Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator

[Michael Morris]

On Mon, Feb 12, 2018 at 8:38 AM, Eli White  wrote:

> I'll chime in on the "What evidence do you have that this is not
> widely-used" ... in fact, I have seen through my PHP career this used very
> regularly, and training/workshop/class sessions at conferences still
> regularly teach this as the 'standard way' to handle shell commands.
>
> So I think that this would have a huge impact on existing code, and I am
> similarly a huge -1.  Is it funky that random backticks cause a shell
> action to happen?  Yes.  But there are a million funky things about PHP,
> and we strive for backward compatibility when at all possible.  And there
> is no direct gain/need to remove this feature.
>
> Eli
>
>
Agreed. There are a lot of things in PHP that are easily overlooked and can
go unused, especially if all one ever does with it is web page generation.
PHP can be used for shell scripting, and I've used it extensively for that
since I don't know how to write bash scripts. I'd personally be rather
peeved if I had to rewrite all my shell scripts.

Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator

[Michael Morris]

On Sun, Feb 11, 2018 at 1:41 PM, Wes  wrote:

> Hello PHPeople, I present to you... the shortest RFC ever.
>
> https://wiki.php.net/rfc/deprecate-backtick-operator
>
> Let me know what you think!
>

-1, not that my vote matters, but huge -1.

Nothing of value is gained by doing this. If there is something of value in
doing this, or some far future feature this clears the way for, please
enlighten me. But from where I sit this does nothing but break code for no
reason. And yes, emitting E_DEPRECATED is a breaking issue for any code
base that prides itself in being about to run all it's units with E_ALL set.

If we are going to go about removing stupid operators in PHP, the current
use of @ as an error suppression operator is much higher on the list since
encourages people to write bad code by sweeping problems under the rug, and
removing it would allow the operator to be reassigned to use as an
annotation operator as seen in Java and other language.  I'm not holding my
breath for that to be done either.

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Michael Morris]

The Dependency injector isn't aware of the reference and is unable to
modify it in any way.  I've been taught to avoid such dependencies, and to
avoid utility libraries which create such dependencies.

On Tue, Feb 6, 2018 at 2:54 PM, Rowan Collins <rowan.coll...@gmail.com>
wrote:

> On 6 February 2018 20:18:07 GMT+00:00, Michael Morris <tendo...@gmail.com>
> wrote:
> >I'm fine with this - I just want the inspector to be part of the
> >language
> >so that a hidden dependency isn't required.
>
> I may be being dumb, but I don't get why you keep referring to this as a
> "hidden dependency". It's a dependency, for sure, but why is it any more
> "hidden" than any other utility library?
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Michael Morris]

On Tue, Jan 30, 2018 at 2:24 PM, Levi Morrison <le...@php.net> wrote:

> On Tue, Jan 30, 2018 at 11:13 AM, Larry Garfield <la...@garfieldtech.com>
> wrote:
> > On Monday, January 29, 2018 6:46:10 PM CST Michael Morris wrote:
> >> On Mon, Jan 29, 2018 at 6:16 PM, Larry Garfield <la...@garfieldtech.com
> >
> >>
> >> wrote:
> >> > Really, these functions would be useful only on arrays, period.  To
> allow
> >> > them
> >> > on anything else is just dangerous, and on other iterables there are
> >> > better,
> >> > more robust approaches (as discussed elsewhere in this thread).
> >> >
> >> > As you've demonstrated they're also quite compact and effective to do
> in
> >> > user-
> >> > space, so unless there's a massive performance difference of moving
> them
> >> > to C
> >> > they don't seem all that appropriate to add to the language directly.
> >> >
> >> > --Larry Garfield
> >>
> >> Didn't you personally raise the issue of hard dependencies doing this
> sort
> >> of functionality creates? Implementable in userland or not, this is
> pretty
> >> low level functionality.
> >
> > I don't recall doing so in this thread, but I most likely have on some
> other
> > issue.  It's the sort of comment that I would make. :-)
> >
> > However, that's for a very commonly used function where just inlining it
> is
> > prohibitive.  As you've demonstrated below, this functionality is easily
> a one
> > liner, and it's a one-liner in an assert statement most likely.
> >
> >> Hmm..  If limited to arrays only then array_filter with count is pretty
> >> close to what we want.
> >>
> >> assert(count(array_filter($a, is_string)) === count($a));
> >>
> >> That's not optimal though - granted assert code doesn't *have* to be
> >> optimal, but that's still a wordy construction.
> >
> > Personally I think that's fine, and doesn't need a language-level utility
> > function to wrap it any further.
> >
> > (Yes, that's a subjective metric.  So are most statements about what
> > should[n't] be included in the language itself.  Others are welcome to
> > disagree, but this falls below my threshold of necessity.)
> >
> > --Larry Garfield
>
>
> I agree with this sentiment from Larry. However I do think there is a
> function we could add:
>
> function every(callable $predicate, traversable $input): bool {
> foreach ($input as $value) {
> if (!$predicate($value)) {
> return false;
> }
> }
> return true;
> }
>
> In which case the code would become:
>
> assert(every('is_string', $input));
>
> Of course, when passing a traversable the caller must to be careful as
> it will be consumed. If they don't want that to happen they can
> convert it to an array (possibly with iterator_to_array).
>
> The reason this "every" function is better than "array_test" is
> because it is more general and works with more things than just types.
> The name "every" I borrowed from Clojure, but it's known by many
> names; in Java it is known as "allMatch".
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I'm fine with this - I just want the inspector to be part of the language
so that a hidden dependency isn't required.

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

[Michael Morris]

On Mon, Feb 5, 2018 at 8:33 AM, Marco Pivetta <ocram...@gmail.com> wrote:

>
> On Mon, Feb 5, 2018 at 3:28 PM, Michael Morris <tendo...@gmail.com> wrote:
>
>> The problem is that behavior has been around so long that any attempt to
>> change it would incur a massive amount of changes. Using the E_STRICT
>> notice level instead of E_DEPRECATED has been floated as one fix for this,
>> but this doesn't change the fact that major applications and frameworks,
>> such as Drupal, pride themselves in being able to pass all tests even with
>> E_STRICT enabled. The maintainers of these projects would be annoyed to
>> say
>> the least to need to fix thousands of lines of code to get back to that
>> point, and downstream projects such as Drupal could end up waiting years
>> for all their upstream libraries to get their act together.
>>
>
>  Much like any upgrade requiring patches for full compliance with newer
> PHP versions, it needs work.
>
> The typical workflow is:
>
>  * add PHP.NEXT to the CI setup
>  * run everything through the tests again, figure out how much has broken
>  * fix it
>
> In this case, we even *already* have *multiple* tools that automatically
> fix this problem in one shot.
>
> Since the two issues are somewhat tied, why not bind them to a
>> configuration flag following the pattern that was used to ultimately
>> remove
>> register_globals functionality from the language?  At this point let it be
>> known that when constant/function overloaders hit a php.ini config option
>> will be added to turn them on -- and turning them on will turn global
>> scoping for functions off.
>>
>
> Argh
>
>
Agreed, but you can't just pull the rug out from under people. It's
painful, but it's better to let people opt in to such a major change than
to "break" their code.



>
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

[Michael Morris]

May I propose a compromise?

If I understand what I've read over, the default of functions and constants
to global scope is the primary blocking issue for creating an autoloader
for these elements. Where that not PHP's behavior this functionality could
have been implemented by now.

The problem is that behavior has been around so long that any attempt to
change it would incur a massive amount of changes. Using the E_STRICT
notice level instead of E_DEPRECATED has been floated as one fix for this,
but this doesn't change the fact that major applications and frameworks,
such as Drupal, pride themselves in being able to pass all tests even with
E_STRICT enabled. The maintainers of these projects would be annoyed to say
the least to need to fix thousands of lines of code to get back to that
point, and downstream projects such as Drupal could end up waiting years
for all their upstream libraries to get their act together.

Since the two issues are somewhat tied, why not bind them to a
configuration flag following the pattern that was used to ultimately remove
register_globals functionality from the language?  At this point let it be
known that when constant/function overloaders hit a php.ini config option
will be added to turn them on -- and turning them on will turn global
scoping for functions off.

This solution isn't perfect.  From where Drupal stands, even if all it's
own code stopped using global functions the packages it relies on likely
will continue to do so for some time. Even if they don't, there may be
compatibility issues with the newer version.

A slightly better solution would be to allow this to be set on a per
namespace basis, but as PHP has no true notion of a namespace I don't think
this can be implemented.  The declare() statement might allow it to be done
on a per file basis, but that's going to get messy fast.

Still, I feel it is a workable approach despite the drawbacks.  If anything
this problem highlights another problem elsewhere in PHP - the inability to
isolate package configuration, or configure packages at all.  But that's a
topic for another RFC, one I won't be starting cause I have no idea how to
fix it.

On Mon, Feb 5, 2018 at 8:09 AM, Christoph M. Becker 
wrote:

> On 04.02.2018 at 22:56, Stanislav Malyshev wrote:
>
> >> To get the same benefits (jit and such) wouldn't it be better to
> introduce
> >> a "use function root;" or similar statement or a declare() to specify
> this
> >> file imports all root functions?
> >
> > We already have this right now, […]
>
> Do we?  AFAIK, it is not possible to import *all* functions (or even all
> symbols, for that matter) of a namespace, without explicitly mentioning
> them.
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Michael Morris]

On Tue, Jan 30, 2018 at 12:13 PM, Larry Garfield <la...@garfieldtech.com>
wrote:

> On Monday, January 29, 2018 6:46:10 PM CST Michael Morris wrote:
> > On Mon, Jan 29, 2018 at 6:16 PM, Larry Garfield <la...@garfieldtech.com>
> >
> > wrote:
> > > Really, these functions would be useful only on arrays, period.  To
> allow
> > > them
> > > on anything else is just dangerous, and on other iterables there are
> > > better,
> > > more robust approaches (as discussed elsewhere in this thread).
> > >
> > > As you've demonstrated they're also quite compact and effective to do
> in
> > > user-
> > > space, so unless there's a massive performance difference of moving
> them
> > > to C
> > > they don't seem all that appropriate to add to the language directly.
> > >
> > > --Larry Garfield
> >
> > Didn't you personally raise the issue of hard dependencies doing this
> sort
> > of functionality creates? Implementable in userland or not, this is
> pretty
> > low level functionality.
>
> I don't recall doing so in this thread, but I most likely have on some
> other
> issue.  It's the sort of comment that I would make. :-)
>

It was during the discussion on the Drupal list on adding runtime
assertions, the Inspector class in general. Curiously, no one on that list
raised the problem of allowing Inspector to traverse any Traversable.  At
the time Drupal was PHP 5.4 min, so no generators to consider, and I guess
the other implications skipped everyone's mind.

Personally I think that's fine, and doesn't need a language-level utility
> function to wrap it any further.
>
>
We'll just have to disagree then.  After all, roughly half the array_*
functions can be user implemented, as can roughly half the string functions
(though how to do so is often cryptic to beginners).

array_test might not be the best name.  Anyone got alternatives other than
the one in the abandoned RFC mentioned elsewhere in this thread (Not that
that one is bad, but if this is the direction to go some input on what to
actually call the thing would be nice.)?

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Michael Morris]

On Mon, Jan 29, 2018 at 6:16 PM, Larry Garfield 
wrote:
>
>
> Really, these functions would be useful only on arrays, period.  To allow
> them
> on anything else is just dangerous, and on other iterables there are
> better,
> more robust approaches (as discussed elsewhere in this thread).
>
> As you've demonstrated they're also quite compact and effective to do in
> user-
> space, so unless there's a massive performance difference of moving them
> to C
> they don't seem all that appropriate to add to the language directly.
>
> --Larry Garfield
>

Didn't you personally raise the issue of hard dependencies doing this sort
of functionality creates? Implementable in userland or not, this is pretty
low level functionality.

Hmm..  If limited to arrays only then array_filter with count is pretty
close to what we want.

assert(count(array_filter($a, is_string)) === count($a));

That's not optimal though - granted assert code doesn't *have* to be
optimal, but that's still a wordy construction.

So what about this function

bool array_test(array $array [, callable $callback [, mixed $flag = 0]])

Iterates over $array, passing the value of each element to $callback. If
the callback returns true for all elements the array_test returns true,
otherwise it returns false. It is not guaranteed to iterate over the entire
array - it stops when the first false result is returned by the callback.
Flags are the same as array_filter.

So...
assert( array_test($a, 'is_string'), TypeError);
assert( array_test($a, function($v) { return $v instanceof SomeClass; }),
TypeError);


Not what I came into the thread looking for, but it's not bad.

s

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Michael Morris]

On Mon, Jan 29, 2018 at 3:26 PM, Rowan Collins <rowan.coll...@gmail.com>
wrote:

> On 29 January 2018 19:14:43 GMT+00:00, Michael Morris <tendo...@gmail.com>
> wrote:
> >  The is_callable()
> >above prevents iteration over generators, potentially consuming them
> >for no purpose.
>
> Unfortunately, it doesn't: it's not the generator definition that you'll
> be passed, but the Generator object returned when you run it, and that is
> not callable https://3v4l.org/rknQJ
>
> (The definition is more like a constructor, and I wish it didn't look so
> much like a normal function in declaration and use.)
>
> Nor are generators the only non-rewindable iterables you need to worry
> about, so really the only options you have are to only inspect arrays, or
> to add a big fat warning that the function may consume your iterable (or
> enter an infinite loop).
>
>
Ok, so make no attempt to keep people from shooting themselves in the foot
eh?

Fine, is this otherwise workable?

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Michael Morris]

On Mon, Jan 29, 2018 at 3:26 PM, Rowan Collins 
wrote:

>
> Nor are generators the only non-rewindable iterables you need to worry
> about, so really the only options you have are to only inspect arrays, or
> to add a big fat warning that the function may consume your iterable (or
> enter an infinite loop).
>
>
Sorry about the double reply.  What about using count() as a guard?  While
there might be some countable consumables, my understand of generators is
they are often used where no prior count is available. Arrays and
ArrayObjects are countable.

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Michael Morris]

> The more angles we approach this, the more it looks like generics, or at
> least the same basis.


Which is well outside the scope of what I'd like to see, so let's look at
form 2 in closer detail - the all functions.

bool all_array( mixed $var ) {
  if (is_iterable($var) && !is_callable) {
foreach ($var as $v) {
  if (!is_array($v)) return false;
}
return true;
  }
  return false;
}


That is the base function signature and implementation.  The is_callable()
above prevents iteration over generators, potentially consuming them for no
purpose.

The other functions in the family and their single value equivalents are:

is_bool -> all_bool
is_callable -> all_callable
is_double -> all_double
is_float -> all_float
is_int -> all_int
is_iterable -> all_iterable
is_long -> all_long
is_null -> all_null
is_numeric -> all_numeric
is_object -> all_object
is_real -> all_real
is_resource -> all_resource
is_scalar -> all_scalar
is_string -> all_string
is_subclass_of -> all_are

On the last one - is_subclass_of is generally more useful than is_a, but
will doing this cause confusion?  Also, not all of these need to be
included - the above is a list of candidate functions to create.  Of all of
these all_string() would probably see the most use followed by
all_numeric().

This will give the tools to do the desired assertions in a clean, easy to
read manner. Collections that must be of a single iterable class can also
be verified:

assert($a instanceof \SomeClass && all_string($a));

But most of the time $a will merely be an array.

Re: [PHP-DEV] Shorthand proposal for associative arrays

[Michael Morris]

Forgot something in the previous post...

On Fri, Jan 26, 2018 at 12:16 PM, Christian Schneider  wrote:

> Hi there,
> I have a proposal for a shorthand notation of associative arrays borrowed
> from another language:
> :$foo
> would be equivalent to
> 'foo' => $foo
> and would work with array, list or []
>
> Motivation behind it, maybe someone else finds more good uses:
>
> 1) Emulating named parameters with associative arrays like
> html::img([ 'src' => $src, 'alt' => $alt ]);
>could be written as
> html::img([ :$src, :$alt ]);
>which encourages consistent naming of variables and parameters
>

The most similar extant feature to this is compact, but it's not as compact
as this syntax.

$src = 'my.jpg';
$alt = 'My alt';
html::img(compact($src, $alt));

will accomplish the same thing since compact does the reverse of extract -
it pulls the specified variables from the local scope and puts them into an
associative array.

Re: [PHP-DEV] Shorthand proposal for associative arrays

[Michael Morris]

On Fri, Jan 26, 2018 at 2:00 PM, David Rodrigues 
wrote:

> Maybe you should see the extract() method.


Uhm, what? You need to learn what extract does before you recommend it as
an alternative to someone's proposal.  Extract takes an array and moves
their keys onto the local symbol table. So

extract( ['src' => 'myimg.jpg', 'alt' => 'My alt']);
echo $src; // myimg.jpg
echo $alt; // My alt

Using extract on an array with numeric keys gives you fun stuff like $0, $1
and so on.  Extract sees most of its use in PHP based template management
classes where an associative array is extracted than a template file is
included, to allow the template file to use the key names as variables
rather than the array syntax.

As to the proposal itself.

> Motivation behind it, maybe someone else finds more good uses:
>
> 1) Emulating named parameters with associative arrays like
> html::img([ 'src' => $src, 'alt' => $alt ]);
>could be written as
> html::img([ :$src, :$alt ]);
>which encourages consistent naming of variables and parameters

I've been mulling this over since I saw it earlier today.  It's kinda neat
to be honest.

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Michael Morris]

On Thu, Jan 25, 2018 at 11:59 PM, Niklas Keller <m...@kelunik.com> wrote:

> Michael Morris <tendo...@gmail.com> schrieb am Fr., 26. Jan. 2018, 02:06:
>
>> On Thu, Jan 25, 2018 at 3:04 PM, Niklas Keller <m...@kelunik.com> wrote:
>>
>> >
>> >>
>> >> $a instanceof array
>> >>
>> >
>> > That might work, but array should only return true if it's an
>> > array, not for anything that implements ArrayAccess.
>> >
>> >
>>
>> Related:
>>
>> On Thu, Jan 25, 2018 at 4:11 PM, Levi Morrison <le...@php.net> wrote:
>>
>> >
>> >
>> > I see no value to this operator being applied to non-array
>> > traversables.
>>
>>
>> If an array access object can't masquerade as an array it loses some of
>> its
>> value, but Niklas is right - it is important to distinguish such objects
>> from native arrays.  One solution would be to promote "iterable" to
>> keyword
>> status.  The flexibility to take any iterable will be needed I think.
>>
>> $a instanceof iterable
>>
>> Would return true for anything iterable (which we can already test with
>> is_iterable() ) where all values where strings.
>>
>> On Thu, Jan 25, 2018 at 4:11 PM, Levi Morrison <le...@php.net> wrote:
>> >
>> > Our iterators cannot always be reliably rewound, such as
>> > when using generators. Checking that the generator returns only
>> > strings would consume all the input and would therefore be useless.
>>
>>
>> True - I hadn't thought of those. But as of PHP 7 generators can type
>> declare their return value.
>
>
> They can only define generator as return type, which is what they return
> when you call a generator function.
>
> Even if you could declare the return type of the generator, you'd still
> have the same problem with the yielded values.
>

See my comment about coding around morons being a pointless exercise.  You
throw an error and force the moron to fix their code.


>
> So, given `$a instanceof iterable`, if
>> $a is a reference to a generator, then the engine could check the return
>> type declaration and only give true on a match without attempting to use
>> the generator.
>>
>> We can follow this pattern farther - The return of an
>> ArrayAccess::offsetGet and Iterator::current() can be similarly tested by
>> instanceof rather than actually pulling data from these methods.
>>
>> We are having the return rely on the promise of the code, but in each case
>> TypeError would be raised anyway if it breaks it's promise to instanceof
>> so
>> errors aren't being avoided.
>>
>>
>>
>> > Returns true if $a is an array (or implements array access) and that all
>> >> it's members are strings.
>> >>
>> >> $b instanceof SomeClass
>> >>
>> >> Returns true if SomeClass can be iterated and contains only strings.
>> >>
>> >
>> > This would block generics with that syntax then.
>> >
>>
>> I don't understand this comment.
>>
>
> You restrict these type parameters to iterators, but generics are useful
> in a lot more places.
>

iterABLE --- not iterOR.  Two different things.

Iterable is a psuedotype in PHP covering anything that can be traversed
with foreach, including std_class, which is what I think what you mean by
generator.  There's even an existing function, is_iterable() to detect
them. `$a instanceof iterable` will return the same as `is_iterable($a);`

Generics specifically are already detectable by `$a instanceof stdClass`
`$a instanceof Iterator` detected that interface, but not arrays and
generics.
`$a instanceof iterable` would detect all three.

The similarity of the names is regrettable, but it's already in place and
can't be changed at this point.

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Michael Morris]

On Thu, Jan 25, 2018 at 3:04 PM, Niklas Keller  wrote:

>
>>
>> $a instanceof array
>>
>
> That might work, but array should only return true if it's an
> array, not for anything that implements ArrayAccess.
>
>

Related:

On Thu, Jan 25, 2018 at 4:11 PM, Levi Morrison  wrote:

>
>
> I see no value to this operator being applied to non-array
> traversables.


If an array access object can't masquerade as an array it loses some of its
value, but Niklas is right - it is important to distinguish such objects
from native arrays.  One solution would be to promote "iterable" to keyword
status.  The flexibility to take any iterable will be needed I think.

$a instanceof iterable

Would return true for anything iterable (which we can already test with
is_iterable() ) where all values where strings.

On Thu, Jan 25, 2018 at 4:11 PM, Levi Morrison  wrote:
>
> Our iterators cannot always be reliably rewound, such as
> when using generators. Checking that the generator returns only
> strings would consume all the input and would therefore be useless.


True - I hadn't thought of those. But as of PHP 7 generators can type
declare their return value.  So, given `$a instanceof iterable`, if
$a is a reference to a generator, then the engine could check the return
type declaration and only give true on a match without attempting to use
the generator.

We can follow this pattern farther - The return of an
ArrayAccess::offsetGet and Iterator::current() can be similarly tested by
instanceof rather than actually pulling data from these methods.

We are having the return rely on the promise of the code, but in each case
TypeError would be raised anyway if it breaks it's promise to instanceof so
errors aren't being avoided.



> Returns true if $a is an array (or implements array access) and that all
>> it's members are strings.
>>
>> $b instanceof SomeClass
>>
>> Returns true if SomeClass can be iterated and contains only strings.
>>
>
> This would block generics with that syntax then.
>

I don't understand this comment.


On Thu, Jan 25, 2018 at 5:28 PM, Larry Garfield 
 wrote:

>
>
> Is this to ensure that everything coming OUT of a collection is a given
> type,
> or that everything put IN a collection is a given type?
>

Ensure (or try to ensure, since reporting the promises of another method's
return type isn't certain) that things coming OUT are a given type.  Leave
the headache of guarding inputs for another day and RFC.


>
> Asserting that "at this point in time, everything in this collection is a
> given type" is honestly fairly useless unless it's enforced to stay that
> way.


No more useless than type declarations are if a programmer does this...

function foo (string $a) {
  $a = (int) $a;
}

Every feature of the language can be rendered useless by the right amount
of stupidity. No feature recommendation should be beholden to the "what if
a moron does X?" argument.

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Michael Morris]

On Thu, Jan 25, 2018 at 2:39 PM, Niklas Keller  wrote:

>
> So, given `$a collectionof string` the operator returns whether or not $a
>> is, at that time, a collection of strings (be it an array or other
>> iterable). It doesn't insure $a will stay that way - it's just a check of
>> the variables status at a given moment, which is the best that can be
>> hoped
>> for in PHP.
>>
>
> That should be a function, not an operator, unless you can bring up very
> good arguments to make it an operator.
>

Consistency with instanceof.



Hmm, it might be possible to just pile this all onto instanceof - following
Derrick's mention of how Java does things, so here's a third implementation
approach.  It would look like this:

$a instanceof array

Returns true if $a is an array (or implements array access) and that all
it's members are strings.

$b instanceof SomeClass

Returns true if SomeClass can be iterated and contains only strings.

The question is can the token parser handle that pattern?  Or does the
current usage of < and > in their boolean form block this?

If this third approach is accepted then we have no BC breaks at all since
there's no new keyword or function. We just have a *very* expanded
instanceof operator.

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Michael Morris]

On Thu, Jan 25, 2018 at 2:16 PM, Rowan Collins <rowan.coll...@gmail.com>
wrote:

> On 25/01/2018 18:56, Michael Morris wrote:
>
>> Ok, let's stay on topic please.
>> This RFC discussion is about an operator or family of functions to verify
>> that a given $var is a collection.  Objects which enforce collection
>> integrity is a tangential but whole other topic outside the scope of what
>> I
>> proposed in the first post.
>>
>
>
> Well, it's more convergent than tangential: if Derick's "generics-lite"
> were implemented, the desire for a collectionof operator might be lower,
> because people would "$foo instanceof Collection" instead.
>

Yes, but given what has been said on the issue by the senior maintainers,
the chances for Derrick's "generics lite" counter-proposal ever seeing the
light of day are somewhere between 0, null, false and empty string.

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Michael Morris]

On Thu, Jan 25, 2018 at 2:10 PM, Rowan Collins 
wrote:

> On 25/01/2018 14:52, Derick Rethans wrote:
>
>> IMO, it makes a lot more sense to check integrity when creating the
>> "array" structure. Instead, I would suggest to add a native Collection
>> type, that takes a "type" as argument. They aren't quite full generics,
>> but it does 1. fix something; 2. isn't really complicated.
>>
>> What I am suggesting is to add a new syntax "Collection<$type>",
>> mimicking a class, but having a type as "argument":
>>
>> $a = new Collection;
>>
>
> So would I be right in thinking this would mean adding basic support for
> generics to the engine, but not letting new ones be defined in userland?
> So, a bit like how internal or extension classes have the ability to do
> more overloading of casts and operators than userland classes?
>
> If so, I like the concept, but wonder whether the parts of the
> implementation it would need are the easy parts of the hard ones. I guess
> not being able to inherit from the generic would get rid of a bunch of
> complexity, but don't really know where else the challenge lies.
>

He's getting the syntax from Java.  Java collections allow you to specify
the type they are constrained to in <> after the class name.  Type Script
does something similar.  The problem is that Java already has the policing
mechanics present in the runtime to police insertions into the collection
and guarantee they are of the correct type.  PHP has no such mechanism in
place and in previous discussion threads the primary maintainers have
underscored that adding such is highly difficult.

It is also completely tangential to and a distraction from what I propose
and would like to focus on here.  Regardless of whether PHP ever gets a
core class or construct for type uniform collections, the ability to verify
that variables are a "collection of something" will remain.  That is the
issue I want to discuss and address here - verifying that existing
variables are a given collection type, not debating pie-in-the-sky, may
never be implementable classes that self insure their own integrity.

So, given `$a collectionof string` the operator returns whether or not $a
is, at that time, a collection of strings (be it an array or other
iterable). It doesn't insure $a will stay that way - it's just a check of
the variables status at a given moment, which is the best that can be hoped
for in PHP.

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Michael Morris]

On Thu, Jan 25, 2018 at 10:14 AM, Bishop Bettini  wrote:

>
> Agreed, and we can get *almost* there today with:
>
> $collection = collection_of('is_int', [ 1, 2 ]);
>

Ok, let's stay on topic please.

This RFC discussion is about an operator or family of functions to verify
that a given $var is a collection.  Objects which enforce collection
integrity is a tangential but whole other topic outside the scope of what I
proposed in the first post.

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Michael Morris]

On Thu, Jan 25, 2018 at 10:21 AM, Derick Rethans  wrote:

>
> PHP owns the top-level namespace. It has always done that. It's even
> documented: http://docs.php.net/manual/en/userlandnaming.rules.php
>
>
That doesn't stop the bellyaching when the refactoring becomes necessary.
If possible, it is best to avoid choosing a name that will cause a lot of
projects to refactor.

[PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Michael Morris]

Ok, here's another idea I've been mulling over. This I know is possible
because I've done it using user land code, specifically Drupal 8's
Assertion\Inspector class.

https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Component%21Assertion%21Inspector.php/class/Inspector/8.5.x

These methods provide a means to inspect collections - arrays usually but
also Traversables. They fill a hole in the PHP library - the ability to
check collection integrity.

To answer the question "Why in core?" - well, Drupal needing to do this
using a library referenced only by assert() statements creates an
undocumented dependency for any class that wants to run these checks. From
a pragmatic standpoint it just feels wrong.  Most other languages have some
means of doing these checks.




IMPLEMENTATION STYLE #1:  collectionof operator
The style of implementation I like the most is a collectionof operator in
parallel to the instance_of operator.  It would be instanceof's plural
brother, so

$arg collectionof \SomeClass

To pass the check $arg must be of the iterable psuedotype with all its
values being a \SomeClass object.

This is all well and good, but collection integrity checks are usually
going to be looking to see if all the members are the same scalar.

$arg collectionof string

For language consistency we would need to allow instance_of to do the same,
which it currently does not.

$arg instanceof string

This does create duplication with the is_* family of functions, but
instanceof already overlaps is_a heavily.



IMPLEMENTATION STYLE #2: all_*
This style takes the is_* family and creates plural cousins for them.
Example:

all_string($arg);

This is most similar to the user land solution. Following the current is_*
family this gives us all_array(), all_bool(), all_callable(), all_double(),
all_float(), all_int(), all_integer(), all_iterable(), all_long(),
all_null(), all_numeric(), all_object(), all_real(), all_scalar(), and
all_string(). One other function, all_are(), would be necessary for class
and interface inspection.

That's a lot of new functions, and the chance of BC breaking with someone's
code is very high, so I don't personally like this approach. I'm putting it
out there as alternate because despite that shortcoming it is a sensible
alternative.

[PHP-DEV] Website mangled because us1.php.net is down.

[Michael Morris]

http://www.php.net is badly mangled, apparently because it's referencing
files from us1.php.net and that server appears to be down at the moment.

BTW, what should be the tag for this?

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

[Michael Morris]

On Wed, Jan 10, 2018 at 12:27 PM, Rasmus Lerdorf  wrote:

>  If you stay away from trying to change a 25-year old loosely typed
> language into a strictly typed one, then the RFC becomes much simpler.
>
> -Rasmus
>

I have REPEATEDLY stated that is not the goal. I don't misrepresent what
you say, please do not do that to me.

I want to see strict typing as an option, not a requirement.

Arggh...

I said I'd stay away from implementation, but would this work?  Working
this into z_val in any way is problematic. So, store elsewhere?

Create a symbol table that holds the strict variables and the types they
are locked into.  The strict keyword pushes them onto that table, the var
keyword pulls them off. When an operation that cares about type occurs
check that table - if the var appears there than authenticate it.

I would hope that if a programmer doesn't want strict typing the overhead
of checking an empty table would be minimal, even if repeated a great many
times.

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

[Michael Morris]

On Wed, Jan 10, 2018 at 9:04 AM, Rasmus Lerdorf <ras...@lerdorf.com> wrote:

>
>
> On Wed, Jan 10, 2018 at 5:27 AM, Michael Morris <tendo...@gmail.com>
> wrote:
>>
>> Also, drawing the architectural drawings for a skyscraper is also like
>> only
>> 10% of the work, but it's a damn important 10%.
>>
>
> Wow, that's rather insulting to the amazing work Dmitry, Nikita, Xinchen
> and others are doing working on the core of PHP.
>

No insult was intended here. I apologize if any is taken.


> Describing the syntax/UI for a feature like this is nothing like the
> architectural drawings for a skyscraper.
>

In terms of time and effort spent it is. It often takes years to complete
plans drawn up over the span of weeks. The analogy becomes more firm when
you compare the man hours on each side - an architect can draw up plans for
a house in less than 100 hours (unless it's a freaking huge house). The
contractor labor hours will be 100 times that at a minimum. If anything I'm
off in scales, but I was being anecdotal - I wasn't aiming for precise
accuracy.

Plans still must precede work, and if the ramifications of those plans are
to be far reaching they need to be agreed upon as early as possible.

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

[Michael Morris]

On Wed, Jan 10, 2018 at 12:53 AM, Rasmus Lerdorf  wrote:

>
> The difference here is that the end syntax is something like 10% of the
> problem. 90% of it is fitting it into the engine in an efficient manner
> giving that it is affecting the very core of the engine. An RFC on this
> issue that doesn't address the bulk of the problem isn't all that helpful.
>
>
It makes absolutely NO sense to do that 90% of the work to have it all
burned up when the proposal fails to carry a 2/3rds vote because the syntax
is disliked.

Also, drawing the architectural drawings for a skyscraper is also like only
10% of the work, but it's a damn important 10%.

That the implementation will be a major pain in the ass to do is all the
more reason to create and pass a planning RFC before doing any related
code/implementation RFC's. It will encourage people to do the research to
try to figure out how to get this done because they know the syntax is
approved and they aren't fiddling around in the dark trying to figure out
how to do something that may not be accepted for inclusion at all, which is
a huge waste of time.

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

[Michael Morris]

Before I begin, and without picking on anyone specific, I want to say that
it is generally unhelpful to say that because I, or others, do not know how
the engine is set up that it is impossible to make any meaningful
contributions to the list or on this issue specifically.  My clients don't
understand HTML.  If I told them they needed to study how HTML works before
trying to give me input on the sites I'm building for them I'd likely be
fired.  As a theater major I know quite a bit more than most of the people
on this list about what makes a good play or movie actually work, but I
don't pretend that knowledge is prerequisite to knowing if a play or movie
is good.  It either works, or it doesn't.

If the fallback to all suggestions is "Shut up, that's impossible to do
given current engine architecture." then I'm afraid that PHP is doomed to
become the next COBOL - a language with a lot of important legacy programs,
but no new developers or future as those old systems finally give up the
ghost. Also, given that HHVM has implemented at least one aspect if this
proposal with classes the argument that it's impossible carries a rather
large spoonful of salt.

This said, I will refrain from offering any more input on how this might be
implemented as it is clearly not wanted. I will instead focus on the
desired end state.


Much of what follows is based on Michal Brzuchalski's comments.  His
commentary can be largely summed up with "using the var keyword in a
counter-intuitive way is just going to make matters worse. Also,
getter/setter debates are quite a bit out of scope.



Third Draft.

Target version: PHP 8.

This is a proposal to strengthen the dynamic type checking of PHP during
development.

Note - this is not a proposal to change PHP to a statically typed language
or to remove PHP's current typing rules. PHP is typed the way it is for a
reason, and will remain so subsequent to this RFC. This RFC is concerned
with providing tools to make controlling variable types stronger when the
programmer deems this necessary.



DEFINITIONS
Before a meaningful discussion on types and type handling can be performed
some terms must be defined explicitly, especially since their definitions
in common parlance may change from language to language, and even
programmer to programmer. I

* Static Typing: This typing is performed by the compiler either explicitly
or implicitly.
* Dynamic Typing: This typing is performed by the runtime. Unlike static
typing it allows for varying degrees of variable coercion.
* Strong/Weak typing: These terms typically refer to the amount of latitude
the run time has to coerce variables - the more latitude the "weaker" the
typing.



VARIABLE DECLARATION (GLOBAL AND FUNCTION SCOPE)

PHP currently has no keyword to initialize a variable - it is simply
created when it is first referenced. The engine continually coerces the
variables into the required types for each operation. While this is a very
powerful ability, it runs into problems with comparisons (
http://phpsadness.com/sad/52 ). As a result of this issue PHP (and many
languages that share this problem such as JavaScript) provides the strict
comparison operator.  Avoiding this issue is one reason it can be useful to
have some amount of control over a variable's type. This can be
accomplished with two keywords, one old and one new: var and strict.

var $a = 5;
strict $b = 9;

Together these are "mutability operators" - that is they control if a
variable can mutate, be coerced, recast or what have you between types. The
strict keyword removes the mutability of a variable between types. The var
keyword restores it. The keywords perform these operations even in the
absence of an assignment, though using strict without any assignment will
lead to an error since type will be unknown.  Examples.

var $a; // $a will be created and be NULL.
strict $a; // TypeError - strict variables must have an explicit type or a
value from which a type can be inferred.
$b = 5;
strict $b; // $b locks down to integer since it was already declared. It's
value remains 5.
var $b; // $b's ability to be coerced is restored.
strict int $c; // Works. $c will be empty - any assignment must be the
specified type.
strict $d = 'Hello'; // Works. Type of string can be inferred.

Both keywords allow comma delimited lists of declarations (for
consistency), but strict will be the one to use it most frequently:

strict $a = 1, $b = "Hello", $c = 3.14, $d = [];

$a is inferred to int, $b to string, $c to float and $d to array.



FUNCTION DECLARATION

The strict keyword in a function declaration locks down the argument var
for the remainder of the function (or until var is used). For consistency
it is recommended that var be allowed as well, but it wouldn't do anything
beyond cuing IDE's that mixed will be accepted.

function foo (strict int $a, strict string $b, var $c, strict $d = true) {}



ARRAYS
If an array is strict all of its keys and values will be strict and
inferred on 

Re: [PHP-DEV] Deprecation of assert() with string argument

[Michael Morris]

On Sat, Jan 6, 2018 at 7:36 AM Christoph M. Becker 
wrote:

> Hi everybody!
>
> As of PHP 7.2.0 calling assert() with a string argument has been
> deprecated[1].  However, it seems that ASSERT_QUIET_EVAL /
> assert.quiet_eval is supposed to only work as documented, if a string
> argument is passed[2].  If that is indeed the case, wouldn't it make
> sense to deprecate the usage of this flag / ini setting as well?
>
> [1]
>  >
> [2] 
>

Yes.

For what it’s worth, I’m expecting the asset_options function to be
deprecated entirely eventually and am working on a patch for Drupal to
address this

>
>
>

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

[Michael Morris]

On Thu, Jan 4, 2018 at 7:21 PM Rasmus Lerdorf  wrote:

>
> > On Jan 4, 2018, at 13:09, Andreas Hennings  wrote:
> >
> > A system where all variables are type-locked could in fact be faster
> > than a system with dynamically typed variables.
> > Depends on the implementation, of course. I imagine it would be a lot
> > of work to get there.
>
> I think you, and many others, commenting here, should start by looking at
> the engine implementation. Any successful RFC needs to have a strong
> implementation behind it, or at the very least a very detailed description
> of how the implementation would mesh with the existing engine code.
>
> The reason we don’t have typed properties/variables is that it would
> require adding type checks on almost every access to the underlying zval.
> That is a huge perf hit compared to only doing it on method/function egress
> points as we do now.


I’ve been thinking on this during my drive today to a new job and city. I
promise to read over the current implementation before going further, but a
quick question - what if the underlying zval wasn’t a zval but a separate
class specific to the data type but implementing the same interface as
zval? The compiler would choose to use the alternate classes when it
encounters new syntax calling for their use, in effect adding a static
typic layer that augments the existing dynamic typing layer.



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

Re: [PHP-DEV][RFC][DISCUSSION] Strong Typing Syntax

[Michael Morris]

Second Draft based on the feedback upstream.

Target version: PHP 8.

This is a proposal to strengthen the dynamic type checking of PHP during
development.

Note - this is not a proposal to change PHP to a statically typed language
or to remove PHP's current loose typing rules. PHP is a weakly typed
language for a reason, and will remain so subsequent to this RFC. This RFC
is concerned with providing tools to make controlling variable types
stronger when the programmer deems this necessary.



VARIABLE DECLARATION

PHP currently has no keyword to initialize a variable - it is simply
created when it is first referenced. The engine infers the appropriate type
for the variable, and this may be later cast to other types depending on
the context of the code. Objects can have magic functions to carry out this
casting such as __toString.

It is sometimes useful to explicitly state a variable's type. One case is
when the engine might incorrectly infer the type. For example "073117" is a
valid octal integer but also a date string in mmddyy format, so a
comparison with another date string in the same format could be... amusing.
While there is a string comparison function, that functions presence is
borne of the fact that we can't reliably compare "073117" with say,
"010216" because of the int casting possibility.

Since the scalar types have already been reserved as keywords they can be
used to declare variables in a manner not unlike C or Java.

int $a = 073117;

The var keyword is still around from PHP 4 days but is going unused.  In
JavaScript var is used to formally declare a variable though it isn't
required (It remains important because without it JavaScript will search
the scope chain of the current closure all the way to the top scope. If it
doesn't find the reference it only then creates one. This can lead to huge
headaches so the creation of variables without using var is strongly
discouraged in JavaScript).

Since the keyword is available, let's make use of it.

var $a = "123";

What I propose this will do is formally declare $a, infer it's type, then
LOCK the type from casting. If further assignments are made to the variable
the quantity being assigned will be cast to type desired if possible,
otherwise a type error will be raised.

var string $a = $_POST['date'];

This syntax allows the programmer to choose the type rather than allowing
the engine to infer it. Here $_POST['date'] might be provided in date
string that might be confused for an octal int.

This magical casting is suggested because it follows the spirit of PHP, but
it may not be strict enough. For those the type can be explicitly declared
without using the var keyword as follows.

int $a = 4;

In this event a type error will occur on any attempt to assign a value to
$a that isn't an int.

The variable can still be re-declared in both cases so.

var $a = 4;
string $a = "Hello";

The var keyword can be combined with the new keyword to lock an object
variable so it doesn't accidentally change

var $a = new SomeClass();

As noted above a deliberate redeclare can still change the type of $a.



ARRAYS
All members of an array can be cast to one type using this syntax

var string array $a = [ 'Mary', 'had', 'a', 'little', 'lamb' ];
int array $b = [1,2,3,5];

Or members can be individually cast

var $a = [ var 'Todd', var 'Alex' ];
$b = [string 'id' => int 1, 'name' => string 'Chad'];

Again, following rules similar to the above.  The main reason for doing
this is to insure smooth interaction with the pack and splat operators.

function foo (var string array $a = ...);

And speaking of functions, that's the next section.



FUNCTION DECLARATION

Variables are also declared as arguments to functions.  I propose using the
var keyword to lock the resulting variable and perform a cast if possible.

function foo( var string $a, var $b ) {}

Note that using var without explicitly calling type will be legal if rarely
used for consistency reasons. Also, someone might have a use for an
argument who's type could be anything, but won't change after it is
received.

The type can also be inferred from the default.

function foo( var $a = "hello" ) {}

This syntax is essentially doing a redeclare of the variable. This could be
very troublesome with references, so a Type error will result if this is
tried.

function foo ( var &$a = "Hello" ) {}

$b = 3;
foo($b);

With objects the var keyword can be used to prevent the function from
changing the object.

function foo ( var SomeClass $a ) {}





CLASS MEMBER DECLARATION

Variables also appear as object members. Following the pattern established
above their types can be locked. A couple note though

class SomeClass {

  var $a = '3';
  public var $b = 'hello';

}

For backwards compatibility the var keyword by itself must be equivalent to
"public". It is only when a scope operator is present that var takes on its
new meaning in this context.

Magic __set and __get cannot access variables with locked types because,

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

[Michael Morris]

On Wed, Jan 3, 2018 at 3:26 PM, Rowan Collins <rowan.coll...@gmail.com>
wrote:

> Hi Michael,
>
> On 02/01/2018 10:35, Michael Morris wrote:
>
>> I would like to propose a clean way to add some strong typing to PHP in a
>> manner that is almost fully backward compatible (there is a behavior
>> change
>> with PHP 7 type declarations). As I don't have access to the add RFC's to
>> the wiki I'll place this here.
>>
>
> Thanks for putting this together. Perhaps unlike Andreas, I think it is
> good to look at typing changes as a unified framework, rather than
> considering "typed properties", "typed variables", etc, as separate
> concerns. If we don't, there is a real risk we'll end up making decisions
> now that hobble us for future changes, or over-complicating things in one
> area because we're not yet ready to make changes in another.
>

My thoughts exactly. PHP already has enough warts born of piecemeal design
- a cursory look at the PHP string functions shows this very well. We have
functions with haystack/needle and needle/haystack. Some function names are
_ delimited, some aren't (or were meant to be camel cased but since PHP
function labels aren't case sensitive), and so on.  When I see an RFC based
on types it worries me precisely because without a core plan of action we
are inviting more language fragmentation.


>
> My own thoughts on the subject from a while ago are here:
> http://rwec.co.uk/q/php-type-system In that post, I borrowed the term
> "container" from Perl6 for the conceptual thing that type constraints are
> stored against; in PHP's case, this would include variables, object
> properties, class static properties, function parameters, and return
> values. I think a good plan for introducing typing is one that considers
> all of these as equals.
>
>
That was one of the most enjoyable reads I've had in awhile and I can't
think of anything there I disagree with. I'm still working through your
references for how Python is handling things and the treatise on the nature
of types.


> The biggest issue with any proposal, though, is going to be performance. I
> don't think this is an incidental detail to be dealt with later, it is a
> fundamental issue with the way type hints in PHP have evolved. PHP is
> extremely unusual, if not unique, in exclusively enforcing type constraints
> at runtime. Other languages with "gradual typing" such as Python, Hack, and
> Dart, use the annotations only in separate static analysers and/or when a
> runtime debug flag is set (similar to enabling assertions).
>
>
Has the bus already left the station forever on this?

I think it's clear that what we are discussing here can't go into effect
before PHP 8. Further, it could very well be on of if not the key feature
of PHP 8. In majors backwards compatibility breaks are considered were
warranted.

I'm not familiar with the Zend Engine as I probably should be. I bring the
perspective of an end user. From what you've posted am I correct in stating
that PHP Type Hints / scalar Type Declarations are in truth syntactic sugar
for asserting the type checks.  Hence we read this

function foo( ClassA $a, ClassB $b, string $c ) {}

But the engine has to do the work of this...

function foo ( $a, $b, $c ) {
  assert( $a instanceof ClassA, TypeError );
  assert( $b instanceof ClassB, TypeError );
  assert( is_string($c), InvalidArgument );
}

If that is indeed the case, why not disable these checks according to the
zend.assertions flag, or if that's too bold a move create a php.ini flag
that allows them to be disabled in production.

Existing code would be unaffected if it has been fully debugged because, in
accordance with the principles of Design by Contract, a call with an
illegal type should be impossible. For code that isn't up to par though we
have the possibility of data corruption when the code proceeds past the
call to wherever the reason for that type hint is. I'll hazard that most of
the time that will be a call to method on non-object or something similar.

PHP programmers however would need to get used to the idea that their type
hints mean nothing when assertions are turned off (or if handled by a
separate flag, when that flag is turned off).  I'm ok with this, but I'm a
big proponent of Design by Contract methodology as a supplement to Test
Driven Design.

Another thing to consider is that if the existing type hints are so
expensive, this change might grant a welcome speed boost.

Extending that to all containers means every assignment operation would
> effectively need to check the value on the right-hand-side against the
> constraint on the left-hand-side. Some of those checks are non-trivial,
> e.g. class/interface constraints, callable; or in future maybe "array of
> Foo", "Foo | Bar | int", "Foo &am

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

[Michael Morris]

On Wed, Jan 3, 2018 at 12:21 PM, Andreas Hennings 
wrote:

> Another idea I have when reading this proposal is "implicit" typing
> based on the initialization.
>
> E.g.
>
> $x = 5;
> $x = 'hello';  // -> Error: $x was initialized as integer, and cannot
> hold a string.
>
>
No, no no.  I don't think I'd like that always on approach. However, I just
had an idea.


Let's step back.  Way back.  PHP/FF days back.

Back in the day Ramus chose to put variables off on their own symbol table
for performance reasons.  This isn't as necessary now, but vars in PHP
continue to be always $something.

Now I don't know the implementation can of worms this would touch but what
if this was changed for the locked type variables.  That would distinguish
them greatly..

int x = 5;

Here x is a locked type variable of the integer type.  Since it's also on
the same symbol tables as the classes, functions, constants et al I presume
it is namespace bound as well.

var x = 5;

If allowed what would this mean?

And what to do with class members is an open question.


Anyway, I'm looking for an implementation that allows loose and strong
typing to coexist even within a given file. I use loosely typed variables
most of time myself.

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

[Michael Morris]

On Wed, Jan 3, 2018 at 12:10 PM, Andreas Hennings 
wrote:

> This proposal contains some interesting ideas, which I see as separate:
> 1. A syntax to declare the type of local variables.
> 2. A syntax to declare the type of object properties.
> 3. Preventing local variables, object properties and parameters to
> change their type after initialization/declaration.
>
> For me the point 3 is the most interesting one.
> I think the other points are already discussed elsewhere in some way,
> although they are clearly related to 3.
>
> Point 3 would be a BC break, if we would introduce it for parameters.
> Current behavior: https://3v4l.org/bjaLQ
>
> Local variables and object properties currently cannot be types, so
> point 3 would not be a BC break for them, if we introduce it together
> with 1 and 2.
> But then we would have an inconsistency between parameters and local
> vars / object properties.
>
> What we could do to avoid BC break is to introduce
> declare(fixed_parameter_types=1) in addition to
> declare(strict_types=1).
> For local variables and object properties, the type would always be fixed.
> But for parameters, it would only be fixed if the
> declare(fixed_parameter_types=1) is active.
>
> Maybe to make it less verbose, we could say declare(strict_types=2),
> which would mean the combination of both those things?
> Or some other type of shortcut.
> I think we will have to think about shortcuts like this if we
> introduce more "modes" in the future.
>
>
There will be occasions where having an unfixed variable alongside normal
ones will be desirable.


>
> > Currently the var keyword is used to formally declare a variable.
>
> Are you talking about local variables?
> In which PHP version? https://3v4l.org/o0PFg
>
>
Sorry, I'm confusing PHP for JavaScript. I forgot that the var keyword was
only used in PHP 4 for class members. For some reason my brain assumed it
was usable in a local scope.


> Afaik, currently var is only used for class/object properties from the
> time when people did not declare the visibility as
> public/protected/private.
>
>

>
> If no type is specified, then "mixed" should be assumed, not "scalar".
> Assuming "scalar" would be a BC break, and it would be confusing.
>
>
Ok. I'm misusing the term scalar to mean "variable who's type can be
changed at will depending on context." Sorry.

Re: [PHP-DEV] Mailing list moderation

[Michael Morris]

On Wed, Jan 3, 2018 at 11:05 AM, Chase Peeler  wrote:

> On Wed, Jan 3, 2018 at 10:49 AM Paul Jones  wrote:
> > > On Jan 2, 2018, at 12:29, Dustin Wheeler  wrote:
> > > On Tue, Jan 2, 2018 at 12:19 PM, Levi Morrison  wrote:
> >
> > If someone dislikes Tony's commentary for any reason (or no reason!) they
> > are free to filter his messages themselves -- and then unfilter his
> > messages when they see fit.
> >
>
> I agree with Paul. It would be different if email clients that allowed
> filtering were expensive or hard to find. They aren’t, though. Pretty much
> every email client not only allows filtering, but rather advanced filtering
> as well.
>

All fine and well, but it doesn't work when people start quoting the
offender. Also, filters don't stop the poison from affecting the mood of
the posters who interact with him.

In my experience loud and obnoxious voices drive off thoughtful and
introspective ones every time. That is the consequence of giving a platform
to them. As the saying goes, It's pointless to wrestle a pig - you'll just
get muddy and the pig enjoys it. From a moderators standpoint, if you
refuse to block jerks eventually all you'll be left with are jerks.


>
> Instead of suspending users, no matter how egregious their offenses may be,
> let individual users filter them out as they see fit.
>
>
Again, in my experience people usually elect to simply leave altogether
rather than set a long block list.  And frankly Tony isn't worth even one
contributing coder.

Tony has been asked multiple times by multiple people to behave.  He's been
banned from other PHP related forums I know of. He's not here to contribute
in any meaningful way, only complain and make passive agressive swipes at
other users. I could go on, but I think that alone makes the case that he
needs to be gone.

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

[Michael Morris]

On Wed, Jan 3, 2018 at 3:50 AM, Niklas Keller  wrote:

> Hey Michael,
>
> I don't think the BC break is acceptable. You argue that scalar type
> declarations are relatively new, but in fact they're already years old now.
> They're used in most PHP 7+ packages. Even if changing types might be
> discouraged, it still happens a lot.
>

Hmm.  Well, that aspect of this can be dropped. What about the rest of it?

Re: [PHP-DEV] Re: Mailing list moderation

[Michael Morris]

On Tue, Jan 2, 2018 at 6:47 AM, Derick Rethans  wrote:

> On Tue, 2 Jan 2018, Nikita Popov wrote:
>
> > This mail is going to both the systems group and internals mailing
> > list.
> >
> > I would like to request a mailing list suspension for the users
> > tonymars...@hotmail.com and li...@rhsoft.net, who have recently been
> > aggressively derailing the "Scalar Pseudo-type" thread, despite
> > requests to moderate their participation both in that thread, and on a
> > number of previous instances -- this is certainly not the first time
> > these two users have converted an RFC discussion into a dick measuring
> > contest.
>
> +1
>
> > If these users cannot be suspended, I would like to request specific
> > instructions under what circumstances users can be suspended from the
> > internals list, and what procedures need to be followed to achieve
> > this.
>
> I tried to write these down as part of the community health project, but
> as you know that didn't get anywhere...:
> https://github.com/derickr/php-community-health/blob/master/RFC.rst
>
> cheers,
> Derick
>
>
>
+1

For What It's Worth, these two are the only two I've put on killfile here.
I'm probably not the only one to do so either.

Re: [PHP-DEV][RFC][DISCUSSION] Strong Typing Syntax

[Michael Morris]

On Tue, Jan 2, 2018 at 7:08 AM, Hidde Boomsma  wrote:

> Dear Michael,
>
> Are you aware of this RFC: https://wiki.php.net/rfc/typed-properties
>
>
I was not aware of it. What I propose has a much wider scope, but the fact
there was slowdown on the last implementation try is concerning.

[PHP-DEV][RFC][DISCUSSION] Strong Typing Syntax

[Michael Morris]

Apologies for the double post - I missed a tag and I'm not sure the list
server will send it along because of that mistake.


I would like to propose a clean way to add some strong typing to PHP in a
manner that is almost fully backward compatible (there is a behavior change
with PHP 7 type declarations). As I don't have access to the add RFC's to
the wiki I'll place this here.

Before I begin detailing this I want to emphasize this syntax is optional
and lives alongside PHP's default scalar variables. If variables aren't
declared using the syntax detailed below than nothing changes.  This is not
only for backwards compatibility, but it's also to keep the language easy
to learn as understanding datatypes can be a stumbling block (I know it was
for me at least).

VARIABLE DECLARATION

Currently the var keyword is used to formally declare a variable.  The
keyword will now allow a type argument before the var name as so

var [type] $varname;

If the type is omitted, scalar is assumed.  If Fleshgrinder's scalar RFC is
accepted then it would make sense to allow programmers to explicitly
declare the variable as a scalar, but in any event when the type is omitted
scalar must be assumed for backwards compatibility.

The variables created by this pattern auto cast anything assigned to them
without pitching an error. So...

var string $a = 5.3;

The float of 5.3 will be cast as a string.

For some this doesn't go far enough - they'd rather have a TypeError thrown
when the assignment isn't going to work.  For them there is this syntax

string $a = "Hello";

Note that the var keyword isn't used.


FUNCTION DECLARATION

PHP 7 introduced type declarations.  This RFC calls for these to become
binding for consistency, which introduces the only backward compatibility
break of the proposal.  Consider the following code.

function foo ( string $a ) {
  $a = 5;
  echo is_int($a) ? 'Yes' : 'No';
}

Under this RFC "No" is returned because 5 is cast to a string when assigned
to $a. Currently "Yes" would be returned since a scalar has the type that
makes sense for the last assignment.

I believe this is an acceptable break for two reasons. 1, the type
declaration syntax is relatively new.  2, changing the type of a variable
mid-function is a bad pattern anyway.


OBJECT TYPE LOCKING

Currently there is no way to prevent a variable from being changed from an
object to something else. Example.

$a = new SomeClass();
$a = 5;

If objects are allowed to follow the same pattern outlined above though
this problem is mostly solved..

SomeClass $a = new SomeClass();
var SomeClass $a = new SomeClass();

QUESTION: How do we handle the second auto casting case? $a is not allowed
to not be a SomeClass() object, but there are no casting rules. We have
three options:
1. Throw an error on illegal assign.
2. Allow a magic __cast function that will cast any assignment to the
object.
3. Create a PHP Internal interface the object can implement that will
accomplish what 2 does without the magic approach.

Note that 1 will need to occur without implementation. 2 and 3 are not
mutually exclusive though my understanding is PHP is moving away from magic
functions.


CLASS DECLARATION
Again, by default class members are scalars. The syntax translates over
here as might be expected.

class SomeClass {
  public var string $a;
  protected int $b;
  private SomeOtherClass $c;
  public var SomeThirdClass $d;
}

Note a default value doesn't need to be provided.  In the case of object
members, these types are only checked for on assignment to prevent
recursion sending the autoloader into an infinite loop.

Also note that one of the functions of setters - guaranteeing correct type
assignment - comes free of charge with this change.


COMPARISON BEHAVIOR
When a strongly typed variable (autocasting or not) is compared to a scalar
variable only the scalar switches types. The strict comparison operator is
allowed though it only blocks the movement of the scalar.

Comparisons between strongly typed variables are always strict and a
TypeError results if their types don't match. This actually provides a way
to force the greater than, lesser than, and spaceship operation to be
strict.


FUNCTION CALLING
When a strong typed variable is passed to a function that declares a
variable's type then autocasting will occur so long as the pass is not by
reference.  For obvious reasons a TypeError will occur on a by reference
assignment..

function bar( string $a) {}
function foo( string &$a ) {}

$a = 5.3;
foo( $a ); // Works, $a is a scalar, so it type adjusts.
var bool $b = false;
foo( $b ); // TypeError, $b is boolean, function expects to receive a
string by reference.
bar($b); // Works since the pass isn't by reference, so the type can be
adjusted for the local scope.


CONCLUSION
I believe that covers all the bases needed. This will give those who want
things to use strong typing better tools, and those who don't can be free
to ignore them.

[PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

[Michael Morris]

I would like to propose a clean way to add some strong typing to PHP in a
manner that is almost fully backward compatible (there is a behavior change
with PHP 7 type declarations). As I don't have access to the add RFC's to
the wiki I'll place this here.

Before I begin detailing this I want to emphasize this syntax is optional
and lives alongside PHP's default scalar variables. If variables aren't
declared using the syntax detailed below than nothing changes.  This is not
only for backwards compatibility, but it's also to keep the language easy
to learn as understanding datatypes can be a stumbling block (I know it was
for me at least).

VARIABLE DECLARATION

Currently the var keyword is used to formally declare a variable.  The
keyword will now allow a type argument before the var name as so

var [type] $varname;

If the type is omitted, scalar is assumed.  If Fleshgrinder's scalar RFC is
accepted then it would make sense to allow programmers to explicitly
declare the variable as a scalar, but in any event when the type is omitted
scalar must be assumed for backwards compatibility.

The variables created by this pattern auto cast anything assigned to them
without pitching an error. So...

var string $a = 5.3;

The float of 5.3 will be cast as a string.

For some this doesn't go far enough - they'd rather have a TypeError thrown
when the assignment isn't going to work.  For them there is this syntax

string $a = "Hello";

Note that the var keyword isn't used.


FUNCTION DECLARATION

PHP 7 introduced type declarations.  This RFC calls for these to become
binding for consistency, which introduces the only backward compatibility
break of the proposal.  Consider the following code.

function foo ( string $a ) {
  $a = 5;
  echo is_int($a) ? 'Yes' : 'No';
}

Under this RFC "No" is returned because 5 is cast to a string when assigned
to $a. Currently "Yes" would be returned since a scalar has the type that
makes sense for the last assignment.

I believe this is an acceptable break for two reasons. 1, the type
declaration syntax is relatively new.  2, changing the type of a variable
mid-function is a bad pattern anyway.


OBJECT TYPE LOCKING

Currently there is no way to prevent a variable from being changed from an
object to something else. Example.

$a = new SomeClass();
$a = 5;

If objects are allowed to follow the same pattern outlined above though
this problem is mostly solved..

SomeClass $a = new SomeClass();
var SomeClass $a = new SomeClass();

QUESTION: How do we handle the second auto casting case? $a is not allowed
to not be a SomeClass() object, but there are no casting rules. We have
three options:
1. Throw an error on illegal assign.
2. Allow a magic __cast function that will cast any assignment to the
object.
3. Create a PHP Internal interface the object can implement that will
accomplish what 2 does without the magic approach.

Note that 1 will need to occur without implementation. 2 and 3 are not
mutually exclusive though my understanding is PHP is moving away from magic
functions.


CLASS DECLARATION
Again, by default class members are scalars. The syntax translates over
here as might be expected.

class SomeClass {
  public var string $a;
  protected int $b;
  private SomeOtherClass $c;
  public var SomeThirdClass $d;
}

Note a default value doesn't need to be provided.  In the case of object
members, these types are only checked for on assignment to prevent
recursion sending the autoloader into an infinite loop.

Also note that one of the functions of setters - guaranteeing correct type
assignment - comes free of charge with this change.


COMPARISON BEHAVIOR
When a strongly typed variable (autocasting or not) is compared to a scalar
variable only the scalar switches types. The strict comparison operator is
allowed though it only blocks the movement of the scalar.

Comparisons between strongly typed variables are always strict and a
TypeError results if their types don't match. This actually provides a way
to force the greater than, lesser than, and spaceship operation to be
strict.


FUNCTION CALLING
When a strong typed variable is passed to a function that declares a
variable's type then autocasting will occur so long as the pass is not by
reference.  For obvious reasons a TypeError will occur on a by reference
assignment..

function bar( string $a) {}
function foo( string &$a ) {}

$a = 5.3;
foo( $a ); // Works, $a is a scalar, so it type adjusts.
var bool $b = false;
foo( $b ); // TypeError, $b is boolean, function expects to receive a
string by reference.
bar($b); // Works since the pass isn't by reference, so the type can be
adjusted for the local scope.


CONCLUSION
I believe that covers all the bases needed. This will give those who want
things to use strong typing better tools, and those who don't can be free
to ignore them.

Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type

[Michael Morris]

This was supposed to go to the list as well.

On Mon, Jan 1, 2018 at 6:15 AM Michael Morris <tendo...@gmail.com> wrote:

> On Mon, Jan 1, 2018 at 6:01 AM Lester Caine <les...@lsces.co.uk> wrote:
>
>> On 31/12/17 22:45, Michael Morris wrote:
>> > Please do not quote large swaths of Tony Marston's crap.  He's an
>> > unrepentant liar, braggart and trouble maker that most of the list has
>> > on ignore since the admins can't be bothered to do their job and kick
>> him.
>>
>> I'll ignore the slander ...
>>
>
> Before the admins come yelling at me over list rules I want to point out
> that was sent to you personally, not to the list as a whole.
>
> As for the rest of your reply, for both backwards compatibility and ease
> of learning reasons it is impossible to change PHP into a strongly typed
> language. No one has proposed that, at least not me. What I and several
> others have proposed is making strong typing available to those who want it
> in a manner that is backwards compatible. Argue against that if you must.
>
>>
>>
>>

Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type

[Michael Morris]

On Sat, Dec 30, 2017 at 5:37 AM, Lester Caine  wrote:

>
> Not being able to vote, many of us have no option to complain about the
> way things are going. Currently there seems to be several styles of PHP
> form the nice and simple untyped version I moved to from very strictly
> typed hard compiled code I'd been using up until then, through to
> current code which is reliant on third party things like PSR and
> Composer and expects only strictly typed PHP.
>
>

This is born of the fact that while ignoring datatype makes learning PHP
easier, it makes using it harder - especially when testing.

Mark me as against union types. First, it places the burden of getting the
type right on the calling programmer. Stock PHP code doesn't do this and if
popular 3rd party libraries start doing this too much it makes the language
harder to learn.

Second it blocks this proposal, which is a way to give people who want to
control types the ability to do so in their own code without creating BC
breaks in PHP or interoperability problems with other libraries. Doing this
requires declaring variable types as an OPTION.  The default type of a
variable will be scalar.

Under what I propose putting what is now a type hint on the function line
will become a type declaration, and a casting operation will result if the
wrong type is passed in. So

function foo( int $a ) {}

Obviously this path becomes unavailable to us with union types - and by
comparison union types is an ineffective band-aid. The above is a shorthand
for this

function foo ( $arg ) {
  var int $a = $arg;
}

When a variable is declared this way it will autocast any assignment to the
declared type. The only way to get around this is redeclare the type.

Now some might be wondering, why not use this shorter statement:

int $a = 3;

The reason is this - I propose that syntax will lock the type down, but it
won't autocast assignments - it iwll instead throw a TypeError if the
assignment type doesn't match.

Anyway, there is one BC break - see it?

function foo( int $a ) {
  $a = 'hi';
}

Currently $a becomes a string of 'hi'. Under this proposal $a remains an it
and it is assigned the cast result of 'hi', which I believe is 0. Since the
format is relatively new - PHP 7 - changing it in 8 won't be as disruptive
as something that's been around a long time. Also, changing a var type
deliberately after declaring it is a bad practice, further reducing the
scope of code affected, but it's certainly not 0, so this is PHP 8.0
minimum.

Now next, class instance creation.

SomeClass $a = new SomeClass();

Doing this locks $a to SomeClass, and trying to assign it to something else
will trip a type error.

var SomeClass $a = new SomeClass();

Since there's no way to cast arbitrary arguments to SomeClass I'm not sure
how this should be handled.

Within classes..

class SomeClass {

  public $a = null; // Creates a scalar.

  public var int $b = 3; // Creates an autocasting int

  protected int $c = 5; // Creates an int. Errors will pitch on bad assign.

  protected OtherClass $b;

}

This syntax locks down, or *really* locks down types, but it's entirely
opt-in. If we're going to go down the road of sticter types this has to be
done.  It's also an example of why pasting in functionality without an
over-arching plan is a bad idea.  If Union types is included part of this
solution will be forever lost since it's likely incompatible with union
types (or at least union types with scalars - union types with objects
wouldn't be affected).

Re: [PHP-DEV] instanceof survives non-object variables, but crashes on non-object constants.

[Michael Morris]

What would it hurt to allow instanceof to return types other than object?

$x instanceof NULL
$x instanceof string

and so on.  This would be more powerful and useful than throwing an error
where one wasn't being thrown before. It also would let one operator detect
all the types, rather than the plethora of detect functions we currently
have.

On Tue, Dec 19, 2017 at 4:48 PM, Nikita Popov  wrote:

> On Sat, Dec 9, 2017 at 7:28 AM, Andreas Hennings 
> wrote:
>
> > The following (https://3v4l.org/A2Tp6) is ok, it simply returns false:
> >
> > $x = 1;
> > $x instanceof \stdClass;
> >
> >
> > The following (https://3v4l.org/IdSBu) gives a fatal error:
> >
> > 1 instanceof \stdclass;
> >
> > t think this behavior is inconsistent, and we should consider changing
> it.
> >
> > There are two options, but only one is BC.
> >
> > - Let 1 instanceof \stdClass return false, instead of crashing. -> seems
> BC
> > - Let $x instanceof \stdClass crash, if $x is not an object. -> BC break.
> >
> > So it seems the first would the option we should take.
> > This is also what hhvm does, according to https://3v4l.org/IdSBu.
> >
>
> I've prepared a PR for this change: https://github.com/php/php-
> src/pull/2978
>
> From the discussion I'm understanding that our consensus is to implement
> this change, so if there are no further objection I'll merge this in a few
> days.
>
> Nikita
>

Re: [PHP-DEV] [RFC] Mixed Typehint

[Michael Morris]

On Mon, Dec 18, 2017 at 10:34 PM, Michael Moravec 
wrote:

> Hello internals,
>
> I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3:
> https://wiki.php.net/rfc/mixed-typehint
>
> The purpose of this RFC is to introduce "mixed" typehint on language level
> to be used
> as a valid typehint.


If I'm not mistaken, "mixed" is used in documentation when a function has
been overloaded to avoid needing to have documentation for all the methods.
C allows overloading, and I imagine that PHP functions implemented in the
engine using C are using overloading.

To be honest, I'd rather see function overloading in PHP than this, but
that's a massive can of worms with a lot of problems on both the
implementation side and also on the usage side. Function overloading can be
abused to create some rather bizarre and difficult to follow code.  That
said, with PHP moving to be at least a little more strict about variable
types.

As to the proposal itself, I see no advantage over not using a typehint at
all.

More on overloading: https://en.wikipedia.org/wiki/Function_overloading

Re: [PHP-DEV] Changes in namespace importing

[Michael Morris]

I'm sure the internal coders will correct me if I'm wrong on this, but as I
understand it PHP has no notion of packages, yet many calls to modify how
namespace importing works seem to be under the illusion that packages
exist. This is understandable, packages are namespaces are terms used
somewhat interchangeably. However, they aren't the same.  In Java,
Actionscript 3, and I presume C++ and C# when you import a package you are
binding it to the resultant executable the compiler will create. This will
affect the size of that executable regardless of how much of the package
gets used, or even if it gets used.

PHP has packages, but they are compiled in when the interpreter is compiled
and set up on the machine. Adding a package in PHP requires redoing that
compile step and modifying the php.ini to enable the associated .so file.
As for libraries looked up by composer - these are never referenced until
they are called for at runtime and the autoloader gets invoked.

As a result of this PHP's "namespace" resolution is nothing more than a set
of string replace rules done at call time to try to resolve the name to a
known class. It's a convenience shorthand for programmers, but a powerful
one. Also, it has it's limitations.

On Fri, Nov 24, 2017 at 8:21 AM, Rowan Collins 
wrote:

> On 24 November 2017 07:05:52 GMT+00:00, "Khawer ." 
> wrote:
> >We use 'use' keyword to import other namespaces, namespace classes,
> >namespace functions, and namespace constants.
> >
> >Example
> >1) use abc; (Import abc namespace)
> >2) use abc\ClassB; (Import ClassB  from abc namespace)
>
> Although these are described in the manual as separate types of import,
> they are actually the same: they alias a prefix used to rewrite class names
> when you mention them.
>
> If you have a class "One\Two\Test" and a class "One\Two", then "use
> One\Two" will allow you to access them as "Two\Test" and "Two",
> respectively. https://3v4l.org/nQ7pB
>
> Similarly, if you alias a prefix with "use Foo as Bar", then "new
> Bar\Test" will refer to class "Foo\Test", and "new Bar" will refer to class
> "Foo". https://3v4l.org/2r6WN
>
> So "use class" wouldn't make sense, because that's not actually what
> happens.
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Proposal: Rename image functions

[Michael Morris]

No. Hell no. The last thing PHP needs is an ill thought out string of
function name changes to further pollute the global name space. Further,
merely changing the names isn't going to do anything.

What would help is a massive clean and redo for PHP 8 in the same vein as
Actionscript 2 to 3 had a massive cleanup.  Namespaces give us the means to
do it along with the import keyword - but it would be painful to write the
code and I don't think anyone is willing to do it.

The strategy would be to put all existing global namespace functions into a
new namespace:  PHP\Legacy

Then add an import keyword. Similar to use, import pulls the designated
namespace into the current namespace.

Then, for backward compatibility, add a php.ini setting that runs "import
PHP\Legacy" at the start of each script.

Then create the new functions, separated and organized by namespace.  For
example. PHP\String\split.

And while doing this, decide once and for all whether it's haystack, needle
or needle, haystack damn it.

On Sun, Nov 5, 2017 at 4:36 PM, Johannes Schlüter 
wrote:

> On So, 2017-11-05 at 14:51 +0100, Peter Kokot wrote:
> > Hello all,
> >
> > correct me if I'm wrong, but wouldn't be a good practice to follow
> > the
> > currently set coding standards?
> > https://github.com/php/php-src/blob/master/CODING_STANDARDS
>
>
> That is good for new code. But breaking 20 years of history for only
> that reason is questionable.
>
> johannes
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] RFC - Array Of for PHP 7

[Michael Morris]

On Thu, Nov 2, 2017 at 3:21 PM, Larry Garfield 
wrote:

>
> While I normally strongly agree with supporting all traversables, not
> just arrays, in this case I don't think it works.


Hmm.. You're right. Traversables would be best served by having another
method to indicate their return type as part of the interface. Adding this
to the existing traversable interface would be BC breaking. A new interface
would be best and having another interface isn't without precedent -
countable already exists.

This new interface would the PHP engine on what to do.

So, what about this syntax

$a instanceof string[]

If the engine sees this and it's an array, all the values are checked to
see if it's a string.

Else if $a references a generator, the return type definition of the
generator will be checked, and a failure will occur if the generator
doesn't declare its return type.

Else if $a references an object and that object implements the
SingleReturnType* interface then the method of that interface,
getReturnType() is queried and it's return is checked to see if it matches.
In the above case 'string' would need to be returned.

I leave it to people smarter than me to find the holes in the above, but
this moron thinks it might work.

* Someone smarter than me can come up with a better name too :P

Re: [PHP-DEV] RFC - Array Of for PHP 7

[Michael Morris]

Drupal 8 accomplishes this through assert() and a helper class.

function foo ( array $a ) {
  assert( Inspector::assertAllStrings( $a ));
}

This could be improved by having an collectionof operator similar to the
instanceof operator.

function ( array $a ) {
  assert( $a collectionof string );
}

I say "collectionof" because while arrays are the most common traversable
objects, they aren't the only ones.  The above approach, combined with the
existing assert structure, can provide the dev time checking of the code
while in under development, and it can be turned off in production. Or it
can be used outside of assert to be checked at all times.

Since this invokes a new keyword I think that would mean this solution
would be PHP 8.

Brackets might be used with instance of to notify it to traverse down one
level maybe??

function ( array $a ) {
  assert( $a instanceof [string] );
}

This avoids any BC issues, but it looks odd.  Not as odd as \ for a
namespace operation :P  But odd.


On Wed, Nov 1, 2017 at 10:40 AM, Rowan Collins 
wrote:

> On 31 October 2017 17:37:17 GMT+00:00, Levi Morrison 
> wrote:
> >  - Our current infrastructure requires us to check every element of
> >the array for conformance. While undesirable I believe this can be
> >optimized away in the future if we care enough, and therefore not a
> >show-stopper.
>
> Do you have a mechanism in mind for "optimising this away"? I think
> releasing the feature without any optimisation will just lead to painful
> slowdowns when people use it without realising the implications.
>
> As I said in my previous message, it seems to be a fundamental issue with
> PHP's current type declarations that they are a) runtime, and b) asserted
> at arbitrary points, not at assignment. So even if you optimise the check
> slightly, it's still a separate check every time you enter a new function,
> which puts a limit on optimisation.
>
> The only way I've thought of to improve things is to cache the result of
> previous type checks, but this comes with all the normal challenges of
> caching. For instance, all assignments into the array would need to
> invalidate these cached checks, or check the new value against each.
> References would be particularly tricky, as they were with the property
> type hint proposal.
>
> If we selectively invalidated cached checks, we'd be running specific type
> checks at every variable assignment, but not letting the user actually
> assert on those checks. At which point, should we approach from the other
> direction, and let the user declare variable types, rather than assert
> value types?
>
> This is kind of implied if we implement generics, too, since explicitly
> constructing an instance of list is asking the runtime to check future
> assignments to members of that list. In effect, could declaring "int $foo =
> 42;" be considered equivalent to "$foo = new checkedScalar(42);"?
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Re: Wouldn't Exception::getContext() be useful?

[Michael Morris]

Just for debugging. I've been mulling over how to improve exception/error
handling in Drupal 8 out of the box.

On Sat, Oct 21, 2017 at 10:31 AM, Rowan Collins <rowan.coll...@gmail.com>
wrote:

> On 21 October 2017 11:41:46 BST, "Christoph M. Becker" <cmbecke...@gmx.de>
> wrote:
> >On 21.10.2017 at 09:20, Michael Morris wrote:
> >
> >> Right now the only way I know of to see the context of an exception
> >throw
> >> is to pass it in..
> >>
> >> throw new CustomException(get_definted_vars());
> >>
> >> It would be very useful to have exceptions just have this as a
> >method.
> >> set_error_handle had this ability, but it's now deprecated.  I'm
> >guessing
> >> there's an engine reason why this hasn't happened because it seems
> >like a
> >> pretty obvious include to the default methods of the Exception and
> >Error
> >> objects.
> >
> >Quite likely the same reasoning as for deprecating the $errcontext
> >argument applies, see
> ><https://wiki.php.net/rfc/deprecations_php_7_2#
> errcontext_argument_of_error_handler>.
>
>
> See also my posts about the problems of capturing arguments in the
> exception's backtrace (sorry, don't have an archive link to hand).
> Basically, holding references to objects without user interaction makes
> object lifetimes unpredictable and serialization unexpectedly fail.
>
> Did you just want this for debugging, or was there some other use case?
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] Wouldn't Exception::getContext() be useful?

[Michael Morris]

Right now the only way I know of to see the context of an exception throw
is to pass it in..

throw new CustomException(get_definted_vars());

It would be very useful to have exceptions just have this as a method.
set_error_handle had this ability, but it's now deprecated.  I'm guessing
there's an engine reason why this hasn't happened because it seems like a
pretty obvious include to the default methods of the Exception and Error
objects.

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

[Michael Morris]

On Thu, Sep 14, 2017 at 8:33 AM, Lester Caine  wrote:

> UTF8 introduces a level of complexity and can be used used in many
> places in PHP, but it does seem that there is no drive these days to
> make the core a clean UTF8 environment. This should perhaps be addressed
> again for PHP8?
>
>
*Cough*, *Cough*, PHP 6, *Cough*, *Cough*.

Comedy aside, Full UTF functionality was planned for PHP 6 and ended up
sinking the branch because it was way more complicated that anyone realized
at first. Someone involved with the development at that time can speak to
it more accurately - all I know is hearsay and conjecture.

Re: [PHP-DEV] Consider only ignoring newlines for final ?> in a file

[Michael Morris]

On Thu, Sep 7, 2017 at 10:23 AM, Andrea Faulds  wrote:

> What I want to change is how it behaves in other circumstances, i.e.
> templating.
>
> Thanks.
>
>
I get that, but I can think of one example where this innocent change might
BC break something.  You cite this change being for templating - this
implies the php files with this feature are being loaded by another php
file with require() or include(). Suppose someone creates a template
wrapper with this circumstance in mind. Instead of doing the obvious, omit
the final ?> tag in the template, they write code in the template wrapper
to snip the last endline character from the included file. Depending on how
their code is written your change could now become a breaking change: for
example they just lop off the last character of the template's return
without checking to see if it is indeed a newline character.

Re: [PHP-DEV] Consider only ignoring newlines for final ?> in a file

[Michael Morris]

>
>
> Would anyone object to me changing how PHP handles this so that only the
> final ?> tag consumes its following newline, and only at the end of the
> file?
>
>
Captain Obvious here. It has long been the policy of many large PHP
projects to not close the last PHP tag for this reason. This change
wouldn't affect them. It risks affecting projects without this policy, and
those tend to be older and often private.

Re: [PHP-DEV] http_cookie_set and http_cookie_remove

[Michael Morris]

On Tue, Jul 18, 2017 at 3:11 PM, li...@rhsoft.net <li...@rhsoft.net> wrote:

>
>
> Am 18.07.2017 um 21:02 schrieb Michael Morris:
>
>>
>>
>> On Tue, Jul 18, 2017 at 2:56 PM, li...@rhsoft.net > li...@rhsoft.net> <li...@rhsoft.net <mailto:li...@rhsoft.net>> wrote:
>>
>>
>>
>> Am 18.07.2017 um 20:39 schrieb Michael Morris:
>>
>> Personally, I no longer directly use these calls, preferring
>> instead to use
>> Symfony's HTTP foundation classes. Those in turn are, I
>> understand, in the
>> process of being converted to implement the common interface
>> outlined here:
>> http://www.php-fig.org/psr/psr-7/
>> <http://www.php-fig.org/psr/psr-7/>  I would be much more
>> interested in
>> seeing a bare bones implementation of that agreed on standard in
>> the
>> language core then seeing something entirely new, especially a
>> band aid
>> solution
>>
>>
>> but why do you do this?
>>
>>
>> Because I want to be done in a matter of hours or at most days instead of
>> a matter of weeks or months. I've been down the "roll your own" road many
>> times. It usually isn't worth it
>>
>
> it is when done right
>

Whatever Tony.

* Over the top claims, check.
* Condescending remarks, check.
* Superior attitude problem, check.

Yeah, I'm calling alt account.  On the off chance you aren't Tony, you're
still the type of person I don't have time for in my life. To the block
list you go.

Re: [PHP-DEV] http_cookie_set and http_cookie_remove

[Michael Morris]

On Tue, Jul 18, 2017 at 2:56 PM, li...@rhsoft.net <li...@rhsoft.net> wrote:

>
>
> Am 18.07.2017 um 20:39 schrieb Michael Morris:
>
>> Personally, I no longer directly use these calls, preferring instead to
>> use
>> Symfony's HTTP foundation classes. Those in turn are, I understand, in the
>> process of being converted to implement the common interface outlined
>> here:
>> http://www.php-fig.org/psr/psr-7/  I would be much more interested in
>> seeing a bare bones implementation of that agreed on standard in the
>> language core then seeing something entirely new, especially a band aid
>> solution
>>
>
> but why do you do this?
>
>
Because I want to be done in a matter of hours or at most days instead of a
matter of weeks or months. I've been down the "roll your own" road many
times. It usually isn't worth it.

Re: [PHP-DEV] http_cookie_set and http_cookie_remove

[Michael Morris]

Personally, I no longer directly use these calls, preferring instead to use
Symfony's HTTP foundation classes. Those in turn are, I understand, in the
process of being converted to implement the common interface outlined here:
http://www.php-fig.org/psr/psr-7/  I would be much more interested in
seeing a bare bones implementation of that agreed on standard in the
language core then seeing something entirely new, especially a band aid
solution.

On Tue, Jul 18, 2017 at 1:49 PM, Andrey Andreev  wrote:

> Hi Andreas,
>
> On Tue, Jul 18, 2017 at 7:39 PM, Andreas Treichel 
> wrote:
> > Hello Andrey,
> >
> >>> $options are equal to the optional parameters of setcookie and
> >>> setrawcookie.
> >>> $options may contain:
> >>>
> >>> expires: int
> >>> path: string
> >>> domain: string
> >>> secure: bool
> >>> httponly: bool
> >
> >
> >> 1. The wording here implies that these are the *only* attributes
> >> allowed. In the interest of forward-compatibility, I'd allow arbitrary
> >> attributes as well.
> >
> >
> > This are the only supported options in the current implementation. Future
> > extension like samesite cookies can add more options. Unknown options are
> > ignored and trigger a warning.
> >
>
> That's what I was afraid of, and what I suggested be changed.
>
> If we had a similar, array-of-attributes API that did NOT ignore or
> trigger warnings for unknown attributes, everybody using PHP would've
> been able to use SameSite already.
>
> >>> encode is an additional option to remove the requirement of a raw and
> non
> >>> raw function.
> >>>
> >>> encode: int
> >>> HTTP_COOKIE_ENCODE_NONE (same as setrawcookie)
> >>> HTTP_COOKIE_ENCODE_RFC1738 (same as setcookie)
> >>> HTTP_COOKIE_ENCODE_RFC3986
> >
> >
> >> 2. I don't think this is necessary, nor that it belongs in the $options
> >> array.
> >
> >
> > Most users dont know the correct encoding for cookies. This idea is from
> the
> > $enc_type parameter of http://php.net/http_build_query. The
> documentation of
> > http_cookie_set() should explain it the same way.
> >
> > Maybe i can move it out of the $options array and add an extra parameter
> for
> > the encoding, if the $options are the wrong location for this.
> >
>
> On another note, I'd also move the 'expire' option to a separate
> parameter and remove $options to $attributes.
>
> 'expire' is not a known cookie attribute; PHP uses it to calculate the
> Expires and Max-Age attributes ...
>
> >
> >> Anybody who'd use it, would have to read RFC1738 and/or RFC3986 to
> >> know what they do.
> >
> >
> > This is the same as setcookie(). No one has to read the rfc, which is not
> > interested as it exactly works. HTTP_COOKIE_ENCODE_RFC1738 is the default
> > for the encode option and encode the value the same ways as setcookie
> encode
> > it.
> >
> > the default values for the options are the same as thr parameters for the
> > current setcookie(). The default values for the $options:
> >
> > expires: int, default: 0
> > path: string, default: ""
> > domain: string, default: ""
> > secure: bool, default: false
> > httponly: bool, default: false
> > encode: int, default: HTTP_COOKIE_ENCODE_RFC1738
> >
> >
> >> And as the constant names aren't particularly short either, it is
> >> easier for me to just apply an encoding function directly to $value
> >> before passing it.
> >
> >
> > The current names of the constants are not short, but in most cases i
> think
> > you dont need it.
> >
> >
> >> Also, RFC 6265 (section 4.1.1) only mentions Base64 as a suggestion
> >> for encoding (and that's a SHOULD).
> >> Link: https://tools.ietf.org/html/rfc6265#section-4.1.1
> >
> >
> > http_cookie_set() use the same encoding per default as setcookie().
> >
>
> Sorry, but this is kind of pointless then. I liked your proposal,
> because it's a chance to have a shiny new API that doesn't come with
> all the legacy stuff already built into setcookie().
>
> But if we want an array-based setcookie() alternative without changing
> anything else, we can just change setcookie() to accept arrays. In
> hindsight, if this is really what you wanted, then I have to agree
> with Dan - that is building on foundation of sand.
>
> Cheers,
> Andrey.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] Allow else after loop structures for,foreach and while?

[Michael Morris]

Reading the array coalesce operator concept thread I thought of this. I
think I've seen in another language but I'm not sure.  Anyway, here goes...

Allow else blocks to follow iteration blocks.  The else block is executed
if no iteration occurs for any reason.

foreach ($array as $key => $value) {
  echo 'Result ' . $key . ' with value: ' . $value . "\n";
}
else {
  echo 'No results';
}

There's no reason why this can't be allowed with for and while as well.
Obviously do while loops won't be allowed to use this since they always
execute at least once.

Like the proposal I was reading when I thought about this is largely syntax
sugar to make things slightly easier to read and less verbose than the
alternative.

if (count($array) > 0) {
  foreach ($array as $key => $value) {
echo 'Result ' . $key . ' with value: ' . $value . "\n";
  }
}
else {
  echo 'No results';
}

However the above existing solution doesn't allow $array to be a
traversable but non-countable object. We can add other checks, but the
verbosity increases.

Back to the issue I was reading when I was reading this, it might be
possible to allow foreach/else to take a non array argument without
tripping off a warning. In that case the expectation is that the programmer
gets to control the response, or elect to have no response with else {}

Re: [PHP-DEV] RFC proposal

[Michael Morris]

On Fri, Jun 2, 2017 at 1:36 PM, Rowan Collins <rowan.coll...@gmail.com>
wrote:

> On 2 June 2017 18:21:34 BST, Levi Morrison <le...@php.net> wrote:
> >On Fri, Jun 2, 2017 at 11:12 AM, Michael Morris <tendo...@gmail.com>
> >wrote:
> >> What about foreach by reference, which is honestly the only time I
> >use
> >> referencing anymore...
> >>
> >> foreach ($array as $key => &$value) {
> >>   $value = someOp($value);
> >> }
> >>
> >> Is this also bad?
> >
> >I'm not going to say "bad" but I would not personally write it that
> >way. If the memory cost is too high to duplicate then ...
>
> The times I've used foreach-by-reference have absolutely nothing to do
> with memory cost. Mostly, they're situations where explicitly writing back
> into the original array would be tediously long-winded, like this:
>
> $some_array[$some_outer_key][$loop_key]['foo'] =
> some_func($loop_value['foo']);
> $some_array[$some_outer_key][$loop_key]['bar'] =
> some_other_func($loop_value['bar'], true);
>
> Granted, there are probably major refactorings that would be in some way
> better, but changing $loop_value to a reference gives the much more
> readable:
>
> $loop_value['foo'] = some_func($loop_value['foo']);
> $loop_value['bar'] = some_other_func($loop_value['bar'], true);
>
> References are fiddly, but they do have their uses. Short of eliminating
> mutability, per functional programming, I think they'll always have their
> place, in some form.
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>


Same here.  I was just trying to keep my example simple. I agree that a
generator, or even better array_map, would be a better way to deal with the
simplistic example I gave.

Re: [PHP-DEV] RFC proposal

[Michael Morris]

What about foreach by reference, which is honestly the only time I use
referencing anymore...

foreach ($array as $key => &$value) {
  $value = someOp($value);
}

Is this also bad?

On Fri, Jun 2, 2017 at 10:56 AM, Johannes Schlüter 
wrote:

> On Fr, 2017-06-02 at 15:21 +0200, Bartłomiej Krukowski wrote:
> > Hello,
> >
> > PHP allows for using implicit references in arguments of function. In
> > most common case we have to mark that variable is an reference in
> > head of function, in other case we will receive fatal error (@see
> > example - http://ideone.com/7zkgQQ ). There
> > is an option to use variable as implicit reference (@see example - ht
> > tp://ideone.com/T6oF7C ), I think it should
> > not be possible. Only explicit references should be allowed (except
> > objects).
>
> The argument to the function in the second value is an array which is
> passed by value. A copy of the array keeps the references as
> references. This is consistent. Unless we have typed arrays or anything
> like that the function call shouldn't care about the content.
>
> Aside from that references are a legacy construct and shouldn't be used
> anymore. Using objects or relying on copy-on-write usually leads to
> clearer code, reduced memory and faster execution. (in the past there
> had been a few exceptions where arrays of references were good for some
> graphs/trees with recent improvements to objects this is less the case)
>
> johannes
>
> http://schlueters.de/blog/archives/125-Do-not-use-PHP-references.html
> http://schlueters.de/blog/archives/141-References-and-foreach.html
> http://schlueters.de/blog/archives/180-References-Still-bad-in-PHP-7.ht
> ml
> http://schlueters.de/blog/archives/181-More-on-references.html
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Add is_vectorlike($array) function

[Michael Morris]

For what it's worth, the Drupal assertion inspector calls these "Strict
Arrays" since that's what they are - arrays in the true sense of the term
found in all other languages. What PHP is calling an "array" is more
accurately a "map" or "hash"

There is value in this validation - https://www.drupal.org/SA-CORE-2014-005
relied on the attacker providing an sql injection where the code was
expecting numeric keys.

There's no easy solution - this is just one of those things where PHP is
painted into a corner by backwards compatibility. Calling them vectors just
seems weird though.  Calling them strict arrays at a language level has its
own problems.

On Thu, May 4, 2017 at 7:23 AM, Jesse Schalken  wrote:

> On Tue, May 2, 2017 at 7:55 PM, Rowan Collins 
> wrote:
>
> > +1, I've been thinking of making a similar suggestion. We can bikeshed
> the
> > name (it should certainly start with "array_"), but I think there's a
> very
> > good case for having an optimised implementation built in, given the
> > opportunities for short-cutting based on representation details.
> >
>
> Something like array_is_vectorlike(), array_is_vector() or
> array_is_sequential() sound good to me. You could also do the opposite,
> array_is_assoc().
>
> As an example use case, serialization formats often dynamically switch
> > between an "array"/"vector"/"list", and a "hash"/"dictionary"/"table". I
> > came upon this example recently: https://github.com/php-amqplib
> > /php-amqplib/blob/master/PhpAmqpLib/Wire/AMQPAbstractCollection.php#L218
>
>
> Another reason this function would be of utility is that it would
> discourage even more inefficient implementations that allocate new arrays,
> like the one in that code ("array_keys($val) === range(0, count($val) -
> 1)"), and nearly every single answer to this StackOverflow question (except
> mine):
> https://stackoverflow.com/questions/173400/how-to-check-
> if-php-array-is-associative-or-sequential/
>

Re: [PHP-DEV] Re: [RFC][Discuss] Arrow Functions

[Michael Morris]

On Fri, Feb 3, 2017 at 3:37 PM, Niklas Keller  wrote:
>
>
> There are more drawbacks to that syntax like no parameters looking pretty
> weird: || =>
>
>
I can't think of a valid example of an arrow function without any arguments
at all. These functions are very simple iterators to plug into things like
array_map. If you can think of one please post it.

Re: [PHP-DEV] Re: [RFC][Discuss] Arrow Functions

[Michael Morris]

On Fri, Feb 3, 2017 at 3:34 PM,  wrote:

> I like the suggested syntax. The only drawback I see is that it inhibits
> the future addition of union types for closures:
>
> |int | float $x| => $x
>
> Adding parentheses of course resolves the issue but looks a bit awkward:
>
> |(int | float) $x| => $x
>
> Apart from that I have nothing to complain about. I'd be happy either way.
>

Good point, but union types are going to come up in this context I think.
Remember, these are for one line functions, which highly limits what they
can do.

>
>

Re: [PHP-DEV] Re: [RFC][Discuss] Arrow Functions

[Michael Morris]

On Fri, Feb 3, 2017 at 12:53 PM, Levi Morrison  wrote:
>
> > To that end, I'd like to gauge interest in a pure syntax based
> > alternative that is similar to Rust and Ruby.
> > Instead of:
> >
> > fn(params) => expr
> >
> > What about:
> >
> > |params| => expr
>

Looks great to me from up here in the peanut gallery.

Re: [PHP-DEV] [RFC][Discuss] Arrow Functions

[Michael Morris]

On Tue, Jan 31, 2017 at 12:29 PM, Larry Garfield 
wrote:

> On 01/31/2017 05:14 AM, Bob Weinand wrote:
>
>>
>>> In the case that regular closures got auto-capture, would a
 `use($foo, $bar, $baz)` segment on a closure still be honoured (i.e.
 disable auto-capture), and would it have any impact (positive or
 negative) on performance/memory usage? After several years of JS
 closure ‘fun’ I kind of like that with PHP you only inherit the
 variables you explicitly `use()` in closures.

>>> Wouldn't there be just too many existing closures, which do not use
>>> `use` but (maybe) expect a clean scope?
>>>
>>
>> The RFC is exclusively proposing single-expression short Closures.
>> We do NOT want multi-statement short Closures; it is a *feature* that
>> generic Closures need an "use ($foo, $bar)".
>> This vastly improves readability and debuggability - it basically tells
>> you whether the variables inside the code are imported or not. As Stephen
>> Reay notes:
>>
>>> After several years of JS
 closure ‘fun’ I kind of like that with PHP you only inherit the
 variables you explicitly `use()` in closures.

>>>
>> So, auto-import for generic Closures definitely isn't an option.
>> Just on short, single-line Closures there is no benefit to "use ()", as
>> EVERY variable used in the short Closure is supposed to be an imported
>> variable. There is no point in forcing the user to distinguish between
>> imported and local variable here.
>>
>> Also, using "fn" in favor of "function" has the advantage of less clutter
>> in one line. Compare
>>
>> array_map(fn($x) => $x + 1)
>>
>> to
>>
>> array_map(function($x) => $x + 1)
>>
>> The syntactical construction is already pretty clearly showing what's
>> going on. The "function" keyword itself is already larger than the whole
>> body. It distracts while reading the actual code.
>> Additionally, using "fn" is optically highlighting the fact that it's a
>> short-Closure with auto-import and not a normal Closure with explicit
>> import.
>>
>> Thanks,
>> Bob
>>
>
> I must agree with Bob and the other authors.  The entire point of this RFC
> is to reduce the amount of typing, and therefore reading, that goes into
> using simple closures as first-class values.  Using longer keywords instead
> of shorter ones is counter to that aim.  It sounds like the earlier
> proposal of keyword-less closures isn't technically feasible or it would
> make sense to argue for that.
>
> My question is why there's no mention of HHVM short closures, or the
> previous RFC to take that approach.  See:
>
> https://docs.hhvm.com/hack/lambdas/introduction
>
>
>

For what it's worth I'd rather look at

array_map( $x ==> $x + 1);

than

array_map( fn($x) => $x + 1 )

Not to mention the former isn't a bc break.

Re: [PHP-DEV] Fwd: Type Collection

[Michael Morris]

When I wrote the Assertion Inspector in Drupal 8 much of the library was
concerned with insuring that all members of an array where of type X, so
having a language construct to enforce this would be useful.  I'm no
language architect, but I'll take a crack at it..  We already have this

function foo ( array $myArray )

Can the parser deal with multiple hints like so?

function foo ( array string $myArray )

If so I think that's the most intuitive way of handling it.  If not maybe a
colon?

function foo ( array:string )

Or bracing as some docblocks already do

function foo (array[string] $myArray)

Having typed them out I sorta like the third one since it would allow
multiple types with the pipe operator as seen in another rfc

function foo (array[string | int] $myArray)



On Mon, Jan 30, 2017 at 3:18 PM, Rasmus Schultz  wrote:

> > Basically Foo[] to indicate an array of objects of type Foo
>
> I would be fine with that, as long as it's sugar for array
>
>
> On Sun, Jan 29, 2017 at 4:51 PM, Sebastian Bergmann 
> wrote:
>
> > Am 28.01.2017 um 17:10 schrieb Niklas Keller:
> > > sounds like everything you want is typed arrays?
> >
> > I would love typed arrays. Basically Foo[] to indicate an array of
> objects
> > of type Foo. IDEs such as PhpStorm as well as documentation tools already
> > support this syntax when used in docblocks.
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>

Re: [PHP-DEV] Typed properties problems

[Michael Morris]

On Tue, Jan 17, 2017 at 4:52 PM, Stanislav Malyshev 
wrote:

> Hi!
>
> > That's pretty messed-up right there. At least in the object cases there's
> > an E_WARNING "Creating default object from empty value" - with the array
> > case, nothing, it just converts your boolean into an array. Yikes.
>
> You told PHP you want an array, you get an array.
>
>
Exactly.  Scalars can change datatypes without warning.  That's powerful,
but also migrane inducing when not used properly.

I taught myself PHP. For the first two years I had no real grasp of the
significance of datatypes, and it would be another two before I felt a need
to want to control datatypes.  Strict datatyping makes a language harder to
use for beginners.  Loose datatyping can make debugging harder on veterans.
For that reason PHP should ideally be able to do both.  A step in that
direction was taken in 7 with the strict type declarations for function
arguments and returns.

Applying this to properties would be nice, but the coercion rules for
situations like Stanislav gave are going to be difficult.

Re: [PHP-DEV] [RFC] Abolish 50%+1 Votes

[Michael Morris]

Otherwise - it's a simple majority (>50%, or even just the option that got
> the most votes in case of a 3-way or 4-way vote).
>

There are better options for choices of 3 or more than the most votes
system and I strongly recommend that they be used.  Allow me to present an
example.

Suppose we needed to include new functionality in PHP, and there where
three libraries available to provide it.  A is the oldest and most mature
but hasn't been maintained in awhile. B is a less stable fork but has more
active maintenance.  A & B have the same API.  C is the newest cutting edge
version, but has a different API.

A vote is held.  32% for A, 31% B and 37% for C.  C wins in this scenario
because the majority was split across the two similar choices A & B.  If
ranked choice ballots were used in this scenario B would be eliminated on
the first round and the second choices of those ballots would be examined
with an end result of 58% for A, 42% for C, meaning most of the supporters
of B would settle for A but didn't really like C.

A lot of the bad blood in American politics can be directly linked to this
problem - splitting a majority in 3 or more way races. Political parties
arose specifically to prevent this splitting, but its a case that the cure
is worse than the disease.  I don't think PHP is in any danger of devolving
into this sort of acrimony, but it's still worth avoiding the problem
entirely with ranked choice balloting where appropriate.

Re: [PHP-DEV] Re: [RFC] Abolish 50%+1 Votes

[Michael Morris]

On Thu, Nov 17, 2016 at 5:33 PM, Adam Baratz  wrote:

>
>
> I agree with this. We could end up with a different system if we look at
> this holistically. Also, I'm not sure what the urgency in making this
> change is. I'd rather be thoughtful about a substantive change like this.
>
> It might help to articulate the goals of the voting system. I agree with
> the gut feel that 50%+1 is a weak test, but that really depends on what's
> being tested. If we can articulate goals in the RFC, that will also help
> inform how the community approaches writing RFCs.
>
> I have some concerns that a very high bar will make it difficult to change
> extensions if their users aren't well-represented here.
>
>
My opinion, for what it's worth, is that simple majority should be
sufficient for any non-binding decision - that is a choice that doesn't
have BC breaks and further doesn't create future BC breaks if the measure
is voted out.

Simple majority should also be sufficient if there is no status quo other
than doing nothing and doing nothing isn't a viable choice.

Ranked choice ballots should be used when there are three or more competing
plans of action as it is better for reaching consensus in those situations.

These rules as well as who has a right to vote need to be more clearly
documented somewhere.

Re: [PHP-DEV] Re: [RFC] Abolish 50%+1 Votes

[Michael Morris]

The study of voting systems is a hobby of mine and I've encoding vote
gathering algorithms implementing them before, so this gives me a bit of
insight into the discussion at hand that I would like to share.  The goal
of any voting system is to reach a consensus, and while majority rule
(regardless of the amount of the majority) is appropriate for most issues,
it is not appropriate for all.  Specifically, it fails to work in any
situation where the group is being asked to reach a consensus on three or
more choices.

Ironically the choice put forth in this thread is just such an instance.
Stay at 50%+1, Go to 2/3rds, 3/4ths has been mentioned and 3/5ths is
another commonly required ratio.  Four choices.

The best method for dealing with this situation is a ranked choice ballot
and an instant run off vote. The ballot itself asks the voters to rank
their choices, not just stamp a single one. The votes are counted using the
expressed first choice on the ballot.  If the measure doesn't pass then the
option with the fewest supporters is disqualified. The ballots for that
option are recounted and the 2nd choice is added to the counts. If the
measure still doesn't pass this process is repeated, recursively until
there are only two candidate, in which case the one with the majority wins.

This method doesn't work directly with methods requiring a plurality other
than a simple majority, but it isn't meant to be applied in the same
situations.

I'm putting this forward because I worry the group might paint themselves
into a corner by requiring all issues require a super majority, because
that's going to fall apart when there are three or more possibilities.  The
methods can be combined, using ranked choice to determine which option will
be put up against the status quo, then a super majority vote to determine
if that option will be chosen over the status quo.

​

[PHP-DEV] Type locked variables

[Michael Morris]

Perhaps it's time to revisit the idea of allowing variables to have their
types locked down. The keywords needed are already reserved. So...

string $a = "hello";
int $b = 5;

Once declared this way the variable's type won't change unless it gets
unset. In normal mode PHP will coerce any assignment to the variable to the
desired type. If declare strict types is on then assigning the wrong type
to a variable would raise a type error.

Note this would simplify one of the use cases of setters - insuring the
class member is of a valid type.

The idea of function overloading reminded me of this. I'd consider being
able to do this sort of type lockdown to be prerequisite to having
overloaded functions.

Since this approach is entirely opt in I don't think it would make the
language harder to learn.

Re: [PHP-DEV] function overloading

[Michael Morris]

On Tue, Nov 15, 2016 at 11:14 AM Dominic Grostate <
codekest...@googlemail.com> wrote:

> I think this may have been discussed before, but I was largely dismissed
> because no one though it would be possible to implement.
>
> However assuming it is possible, what is the general feeling towards
> function overloading, as seen in C# and Java?
>
> To me, it saves me coming up with convoluted names for tackle various
> parameter combinations, even though the function/methods themselves all do
> the same thing, as well as saving having to omit type hinting in order to
> manually type check within the function.
>
> The previous RFC on union types attempted to fulfill a similar operation,
> but it failed to go through, but given the support it never the less had,
> I'm hoping that overloading will be more acceptable.
>
> To give an idea of how I'd implement it, I'd first try by hashing the
> function name with the type hints, plus the number of arguments, with
> variadics and references also taken into account on top of handling of
> dynamic arguments.
>
> The exact method is open to implementation, but it is possible to create an
> order priority and conflict resolution to enable overloading, while
> hopefully maintaining backwards compatibility with all existing
> core/ext/user functions.
>
> Please give your thoughts, thanks,
> Dominic
>

Without scalars alone this just becomes a headache to debug. Which function
will be called if the scalar matches none of the function signatures? It's
really to easy to change a variable's type. Casting can help, but it's
still touchy.

[PHP-DEV] Low Hanging Fruit

[Michael Morris]

What are some outstanding bugs that should be relatively easy to fix that
no one has gotten around to? Low hanging fruit as it were for beginning
devs.

Re: [PHP-DEV] [RFC][DISCUSSION] Object type hint

[Michael Morris]

On Mon, Oct 24, 2016 at 3:21 AM, Michał Brzuchalski <mic...@brzuchalski.com>
wrote:

>
>
> 2016-10-24 8:45 GMT+02:00 Michael Morris <tendo...@gmail.com>:
>
>> On Sun, Oct 23, 2016 at 3:39 AM, Michał Brzuchalski <
>> mic...@brzuchalski.com>
>> wrote:
>>
>>
>> https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Comp
>> onent%21Assertion%21Inspector.php/function/Inspector%3A%3Aas
>> sertAllObjects/8.2.x
>>
>
> You're missing is_object on $member in foreach in your implementation
>

Wrong - read the code more carefully. The function is variadic. If only 1
argument is passed then is_object is checked against all members of the
array to test.  If 2 or more arguments are passed than the instanceof
operator is used instead. This operator will return false when testing non
objects.


> and it won't be even needed if there where object type hint.
>
>

Wrong again. The method tests a collection (array or traversable) to see if
each member satisfies its test.  Type hints do not work that way at all.
Even if they did, this code must work under PHP 5.5.

If you're going to criticize someone's code at least read over it
carefully. And it wouldn't hurt to check the unit tests either since they
do exist for this method. See here:

https://api.drupal.org/api/drupal/core%21tests%21Drupal%21Tests%21Component%21Assertion%21InspectorTest.php/function/InspectorTest%3A%3AtestAssertAllObjects/8.2.x

Best practice is to test for interfaces or more rarely classes. This RFC
encourages people to not do this so I'm not in favor of its inclusion.

Re: [PHP-DEV] [RFC][DISCUSSION] Object type hint

[Michael Morris]

On Sun, Oct 23, 2016 at 3:39 AM, Michał Brzuchalski 
wrote:

> Hi all,
>
> I would like to initiate discussion for Object typehint RFC
> https://wiki.php.net/rfc/object-typehint
>
> This feature is developed to provide missing functionality which is needed
> and quite easy to introduce.
> There are many people which I've talked about the benefits of this
> functionality.
>
> For those who doesn't like the idea and think they won't need neither use
> it rather than just saying 'no' they
> please say why other people who want to use that parameter type are wrong,
> for wanting to do that.
>
>
Type hinting, along with the assert statement, provide a means to establish
expectations for a methods. It's part of a coding paradigm known as 'design
by contract' and it's critical for large teams and projects that are used
among multiple teams.

Checking to see if a variable is an object in no way provides a real test
of what can be done with it.  Can it be iterated on? Probably, but not
always. Does a method exist on the object? No way to know without further
testing.

Defining what an object can do is the reason interfaces exist. This is also
why objects are allowed to implement multiple interfaces, so that they can
be labeled according to all the roles they can fulfill.

My principle worry with this RFC is it encourages an anti-pattern - not
using interfaces and thereby not clearly labeling what objects can and
cannot do.

The one situation this might be useful requires additional testing anyway -
that would be a method that will receive objects of one or more classes
that don't have a common interface and rewriting the class to add the
desired interface isn't viable (for example, the objects come from
different packages). In that event though type hinting for an object is
only going to be the first step in determining if the code state is sane,
you'll also need to check if the object belongs to one of the several
classes the code can work with.  This gets even hairier when dealing with a
collection of objects.  I wrote this generic assertion for Drupal 8.

https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Component%21Assertion%21Inspector.php/function/Inspector%3A%3AassertAllObjects/8.2.x

In your own code you'll likely need to do something similar with your
argument.  Incidentally, these sorts of tests, which can only fail if the
code is wrong, are what assert statements are to be used for, not
exceptions. This way the check for correct objects can be turned off in
production to avoid the cpu overhead of the test (assuming your function
doesn't need to switch to different branches depending on the exact object
used).

In summary, -1 to this as it encourages bad code writing.