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

2019-04-03 Thread M. W. Moe
, 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 */ > >

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

2019-04-03 Thread 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

[PHP-DEV] Question about adding !function_identifier

2019-04-03 Thread 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

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

2019-04-03 Thread M. W. Moe
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 i

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

2019-04-03 Thread 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

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

2019-04-03 Thread M. W. Moe
r. 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 > > st

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

2019-04-03 Thread M. W. Moe
, 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 s

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

2019-04-03 Thread M. W. Moe
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 s

[PHP-DEV] Question about adding !function_identifier

2019-04-03 Thread 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

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

2019-04-04 Thread 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

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

2019-04-04 Thread M. W. Moe
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 - d

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

2019-04-05 Thread 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

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

2019-04-10 Thread 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

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

2019-04-09 Thread 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,

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

2019-04-09 Thread M. W. Moe
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 rep

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

2019-04-08 Thread 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, > > > >

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

2019-04-11 Thread M. W. Moe
, 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 previo

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

2019-04-11 Thread 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

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

2019-04-11 Thread M. W. Moe
t;> 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 >> wr

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

2019-04-11 Thread 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 >

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

2019-04-11 Thread M. W. Moe
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. >

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

2019-06-15 Thread 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

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

2019-06-15 Thread 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,

Re: [PHP-DEV] Re: MODERATE spam

2019-05-18 Thread 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,

Re: [PHP-DEV] Re: MODERATE spam

2019-05-18 Thread 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; shoul

Re: [PHP-DEV] High performance function autoloading

2019-05-20 Thread 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

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

2019-04-30 Thread 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

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

2019-05-01 Thread 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

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

2019-04-21 Thread 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

Re: [PHP-DEV] Object Type Casting Reloaded

2019-04-22 Thread 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

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

2019-04-24 Thread 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

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

2019-04-24 Thread 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

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

2019-04-10 Thread 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

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

2019-04-10 Thread 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

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

2019-08-16 Thread 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

Re: [PHP-DEV] Silent Types

2019-09-04 Thread 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

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

2019-09-09 Thread 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: >

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

2019-09-09 Thread 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 deta

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

2019-09-23 Thread 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;

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

2019-10-05 Thread 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

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

2019-10-08 Thread 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,

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

2019-10-08 Thread 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 > >

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

2019-10-08 Thread 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

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

2019-10-08 Thread 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?

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

2019-10-08 Thread 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

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

2019-10-09 Thread 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;