Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[M. W. Moe]

Hello,

I don't understand why people complain about PHP in term of comparison; if
they like more C# or python why don't just
go there?

historically php is a kind of C like dialect with some perlish running thru
an apache-mod giving the opportunity
to break free from the CGI cumbersome  world; the change-reload-zero-config
was `magic`; writing web-forms
became fast and easy.

PHP has still this advantage (or regain it) fast and dirty; totally hindie.


On Wed, Oct 9, 2019 at 10:58 AM Bishop Bettini  wrote:

> On Wed, Oct 9, 2019 at 12:19 PM Olumide Samson 
> wrote:
>
> >
> >
> > On Wed, Oct 9, 2019, 3:41 PM Bishop Bettini  wrote:
> >
> >> On Mon, Oct 7, 2019 at 5:21 PM Olumide Samson 
> >> wrote:
> >>
> >>> On Mon, Oct 7, 2019, 9:20 PM Claude Pache 
> >>> wrote:
> >>>
> >>> > > Le 7 oct. 2019 à 22:06, Olumide Samson  a
> >>> écrit :
> >>> > >
> >>> > > What's the goal of PHP?
> >>> >
> >>> > One important goal is (like many programming languages) to get work
> >>> done.
> >>> >
> >>> I disagree, coz this seems to be a goal cooked up by you(even if I
> might
> >>> believe in the general idea of that goal, I still can't believe it
> until
> >>> I
> >>> see where it was outlined).
> >>>
> >>
> >> I think the PHP web-site[1] supports Claude's statement:
> >>
> >> "PHP is a popular general-purpose scripting language that is especially
> >> suited to web development.
> >> Fast, flexible and pragmatic, PHP powers everything from your blog to
> the
> >> most popular websites in the world."
> >>
> >> The adjectives used:
> >>
> >>- General-purpose
> >>- Fast
> >>- Flexible
> >>- Pragmatic
> >>
> >> The last one, pragmatic, applies to Claude's point. Various definitions
> >> of pragmatic include:
> >>
> >>- "solving problems in a sensible way that suits the conditions that
> >>really exist now, rather than obeying fixed theories, ideas, or
> rules" [2]
> >>- "of or relating to a practical point of view or practical
> >>considerations." [3]
> >>- "involving or emphasizing practical results rather than theories
> >>and ideas" [4]
> >>
> >> With respect to Mark's proposal, deprecating back-ticks: maybe it's more
> >> pragmatic to have a single, well-defined, and obvious way to invoke an
> >> external process. Sure, yet PHP isn't just "pragmatic". It's also
> flexible
> >> and general-purpose. Flexible is the opposite of rigid, meaning there
> are
> >> circumstances where a second way, or even a third way, may provide more
> >> practical utility than the single canonical interface. General-purpose
> >> means a language is useful in many ways. PHP while "especially suited
> for
> >> web-development" is also useful as an ad-hoc shell scripting language
> and,
> >> in that context, back-ticks are welcomed.
> >>
> >> If we take back-ticks away, we hobble the "quick-scripting for personal
> >> use" flexibility in favor of the enterprise-grade "distributed
> development,
> >> high code-reuse and review" architecture. That seems to run counter to
> the
> >> nature of PHP.
> >>
> >> [1]:https://www.php.net
> >> [2]:https://dictionary.cambridge.org/us/dictionary/english/pragmatic
> >> [3]:https://www.dictionary.com/browse/pragmatic
> >> [4]:
> https://www.macmillandictionary.com/us/dictionary/american/pragmatic
> >>
> >
> > That's written as "features" not "goals", you know what goal is?
> >
> > Goal is like a mission, a statement written to be taken seriously.
> > Checkout python.org you will see an example of what goal is, written
> > clearly as "mission" not "features and what it is/does".
> >
> > I rest my case.
> >
>
> "The main goal of the language is to allow web developers to write
> dynamically generated web pages quickly, but you can do much more with
> PHP." [1]
>
> If you're referring to the mission of the Python Software Foundation, you
> will not find an analogue in the PHP world. PHP does not have a steering
> organization like that. The PHP Group holds copyright, but exercises no
> sanctioned governance. "The people writing the code get to call the shots,
> for better or worse." [2] We are a developer confederation, each individual
> with their own goals who all have a passion for PHP the language, and we
> work as best we can together to achieve them. It'd be nice to elevate our
> confederation to a collective, with a steering board and clear guidance,
> but that's -- perhaps -- a Sisyphean task.
> [1]:https://www.php.net/manual/en/preface.php
> [2]:https://externals.io/message/107079
>

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[M. W. Moe]

Hello,

the point Stanislav is really not about whom; that's about thinking, work,
effort, personal walk thru a problem;
and I am sorry he is fully right; live example:

"I think that's been inconsistencies from the part of early contributors
which is the same reason we are having "haystack and needle" problem and
I'm not sure there's a problem fixing those old days mistake."

is this embodiment of arrogance, vulgarity hence stupidity because to me
they are synonyms helps anyone?

Regards.

On Tue, Oct 8, 2019 at 4:39 PM Mark Randall  wrote:

> On 09/10/2019 00:26, Stanislav Malyshev wrote:
> > That's part of the problem. RFC should be for something that is
> > necessary and beneficial for the whole community, doubly and triply so
> > when we're talking about BC breaks. It shouldn't be just "whatever I
> > want, let me put it to a vote". RFCs are not a twitter poll where
> > anybody can vote on anything and anything goes. It should be used
> > responsibly, and if people don't understand this responsibility maybe
> > it's too early for them to propose any RFCs.
>
> Might I request that you please stick to discussing the actual topic of
> the RFC, rather than trying to shift the conversation towards who can
> and cannot propose RFCs :-)
>
> If you want to discuss changing the RFC mechanics and who is entitled to
> make them, please make your own RFC.
>
> Thank you.
>
> Mark Randall
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[M. W. Moe]

Hello,

what you write and advocate for can't be heard by a vast majority of people
here; because they are just not North-American; somehow
that's a very interesting trait; most of people despise `kind` moralism.


On Tue, Oct 8, 2019 at 2:14 PM Mike Schinkel  wrote:

> > On Oct 8, 2019, at 4:29 PM, Lynn  wrote:
> > My middle ground is a vote, regardless of outcome.
>
> If a vote is the middle ground then why the need to participate in any
> discussion?
>
> Also, how is a vote a middle ground? A vote ensures that one sides wins
> and the other side looses.  IOW, a zero-sum game.
>
> Why does it not make better sense to actively look for ways to optimize
> outcomes so that the most people can win?  For example...
>
> > This RFC is pretty simple, a deprecation + removal in a later patch,
> there's not much to compromise on the implementation.
>
> A compromise might be "NO agreement to remove in a later patch."
>
> Why does it not make sense to offer that up as a consolation to the one
> asking for deprecation?  If they accepted and changed the RFC, then more
> people could get a "win."
>
> > If people think a deprecation should not be done or if it's not worth
> it, a vote is the way to show that opinion.
> > If there are enough reasons to not deprecate them, the voting process
> will show this and the RFC will be rejected.
>
> I have noticed on this list much discussion of the "minority vs. the
> majority."  But that is a red-herring. There are a small number of people
> who have a vote (~200?) whereas there are over 5 million PHP developers and
> even more PHP stakeholders who have no vote.
>
> In other words, when internals@ votes unanimously on an RFC they still
> only represent ~0.004% of PHP stakeholders.  Basically an aristocracy.
>
> So while a vote is a way to share an opinion, it is not representative of
> the opinions of those it may affect.  It is a shame that the PHP voting
> process has no objective way to incorporate userland concerns except when
> some act as their proxy. Which is not the same as userland having explicit
> representatives with a vote.
>
> > PS. We need a CoC.
>
> 100% agree.
>
> -Mike
>
> P.S. I also think PHP needs an agreed statement of principles (Mission,
> Vision and Values.) With said statement RFCs could be evaluated to
> determine if they align with PHP's previously-agreed principles. Such a
> statement could be revised from time to time, but having one would resolve
> a lot of contentious debates before they happen.
>
>
>

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[M. W. Moe]

Hello,

I answered you privately about this kind of false assumptions and
projections. (I have an education)

On Tue, Oct 8, 2019 at 1:38 PM Mike Schinkel  wrote:

> > a middle ground about/with silliness? there is none, for people in their
> right mind; should people really find/force
> > themselves into conciliation about non-sense? I don't think so and
> mostly; I have no say about deprecating that;
> > but is that a priority? does it harm anyone? someone have died from
> backtick infection, it must be according to some?
> > and so on. Don't see where there is a heated topic; solely a reminder
> about reality and facts.
>
> > What would a happy medium be? backticks working 50% of the time?
> > This is like someone being pregnant, either you are or you are not there
> is
> > no half pregnant. Either backticks work like they have in shells for
> decades
> > or they don't work. What's the point of deprecating them without a plan
> to
> > remove them? A notice without future action is a bad idea, as it sets
> > standard that some deprecation messages will not be acted upon.
>
> Well, those are exactly the opposite of the types of responses I had hoped
> for.
>
> Responses that ignore the concerns of others. Responses that (implicitly?)
> insult the intelligence of others. And responses that can only see things
> from one myopic perspective.
>
> These responses highlight perfectly why discussions on this list are so
> contentious.
>
> -Mike

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[M. W. Moe]

@Mike Schinkel,

a middle ground about/with silliness? there is none, for people in their
right mind; should people really find/force
themselves into conciliation about non-sense? I don't think so and mostly;
I have no say about deprecating that;
but is that a priority? does it harm anyone? someone have died from
backtick infection, it must be according to some?
and so on. Don't see where there is a heated topic; solely a reminder about
reality and facts.

Regards.

On Tue, Oct 8, 2019 at 1:12 PM Mike Schinkel  wrote:

> My, my this is a heated topic.
>
> I am commenting in part because I do not have a dog in this hunt.  I am
> okay leaving it, I am okay if it is deprecated.  There are other things for
> PHP that I care far more about than this RFC.  So...
>
> I am wondering if everyone participating in this discussion would be
> willing to ask themselves "Is there any middle ground where I can respond
> in a way that is win-win for everyone involved?" rather than retreating to
> each other's respective corners and fighting as if to the death?
>
> If I did not know better I would think this group was filled with members
> of the US Congress because of the unwillingness to compromise and seek
> common ground.
>
> For example, would those who oppose this RFC change to support it if this
> was changed from:
>
> > Although the deprecation notice itself will carry no backwards
>
> > compatibility changes, this RFC is written with the intent that the
>
> > backtick operator would eventually be removed in a later version
>
>
> To this?:
>
> The deprecation notice will carry no backwards compatibility changes.
> In addition this RFC is explicitly not recommending removal of the
> backtick operator in a later version. To remove it — if ever desired —
> will require an additional RFC to be passed.
>
>
> Maybe the above resolves the objections against this RFC?  Or maybe the
> above makes it useless in the minds of those who want to get rid of
> backtick? But this specific FRC does not matter to me
>
> The point however, is can we not work to some form of happy medium rather
> than everyone fighting a zero sum game?
>
> -Mike
> #jmtcw

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[M. W. Moe]

Hello,

would say intellectually speaking I could accept the argument of
time\investment\code however
in reality figuring out for someone having a minimum of shell experience in
that case, would figure
out in 5 minutes if he is very slow minded;  none the less,  learning new
features, new apis, that's
the life of a software developer; once again there is a discussion about a
mosquito with very strong
arguments made about hypothetical difficulties.

There are far more complex  and mind challenging  topics which are
disregard; which would ask thoughts
on the long term; in profit of minor issues thrown into the arena with no
more than a 5 minutes thinking.

Regards.

On Tue, Oct 8, 2019 at 5:24 AM Claude Pache  wrote:

>
>
> > Le 8 oct. 2019 à 12:24, Reindl Harald (privat)  a
> écrit :
> >
> >
> >
> > Am 08.10.19 um 11:00 schrieb Claude Pache:
> >> * People trying to deactivate functions executing external programs
> (such as `shell_exec`) using the "disable_function" ini directive,
> wondering how to deactivate the backtick operator (since there is no
> `disable_operator` directive)
> >
> > would you at least mind to back your claims by a simple test?
> >
> > Warning: shell_exec() has been disabled for security reasons in
> > /mnt/data/www/www.rhsoft.net/test.php on line 1
> >
> > [harry@srv-rhsoft:/www/www.rhsoft.net]$ cat test.php
> > 
>
> Hi,
>
> I think you missed my point. I wasn’t claiming that there is any technical
> difficulty in disabling the backtick operator. I am claiming that people
> take time wondering how to do that, searching for the solution, and
> discovering that they just need to disable `shell_exec`.
>
> More generally, people take time in understanding the peculiarities of
> that uncommon feature which is the backtick operator. This is a real cost.
> Another example that is popping in my mind is:  Does the operator supports
> variable interpolation (like double-quoted strings) or not (like
> single-quoted strings). (Please, don’t lose time in answering that
> question. The simple answer is: Just use `shell_exec()` with the type of
> quotes you mean, and: Tell everybody to just use `shell_exec()` with the
> type of quotes they mean.)
>
> —Claude
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[M. W. Moe]

do you think because it's short you'll lose your virginity. I am sorry
about the vulgarity; but your stand is stand is ridiculous.

On Sat, Oct 5, 2019 at 4:04 PM Olumide Samson  wrote:

> I think something that deals with system commands should be highly obvious
> and should not be allowed through shortcut syntax that made it easy to be
> hidden amongst codes for many security reasons.
>
> There's already a popular way without hidden syntax and which speaks of
> itself in a verifiable way called "exec", I'm not saying we should have it
> removed just because it isn't obviously popular or it doesn't affect
> anything for now; my argument is since we are moving to Version 8 of PHP,
> it should be deprecated for exec usage since they both do same thing and
> exec is highly obvious as a command function.
>
> This isn't high cost breaking changes coz it has a verifiable, ready
> alternative to upgrade to without huge Regex searches.
>
> Thanks,
> Samson.
>
> On Sat, Oct 5, 2019, 9:26 PM Andreas Hennings  wrote:
>
> > The first time I saw the backtick operator in code, I thought it must
> > be some kind of ancient alternative syntax for string literals.
> > (and no, I did not know that these are called "backticks")
> >
> > When I learned that code "quoted" in this way is immediately executed
> > as shell commands, this seemed like a completely insane and reckless
> > language design.
> >
> > In most projects, executing shell commands should be something rare,
> > and the few cases where it happens should be visible and searchable.
> >
> > Perhaps a legitimate use case would be a file that is essentially a
> > shell script with some PHP sprinkled in.
> >
> > But overall I think we should rather get rid of this feature.
> >
> >
> > On Sat, 5 Oct 2019 at 22:02, Lynn  wrote:
> > >
> > > > Hi!
> > > >
> > > > > This is true, if you know they are called a backtick. It's not a
> > > >
> > > > I think it's reasonable to expect some minimal level of knowledge
> from
> > > > the user. We're not targeting infants in the kindergarten here. So
> > while
> > > > we aim to not present too many obstacles to the novice user, we can
> > > > reasonably expect from them at least basic middle-school level
> > knowledge
> > > > and abilities - and occasional read of the documentation never killed
> > > > anybody either.
> > > >
> > >
> > > Hi,
> > >
> > > I didn't know the name of this character until several years after I
> > > started PHP, and I only found out because a colleague pointed it out to
> > me.
> > > I don't think it's a good idea to assume people know the name of this
> > > operator or known how to find it easily. Googling is a skill on its own
> > > that not everyone masters, as much as I'd like to see this in our
> field.
> > I
> > > also don't see how school knowledge is important here, especially as I
> > went
> > > to school and I did not learn about it there. Besides of this, there
> are
> > > also keyboard( layout)s that don't have a backtick character present.
> > >
> > > Regards,
> > > Lynn van der Berg
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>

Re: [PHP-DEV] PHP 7.4 BC break with openssl_random_pseudo_bytes()

[M. W. Moe]

Hello,

"A little side-node: random_int(0, 0) does not throw an exception which
makes random_bytes and random_int inconsistent by your logic ;-)"

not really; there are still different functions; hence they can differ in
their behavior; + that's not a matter of individual logic but an api
choice; everything can be argued *; however, I don't see any BC break here
but a `addon` instead of failing silently, like it was before; hiding a
very wrong state.


Regards.

* the smiley doesn't help.

On Mon, Sep 23, 2019 at 9:34 AM Christian Schneider 
wrote:

> Am 23.09.2019 um 17:16 schrieb Larry Garfield :
> > I cannot speak for OpenSSL,  but random_bytes() and random_int() were
> changed very late in the 7.0 cycle to throw exceptions so that they "fail
> closed".  Otherwise if you expect a random value back but get a constant
> value (false or empty string), if you don't remember to check it yourself
> every time then you now have a security hole because you're using a
> constant seed for random-dependent behavior.
>
> I see your point but I'm still not convinced that it is worth the BC.
> But whatever is decided for this specific change, I'm more interested in
> handling this properly for future RFCs, i.e. people should get the full
> picture concerning BC before voting.
>
> A little side-node: random_int(0, 0) does not throw an exception which
> makes random_bytes and random_int inconsistent by your logic ;-)
>
> - Chris
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] non-PIC build broken on oss-fuzz

[M. W. Moe]

ok got thru the link: I think it's written in plain sight `recompile with
-fPIE and relink with -pie`.

On Mon, Sep 9, 2019 at 10:42 AM M. W. Moe  wrote:

> You try to mix static and dynamic linkage; there is something wrong
> regarding the setup of target platform;
> enumerate details about flavors.
>
>
> On Sun, Sep 8, 2019 at 10:13 PM Stanislav Malyshev 
> wrote:
>
>> Hi!
>>
>> Looks like commit eef85229d0fe9f69d325aa0231e592f35c468afb broke
>> oss-fuzz builds:
>>
>> https://oss-fuzz-build-logs.storage.googleapis.com/log-66ab74a7-4ece-4e14-b21b-f60527dd7244.txt
>>
>> The error message is:
>>
>> Step #4: /usr/bin/ld: dynamic STT_GNU_IFUNC symbol `php_stripslashes'
>> with pointer equality in `ext/standard/string.o' can not be used when
>> making an executable; recompile with -fPIE and relink with -pie
>> Step #4: clang-10: error: linker command failed with exit code 1 (use -v
>> to see invocation)
>> Step #4: make: *** [sapi/cli/php] Error 1
>> Step #4: Makefile:264: recipe for target 'sapi/cli/php' failed
>>
>> I'm not sure I understand what's going on here - I suspect the non-PIC
>> build somehow conflicts with stripslashes optimizations, but I don't
>> know the details. May be specific to clan builds...
>> --
>> Stas Malyshev
>> smalys...@gmail.com
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>

Re: [PHP-DEV] non-PIC build broken on oss-fuzz

[M. W. Moe]

You try to mix static and dynamic linkage; there is something wrong
regarding the setup of target platform;
enumerate details about flavors.


On Sun, Sep 8, 2019 at 10:13 PM Stanislav Malyshev 
wrote:

> Hi!
>
> Looks like commit eef85229d0fe9f69d325aa0231e592f35c468afb broke
> oss-fuzz builds:
>
> https://oss-fuzz-build-logs.storage.googleapis.com/log-66ab74a7-4ece-4e14-b21b-f60527dd7244.txt
>
> The error message is:
>
> Step #4: /usr/bin/ld: dynamic STT_GNU_IFUNC symbol `php_stripslashes'
> with pointer equality in `ext/standard/string.o' can not be used when
> making an executable; recompile with -fPIE and relink with -pie
> Step #4: clang-10: error: linker command failed with exit code 1 (use -v
> to see invocation)
> Step #4: make: *** [sapi/cli/php] Error 1
> Step #4: Makefile:264: recipe for target 'sapi/cli/php' failed
>
> I'm not sure I understand what's going on here - I suspect the non-PIC
> build somehow conflicts with stripslashes optimizations, but I don't
> know the details. May be specific to clan builds...
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Silent Types

[M. W. Moe]

Hello,

this would be very possible constant with the actual without breaking BC

allow declare var = value : type; -> throws if assignment + type  fails
the grammar context is exactly the same than a function return.

Best.


On Wed, Sep 4, 2019 at 10:18 AM Andreas Hennings 
wrote:

> On Wed, 4 Sep 2019 at 09:22, Lynn  wrote:
> >
> > Note that this behavior would require making some decisions whether or
> not
> > in the future this opt-in behavior should change when a default value is
> > given, such as with C# and type inference when declaring a variable,
> based
> > on its assigned value.
>
> I think this would too easily lead to mistakes.
> E.g. if in a git commit, "$x = 5.6;" is replaced with "$x = 5;" or "$x
> = '5.6';", then would a reviewer notice that this implicitly changes
> the type?
> Also, what if the initialization is inside an if branch? Later the
> if/else gets reordered, or one of the conditional branches gets
> removed, and the variable changes its type?
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[M. W. Moe]

Hello,

if you would drop zend engine as is and the idea behind it (which is most
difficult thing to admit and accept),
then use llvm-core. Making:
-- lexer, parser grammar
-- reference counting
-- type hint policies
-- builtins container
-- JITTER for compatibility.
-- bytecode
-- LLVM bytecode
-- symbolicated machine code
-- and so on

it's like picking your nose; meaning easy-peasy: when you have that in
place creating an other
dialect and 1 of them will be same; or even experimenting new
features...

it  will benefit the language at all:
- runtime execution, memory, exception handler  (`normally` handled)
- extension ecosystem you could autopen biddings without introducing bugs
from people.

Best.




On Fri, Aug 16, 2019 at 10:38 AM Mark Randall  wrote:

> On 16/08/2019 17:40, Chase Peeler wrote
> > A BC break to clean up the language might be justified in one case, and
> not
> > in another. To make a blanket statement that we will or will not attempt
> to
> > clean up the language is not wise in my opinion. It puts the project in a
> > bad place if it's forced to stick to it's decision, or, it makes the
> whole
> > reason for having made a decision pointless if we keep finding certain
> > items that are exceptions.
>
>
> Re: Entertainment, I'd liken it to something like watching the replay of
> a car crash. One really shouldn't, but one can't help but be mesmerised.
>
> Onto the matter of nuance in decisions, I agree that things should be
> done on a case-by-case basis, however, you have to have something to
> weigh the pros and cons against.
>
> Right now, so far as I can tell, the value of cleanup and improvement in
> any particular decision is undefined, because there's no general
> consensus on it.
>
> Take short open tags, there are cases made for and against, and in my
> opinion the strongest case for it is language cleanup, to have one fixed
> way of doing something that can be taught so future developers don't
> start wondering what the difference is between them.
>
> But what base weight does cleanup have? Is cleanup hugely important, or
> a complete non-factor that shouldn't be considered at all? If it's
> somewhere in between, where in between.
>
> It would never be used in absolute terms, it's always something that
> would strengthen or weaken other arguments. BC breaking cleanup for
> cleanups sake isn't really going to fly, but cleanup because a
> particular set of functions are inconsistent, or exhibit unintuitive
> behaviour, those ultimately all have to start with a consensus on if
> it's worth breaking something, or making something more complex
> (namespaced function aliases?) for the sake of making the language as a
> whole "better".
>
> My worry is that those with voting privileges on internals may end up
> splitting into two camps, and voting ideas up or down based on personal
> bias towards or against an underlying principle of clean-up and
> improvement or BC-supreme.
>
> I doubt it will come up _often_, but when it does, it seems to be
> incredibly disruptive. I would argue it needs a wider debate and then
> people should use the result of that debate to inform their voting,
> knowing that "PHP" has agreed to weigh certain general concepts in a
> particular way.
>
>
>
> Mark Randall
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV][RFC] Alternative "use" syntax for Closures

[M. W. Moe]

Hello,

if you are upset; it's not the place here; your argument is efficiently
based on problems of indentation and handling commas
properly.

Moreover, but not least, you have no idea what a lambda is; if we admit it
what you propose; that is not feasible in PHP; why? because it would
require a preprocessor; in the case presented, it would be necessary to
import all that existing scope then making a selection; nobody wants that
to happen.

If you do not accept any rational criticism; you should think of doing
something else; I do not know; gardening maybe? who knows.

P.S For my use of the "closure" you made a fool yourself beyond what you
can grasp; but anyhow, my dear, it's refreshing, you made smile.

On Sat, Jun 15, 2019 at 4:34 PM Wes  wrote:

> Welcome to the first inevitable patronizing message... No, my code is not
> smelly. If something is smelling for you, check your armpits.
> Importing 4 variables is not rare. If you think it's rare and should be
> done differently, maybe you should first actually do something with
> Closures before telling people they are wrong.
> And if you use actual names instead of "$var1" or "T1" you will see why I
> am proposing to move the lexical imports where they are the least invasive.
>

Re: [PHP-DEV][RFC] Alternative "use" syntax for Closures

[M. W. Moe]

Hello,

mostly, your argument in your rfc, is all about not finding a good syntax;
hence your have a terrible coding style
and you want to change the language for that.

```
$fn = function (
 T1 $arg1_
, T1 $arg2_
, T1 $arg3_
, T1 $arg4_
, T1 $arg5_
, T1 $arg6_
) use ($var1, &$var2, &$var3, &$var4): T2
{
//  If you want to import more scope vars your code is
//  smelly, should think about writing something else.
return new T2;
};
```


On Sat, Jun 15, 2019 at 3:52 PM Kalle Sommer Nielsen  wrote:

> Hi
>
> Den søn. 16. jun. 2019 kl. 01.37 skrev Wes :
> >
> > Hi Kalle, I realize it's going to be a bit odd when binding by value. But
> > it's not that hard to grasp.
> >
> > ```
> > $a = 123;
> > $closure = function(){
> > use $a;
> > echo $a; // 123
> > };
> > $a = 345;
> > ```
>
> Take this example:
>
> function get_closure() {
>   $a = 123;
>
>   return function() {
> use $a;
> echo $a;
>   };
> }
>
> get_closure()();
>
> $a is not available at this time because the scope of which $a exists
> in is destroyed at this point, which is why it exists as apart of the
> prototype like I mentioned and therefore it can be captured.
>
> Your idea means we need to scan the body of the declared closure for
> use statements to perform the binding at this stage, adding extra
> specialized steps in the executor for only makes me question the
> motive for this again, and if the motive is that "I'm passing an
> excessive amount of values to a closure", then I think you are forcing
> a technique that isn't mean for this to do it anyway. Another thing to
> take into consideration here is the performance impact that it can
> potentially have.
>
> Whether or not its at the top of the body or separated in multiple
> statements or all over the body still means we need to check if the
> body contains such a statement and do the right computations for it, I
> still don't think the argument presented in the RFC justifies this
> potential cost, and would like to see a demo implementation and impact
> it would have first.
>
>
> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] High performance function autoloading

[M. W. Moe]

Hello,

"Disabling function mocking is good", in my life I read many idioties; this
one gets the "Palme d'Or";
This majesty; crowned Emperor.

On Mon, May 20, 2019 at 11:45 AM Marco Pivetta  wrote:

> On Mon, 20 May 2019, 20:01 Gabriel O,  wrote:
>
> >
> > On 20 May 2019 7:17:58 PM Theodore Brown  wrote:
> >
> > > Every time function autoloading been brought up in the past, there
> > > have been concerns about performance issues when calling a global
> > > function from inside a namespace. E.g. calling `strlen` in a loop
> > > would become far slower if every call has to trigger the autoloader.
> >
> > This trick for perf improvement is overblown. It's misconception that it
> > does provide speed advantage for most functions and reasons behind it. It
> > does so only for those implemented as opcodes. People started to abuse it
> > by importing ALL functions. Such overzealous approach completely prevents
> > useful things like function mocking.
> >
>
> Disabling function mocking is good ©️
>
> It was a terrible practice in first place, and it is usually done for
> impure functions that should be wrapped in integration-tested adapters.
>

Re: [PHP-DEV] Re: MODERATE spam

[M. W. Moe]

Ok thanks for the heads-up

hence, if that 's exim you might write a script that keeps alike to
quarantine.


On Sat, May 18, 2019 at 11:16 AM Kalle Sommer Nielsen  wrote:

> Den lør. 18. maj 2019 kl. 20.19 skrev M. W. Moe :
> >
> > Hello,
> >
> > didn't get any; should ask over folks; I suspect it originates from a
> > frustrated individual
> > which didn't found anything else smarter  than spams to achieve his pity
> > vendetta.
> >
> > Did you kept the original ones?
> >
> > tschüss.
>
> These mails only goes to moderators of the php-announce@ list,
> typically RMs and the like moderates this list hence why only a
> handful has gotten them, each moderation mail contains the original
> mail and addresses to approve or reject the message.
>
>
> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net
>

Re: [PHP-DEV] Re: MODERATE spam

[M. W. Moe]

Hello,

didn't get any; should ask over folks; I suspect it originates from a
frustrated individual
which didn't found anything else smarter  than spams to achieve his pity
vendetta.

Did you kept the original ones?

tschüss.

On Sat, May 18, 2019 at 8:12 AM Sara Golemon  wrote:

> On Sat, May 18, 2019 at 5:22 AM Christoph M. Becker 
> wrote:
>
> > On 18.05.2019 at 12:06, Joe Watkins wrote:
> >
> > > Does anyone know what is the cause of all the spam from the announce
> > > mailing list? I'm not sure who is getting it, but I'm getting a few
> > emails
> > > a minute sometimes, it's rather annoying ...
> >
> > I can confirm that the spam to this mailing list has drastically (by at
> > least factor 10) increased since a week ago.
> >
> > > Can someone do some magic, and make it go away please ?
> >
> > +1
> >
> > Same, I set up a (probably over-broad) gmail filter to bin those, but
> it's
> possible I'm missing some legit ones now.
>
> -Sara
>

Re: [PHP-DEV] [RFC] Allow throwing exceptions from __toString()

[M. W. Moe]

Hello,

the _convert_to_string return signature should be changed i.e returning a
status;
hence, accordingly to this status, within a context caller, you may decide
to trigger
an exception  or not ; that's not the role of a conversion function to
handle
those concerns; thus the realm is wider than what it is sold here.

Cheers!

On Wed, May 1, 2019 at 7:53 AM Bishop Bettini  wrote:

> On Wed, May 1, 2019 at 7:36 AM Dan Ackroyd  wrote:
>
> > On Wed, 1 May 2019 at 03:54, Bishop Bettini  wrote:
> > >
> > > But I'd still think this would be a "many eyes needed" kind of PR,
> > especially from extension maintainers.
> >
> > Hypothetically, what should these extension maintainers be looking for?
> >
> > Other than "Mmm-hmm. Mmm-HMM. I know some of these words!" ?
> >
>
> Indeed. I'm by no means an expert, but here's what I did for phar and imap
> extensions. I read the RFC and "got to know" the new helper methods for
> resolving stringy content. I then looked at the PR for all changes to phar
> and imap, verifying that I understood the changes Nikita made. Then I went
> to master and PHP-7.4 branches and looked for any other cases that might
> need to be changed, and while there took mental note of improvement
> opportunities should this RFC pass.
>
> When I was in there, I was basically looking for "convert_to_string" (and
> friends) and if I found any that Nikita hadn't already found, replacing
> those with one of the new helpers and making sure I understood the choice
> Nikita made and commenting if I disagreed. I was also looking for any case
> where the conversion touched data that persisted and made sure it wasn't
> going to get trashed by a bad conversion.
>
> I also went through code outside phar and imap looking for things I didn't
> understand or surprised me or didn't look correct. Suffice to say, there's
> a lot of code to look through. Some code surprised me, like that the (new
> DateInterval(...))->{$badStr} unhappy path didn't adhere to the
> has_property contract, so that was a bugfix Nikita made as an artifact of
> this sweep, which is great and I think emblematic of the reason to get more
> eyes on this: might be more of those lurking in the code base.
>

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

[M. W. Moe]

Hello,

a bit of fuzz; no need having a dramatic posture either; php RFC system
needs to be matured; the same way
than c++ fellowship (I don't say it was without dramas over the years); in
my opinion there are two many of them
opened at the same time; some targets strictly the userspace; some language
features and finally other regards
the zend engine (absolute on purpose); maybe they should not be discussed
on the same list.

tschüss!

On Tue, Apr 30, 2019 at 11:25 AM Zeev Suraski  wrote:

> On Tue, Apr 30, 2019 at 8:14 PM Derick Rethans  wrote:
>
> > On Mon, 29 Apr 2019, Zeev Suraski wrote:
> >
> > > On Sun, Apr 28, 2019 at 11:32 PM G. P. B. 
> > wrote:
> > >
> > > > I think this just boils down to what is an acceptable majority, if
> > > > 2/3 is not enough then 3/4 but this is another debate altogether.
> > > >
> > >
> > > I've argued in the past that it would make sense to require a 9/10
> > majority
> > > for RFCs.  Very few RFCs that passed - only cleared a 2/3 majority.
> > > Usually (in the vast majority of cases), it either clears a nearly
> > > unanimous vote - or it doesn't even come close to 2/3.
> > >
> > > RFCs that have a high number of votes (i.e., that people feel strongly
> > > about), and barely pass the 2/3 mark - are controversial and saw
> > division.
> > > Yes, it means that out of the (almost random) group of people who are
> > > currently enabled to vote by our (flawed) voting system
> >
> > If you think it's flawed
>
>
> It's not that I think it's flawed - I know it's flawed.  It doesn't
> implement what was agreed upon when the Voting RFC was enacted.
>
>
> > , you know that the RFC process is there for
> > anybody to change it. Joe already managed twice towards what you
> > suggested in your stalled RFC:
> >
> > - https://wiki.php.net/rfc/abolish-short-votes
> > - https://wiki.php.net/rfc/abolish-narrow-margins (btw, you voted
> >   against this one to raise the barrier from 50%+1 to ⅔rds).
> >
>
> I'm well aware of it.  In doing that, I think we greatly complicated the
> prospects of fixing the voting eligibility - which is an infinitely hotter
> potato to handle. Both 'abolish' RFCs enjoyed popular support and had very
> little touchy subjects - unlike the topic of who gets to vote, or the
> prospect of moving to a consensus-based system.
>
> > It's absolutely fine to dislike short tags.  It's absolutely fine to
> > > believe it shouldn't have been introduced.  But the gap between that,
> > > and thinking it's fine to remove it - is very, very big.
> >
> > But the fact is that the RFC passed. And retroactively changing rules
> > because somebody don't agree with a decision is making a farce out of
> > the process.
> >
>
> I've detailed the issues with the RFC in my other reply.
>
> I'm well aware that I'm spending quite a bit of 'credit capital' by
> weighing in on this, and I'm enjoying it roughly as one would enjoy having
> their tooth pulled out without anesthesia (which still pales in comparison
> to what it would take to fix our voting process, which will probably be
> akin to having an entire set of teeth pull out in the same way).   The
> reason I'm still doing it is that it's clear this RFC was flawed in its
> voting options, its substance, and the level of discussion that surrounded
> it (the last one is my opinion, the first two are facts) - and it will have
> HUGE implications on hundreds of thousands if not millions of users.  So as
> I said when I first engaged this thread - as much as I'm 'enjoying' this, I
> prefer to take the personal hit and do whatever I can to prevent our users
> from taking the hit.
>
> If we are to inflict this hit on our users - we need to have each and every
> t crossed and i dotted.
>
> Zeev
>

Re: [PHP-DEV] [RFC] Deprecate left-associative ternary operator

[M. W. Moe]

Hello,

the underlaying discussion here is more important; than just voting yes or
no on uncompleted hamiltonian graphs; the real question here does php8 will
be a break thru; meaning bugger off the mistakes of the past or a
continuation of them; until this RCF does not happen; I would say nothing
interesting will ever happen.

Have a good day.

On Wed, Apr 24, 2019 at 10:25 AM Sara Golemon  wrote:

> On Tue, Apr 23, 2019 at 3:56 AM Nikita Popov  wrote:
>
> > Can't say I understand your position here. Don't want to change the
> > ternary from left-associative to right-associative? I can understand
> that:
> > Silent behavior changes are always problematic. This is not what the RFC
> > proposes though.
> >
> > Did the RFC change since introduction? I may have been looking at a stale
> load of the page (opened it up awhile ago and only just got around to
> responding).
>
> As for what it says atm, I still think it goes too far.  the warning in 7.4
> I can support, but I'm not a fan of breaking existing code on a feature
> that's this old. Ratchet up the warning in 8.0 if you'd like, but error is
> further than I'm willing to go on this one.
>
>
> > 20 years of code in the wild has not "accepted that fact and moved on".
> If
> > a left-associative ternary is used, it is almost certainly a bug. If
> people
> > use this structure by accident (because it is familiar from other
> > programming languages), I'd like them to get an error instead of having
> to
> > figure out why their obviously correct code is not working or, in the
> worse
> > case, just leave behind buggy code.
> >
> > I'm on dismal wifi at the moment, else I'd do some searches, but do you
> have any examples of code in the wild subject to this bug?
> I agree it's a lousy state, but it's not emergent.
>
> -Sara
>

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

[M. W. Moe]

Hello,

just deprecate it; please stop this load of nonsense; it's not even a
rational discussion here; that's a lot of idiotic rumblings.

Have a good day.

On Wed, Apr 24, 2019 at 11:23 AM Chase Peeler  wrote:

> On Wed, Apr 24, 2019 at 2:20 PM Сергей Пантелеев 
> wrote:
>
> > Hi,
> >
> > >Also imo the reason why people write now (and not in the discussion
> > phase) because for some time in the voting there wasn't the 2/3 majority
> > for the 7.4 (so no sense to clutter the list) and now in the end only 1-2
> > votes make the difference.
> >
> > If this RFC has caused such a resonance _after_ the vote, maybe, it can
> be
> > reopened for a few days so that those who have not voted can do it?
> >
> > Thus, it is not the "1-2 votes" that will matter.
> >
> I think a lot of the people speaking against it, both before and after,
> don’t get a vote.
>
> I think the people that this is going to have the biggest negative impact
> on are the developers out there that don’t even know this mailing lists
> exists, much less this RFC or discussion.
>
>
> > —
> > Sincerely,
> > Sergey Panteleev
> > On 24 Apr 2019, 21:08 +0300, Reinis Rozitis , wrote:
> > > > -Original Message-
> > > > From: Marco Pivetta [mailto:ocram...@gmail.com]
> > > >
> > > > Also a good chance to finally take a look at code that has been
> > rotting in a hard
> > > > drive for too much time.
> > >
> > > It's an odd way of justifying a BC break by saying "you can write this
> > one-liner sed or use this third-party tool to alter you code" exactly the
> > same way every backwards incompatible change can be fixed then .. and
> then
> > it makes no sense to even discuss.
> > >
> > > At the beginning of the proposal it was asked (on mailinglist) if the
> > change has any impact on performance (php runs faster/language parses
> > becomes substantially simple etc), if there are any security issues (like
> > with magic quotes) or maybe similarly as with different extensions there
> is
> > no one to support the code anymore.
> > >
> > > But in the end there is only the ' > documentation discourages short tags because that’s ini specific (while
> > there are bunch of other ini directives which change the the way php
> works
> > (like for example precision)) .. and that's it.
> > >
> > > So instead of by default disabling it and allowing the users make an
> > conscious choice to reenable the option if needed it's removed
> altogether.
> > >
> > >
> > >
> > > Also imo the reason why people write now (and not in the discussion
> > phase) because for some time in the voting there wasn't the 2/3 majority
> > for the 7.4 (so no sense to clutter the list) and now in the end only 1-2
> > votes make the difference.
> > >
> > > rr
> > >
> > >
> > >
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> >
> --
> Chase Peeler
> chasepee...@gmail.com
>

Re: [PHP-DEV] Object Type Casting Reloaded

[M. W. Moe]

Hello,

Sebastian yes; interface or abstract have been somehow created for that
purpose; even if I find people abusing of those constructs; now if your
container is generalized and represents dynamic data; for instance like a
Message class
it could hold dynamic data types;

let say:
// abstract public offsetGet
 ( mixed

 $offset ) : mixed

$service = $diContainer['email.service'] of ?EmailService; // else throw
TypeError(this type instead of null or EmailService)


On Mon, Apr 22, 2019 at 10:07 PM Sebastian Bergmann 
wrote:

> Am 22.04.2019 um 23:47 schrieb Benjamin Morel:
> > These combine into a third advantage: readability. Today's equivalent of
> > the above one-liner could be:
> >
> >  /** @var EmailService $service */
> >  $service = $diContainer->get('email.service');
> >  if (! $service instanceof EmailService) {
> >  throw new TypeError('Expected instance of EmailService, ...');
> >  }
>
> Today's equivalent is, at least for me, is this one-liner:
>
>  assert($service instanceof EmailService);
>
> This way the IDE knows what type $service is supposed to be and there will
> be an exception at runtime (given the appropriate configuration) when this
> is not the case.
>
> Personally, I prefer hand-written factories that have an explicit
> createEmailService() method with a :EmailService return type declaration,
> for example, over the implicitness of a dependency injection container as
> the latter disguises and obscures dependencies.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2

[M. W. Moe]

Hello,

"Since we can define array element by reference now, it doesn't make sense
to change the way of storing values just because it's unpacking. In other
words, the conversion of how values are stored isn't part of spread
operator."

yes it is; no matter what you "think"; banding reality/facts only exists in
blockbusters.



On Sun, Apr 21, 2019 at 12:31 PM CHU Zhaowei  wrote:

> On Monday, April 8, 2019 9:22 PM Nikita Popov 
> wrote:
>
> > This looks reasonable to me. My only concern would be the "by-reference
> passing" section of the RFC. The current proposal states that [...$arr]
> will preserve references in $arr, which is not the behavior I would expect.
> >
> > Is this choice for parity with the unpacking functionality in calls? In
> that case I think it is important to understand that for argument unpacking
> the handling of references is decided by the called function, not what is
> in the array. If the function accepts an argument by-reference, then the
> corresponding element in the array will be turned into a reference
> (regardless of whether it was one before). Conversely, if the function
> accepts an argument by-value, then the element from the array will be
> passed by-value (regardless of whether it was a reference before). A
> similar concept doesn't really exist for unpacking in arrays.
>
> No. I understand it's decided by the definition of the function that
> whether the arguments are passed by-value or by-reference, and it's not
> able to be changed by the caller. So the spread operator here extracts the
> array, no matter it contains referenced element or not, and the conversion
> from by-ref to by-val or by-val to by-ref is done during passing to the
> callee. Back to the array definition scenario, the spread operator will
> also extracts the array, and it should be the array definition to decide
> whether conversion is needed. Since we can define array element by
> reference now, it doesn't make sense to change the way of storing values
> just because it's unpacking. In other words, the conversion of how values
> are stored isn't part of spread operator.
>
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures

[M. W. Moe]

@Benjamin Morel

you must certainly have basic comprehension troubles; read me back; it is
public; keep for yourself your
emotional false projections to myself and infantile behaviors to yourself;
I would never dare simply by following
the basic rules of education; maybe english grammar should introduce a
point of `ironism`; would help or not.

You have a good day; thank you.

On Thu, Apr 11, 2019 at 10:41 AM M. W. Moe  wrote:

> @Robert Hickman
>
> yes somehow that's a valid conclusion; however, I can walk and talk; it
> does not
> bother me at all; I like distractions.
>
> You have a nice day.
>
> On Thu, Apr 11, 2019 at 9:38 AM Robert Hickman 
> wrote:
>
>> @M. W. Moe If you don't like the java-isms you can ignore them to a
>> large extent, which I do. However in doing so you're going against the
>> grain and will end up writing a lot of stuff yourself. I do find it
>> weird how PHP has morphed so drastically from it's origins and also
>> wander why. If people wanted a Java-esque language, why not use Java
>> in the first place?
>>
>> This discussion is off topic.
>>
>> On Thu, 11 Apr 2019 at 17:15, Benjamin Morel 
>> wrote:
>> >
>> > > why? if voicing reasonable criticisms is bothering you; then you
>> should
>> > do something else in life;
>> > > because engineering is built on this `very` concept;
>> >
>> > You're very welcome to challenge the "java impurities" that have been a
>> > foundation of the language for 15 years—although you may better invest
>> your
>> > own time by switching to another language that's already closer to what
>> you
>> > expect.
>> >
>> > But calling people pigs when they disagree with you is not what I'd call
>> > reasonable criticism.
>> >
>> > > I am not in the apex or any emotional trend; it does not interest me.
>> >
>> > Oh that's exactly the impression you've left so far.
>>
>

Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures

[M. W. Moe]

@Robert Hickman

yes somehow that's a valid conclusion; however, I can walk and talk; it
does not
bother me at all; I like distractions.

You have a nice day.

On Thu, Apr 11, 2019 at 9:38 AM Robert Hickman 
wrote:

> @M. W. Moe If you don't like the java-isms you can ignore them to a
> large extent, which I do. However in doing so you're going against the
> grain and will end up writing a lot of stuff yourself. I do find it
> weird how PHP has morphed so drastically from it's origins and also
> wander why. If people wanted a Java-esque language, why not use Java
> in the first place?
>
> This discussion is off topic.
>
> On Thu, 11 Apr 2019 at 17:15, Benjamin Morel 
> wrote:
> >
> > > why? if voicing reasonable criticisms is bothering you; then you should
> > do something else in life;
> > > because engineering is built on this `very` concept;
> >
> > You're very welcome to challenge the "java impurities" that have been a
> > foundation of the language for 15 years—although you may better invest
> your
> > own time by switching to another language that's already closer to what
> you
> > expect.
> >
> > But calling people pigs when they disagree with you is not what I'd call
> > reasonable criticism.
> >
> > > I am not in the apex or any emotional trend; it does not interest me.
> >
> > Oh that's exactly the impression you've left so far.
>

Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures

[M. W. Moe]

@Fabien S

yes, I think you could remove decoration; but still lambda capture process
must
be clarified i.e iterating your ruleset; you don't want to capture every
scope variables.



On Thu, Apr 11, 2019 at 8:22 AM Fabien S  wrote:

> Thanks a lot for all your efforts Nikita.
>
> I really like the Haskell `\($x)` syntax, could someone confirm if it
> would possible to drop the parenthesis (like `\$x`) if we have one argument
> ?
>
> Thanks in advance, regards

Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures

[M. W. Moe]

@Benjamin Morel

why? if voicing reasonable criticisms is bothering you; then you should do
something else in life;
because engineering is built on this `very` concept; I am not in the apex
or any emotional trend;
it does not interest me.

 You have a good day!

On Thu, Apr 11, 2019 at 7:58 AM Benjamin Morel 
wrote:

> > yes php still suffers of
> > it's java-like-transform; historically named php5;
> > repeating the same design traps almost 20 years after it;
>
> Maybe you could just switch to another language then, and bother another
> mailing list?
>
>
> On Thu, 11 Apr 2019 at 16:51, M. W. Moe  wrote:
>
>> @Stephen Reay
>>
>> i) Good for you!, if you say so must be the truth; yes php still suffers
>> of
>> it's java-like-transform; historically named php5;
>> repeating the same design traps almost 20 years after it; and in the
>> real-life the most interesting inquiries about the language evolution are
>> blocked by this fact and make tedious what would look like very simple
>> changes.
>>
>> ii) BTW, that's you making personal experience an absolute rule and
>> projecting your own limitations as a valuable intellectual argument; , not
>> myself; my remark was just an illustration.
>>
>> You have a good day!
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Apr 10, 2019 at 9:23 PM Stephen Reay 
>> wrote:
>>
>> >
>> > > On 11 Apr 2019, at 00:32, M. W. Moe  wrote:
>> > >
>> > > I have never seen ML programmers being improductive;
>> >
>> > Great. I’ve never seen a pig crash a plane, therefore all pilots should
>> be
>> > pigs?
>> >
>> > Given your previous comments regarding removing “java impurities” it’s
>> > hard to take anything you suggest seriously.
>> >
>> >
>> >
>>
>

Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures

[M. W. Moe]

@Stephen Reay

i) Good for you!, if you say so must be the truth; yes php still suffers of
it's java-like-transform; historically named php5;
repeating the same design traps almost 20 years after it; and in the
real-life the most interesting inquiries about the language evolution are
blocked by this fact and make tedious what would look like very simple
changes.

ii) BTW, that's you making personal experience an absolute rule and
projecting your own limitations as a valuable intellectual argument; , not
myself; my remark was just an illustration.

You have a good day!







On Wed, Apr 10, 2019 at 9:23 PM Stephen Reay 
wrote:

>
> > On 11 Apr 2019, at 00:32, M. W. Moe  wrote:
> >
> > I have never seen ML programmers being improductive;
>
> Great. I’ve never seen a pig crash a plane, therefore all pilots should be
> pigs?
>
> Given your previous comments regarding removing “java impurities” it’s
> hard to take anything you suggest seriously.
>
>
>

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

[M. W. Moe]

deprecate short closing tag
 wrote:
>
> Finally!!! everybody will be able to parse my xml files with embedded
> php1!1 if I ever wrote one!!!
>
> Sorry for the sarcasm, please don't consider this as a personal attack. The
> whole community (not just you) considers short open tags poison because not
> XML-compatible... while they use stuff like twig, which is also not
> XML-compatible.
>
> This is just beyond my understanding.
>
> But sure, let's keep vilifying this kind stuff and pretend they are the
> root cause of PHP's bad rep.
>
> Sorry again for the negativity.

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

Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures

[M. W. Moe]

@Stephen Reay,

I have never seen ML programmers being improductive; that's because maybe
you witness  people
unfit for it; math is less character and contextual i.e meanings change
according to environment;
it's fully readable to people fitted for it.

On Wed, Apr 10, 2019 at 10:18 AM M. W. Moe  wrote:

> Hello,
>
> this is not much the syntax which is problematic here but the implicit
> lambda capture ruleset proposed; for that,
> it would require (fully justified in this case) a preprocessing step hence
> a language contextual analysis step
> or what people call `static`.
>
> On Wed, Apr 10, 2019 at 2:35 AM Stephen Reay 
> wrote:
>
>>
>> > On 10 Apr 2019, at 15:59, Robert Hickman  wrote:
>> >
>> >> I'd just like to amplify this mention of 3rd party tooling: if we go
>> with
>> >> something which requires complex lexer/parser rules, then every editor,
>> >> IDE, and static analysis tool will need to also work with that syntax.
>> >>
>> >
>> > Is this actually a problem? Don't these tools make use of existing
>> > parsers like 'php parser', thus the cost is lower than initially
>> > apparent?
>> >
>> > --
>> > PHP Internals - PHP Runtime Development Mailing List
>> > To unsubscribe, visit: http://www.php.net/unsub.php
>> >
>>
>> This seems like a risky thing to assume “it’ll be fine” about.
>>
>> I’d like to add my (non-voting) voice in favour of the `fn(…)` syntax. I
>> don’t know that I’d get a lot of use out of short closures anyway, but I’d
>> at least like it to remain readable on the occasion I might use them, or
>> (more likely) work on something where someone else uses them.
>>
>> I question (loudly) any view that less characters is automatically
>> improves readability. I’ve yet to see a project anywhere that suffered
>> overrun or saw low productivity because developers were busy typing/reading
>> parenthesis around argument lists or keywords.
>>
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>

Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures

[M. W. Moe]

Hello,

this is not much the syntax which is problematic here but the implicit
lambda capture ruleset proposed; for that,
it would require (fully justified in this case) a preprocessing step hence
a language contextual analysis step
or what people call `static`.

On Wed, Apr 10, 2019 at 2:35 AM Stephen Reay 
wrote:

>
> > On 10 Apr 2019, at 15:59, Robert Hickman  wrote:
> >
> >> I'd just like to amplify this mention of 3rd party tooling: if we go
> with
> >> something which requires complex lexer/parser rules, then every editor,
> >> IDE, and static analysis tool will need to also work with that syntax.
> >>
> >
> > Is this actually a problem? Don't these tools make use of existing
> > parsers like 'php parser', thus the cost is lower than initially
> > apparent?
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
> This seems like a risky thing to assume “it’ll be fine” about.
>
> I’d like to add my (non-voting) voice in favour of the `fn(…)` syntax. I
> don’t know that I’d get a lot of use out of short closures anyway, but I’d
> at least like it to remain readable on the occasion I might use them, or
> (more likely) work on something where someone else uses them.
>
> I question (loudly) any view that less characters is automatically
> improves readability. I’ve yet to see a project anywhere that suffered
> overrun or saw low productivity because developers were busy typing/reading
> parenthesis around argument lists or keywords.
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures

[M. W. Moe]

and maybe one day if public, protected, private, interface, abstract i.e
java impurities are finally removed:

class bar
{
   owned var $m_a : float = 0.0;
 var $b : object = null;

   fn foo(int $x, int $y) : int
   { return fn($x) [&$y] { $x * $y; }; }

   owned fn bar() : void
   { return; }
}

On Tue, Apr 9, 2019 at 5:33 PM M. W. Moe  wrote:

> Hello,
>
> for now what I see is a bit of everything:
> - adding a contextual keyword/alias to function
> - enforce by reference
> - a lack of coherence
>
> too mockups (I like the arrow idea but won't ever replace `use`
> functionalities)
>
> "keeping the unnecessary  arrow"
>
> class bar
> {
>public fn foo(int $x, int $y)
>{
>   return fn($x) [&$y] => {
>  $x * $y;
>   };
>}
> }
>
> "aliasing function keyword to fn; aliasing use keyword  with brackets
> syntax"
>
> class bar
> {
>public fn foo(int $x, int $y)
>{
>   return fn($x) [&$y] { $x * $y; }
>}
> }
>
>
> On Tue, Apr 9, 2019 at 3:29 PM Kosit Supanyo 
> wrote:
>
>> Hi internals,
>>
>> This is my first write to this list but I've been followed
>> your discussions quite a while ago. For a brief introduction,
>> my name is Kosit, I'm a programmer from Thailand and I've been using
>> PHP since version 3 (for a short period before moving to PHP4).
>>
>> I'm a fan of `fn` syntax and OK to go with it but I would like to
>> propose some extended syntax & behavior about binding.
>>
>> What if we can omit the `use` keyword at all and use only
>> second parentheses for variable & reference binding
>> and make the presence of second parentheses turn off implicit variable
>> binding.
>>
>> $a = 0;
>> $f1 = fn(): int => $a;
>> $b = 0;
>> $f2 = fn(): int () => $b;
>>
>> equivalent to
>>
>> $a = 0;
>> $f1 = function () use ($a) { return $a; };
>> $b = 0;
>> $f2 = function () { return $b; };
>>
>> And what if we can omit parentheses at all if fn has no parameters.
>>
>> $f = fn => $this->doSomethingWithAB($a, $b);
>> $multiStmtBody = fn {
>> // ...
>> };
>>
>> When people want to import references (and addtional variables)
>> they have to do it explicitly like before but without `use` keyword.
>>
>> $f = fn($y): array (&$arr, $x) => $this->doSomethingWithArrAndXY($arr,
>> $x, $y);
>>
>> equivalent to
>>
>> $f = function ($y): array use (&$arr, $x) {
>> return $this->doSomethingWithArrAndXY($arr, $x, $y);
>> };
>>
>> Second parens without `use` keyword may be ugly but can be seen as
>> an abbreviation of old closure syntax.
>>
>> This can eliminate possible problems of reference binding (switching)
>> syntax
>> described in the RFC that may cause undesired behavior and performance
>> problem
>> because `use (&)` will make all variables by-reference bound.
>>
>> Summary:
>>
>> 1. No `use` keyword for binding.
>> 2. The presence of second parentheses will turn off implicit binding.
>> 3. Can omit parentheses if fn has no parameters.
>>
>> I apologize in advance for my bad English
>> but I hope my idea can be taken into consideration
>> or at least can be transformed into another useful idea.
>>
>> Regards,
>> Kosit
>>
>> On Mon, Apr 8, 2019 at 9:07 PM Nikita Popov  wrote:
>> >
>> > On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov 
>> wrote:
>> >
>> > > Hi internals,
>> > >
>> > > Motivated by the recent list comprehensions RFC, I think it's time we
>> took
>> > > another look at short closures:
>> > >
>> > > https://wiki.php.net/rfc/arrow_functions_v2
>> > >
>> > > This is based on a previous (withdrawn) proposal by Levi & Bob. It
>> uses
>> > > the syntax
>> > >
>> > > fn($x) => $x * $multiplier
>> > >
>> > > and implicit by-value variable binding. This example is roughly
>> equivalent
>> > > to:
>> > >
>> > > function($x) use($multiplier) { return $x * $multiplier; }
>> > >
>> > > The RFC contains a detailed discussion of syntax choices and binding
>> modes.
>> > >
>> > > Regards,
>> > > Nikita
>> > >
>> >
>> > Heads up: I plan to start voting on this RFC tomorrow if nothing new
>> comes
>> > up.
>> >
>> > Most of the discussion was (as expected) about the choice of syntax.
>> > Ultimately I think there are many reasonable choices we can make here,
>> but
>> > we should stick to a specific proposal for the purposes of the RFC vote.
>> > None of the given arguments convinced me that some other syntax is
>> > *strictly* better than the proposed fn($x, $y) => $x*$y -- it's more a
>> > matter of some choices being slightly better in one case and slightly
>> worse
>> > in another. My personal runner-up would be \($x, $y) => $x*$y, but I
>> > suspect that there are some people who are more strongly biased against
>> > "sigil salad" than I am...
>> >
>> > Nikita
>>
>

Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures

[M. W. Moe]

Hello,

for now what I see is a bit of everything:
- adding a contextual keyword/alias to function
- enforce by reference
- a lack of coherence

too mockups (I like the arrow idea but won't ever replace `use`
functionalities)

"keeping the unnecessary  arrow"

class bar
{
   public fn foo(int $x, int $y)
   {
  return fn($x) [&$y] => {
 $x * $y;
  };
   }
}

"aliasing function keyword to fn; aliasing use keyword  with brackets
syntax"

class bar
{
   public fn foo(int $x, int $y)
   {
  return fn($x) [&$y] { $x * $y; }
   }
}


On Tue, Apr 9, 2019 at 3:29 PM Kosit Supanyo  wrote:

> Hi internals,
>
> This is my first write to this list but I've been followed
> your discussions quite a while ago. For a brief introduction,
> my name is Kosit, I'm a programmer from Thailand and I've been using
> PHP since version 3 (for a short period before moving to PHP4).
>
> I'm a fan of `fn` syntax and OK to go with it but I would like to
> propose some extended syntax & behavior about binding.
>
> What if we can omit the `use` keyword at all and use only
> second parentheses for variable & reference binding
> and make the presence of second parentheses turn off implicit variable
> binding.
>
> $a = 0;
> $f1 = fn(): int => $a;
> $b = 0;
> $f2 = fn(): int () => $b;
>
> equivalent to
>
> $a = 0;
> $f1 = function () use ($a) { return $a; };
> $b = 0;
> $f2 = function () { return $b; };
>
> And what if we can omit parentheses at all if fn has no parameters.
>
> $f = fn => $this->doSomethingWithAB($a, $b);
> $multiStmtBody = fn {
> // ...
> };
>
> When people want to import references (and addtional variables)
> they have to do it explicitly like before but without `use` keyword.
>
> $f = fn($y): array (&$arr, $x) => $this->doSomethingWithArrAndXY($arr,
> $x, $y);
>
> equivalent to
>
> $f = function ($y): array use (&$arr, $x) {
> return $this->doSomethingWithArrAndXY($arr, $x, $y);
> };
>
> Second parens without `use` keyword may be ugly but can be seen as
> an abbreviation of old closure syntax.
>
> This can eliminate possible problems of reference binding (switching)
> syntax
> described in the RFC that may cause undesired behavior and performance
> problem
> because `use (&)` will make all variables by-reference bound.
>
> Summary:
>
> 1. No `use` keyword for binding.
> 2. The presence of second parentheses will turn off implicit binding.
> 3. Can omit parentheses if fn has no parameters.
>
> I apologize in advance for my bad English
> but I hope my idea can be taken into consideration
> or at least can be transformed into another useful idea.
>
> Regards,
> Kosit
>
> On Mon, Apr 8, 2019 at 9:07 PM Nikita Popov  wrote:
> >
> > On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov 
> wrote:
> >
> > > Hi internals,
> > >
> > > Motivated by the recent list comprehensions RFC, I think it's time we
> took
> > > another look at short closures:
> > >
> > > https://wiki.php.net/rfc/arrow_functions_v2
> > >
> > > This is based on a previous (withdrawn) proposal by Levi & Bob. It uses
> > > the syntax
> > >
> > > fn($x) => $x * $multiplier
> > >
> > > and implicit by-value variable binding. This example is roughly
> equivalent
> > > to:
> > >
> > > function($x) use($multiplier) { return $x * $multiplier; }
> > >
> > > The RFC contains a detailed discussion of syntax choices and binding
> modes.
> > >
> > > Regards,
> > > Nikita
> > >
> >
> > Heads up: I plan to start voting on this RFC tomorrow if nothing new
> comes
> > up.
> >
> > Most of the discussion was (as expected) about the choice of syntax.
> > Ultimately I think there are many reasonable choices we can make here,
> but
> > we should stick to a specific proposal for the purposes of the RFC vote.
> > None of the given arguments convinced me that some other syntax is
> > *strictly* better than the proposed fn($x, $y) => $x*$y -- it's more a
> > matter of some choices being slightly better in one case and slightly
> worse
> > in another. My personal runner-up would be \($x, $y) => $x*$y, but I
> > suspect that there are some people who are more strongly biased against
> > "sigil salad" than I am...
> >
> > Nikita
>

Re: [PHP-DEV] [RFC] Nullable Casting

[M. W. Moe]

Hello,

i) was intentional.

ii) Not our fault, we do not have this function in our code-base and won't
ever; we would not even dare 8).

Cheers!

On Mon, Apr 8, 2019 at 7:44 AM Dan Ackroyd  wrote:

> On Mon, 8 Apr 2019 at 04:21, M. W. Moe  wrote:
> >
> > Hello,
> >
> > looks like you are living in a pig stall; php would be benefit from type
> safety when explicitly required.
> >
> > Regards.
>
> Hi Moe,
>
> It seems you:
>
> i) accidentally hit reply, instead of reply all. This is an easy
> mistake to make.
>
> ii) Appear to be trying to compare me to a pig? I'm not sure that this
> is contributes to a productive discussion. Technical arguments are
> much better received than animal comparisons.
>
> cheers
> Dan
> Ack
>

Re: [PHP-DEV] Question about adding !function_identifier

[M. W. Moe]

Hello,

there is some trace of absolutism in every statements:

first;;; saying php is a highly dynamic is not not fact but a sorry ***
excuse; ain't part of engineering ; admitting php5 is a load of idiotic
mistakes yes; I like people going for reality not ideology; with facts you
can work with ideology; an infinite debate of nonsense with fanatics.

second;;; you can properly handling it without a preprocessor as people
trying hard to name it by going thru abusing
statements about static analysis; it's all about handling an exception
process properly; but it will require to break
compatibility as I mentioned previously.

Best.


On Fri, Apr 5, 2019 at 10:03 AM Benjamin Morel 
wrote:

> >
> > Yes, I think we are rapidly approaching the limit where to make the
> > language stricter, we need an official static analysis tool, like Hack
> has,
> > rather than trying to do everything at run-time.
>
>
> It might even be possible to build this into OpCache somehow, so that if
> > you pre-analyse your code, it will skip runtime checks that it can prove
> > will never fail (e.g. return type annotation on a function that always
> > returns literals).
>
>
>
> > The tricky part is that PHP is a highly dynamic language (...)
>
>
> Features like scalar type hints, return types, property type hints, and
> preloading (which makes the definition of a type-hinted class available at
> compile time), should definitely help towards skipping a lot of runtime
> checks!
>
>
> On Fri, 5 Apr 2019 at 11:37, Rowan Collins 
> wrote:
>
> > On Fri, 5 Apr 2019 at 09:57, Robert Hickman 
> wrote:
> >
> > > >
> > > > For instance:
> > > >
> > > > function foo(): type nothrow {
> > > > throw new SomethingException;
> > > > }
> > >
> > > Would it be possible to analyse the call graph at compile time
> > > (bytecode generation) and then trigger a fatal error? It wouldn't be
> > > possible for variable functions/methods though. A separate static
> > > analyser could do the same thing.
> > >
> >
> >
> > Yes, I think we are rapidly approaching the limit where to make the
> > language stricter, we need an official static analysis tool, like Hack
> has,
> > rather than trying to do everything at run-time.
> >
> > It might even be possible to build this into OpCache somehow, so that if
> > you pre-analyse your code, it will skip runtime checks that it can prove
> > will never fail (e.g. return type annotation on a function that always
> > returns literals).
> >
> > The tricky part is that PHP is a highly dynamic language, so there's a
> lot
> > of cases where the analysis can only return "maybe". My understanding is
> > that this is what a lot of the work on Hack is doing: creating a language
> > which looks a lot like PHP, but doesn't have as many ambiguous cases
> which
> > can't be analysed statically.
> >
> > Regards,
> > --
> > Rowan Collins
> > [IMSoP]
> >
>

Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings

[M. W. Moe]

Hello,

Yes and No php has an existing echo-system of extensions which could not
work
without this ini model; therefor it's fashion trend which is in my opinion
unrealistic or you
are ready to break existing infrastructures.

Enforcing  the right behavior (third one) will break existing code big
time; hence at some point
you need to go with a transitional state; it does not say that one day
you'r not gonna retire it
and finally enforcing only one ((the right behavior (third one))).




On Thu, Apr 4, 2019 at 9:06 AM Benjamin Morel 
wrote:

> what about exposing a strict keyword option or a php ini option?
>
>
> There is a trend right now towards avoiding the language to be dependent
> on php.ini options. I'm on board with this, and would personally strongly
> discourage introducing such an option, and enforce one of these options for
> everyone instead.
>
> On Thu, 4 Apr 2019 at 17:05, M. W. Moe  wrote:
>
>> Hello,
>>
>> what about exposing a strict keyword option or a php ini option?
>>
>> - NO - leave as it isdefault
>> - YES - allow trailing whitespace   punks
>> - YES - disallow leading whitespace sane people
>>
>> On Thu, Apr 4, 2019 at 1:57 AM Benjamin Morel 
>> wrote:
>>
>>> What about going forward with the trailing whitespace RFC right now, but
>>> ask to vote between 3 options?
>>>
>>> - NO - leave as it is
>>> - YES - allow trailing whitespace
>>> - YES - disallow leading whitespace
>>>
>>> And then proceeding with the string to number comparison RFC?
>>>
>>> Ben
>>>
>>> On Thu, 4 Apr 2019 at 01:15, Andrea Faulds  wrote:
>>>
>>> > Nikita Popov wrote:
>>> > > I'm always a fan of making things stricter, but think that in this
>>> > > particular case there are some additional considerations we should
>>> keep
>>> > in
>>> > > mind.
>>> > >
>>> > > 1. What is more important to me here than strictness is consistency.
>>> > Either
>>> > > both "   123" and "123   " are numeric, or neither are. Making "123
>>>   "
>>> > > numeric is a change we can easily do, because it makes the numeric
>>> string
>>> > > definition more permissive and is thus mostly backwards compatible.
>>> Doing
>>> > > the reverse change is certainly not compatible and will be a much
>>> harder
>>> > > sell.
>>> > >
>>> > > 2. I believe that a large part of the motivation here is that by
>>> making
>>> > the
>>> > > numeric string definition slightly more lax (in a consistent
>>> manner), we
>>> > > can make *other* things more strict, because this essentially
>>> eliminates
>>> > > the only "somewhat reasonable" case of trailing characters. The RFC
>>> > already
>>> > > mentions two of them:
>>> > >
>>> > > a) We can hard reject "123foo" inputs to "int" arguments (and some
>>> other
>>> > > places). Currently this is allowed with a notice. I think if we
>>> resolve
>>> > the
>>> > > trailing whitespace question, then there cannot be any reasonable
>>> > > opposition to this change.
>>> > > b) My own RFC on number to string comparisons would benefit from
>>> this.
>>> > From
>>> > > initial testing it has surprisingly little impact, but one of the few
>>> > cases
>>> > > that turned up was this comparison with a string that had trailing
>>> > > whitespace.
>>> > >
>>> > > Personally I think both of those changes are a lot more valuable
>>> than a
>>> > > stricter numeric string definition without leading/trailing
>>> whitespace.
>>> >
>>> > I'm kinda unsure how to go forward because of these points. I would
>>> like
>>> > to see improved comparisons, and I would like to see the end of the
>>> > “non-well-formed” numeric string, and I think this whitespace RFC could
>>> > be helpful to both. But I can't see the future, I don't know whether
>>> > people will vote for removing leading or permitting traiing whitespace
>>> > and whether or not they will be influenced by or this will influence
>>> > opinion on the further improvements. ¯\_(ツ)_/¯
>>> >
>>> > I'm torn between:
>>> >
>>> > * Vote on allowing trailing whitespace
>>> > * Vote on disallowing leading whitespace
>>> > * Vote on which of those two approaches to go for
>>> > * Trying to bundle everything together and voting on it as a package.
>>> >
>>> > I'm probably thinking too strategically.
>>> >
>>> > Andrea
>>> >
>>> > --
>>> > PHP Internals - PHP Runtime Development Mailing List
>>> > To unsubscribe, visit: http://www.php.net/unsub.php
>>> >
>>> >
>>>
>>

Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings

[M. W. Moe]

Hello,

what about exposing a strict keyword option or a php ini option?

- NO - leave as it isdefault
- YES - allow trailing whitespace   punks
- YES - disallow leading whitespace sane people

On Thu, Apr 4, 2019 at 1:57 AM Benjamin Morel 
wrote:

> What about going forward with the trailing whitespace RFC right now, but
> ask to vote between 3 options?
>
> - NO - leave as it is
> - YES - allow trailing whitespace
> - YES - disallow leading whitespace
>
> And then proceeding with the string to number comparison RFC?
>
> Ben
>
> On Thu, 4 Apr 2019 at 01:15, Andrea Faulds  wrote:
>
> > Nikita Popov wrote:
> > > I'm always a fan of making things stricter, but think that in this
> > > particular case there are some additional considerations we should keep
> > in
> > > mind.
> > >
> > > 1. What is more important to me here than strictness is consistency.
> > Either
> > > both "   123" and "123   " are numeric, or neither are. Making "123
> "
> > > numeric is a change we can easily do, because it makes the numeric
> string
> > > definition more permissive and is thus mostly backwards compatible.
> Doing
> > > the reverse change is certainly not compatible and will be a much
> harder
> > > sell.
> > >
> > > 2. I believe that a large part of the motivation here is that by making
> > the
> > > numeric string definition slightly more lax (in a consistent manner),
> we
> > > can make *other* things more strict, because this essentially
> eliminates
> > > the only "somewhat reasonable" case of trailing characters. The RFC
> > already
> > > mentions two of them:
> > >
> > > a) We can hard reject "123foo" inputs to "int" arguments (and some
> other
> > > places). Currently this is allowed with a notice. I think if we resolve
> > the
> > > trailing whitespace question, then there cannot be any reasonable
> > > opposition to this change.
> > > b) My own RFC on number to string comparisons would benefit from this.
> > From
> > > initial testing it has surprisingly little impact, but one of the few
> > cases
> > > that turned up was this comparison with a string that had trailing
> > > whitespace.
> > >
> > > Personally I think both of those changes are a lot more valuable than a
> > > stricter numeric string definition without leading/trailing whitespace.
> >
> > I'm kinda unsure how to go forward because of these points. I would like
> > to see improved comparisons, and I would like to see the end of the
> > “non-well-formed” numeric string, and I think this whitespace RFC could
> > be helpful to both. But I can't see the future, I don't know whether
> > people will vote for removing leading or permitting traiing whitespace
> > and whether or not they will be influenced by or this will influence
> > opinion on the further improvements. ¯\_(ツ)_/¯
> >
> > I'm torn between:
> >
> > * Vote on allowing trailing whitespace
> > * Vote on disallowing leading whitespace
> > * Vote on which of those two approaches to go for
> > * Trying to bundle everything together and voting on it as a package.
> >
> > I'm probably thinking too strategically.
> >
> > Andrea
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>

[PHP-DEV] Question about adding !function_identifier

[M. W. Moe]

Hello @Stephen Reay,

yes I have that in my, I was thinking about reusing the `throw` keyword and
re-contextualizing it à la use

  function handle(int $cmd, ...$args) : int throw(legit, error) /*
Throws only those else triggers runtime error */
  { return -1; }

  function handle(int $cmd, ...$args) : int throw(true) /* Throws any */
  { return -1; }

  function handle(int $cmd, ...$args) : int throw(false) /* Triggers
warning, auto-catch */
  { return -1; }

but unfortunately better forking php4.3 than actual and only re-introducing
what's is usable and discarding the rest mostly all the php5 impurities;
hence you can conceive; I would have to face the clerics of this false
religion; I have something else to do in life!

Best.

Re: [PHP-DEV] Question about adding !function_identifier

[M. W. Moe]

Thanks!

On Wed, Apr 3, 2019 at 1:24 PM G. P. B.  wrote:

> Hello,
>
> I don't really see the point of it as you self said this wouldn't add a
> runtime check, so in what is it different to a comment?
> More so reusing ! for this will, in my opinion, just lead to confusion as
> people will think it negates the function, this is what
> I would expect it to do at first glance.
> Also comparing it to the nullable question mark is quite bizarre I find,
> why not choose the ampersand for references instead?
> At least it would cover the same "scope", as types have nothing to do with
> how a function behaves.
>
> Best regards
>
> George P. Banyard
>

Re: [PHP-DEV] Question about adding !function_identifier

[M. W. Moe]

Hello,

you are very kind and trying hard but that's not the topic; the commenting
section suggestion was some kind of decoy or trap;
it does not address the original request and its scope; what's behind is
more fundamental; I may have a polite discussion and
argument with people; not bulls, they belong to the prairies.

and what  about ?String (cynicism)

Have a good day.

On Wed, Apr 3, 2019 at 11:42 AM Rowan Collins 
wrote:

> On 03/04/2019 18:13, M. W. Moe wrote:
>  > The argument sits there.
>  >
>  > function handle(int $cmd, ...$arg) : int /* throw */
>  > function !handle(int $cmd, ...$arg) : int
>
>
> The first example is unambiguous, easy to understand by anyone with a
> basic knowledge of the language, easy to spot when reading the code,
> easy to grep for, and will be recognised as a comment by any tool for
> parsing PHP.
>
> The second example is hard to spot, completely opaque in meaning, and
> would break any tool which didn't have it added as a feature. I'm really
> struggling to see any advantages at all, other than saving a few key
> presses.
>
> Of course, neither documents what type of exceptions will be thrown, so
> it's a bit like documenting every return type as either "void" or
> "mixed"; which is why the more common practice would look more like this:
>
> /** @throws InvalidFooException */
> function handle(int $cmd, ...$arg): int
>
>
> > you seems not having the experience of working on the same code base
> > with basically literally dozen of people which can at
> > some point intervene; this is reality, this not wrong or bad; you deal
> > with it.
>
>
> You're right, I haven't worked in a team that size, but if I did, I
> would expect strict coding standards that emphasise clear intent and
> documented behaviour to be absolutely essential for everyone to know
> what was going on.
>
>
> > either you enforce extra qualifiers in term of signature or you don't
> > encourage it
>
>
> I'm struggling to see the difference between enforcing "add an ! before
> the name if it throws" and "add a comment next to the name if it
> throws", or even "add X to the name if it throws", unless the language
> itself is going to perform some extra check.
>
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Question about adding !function_identifier

[M. W. Moe]

Hello,

quick commenting usually ends up in a `circus`; either you enforce extra
qualifiers in term of signature or you don't encourage it
you seems not having the experience of working on the same code base with
basically literally dozen of people which can at
some point intervene; this is reality, this not wrong or bad; you deal with
it.

We are a shop where people are using terminal emulators; vim or emacs not
cumbersome IDEs or for some not even a window manager
; reality; you deal with it. Moreover an exception state is not really like
a status; this is an internal language behavior, should
be carried by the syntax even if informal, anyhow could evolve over time.


On Wed, Apr 3, 2019 at 10:24 AM Rowan Collins 
wrote:

> On Wed, 3 Apr 2019 at 17:52, M. W. Moe  wrote:
>
> > not documenting at first is not really a question of laziness or so, as
> > things are still moving around
> > you absolutely  need this agility; a good design layout between theory
> and
> > stable state will refactored
> > discussed a thousand times; that what I expect from engineers; filling
> the
> > gaps between assumptions
> > and reality.
> >
>
>
> I think we have different assumptions about what "documentation" means
> here. I'm not saying you have to write a 500-word paragraph explaining the
> theory and edge-cases in the code; just that you should write a quick
> comment saying what the function expects, and what it will return, beyond
> the ability of the language's syntax.
>
> You *could* write every function like this:
>
> function tbc(...$args) {
> }
>
> That way, you can change the visibility, the argument types, the return
> types, and the name, without "documenting" it in advance. Clearly, that
> would be ridiculous, so you probably actually write this:
>
> public function convertFooToBar(Foo $foo): Bar {
> }
>
> What I mean by "documentation first" is to go a small step further and
> write:
>
> /**
>  * Convert using the lookup tables
>  *
>  * @param Foo $foo Should only be given pre-validated Foo
>  * @return Bar Will always be pre-validated
>  * @throws InvalidFooTypeException
>  */
> public function convertFooToBar(Foo $foo): Bar {
> }
>
>
> This is all part of the *current* design of this function. It might change,
> but if it changes, you change the docblock, just as you'd change the
> signature if you realised it should actually be private, or accept a
> PreValidatedFoo object, or the name is wrong.
>
>
> You seem to want to do this same job, but with as few characters as
> possible, and I don't really understand why, if your aim is to be explicit
> and clear. If you just want to type less, use an IDE or editor with good
> auto-complete support.
>
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>

Re: [PHP-DEV] Question about adding !function_identifier

[M. W. Moe]

The argument sits there.

function handle(int $cmd, ...$arg) : int /* throw */
function !handle(int $cmd, ...$arg) : int

On Wed, Apr 3, 2019 at 10:10 AM M. W. Moe  wrote:

> Hello,
>
> yes this is very true, but still foreign to the language construct; empty
> contextual indicators it's what
> we usually do in C and assembly (it has no cost) especially on extra
> sensitive code to make it short.
>
> On Wed, Apr 3, 2019 at 10:00 AM Claude Pache 
> wrote:
>
>>
>>
>> > Le 3 avr. 2019 à 18:52, M. W. Moe  a écrit :
>> >
>> > Hello,
>> >
>> > not documenting at first is not really a question of laziness or so, as
>> > things are still moving around
>> > you absolutely  need this agility; a good design layout between theory
>> and
>> > stable state will refactored
>> > discussed a thousand times; that what I expect from engineers; filling
>> the
>> > gaps between assumptions
>> > and reality.
>> >
>> > And for me-self throw vs no throw is important language information and
>> > part of internal behaviors;
>> > to clarify, for instance, would be more useful to have such indicator
>> > rather than having having
>> > abstract and interface which are cumbersome; same as the extra public
>> > keyword; you can do without
>> > especially with the new traits construct.
>> >
>> > Best.
>>
>> If you’re unwilling to write a docblock for some good reason, why not
>> just use the built-in, user-extensible way that most programming languages
>> have to add annotations without runtime effect, namely unstructured
>> comments? Something like /* nothrow */ is both forward- and
>> backward-compatible... Am I missing something?
>>
>> —Claude
>>
>>

Re: [PHP-DEV] Question about adding !function_identifier

[M. W. Moe]

Hello,

yes this is very true, but still foreign to the language construct; empty
contextual indicators it's what
we usually do in C and assembly (it has no cost) especially on extra
sensitive code to make it short.

On Wed, Apr 3, 2019 at 10:00 AM Claude Pache  wrote:

>
>
> > Le 3 avr. 2019 à 18:52, M. W. Moe  a écrit :
> >
> > Hello,
> >
> > not documenting at first is not really a question of laziness or so, as
> > things are still moving around
> > you absolutely  need this agility; a good design layout between theory
> and
> > stable state will refactored
> > discussed a thousand times; that what I expect from engineers; filling
> the
> > gaps between assumptions
> > and reality.
> >
> > And for me-self throw vs no throw is important language information and
> > part of internal behaviors;
> > to clarify, for instance, would be more useful to have such indicator
> > rather than having having
> > abstract and interface which are cumbersome; same as the extra public
> > keyword; you can do without
> > especially with the new traits construct.
> >
> > Best.
>
> If you’re unwilling to write a docblock for some good reason, why not just
> use the built-in, user-extensible way that most programming languages have
> to add annotations without runtime effect, namely unstructured comments?
> Something like /* nothrow */ is both forward- and backward-compatible... Am
> I missing something?
>
> —Claude
>
>

Re: [PHP-DEV] Question about adding !function_identifier

[M. W. Moe]

Hello,

not documenting at first is not really a question of laziness or so, as
things are still moving around
you absolutely  need this agility; a good design layout between theory and
stable state will refactored
discussed a thousand times; that what I expect from engineers; filling the
gaps between assumptions
and reality.

And for me-self throw vs no throw is important language information and
part of internal behaviors;
to clarify, for instance, would be more useful to have such indicator
rather than having having
abstract and interface which are cumbersome; same as the extra public
keyword; you can do without
especially with the new traits construct.

Best.


On Wed, Apr 3, 2019 at 9:42 AM Rowan Collins 
wrote:

> On Wed, 3 Apr 2019 at 17:27, M. W. Moe  wrote:
>
> > yes this is very true; but usually on complex design with a lot of folks
> > working on it you start coding before documenting;
> >
>
>
> If it's just syntax that doesn't change behaviour, it's really just
> documentation anyway, and if people are so desperate to dig into the code
> that they can't write a minimal docblock (or so lazy that they won't), how
> likely is it that they'll correctly add this new indicator?
>
> If you want to be explicit, don't put off docblocks until later (writing
> them before you've even implemented the function can be a great way of
> clarifying your design), and use an IDE or CI tool that will tell you when
> they're missing or incorrect.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>

Re: [PHP-DEV] Question about adding !function_identifier

[M. W. Moe]

Hello,

yes this is very true; but usually on complex design with a lot of folks
working on it you start coding before documenting;
I was thinking like c++ `nothrow` identifie (I do know does more than
informal), I am the kind of people who like languages
which are explicit before any documentation and a throw vs nothrow is an
important contextual information, it will forcibly
change the way you engage it.



On Wed, Apr 3, 2019 at 9:20 AM Sara Golemon  wrote:

> On Wed, Apr 3, 2019 at 11:07 AM M. W. Moe  wrote:
>
>> I have a quick question before any formal proposal; would it be complex to
>> add an exclamation mark indicatorin front a function identifier to
>> indicate
>> that function throws; like the nullable question mark for types however
>>  without any runtime check something like a pure syntax indicator to make
>> the code clearer?
>>
>> If you're suggesting something with no runtime validation, then why not
> simply use docblock annotations?  They're widely supported and understood
> already.
>
> Basically, what will having that syntax give you that not having it won't?
>
> -Sara
>

[PHP-DEV] Question about adding !function_identifier

[M. W. Moe]

Hello people,

I have a quick question before any formal proposal; would it be complex to
add an exclamation mark indicatorin front a function identifier to indicate
that function throws; like the nullable question mark for types however
 without any runtime check something like a pure syntax indicator to make
the code clearer?


Have a good day.