Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124078 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 0CD961A009C for ; Sun, 30 Jun 2024 07:18:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1719731963; bh=Eui+OidgOh4anmMFiMo0vMcvSFxDycLL5zVvSzRkOjs=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=mMEGfPymEe/ZzEycr/F3g5dSmpBWYYRQyQb/y1UV4AyWJQuaYXcdypp437g9g7z/S 5n9Nv3MqfpozcIO2DYcFZ5pb2WSZv/GxphRjgzMDaYsWiBJoBts5HbYe803CGWsv3G uHBLRiCsFI7z8LnQWVh5ycNLukIi2rXijUr55zPcOS1fiPJkN93NODfhdvAPHXV1Uj IiwgNbYHVwdDBAhF8BPE15pLja3fhk1OHaaci3oYz8xm5jrsyV8KTrhMVu7dI8M3l6 I4EZTelmyvransWS+QRvBjcVerpebRivVrA07q6i85/v2ZQxyzOgeTAKts6kPEgOGQ Tr5wQD3lMWxRA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 62EDD1809F6 for ; Sun, 30 Jun 2024 07:19:22 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from fhigh4-smtp.messagingengine.com (fhigh4-smtp.messagingengine.com [103.168.172.155]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sun, 30 Jun 2024 07:19:21 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 8C1E9114022A; Sun, 30 Jun 2024 03:18:01 -0400 (EDT) Received: from imap49 ([10.202.2.99]) by compute1.internal (MEProxy); Sun, 30 Jun 2024 03:18:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bottled.codes; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm3; t=1719731881; x= 1719818281; bh=/rbgUzVrGEq4YyfkwYxlvB3a+4e0HWECt9C+gHCXkrw=; b=e 2oEKWFHlBxnlYQqujLhYE7In1NfJ2v7Mxv6RD6hzUL6KInL5CBIX2bPkhkUC67tc d6o3GKs6ND1ULQBB4p5uTSWYlrqxB0KPQCnoRFi49Pv0hK54G8EuBOhJIwnmW1gu 0gMi693mMKI+QmVsmqWix3Qq0dKWClfhIe3OSDyqseW09QyKFTiEE6JQn2vtHd2p YE3hyU++sVteZmVP1fmNcfsXVukm/aBMEAXsYTKvP5SZH5Tk9aBIZay3yu/tzvoA I+YyzOA1Y9FRxskI0l3vroZFr9ANYbeiQoSBjEd7T9gd81AgTc07rl55gR2eUqGx REw3nCm4siUinL499O2hg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1719731881; x=1719818281; bh=/rbgUzVrGEq4YyfkwYxlvB3a+4e0 HWECt9C+gHCXkrw=; b=vxkGSkdGVs2BGhfbDffdKXdq4Ac/3VV+fhgRsD4foECB nF+MhiqVg0M0dO9aSfhmq/oJ2PqcCktY5D9ECmUPnPFAmPKhBuR9en7r8pCLRKpo /Mgn83hP6JEBd1ZgI6zHb+9F9paE9KRtDAIazIL9AZkehAyPDig58TmCU7DRpBK1 wD5IpMpXaEnWRfsrB5CH3GPnq6/cQGNzcjGgvkF7+vgtkcdJItS7fhy9/ipABpO0 o+ciR+86jQdA3ZYkkwqR6kqXV5acrJYeQoBn5QUykcxN+9Jusk+TbGGet/2t1nKo X7BPRHiBw6X7us1ez95hERGAtPcPkkqusex3e8t+eg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddruddtgdduudekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsegrtderreerreejnecuhfhrohhmpedftfho sgcunfgrnhguvghrshdfuceorhhosgessghothhtlhgvugdrtghouggvsheqnecuggftrf grthhtvghrnhephedtiedtkeehtdettefhkedttefgudelkeeggeefveelvdelffdtveet hedutdelnecuffhomhgrihhnpegthhgrthhgphhtrdgtohhmpdhphhhprdhnvghtnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprhhosgessgho thhtlhgvugdrtghouggvsh X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id BC6D715A0092; Sun, 30 Jun 2024 03:18:00 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-538-g1508afaa2-fm-20240616.001-g1508afaa Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 Message-ID: <461ce648-d42f-4ced-a9fd-a03be83fc22e@app.fastmail.com> In-Reply-To: <5B2D9EAB-81E9-4450-A612-EA482DFDFE7B@newclarity.net> References: <0acedb8e-34be-4348-907b-4075cf7641fd@app.fastmail.com> <9c20b078-f82a-47fe-af23-2f3cdd233079@app.fastmail.com> <50529C6A-42BB-4D49-B720-FE1847577484@rwec.co.uk> <97EA49E2-43A9-42D2-B493-A6B66CC54914@edison.tech> <5B0CE06B-DB82-442E-A4A0-BF1B49F42246@newclarity.net> <5B2D9EAB-81E9-4450-A612-EA482DFDFE7B@newclarity.net> Date: Sun, 30 Jun 2024 09:17:15 +0200 To: "Mike Schinkel" Cc: internals@lists.php.net Subject: Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript Content-Type: multipart/alternative; boundary=8b03519c47a2409da20bde634c6d9ce2 From: rob@bottled.codes ("Rob Landers") --8b03519c47a2409da20bde634c6d9ce2 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sun, Jun 30, 2024, at 08:40, Mike Schinkel wrote: > > On Jun 29, 2024, at 9:15 AM, Rob Landers wrote: > > On Sat, Jun 29, 2024, at 13:43, Mike Schinkel wrote: > >>> On Jun 29, 2024, at 7:14 AM, Rob Landers wrote: > >>>> You say it is impractical, you claim millions of users, but you d= on't address why the specific features are impractical. > >>>>=20 > >>>> They are no more impractical than any other new language features= PHP has added in recent years (and I am not being critical of what has = been added, to be clear.) > >>>=20 > >>> So far, nobody has shown how it is practical -- that is on the per= son proposing the RFC. Ideally, this would be it, you show why it is use= ful, how to use it, etc. But it is also political. You need to show why = people would use it, why people would rewrite their entire application t= o use it (if the RFC calls for it), and so far, nobody has shown that ot= her than "there are packages!" > >>=20 > >> The problem with your assertion is that "impractical" is not a crit= icism that can be objectively determined to be true or false. It is just= a pejorative used to stifle discussion which is why I responded to it a= s a did. > >>=20 > >> Yes I agree that it is no proposers to show people why to use it, b= ut it is unfair to proposers to give criticism that can only be classifi= ed as opinion. > >=20 > > The RFC process is people problems, not technical ones. Thus they ca= n only be solved by swaying people's opinions which sometimes involves t= echnicalities. People have and will decline RFCs simply because they don= 't like it. It's that simple. >=20 > Absolutely. =20 >=20 > But that argument encourages a focus on feeling and not technical obje= ctivity.=20 I get it man. I really do. I have gone off on rants on this list a coupl= e of times because people refuse to help make things better if they don'= t like it. They just say "I don't like it, good luck" without much const= ructive feedback like I've (hopefully) been trying to give here. I don't= like this feature as-proposed, but maybe if I nudge you and whomever in= a different direction, you'll come up with something I do like. But if = I don't participate, it is literally a waste of everyone's time.=20 I'm actually on your side. I do want modules, but the devil is in the de= tails.... > If a proposer convinces everyone that their idea is great but ignores = objective technical factors they were get an RFC passed that either cann= ot be implemented or worse actively harms the language. This has happened a few times now... > I argue it is incumbent on those discussing RFCs to remain within the = realm of the objectively quantifiable and to also expect to be challenge= d back when their challenges are not objectively quantifiabl,e such as w= hen the challenge is in the form of an opinion-based characterization (= where "impractical" is an opinion-based characterization without objecti= ve criteria for any proposer to address. Rowan even acknowledged that hi= s question might have been poorly worded.) Yep. This happens, too. See my operator overrides RFC right now. I'm act= ively trying to cater to all the people who voted "NO" on the previous o= perator overrides RFC -- which means doing the opposite of well-research= ed best-practices, but whatever. I can firmly say that the lack of const= ructive criticism has been interesting. I think people want it to fail, = but it's so "php-like" it might actually pass (insert scream emoji here)= . I think constructive criticism is the way to go, and I DO forget this = from time to time, as does everyone. > >>> You need to show why people would use it, why people would rewrite= their entire application to use it (if the RFC calls for it), and so fa= r, nobody has shown that other than "there are packages!" > >>=20 > >> It seems you have not read any of the several other emails I have w= ritten to this list in the past several days that do far more than say "= there are packages!" > >>=20 > >> Please read them in full before making such further equivalently di= smissive claims. > >=20 > > My apologies if I've missed it, but I find your emails extremely har= d to read. The extra indentation you do on your replies makes it show up= as quoted text that I have to expand in my email reader. It may be that= my email reader has hidden entire replies from you and I wouldn't even = know it. >=20 > Interesting. My email style has always been to try to make my emails a= s scannable as possible and I have used intention for that. I never susp= ected that indented would have the opposite effect I intended. >=20 > I would never know that unless someone called it out, which you and Ro= wan have mentioned.=20 >=20 > Thank you and I will try my best to avoid indentions in the future ema= ils to this list. :thumbs-up: Thank you. I didn't think it was on purpose, but to be hones= t, it took a while to figure out what was even going on. :D >=20 > >>> I cringed at this. There is no direct lineage though they borrow c= ome syntax from C, and if you want to push it, you might as well say the= y're descendants of B which borrowed syntax from BCPL which borrowed syn= tax from CPL which borrowed it's syntax from ALGOL... eh, no, these lang= uages are not related to each other. Inspired, maybe. > >>=20 > >> Aside from your cringing, how does your pedanticism here move the d= iscussion forward in a positive manner? > >=20 > > This isn't pedanticism, it's just plainly incorrect. There's been a = lot of that in this thread (I haven't been keeping track of who said wha= t per-se), to the point where some of it can't be taken seriously, like = composer taking the lock file idea from npm. Like, sure, let's just go a= bout rewriting history in this thread too. Most of these assertions can = be checked by simply doing a quick search before sending the email, but = arguments based on lies/incorrect facts are not valid arguments. That is= why I am pointing it out, so that you (or whomever) can come back with = a valid argument. > >=20 >=20 > It is not "incorrect" and these are not "lies." We three were debatin= g a characterization and characterizations are by-nature derived from op= inion thus cannot be objectively judged to be correct or incorrect nor a= ccurately designated as "lies." Ah, sorry, I didn't mean to intend that you (or anyone) were lying! My i= ntention was to simply add that as a possible state of the facts, not th= at anyone was doing it actively! >=20 > To which I will restate: "How is your characterization of the relation= ship between Go and PHP vs. my characterization really relevant to this = discussion, and how does it make positive impact on the debate?" Fair enough, but I didn't know if you would reuse that fact in a rebutta= l. Ergo, it is better to correct it immediately if we want to build on t= he original premise. >=20 > >> Again, you are making a statement that cannot be objectively proven= true or false, and frankly I cannot see any way in which your argument = here matters to discussion of modules. > >=20 > > As someone who used to make a living porting things from one languag= e to another, I can say, quite frankly, that this is objectively true. >=20 > >=20 > I asked ChatGPT: >=20 > "If someone says "X and Y are alike" and someone else says "No, X and = Y are not alike" and follows it up saying based on their experience that= they know "X and Y are not alike" is objectively true, is it possible f= or them to be correct in their assertion that their claim is objective t= ruth? Why or why not?"=20 >=20 > ChatGPT responded =E2=80=94 in part =E2=80=94 with this: >=20 > "If the claim that "X and Y are not alike" is based solely on personal= experience without clear, objective criteria or evidence, then the clai= m is more subjective. Personal experiences can inform perceptions, but t= hey are not sufficient to establish objective truth without verifiable e= vidence." >=20 > And this: >=20 > "Conclusion >=20 > It is possible for someone to be correct in their assertion that their= claim is objectively true if: >=20 > =E2=80=A2 There are clear, agreed-upon criteria for what makes X and Y= alike. > =E2=80=A2 There is verifiable evidence supporting the claim that X and= Y do not meet these criteria. >=20 > If these conditions are met, then the claim that "X and Y are not alik= e" can be objectively true. Otherwise, if the criteria are ambiguous or = the claim is based solely on subjective experience, it cannot be conside= red an objective truth." >=20 > Full reply here: https://chatgpt.com/share/b8ae223c-5d53-4e84-8353-79= d2ac15dd6a >=20 > I see no "clear, agreed-upon criteria for what makes X and Y alike" no= r "verifiable evidence supporting the claim that X and Y do not meet the= se criteria." =20 >=20 > As such, given these criteria, no, it is NOT objectively true. >=20 > Still, once again, "How is your claim of being the exclusive holder of= objective truth between you and me really relevant to this discussion, = and how does it make positive impact on the debate?" I don't remember what we were talking about, but it seems to me that thi= s was an off-topic part of the discussion. If I may throw this back: wha= t does any of this email have to do with modules? :p > > If you go create an RFC right now, you're faced with the following g= uideline in the template, before you even write a word: > >=20 > >> Quoting [[http://news.php.net/php.internals/71525|Rasmus]]: > >>=20 > >> > PHP is and should remain: > >> > 1) a pragmatic web-focused language > >> > 2) a loosely typed language > >> > 3) a language which caters to the skill-levels and platforms of a= wide range of users > > Your RFC should move PHP forward following his vision. As [[http://n= ews.php.net/php.internals/66065|said by Zeev Suraski]] "Consider only fe= atures which have significant traction to a > > large chunk of our userbase, and not something that could be useful = in some > > extremely specialized edge cases [...] Make sure you think about the= full context, the huge audience out there, the consequences of making = the learning curve steeper with > > every new feature, and the scope of the goodness that those new feat= ures bring." >=20 > Per my characterization I see that everything I am proposing fits into= that classification. >=20 > However, based on my recent experience with your propensity to argue a= gainst the characterizations made by others I feel certain you will tell= me that my characterization "wrong" and that you are the only one betwe= en the two of us who could possibly be "correct." =20 I don't think you're wrong and I'm sorry if I've made you feel that way.= I am merely asking you to explain why you think you're right and you mi= ght have to explain it different ways, several times, to several people = before "it clicks." =E2=80=94 Rob --8b03519c47a2409da20bde634c6d9ce2 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Sun, Jun 30,= 2024, at 08:40, Mike Schinkel wrote:
> On Jun 29, 2024, at 9:15 AM, Rob Landers= <rob@bottled.codes> wrot= e:
> On Sat, Jun 29, 2024, at 13:43, Mike Schinkel wrot= e:
>>> On Jun 29, 2024, at 7:14 AM, Rob Landers &= lt;rob@bottled.codes> wrote:=
>>>> You say it is impractical, you claim mil= lions of users, but you don't address why the specific features are impr= actical.
>>>> 
>>>= > They are no more impractical than any other new language features P= HP has added in recent years (and I am not being critical of what has be= en added, to be clear.)
>>> 
&= gt;>> So far, nobody has shown how it is practical -- that is on t= he person proposing the RFC. Ideally, this would be it, you show why it = is useful, how to use it, etc. But it is also political. You need to sho= w why people would use it, why people would rewrite their entire applica= tion to use it (if the RFC calls for it), and so far, nobody has shown t= hat other than "there are packages!"
>> 
>> The problem with your assertion is that "impractical" i= s not a criticism that can be objectively determined to be true or false= . It is just a pejorative used to stifle discussion which is why I respo= nded to it as a did.
>> 
>>= Yes I agree that it is no proposers to show people why to use it, but i= t is unfair to proposers to give criticism that can only be classified a= s opinion.
> 
> The RFC process i= s people problems, not technical ones. Thus they can only be solved by s= waying people's opinions which sometimes involves technicalities. People= have and will decline RFCs simply because they don't like it. It's that= simple.

Absolutely.  
<= div>
But that argument encourages a focus on feeling and n= ot technical objectivity. 

I get it man. I really do. I have gone off on rants on this list a cou= ple of times because people refuse to help make things better if they do= n't like it. They just say "I don't like it, good luck" without much con= structive feedback like I've (hopefully) been trying to give here. I don= 't like this feature as-proposed, but maybe if I nudge you and whomever = in a different direction, you'll come up with something I do like. But i= f I don't participate, it is literally a waste of everyone's time.
<= /div>

I'm actually on your side. I do want modules, b= ut the devil is in the details....

If a proposer convinces everyone that t= heir idea is great but ignores objective technical factors they were get= an RFC passed that either cannot be implemented or worse actively harms= the language.

This has happen= ed a few times now...

I argue it is incumbent on those discussing RFCs to= remain within the realm of the objectively quantifiable and to also exp= ect to be challenged back when their challenges are not objectively quan= tifiabl,e such as when the challenge is in the form of an opinion-based = characterization  (where "impractical" is an opinion-based characte= rization without objective criteria for any proposer to address. Rowan e= ven acknowledged that his question might have been poorly worded.)

Yep. This happens, too. See my oper= ator overrides RFC right now. I'm actively trying to cater to all the pe= ople who voted "NO" on the previous operator overrides RFC -- which mean= s doing the opposite of well-researched best-practices, but whatever. I = can firmly say that the lack of constructive criticism has been interest= ing. I think people want it to fail, but it's so "php-like" it might act= ually pass (insert scream emoji here). I think constructive criticism is= the way to go, and I DO forget this from time to time, as does everyone= .

>>> You need to show why people would use it, why people woul= d rewrite their entire application to use it (if the RFC calls for it), = and so far, nobody has shown that other than "there are packages!"
>> 
>> It seems you have not rea= d any of the several other emails I have written to this list in the pas= t several days that do far more than say "there are packages!"
=
>> 
>> Please read them in full befo= re making such further equivalently dismissive claims.
>= ; 
> My apologies if I've missed it, but I find yo= ur emails extremely hard to read. The extra indentation you do on your r= eplies makes it show up as quoted text that I have to expand in my email= reader. It may be that my email reader has hidden entire replies from y= ou and I wouldn't even know it.

Interesting= . My email style has always been to try to make my emails as scannable a= s possible and I have used intention for that. I never suspected that in= dented would have the opposite effect I intended.

I would never know that unless someone called it out, which you a= nd Rowan have mentioned. 

Thank you an= d I will try my best to avoid indentions in the future emails to this li= st.

:thumbs-up: Thank you. I d= idn't think it was on purpose, but to be honest, it took a while to figu= re out what was even going on. :D


>>> I cringed a= t this. There is no direct lineage though they borrow come syntax from C= , and if you want to push it, you might as well say they're descendants = of B which borrowed syntax from BCPL which borrowed syntax from CPL whic= h borrowed it's syntax from ALGOL... eh, no, these languages are not rel= ated to each other. Inspired, maybe.
>> 
>> Aside from your cringing, how does your pedanticism her= e move the discussion forward in a positive manner?
>&n= bsp;
> This isn't pedanticism, it's just plainly incorr= ect. There's been a lot of that in this thread (I haven't been keeping t= rack of who said what per-se), to the point where some of it can't be ta= ken seriously, like composer taking the lock file idea from npm. Like, s= ure, let's just go about rewriting history in this thread too. Most of t= hese assertions can be checked by simply doing a quick search before sen= ding the email, but arguments based on lies/incorrect facts are not vali= d arguments. That is why I am pointing it out, so that you (or whomever)= can come back with a valid argument.
> 
=

It is not "incorrect" and these are not "lies." = ; We three were debating a characterization and characterizations are by= -nature derived from opinion thus cannot be objectively judged to be cor= rect or incorrect nor accurately designated as "lies."

Ah, sorry, I didn't mean to intend that you (or= anyone) were lying! My intention was to simply add that as a possible s= tate of the facts, not that anyone was doing it actively!

=

To which I will restate: "How is your characterization of the relations= hip between Go and PHP vs. my characterization really relevant to this d= iscussion, and how does it make positive impact on the debate?"

Fair enough, but I didn't know if you = would reuse that fact in a rebuttal. Ergo, it is better to correct it im= mediately if we want to build on the original premise.

>> Again, you are making a statement that cannot be objectively = proven true or false, and frankly I cannot see any way in which your arg= ument here matters to discussion of modules.
> 
> As someone who used to make a living porting things fro= m one language to another, I can say, quite frankly, that this is object= ively true.

<sigh>

=
I asked ChatGPT:

"If someone say= s "X and Y are alike" and someone else says "No, X and Y are not alike" = and follows it up saying based on their experience that they know "X and= Y are not alike" is objectively true, is it possible for them to be cor= rect in their assertion that their claim is objective truth? Why or why = not?" 

ChatGPT responded =E2=80=94 in = part =E2=80=94 with this:

"If the claim tha= t "X and Y are not alike" is based solely on personal experience without= clear, objective criteria or evidence, then the claim is more subjectiv= e. Personal experiences can inform perceptions, but they are not suffici= ent to establish objective truth without verifiable evidence."
=

And this:

"Conclusion

It is possible for someone to be correct in = their assertion that their claim is objectively true if:
<= br>
=E2=80=A2 There are clear, agreed-upon criteria for what m= akes X and Y alike.
=E2=80=A2 There is verifiable evidence= supporting the claim that X and Y do not meet these criteria.
=

If these conditions are met, then the claim that "X = and Y are not alike" can be objectively true. Otherwise, if the criteria= are ambiguous or the claim is based solely on subjective experience, it= cannot be considered an objective truth."


I see no "clear, = agreed-upon criteria for what makes X and Y alike" nor "verifiable evide= nce supporting the claim that X and Y do not meet these criteria." =  

As such, given these criteria, no, i= t is NOT objectively true.

Still, once agai= n, "How is your claim of being the exclusive holder of objective truth b= etween you and me really relevant to this discussion, and how does it ma= ke positive impact on the debate?"

=
I don't remember what we were talking about, but it seems to me tha= t this was an off-topic part of the discussion. If I may throw this back= : what does any of this email have to do with modules? :p
=
> If yo= u go create an RFC right now, you're faced with the following guideline = in the template, before you even write a word:
> <= br>
>> 
>> > PHP is and sh= ould remain:
>> > 1) a pragmatic web-focused lang= uage
>> > 2) a loosely typed language
>> > 3) a language which caters to the skill-levels and plat= forms of a wide range of users
> Your RFC should move P= HP forward following his vision. As [[http://news.php.net/php.internals/66065|said = by Zeev Suraski]] "Consider only features which have significant tractio= n to a
> large chunk of our userbase, and not something= that could be useful in some
> extremely specialized e= dge cases [...] Make sure you think about the full context, the huge aud= ience out there, the consequences of  making the learning curve ste= eper with
> every new feature, and the scope of the goo= dness that those new features bring."

Per m= y characterization I see that everything I am proposing fits into that c= lassification.

However, based on my recent = experience with your propensity to argue against the characterizations m= ade by others I feel certain you will tell me that my characterization "= wrong" and that you are the only one between the two of us who could pos= sibly be "correct."  

I don't think you're wrong and I'm sorry if I've made you feel that wa= y. I am merely asking you to explain why you think you're right and you = might have to explain it different ways, several times, to several peopl= e before "it clicks."

=E2= =80=94 Rob
--8b03519c47a2409da20bde634c6d9ce2--