Hi Michał,
Thursday, February 8, 2024, 2:58:52 AM, you wrote:
>You inspired me to play with serialization format to spot even more
>unnecessary chars https://3v4l.org/DLh1U
>From my PoV there are more candidates to reduce and still keep the safety,
>for eg:
>removing leading ':' before array/obje
Nice work, Jim.
>I enjoy spelunking in the history of the project, so I did some digging. It
>looks to me like Kris didn't quite get the history correct. Boris did propose
>a form of serialization first, but it looks like what became serialize() and
>unserialize() came into the project another way
ll the old Internals posts nothing came up). Most of my
readers are pretty junior but I hate to say something that conflicts with
their intuition.
— S.
On Wed, Feb 7, 2024 at 7:28 AM Ilija Tovilo wrote:
>
> Hi Sandy
>
> On Tue, Feb 6, 2024 at 9:19 PM Sanford Whiteman
> wrote:
Howdy all, haven't posted in ages but good to see the list going strong.
I'd like a little background on something we've long accepted: why
does the serialization format need double quotes around a string, even
though the byte length is explicit?
Example:
s:5:"hello";
All else being equal I w
Tony, you have a point in the sense that a proposed Code of Conduct --
which would have been binding on posts to lists @php.net -- provoked a
fiery debate (to put it mildly) and was eventually withdrawn
(http://news.php.net/php.internals/90726).
The dominant objections to the CoC d
>
> the wording "bounce" is wrong as you don't send active mails, you reject
> messages
FYI, while incorrect, the wording comes from ezmlm, not Aidan:
Messages to you from the internals mailing list seem to
> have been bouncing. I've attached a copy of the first bounce
> message I received.
> rather than having a single untyped parameter amongst typed ones
Yes, when experimenting with strict types, I'd rather move things in and
out of 'mixed' than remove the notation completely. Like you said, 'mixed'
means, "I've reviewed this area and concluded it needs to be dynamic."
Also, may
> I like 2) No possible confusion, and it's a clear tag.
I agree, but it feels like it gets away from PHP's underscore-heavy
syntax. The poll omitted http://www.php.net/unsub.php
> Caching connections within the same request and reusing them is not
> spooky, but caching them long term, across requests, across security
> domains, for extended time - is spooky.
This is exactly what reverse proxies like Nginx and the Akamai CDN do:
reuse the connection between the proxy and o
> ...cases that make sense to nearly everybody for abstract
> bondage-and-discipline notion
Well, the 50 Shades of Grey movie is coming out soon, so let's wait and see how
that does. :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sounds more like a bugfix to me and def'ly an acceptable BC break in
either case. The behavior isn't specified and if anything I would
assume there _wouldn't_ be a swap with SORT_FLAG_CASE on. Interesting
though that many sorting examples (across languages) sidestep this
clearly common case.
-- S.
> I think that usage may have originated in PHP, actually.
Eh, dunno about that...
http://lists.w3.org/Archives/Public/ietf-http-wg-old/1995SepDec/0277.html
for example.
Even some W3C specs use "header" instead of the more accurate "header
field" so it's kind of a done deal.
-- S.
--
PHP Inter
> FWIW, there *is* a practical in-use (de facto if nothing else) convention of
> using _ in hosts for DKIM:
_domainkey is actually in all the DKIM RFCs and in the formal STD 76,
see § 3.6.2.1. Namespace, so it's more than a convention!
--
PHP Internals - PHP Runtime Development Mailing List
To u
Prove I "believe a multipart/form-data mime cannot be sent along with a PUT
request" using messages I have sent to this list. You are basically lying for
effect at this point. I never said that, took pains to explain that I am not
saying that, gave examples utterly to the contrary... yet you ma
> PUT is not intended to necessarily store the request entity body on the file
> system. Its intention is to store the entity body at the request URI.
I never said it was. I used the expression "store at the URI" about
10 ten times on this topic. You are arguing in bad faith by putting
words in
> Specifically, parsing the form data and populating it somewhere accessible
> to the user as it is today in $_POST and making any binary upload available
> in $_FILES or some other fashion. Ideally, making handling PUT more
> consistent with the way PHP handles POST.
OK, the first definition: "ha
> Nowhere did I suggest that the request verbs themselves (i.e. PUT and POST)
> have the same intent. Just
> that the handling of multipart-form data is not specific to either one of
> those verbs.
Define "handling." :/
"Handling" as in "interpreting multipart/form-data as key-value
pairs": a sp
> The HTTP specification doesn't restrict how the request body is encoded
> based on the request verb.
I never said it did... please don't put words in my mouth.
As Will notes, you're sidestepping the point, which standards-savvy
people have been driving at for years: the semantic differences (==
For the umpteenth time, *in what situation must you PUT multipart/form-data or
multipart/x-www-form-urlencoded only to treat it, semantically, as a POST*?
Which UA cannot send a POST? It's like we're completely upside down on this
thread.
If you're PUTing such POSTful content-types for any reas
> $_FILES (whose name is already method-agnostic)
The name appears method-agnostic but the implementation obviously
isn't. It works with multipart/form-data, which is tightly coupled
with POST, but which isn't the only way to transfer files, not by a
long shot. If you ignore the HTTP method you'r
> PUT, DELETE, must be available in a single global variable, the
> variable name is not important
> file_get_contents(‘php://input') - uncomfortably
If the quibble were with file_get_contents(‘php://input') that's not
sufficiently uncomfortable to warrant a new superglobal. I assume you
mean pars
You're right. Guess the build system didn't update
http://pecl.php.net/package/pecl_http with the DLL link as for other
exts.
-- S,
On Mon, Oct 27, 2014 at 12:31 AM, Will Fitch wrote:
>
> On Oct 26, 2014, at 10:38 PM, Sanford Whiteman
> wrote:
>
> pecl/http is availab
> pecl/http is available
To a degree, but no binaries for Windows == not a universal
prescription. Mailparse by contrast does have a shipping DLL.
-- S.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> The only way to do this in PHP now is write a userland function that parses
> multipart form data, which is non-trivial.
In addition to PECL HTTP, you might try PECL Mailparse, which is also
going to be better-tested than anything written in userland.
I sympathize with your overall point: even
You can already do:
$a = 1;
$b = 2;
switch( $switch_value = $a + $b ) {
default:
print $switch_value;
}
No magic or new operator required
-- S.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Mike,
> So it could still be seen as "works as expected", because it just checks if
> any answer is received. If that functionality is useful could be debatable.
That's not expected. Chasing (dereferencing) CNAMEs is one of the
understood burdens of any DNS app; you can't treat the CNAME its
> if somehost.example.com has the MX, it should return true with
> checkdnsrr('somehost.example.com'). If example has the MX set to
> somehost.example.com or similar, it should return true as well. Or am
> I missing your point?
You are missing it, as there are no MX records involved. I'm
demonstr
I don't think you tracked the behavior in the bug report.
If checkdnsrr() is doing an MX query -- not including implicit MX,
only explicit MX -- it must fail when there is no MX record. It can't
return `true` when there is a CNAME (and no MX record for the
canonical hostname, only an A) but `false
Hi Martin,
> The `get_the_used_switch_variable()` is just a placeholder, name can be
> changed to something natural...maybe a constant.
I feel this has diminished utility once you consider that the "switch
variable" is actually an expression and could well include multiple
$variables. Plus there'
> What would happen is it'd throw an E_DEPRECATED for at least the remainder
> of 5.x, then throw the usual E_WARNING for a missing argument starting in
> 7.x with no default.
Sounds OK to me now that I've noticed this:
https://bugs.php.net/bug.php?id=68081
Pretty sure that's a sane report,
Hi Kris,
On a broad level, your RFC asserts that checkdnsrr() is used to
determine "whether or not a hostname exists," but you don't actually
define "exists." It seems to me you're glossing over the fact that
"existence" is application-specific and doesn't add up to one single
RR type or set of t
... thought I just top-posted for the first time in, like, ever -- b/c I
guess janky Gmail does that by default (I had to switch my subscribed
address as php.net was deleting mail relayed through my ISP).
I was just composing an e-mail advising you to follow general netiquette
rules and read the original post. :)
I disagree utterly that I did not sufficiently address the question. I
addressed it in multiple ways:
[1] ANY queries create extraneous traffic, so you want fewer PHP functions
defaulting
ANY (*) requests are key to many DNS amplification attacks and may fail,
even if the RR you want exists when individually requested. Such requests
should be discouraged by clients, IMO. It's disappointing that PHP's
dns_get_record() defaults to ANY.
But more to the point, what is the client-side u
> ... ESPECIALLY since userland implementation is so trivial.
"Trivial" for most users means "copy-paste an unmaintained class
library you found somewhere" so you haven't solved the problem. Unless
something comes from one of the few trusted security extensions or
from a top framework, it's doubtf
> Under normal circumstances, entering elevator or tunnel would not loose
> session ID most likely since lost connection would not loose session ID.
> When end-users simply lost their connection, IP address wouldn't change.
There's good reason to believe that the "event" of being assigned a
new
> When URL based session is used, this feature should be
> disabled as pages are cached by browsers.
OK, I suppose, but that seems to be an edgier case than what we're
already discussing.
> BTW, if connection is unstable and an app force user to logout,
> is it going to be a problem? It would dep
> Users who are concerned for this situation should disable it. Users
> who are concerned security should accept this case.
I assume "users" are as we understand them here, i.e. me.
But as a developer-user I would likely want to empower my end-users to
turn off this feature themselves. With high-
> Let's be clear here: this won't happen (in most cases), because the client
> will simply get a new cookie and the session will keep working; it's like
> what you would implement if your user level goes from anonymous to logged
> in and vice versa.
I'm glad you addressed this because I'd been thi
> I've been thinking about this for a bit and even if you are right
> about being nice to have a way to call a function always after
> constructor. It could happen. You could have a DB class and in
> constructor the user/pass/host/options and then a separate method for
> init().
But that's not Cal
> Not that it would be an argument but just for understanding: Do you know
> any scripting language which has this?
Dropping the "scripting" part... IIRC, C++ calls ctors without
arguments automatically like in my 'sequentialBefore' napkin sketch.
C# has language-level support for 'sequentialBef
> No, that's why I am asking. Why is it an anti-pattern to call a known
> super constructor?
Guess I'd send you to my comments in the earlier thread as I think I
exhausted my ability to dismantle (advisory a..k.a. "pretty please")
Call Super there. Or "?call super antipattern".
Of course, most ev
> Most often if I need a super __construct(), I don't need it exactly
> before or exactly after the bottom constructor but at a specific point
> where I can setup super's input data and do stuff to its output.
I've most often seen, or reluctantly implemented, the Call Super
antipattern by putting
I suggest you read this recent thread for related commentary.
http://www.serverphorums.com/read.php?7,71
In there, I refer to your proposal as Contractual Call Super and I
find it an interesting concept that helps avoid the "advisory call
super" antipattern.
However --
> If the introdu
> And if you think 'London time' is UTC then you will get just as
> many problems half of tbe year.
I said the *end user will assume* UTC timestamps are London time. Not
that London time is UTC. People try to fit what they see into
something they know. People in US-East see stuff 4-5 hours off, t
> In my opinion UTC is a good compromise.
I agree that _in the absence of any other setting_ there's nothing
wrong with using UTC! Let be clear: UTC is a perfectly fine hands-off
default rather than issuing a warning. Non-technical end users will
guess you're on London time but whatever.
I am s
> TZ setting is meant to be the timezone that your site is serving. Of
> course, if the site is meant to serve multiple zones, then UTC may be
> appropriate. But if your site is a local shop in Elbonia, then all your
> times would be appropriate to Elbonian timezone, because all activities
> are do
> Then set the TZ to UTC or whatever else fits your needs. Server side
> TZ from a php point of view can be set to whatever you want, be at the
> php.ini level or in your application configuration (and call the
> appropriate function).
Was there something that indicated I don't know how to do this
> Until a user logs into a site and provides the data of their current
> daylight saving 'location'
Which we might as well assume will never happen. I know our users
don't waste time on this step if it's optional, and I'm not going to
push an E_FATAL onto them by saying I'm not going to show them
> It can be perfectly ok to allow the lib to be extended and the constructor
> extended/replaced with a compatible one.
Well sure, it's great to override constructors completely. If the lib
authors didn't want you to do that, they should've made it final
(which is what I said they should do now).
Encouraging call super is still not the right way to go about this. As
I said before, even with the changes proposed, there's no way to
*contractually enforce* the call super pattern in this language.
That's why it is and will remain an antipattern. So all you're doing
is allowing people to more ea
> I use some OOP library, that is a "black box" and I like it that way.
Hmm, there's "well-documented, change-controlled, trustable API that
you shouldn't try to work around" and then there's "black box." I'm
not sure the latter ever sounds like a good thing... I've always used
it as a bad word.
>> And what about automatic un/serialize() of objects in $_SESSION?
>> People don't even see those function calls in their code, so dropping
>> the function/ality would be a wildly drastic move.
> Nothing about it, the change is for unserialize() function.
OK. I thought of this as one core securi
> This is not a good situation, and presently there are no way to
> avoid it except dropping serialize() completely - which may not be
> an option is some cases and in any case would require serious
> changes to the production code.
And what about automatic un/serialize() of objects in $_SESSION?
> Create something like $foo->bar?() or $foo->bar()?, where you don't
> care whether the function exists, or if $foo is an object. If it
> doesn't exist you just return null.
[1] Don't do this.
[2] What everyone else said.
[3] If you feel you must, this at least "colors within the lines" a
bit m
> How do I verify it, and which projects are applicable?
> Does it depend on how many contributors it has? Users? How long it has
> been around?
> Commercial? OSS? Library? Framework? Applications? Websites?
I've long had the same question. Not that I think I've earned such
honor, believe me, but
> As for classes/interfaces/traits and so on, if they are ever added in PHP
> to be declared inside classes and so on then I see no issues with this.
> A class/interface or a trait keyword would still be needed to make the
> difference between a them imho.
No, if you *only* allow inner classes at
> So no you are not saying "PHP is not Java or C#". I don't want to touch
> any religious views but it's really funny to read :)
Not sure I get your remark... of those languages, I've said, in
essence [1] "Don't *force* PHP to look less like Java, ECMAScript, C#,
or C++ without a good reason and a
> It still looks like some random characters bashed together by a monkey
> with a keyboard.
+1, I am a fiend for ternary expressions and crazy one-liners, but
this makes me want to go back and unroll everything I've ever done
into readable code. :)
-- S.
--
PHP Internals - PHP Runtime Develo
> Classes always should be declared with class keyword, because there could
> be ambiguity whether it's class, interface or trait.
If only inner classes are allowed in a given PHP version, there's no
ambiguity about whether "something{}" just inside a a class is an
inner class.
That's the justifi
> Global functions remain its requirement for keyword, just methods
> lose
I understand that. You didn't read my post carefully because I was
noting this exact inconsistency.
> it. And it doesn't mean that you can't write
> class Foo {
> function bar() {}
> }
No, it means you _have to_ write it
While I'm thinking about this (though I should leave it alone): who's
to say that PHP won't some day get inner classes? By deciding the
"default" inner member of a class will be a function, you're choosing
the one that has a global/procedural equivalent where the short syntax
won't work, instead of
> Let's stop pretending that the vast majority of PHP users actually
> grep source code looking for `function foo`. They don't. *They don't
> even know how to use grep.*
I don't grep as in `grep`, but as in "regex search that is part of my
IDE but is not also tokenizing/whateverizing/PHP-aware."
> I am something of a language guru and to me syntax is *extremely*
> important. Am I of the opinion that removing the function keyword from
> the class definition will help? Yes, I am.
I'm missing the help. It saves 9 characters and creates a disjunction
between global function syntax and functi
Seems this would complicate the transplanting of (global) functions
into (default public) class methods and vice versa. This is a common
refactoring task -- at least IME -- and before I adjust visibility I
would expect the function to Just Work.
So this works in a class to define the function:
fu
I think it was done to ease adoption even though it was known to
violate LSP. To quote Stas, "As for established practice, everybody
expects DateTime, so IMHO we should leave DateTime as base class even
though it's not strictly OO-pure."
This way does let users sub in DateTimeImmutable more easily
P.S. This was the very extension I was referring to when I posted to
Internals sometime last year about developing extensions, latest
books, etc..
It'd been a longtime fantasy of mine because I use PHP for a lot of
sysadmin-type tasks on Windows servers -- DB import/export, nightly
HTTP and FTP tr
> There are native APIs for that (read: non .net, aka C) on Windows
Well aware of that. The EXE does use the Win32 API, not a .NET
wrapper. I've used that API ever since it's been documented.
> using an external process for this purpose would be horrible, in all
> possible ways.
Well, yeah, tha
> I think it'd be great to have a library with unified interface and an
> extension that uses it. However, I'm not sure if these libraries are
> useful in common php use case - short-lived requests. Could I get the
> changes since the last request? Or is it useful only for long-running
> persistent
> This is something of a wet dream of mine
TMI, my friend. TMI.
Anyway... I think your Subject is unnecessarily trolly even if the
substance of your post isn't. So maybe you could re-post with a "WAS:
Questioning..." to avoid p'ing off the dev team?
If I'm understanding your statement of "The a
>> If addPreserveText() uses anything from Footer, it should not be called
>> from TextRun, but if it does not, it should be in Section.
> No, if it was in Section, all the child classes would have to override
> it and throw errors. That results in quite a bit of pointless
> boilerplate code to so
Lester, are you seriously suggesting we coddle providers who either
[a] Willfully misrepresent the PHP versioning system, showing they are
utterly tuned out of the PHP support community?
or
[b] Play unfunny practical jokes on their users and/or troll this very
list?
If anything, their behavio
So... I was thinking of proposing that we perhaps leave Arrays as is
w/r/t undefined indices, while fixing up the ArrayObject gaps and
making that the "smart" one (wrap/box in an AO if you want
expanded/overloadable functionality).
That idea was based on my belief that ArrayObject::offsetGet alrea
> My feeling is that either more complex expressions for operators with an
> implicit "isset" or "!empty" shouldn't work, or that they should cause
> notices.
That's exactly why I think we're going in the wrong direction by
speaking of an "alternate ternary" operator.
You're saying the basic ter
> Use functions.
I understood your post; I was replying to Yahav.
Anyway, I don't agree with you that (built-in) functions are all we
can add because there'll be too much debate. Other languages still
consider adding operators over time and/or allow overloading. Getting
functions added to the la
> I think that you can compare the situation to the short if syntax ($a > $b
> ? $c : $d)
Not sure I understand... that *is* the situation under discussion,
no?
$a > $b ? ...
and
$a ? ...
both use the ternary operator.
You do raise (maybe on purpose, not totally clear what you were
getting a
> MySQl and MyISAM can not be used in conjuction with LIXA for
> distributed transaction processing.
Should be very clear about this in your documentation, as MySQL as RM
will be unsupported in practice in the majority of *MP installations.
You didn't mention MSSQL, I assume because you develop o
> 1. Is there any interest in "two phase commit" inside PHP
> community? Without a real interest, every effort would be useless.
I can't speak to a "critical mass" of interest, but as PHP and MySQL
are closely coupled in the real world, until relatively recently (when
Inno became the default) that
> Whether that article addresses rounding up, down or sideways, it's an
> awfully long article for what should be a fairly simple thing...
It does seem long-winded toward the top. I guess it's notable that in
all that text, it doesn't even note the floor/ceiling concept. I
interpret the absence as
> I'm not sure I understand where the conflict is. 2/3 * 50 == 33 1/3.
> Therefore, 33 states would be just below the required 2/3, while 34 states
> would be just above it. So the 34 figure you quoted seems to match this
> perfectly.
> The article does mention some ambiguity, but that's pertai
> Apparently, we are not the only ones confused by edge cases:
> http://en.wikipedia.org/wiki/Supermajority
Can you point to where there's any suggestion of using the ceiling
(rounding up) instead of requiring whole persons? In fact, the
Wikipedia page matter-of-factly says "...two thirds (curren
Ah, this is why one should trust a coder over a butler:
http://www.ask.com/answers/112530521/5-people-are-voting-what-is-2-3-s-of-a-majority
Ugh.
-- S.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> Sara’s book is still the best we have, nevertheless it shows its
> age. In Theo Schlossnagles "Scalable Internet Architectures" also
> has a chapter on PHP internals. The rest is more or less reading
> existing code and playing around. Looks like somebody on Internals should
> land a book deal :
Hi All,
Trying to ready myself for some possible work w/the core (after I
resurrect all my never-that-great C, heh), I went looking for a recent
book. (I still like old-school supplements.)
I see Sara's from 2006 on Amazon, but nothing after that under 'PHP
internals'. I'm sure that one's not tot
> At most, I'd remove the part that truncates numeric strings like
> "123abc" and always convert them to 0, because that's almost *never*
> an intended effect.
I too find it hard to think of the situation in which data must be
stored, even in a temporary form, as "123abc" but is meant to be
equiv
> Or find a way to have (some of) your users have some level of trust.
Or don't execute anyone's uploads.
If you allow people to upload code, make them say it's code (via
extension *and* by putting it in an executable area).
It is not difficult to predict whether a file will be processed by PHP
> Moreover, that still doesn't protect you, as it would be possible to
> make a valid image where the payload happened in the image data...
Agreed. But sanitizing input by silently removing blocks of data your
users rightfully expect to be preserved? That's egregious, even if it
"worked."
(Like m
>> Then one can strip off the exif info with the comments, I believe.
This presupposes that your users don't expect embedded metadata to be
preserved when people redownload the images.
Not only do photo professionals/hobbyists expect you to keep the
metadata, you also should leave it in for reaso
> But I just wanted to point out that this is something the author
> (and I) would never expect to happen ...
> in_array("123abc", array(3, 7, 123, 28)) === true
Well, would you never expect
select ( '123abc' in (3,7,123,28) )
to return boolean true in SQL?
Because it does.
Me, I'm happy
> Someone actually just pointed out to me that if(-1) returns true. In
> that case, I suppose my suggestion doesn't quite work.
Well, it still "works" depending on what conclusion you want to draw
in your local environment.
Sessions_disabled || yes_active_session might go through the same code
> There is no BC change here as session_status() has been added in the
> 5_4 branch as far as i can tell.
OK, fair enough, I didn't understand it was trying to get into 5.4.
-- S.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> I believe comparing the value against a constant, is always more
> readable than wondering what "truthy" means. if(session_status() ===
> PHP_SESSION_ACTIVE) is much self-documenting than the proposed change.
... also an obvious BC break for anyone who was using the values
instead of the
> Right now strtr('anything', 'anything', '') === 'anything', which
> means that anyone relying on this behavior is doing something strange
> and dumb imo, doing a function call for nothing.
How is relying on by-design behavior that turns the call into a no-op
(instead of wrapping the call in a
As ordered, I will stick to what I feel are community issues and try
to be impersonal.
If PHP users want to be clear that we have made an educated choice to
use/maintain the language, we should appear impeccably well-versed in
the technologies which complement and compete with PHP. I f
> There's no need to be rude. If you can't make your point without
> attacking people, then you need a better argument.
If you can't make your point without misusing terms to the point of
making yourself untrustworthy on that level alone, stop trying to
argue.
The "lazy programmer" axiom
> Also matter of opinion, and of experience. Apart from the fact that
> my use of jQuery amounts to a few weeks out of a (mumble)-year
> programming career, no I don't use pure JSON for it - Javascript
> object literals, yes, but not pure JSON.
It's not just you. The claim that people
> I don't think anyone cares about JSON for the sake of being perfect
> JSON, I didn't intend to give that impression.
Then you should stop saying "pure JSON" and "true JSON" constantly!
> I'm only hoping for something that generally works on par with all
> the other JSON parsers in the world
> Vs. the JSON form:
> {
> time: {'$and': [
> {'$gt': strtotime('-1 day')},
> {'$lt': time()},
> ]},
> '$or': [
> {foo: 'bar'},
> {hello: 'world'}
> ]
> }
That isn't valid JSON for many different reasons... if you think
that's "pure JSON," you
> isapi (is FastCGI now preferred on Win?)
Pls don't remove ISAPI, as it still workswindofor 5.3 even if
deprecated. We still use it as part of third-party x64 Windows builds.
-- Sandy
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/un
> First post here; been watching for a while though.
Same here.
Here's my take:
[1] I don't like ?? / ? because it is disjunctive with === / ==.. The
extra equals sign strengthens equality comparison, while the extra
question mark essentially _weakens_ the ternary operator (making it
mo
100 matches
Mail list logo
