profile
viewpoint

push eventAlexsey/slowloris

Alexsey

commit sha 4f57aa3eee68166d02d2578c5562ef2e1a5959f8

Update README.md

view details

push time in 19 days

push eventAlexsey/slowloris

Alexsey

commit sha e7862779d2fe097724cc8b7eb1611fc56c383ecc

Update README.md

view details

push time in 19 days

push eventAlexsey/slowloris

Alexsey

commit sha 218935ecce7e402ab24e2d8bba7e176b0a2a16a3

initial implementation

view details

push time in 19 days

push eventAlexsey/slowloris

Alexsey

commit sha 2f0e6d70128b89faff2f5a876da1b3f5c9481cfd

initial implementation

view details

push time in 19 days

push eventAlexsey/slowloris

Alexsey

commit sha cfd67b6e5e0d19006826016e46d1786b7085e8a1

initial implementation

view details

push time in 19 days

push eventAlexsey/slowloris

Alexsey

commit sha d6691a9bd11366bd39d41998ffb639d5311e79a2

initial implementation

view details

push time in 19 days

push eventAlexsey/slowloris

Alexsey

commit sha ab3ca7ed3a2082e0b403c33ec0817186346c042f

initial implementation

view details

push time in 19 days

push eventAlexsey/slowloris

Alexsey

commit sha 41c7862a62b9a66d0616444db7cb677d10d6d0da

initial implementation

view details

push time in 19 days

push eventAlexsey/slowloris

Alexsey

commit sha 603571d5c7160e6c828ce947dfa83f3d695434b6

initial implementation

view details

push time in 19 days

push eventAlexsey/slowloris

Alexsey

commit sha 59a7594e31b56e5bb88af3785d03244a8c098c43

initial implementation

view details

push time in 19 days

push eventAlexsey/slowloris

Alexsey

commit sha 978ba2295727e121c59b88060de4ba43b4f62ecf

initial implementation

view details

push time in 19 days

push eventAlexsey/slowloris

Alexsey

commit sha 74565cf710e0a9165ac721fba750409f5de16743

initial implementation

view details

push time in 19 days

push eventAlexsey/slowloris

Alexsey

commit sha b15c34de107cd8c9745e6fb6b79b5c4154d5ad1c

initial implementation

view details

push time in 19 days

push eventAlexsey/slowloris

Alexsey

commit sha b9ac5cfcc399ebf1238fdc849790c16d09b9f9f2

initial implementation

view details

push time in 19 days

create barnchAlexsey/slowloris

branch : master

created branch time in 19 days

created repositoryAlexsey/slowloris

created time in 19 days

issue commentdenoland/deno

Rename Deno into deno

I'm sorry for confusing anyone. Everywhere instead of "host variable" should be "host object". I'll change my previous comments but leave this one so @methodbox comment would not lose sense

Alexsey

comment created time in 24 days

issue commentdenoland/deno

Rename Deno into deno

Modules are self contained and should not lead and of the Deno APIs outside of the module using that namespace.

I'm not talking about technical aspect, but about mental. The problem you are talking about would be solved with Realms. But even when we would have Realms you still should not change interfaces of array methods and other stuff like that. Unless you are the only person who is working with the codebase - in this case, you can do whatever you want, of course.

It isn't a host variable. It is a global namespace. We have examples where these are CamelCase (e.g. Reflect).

Deno is a hots variable Reflect is a native object of ECMAScript spec i.e. not a host variable

A pointed out above, it is not the de-facto in modern JavaScript. TC39 continue to use CamelCas. It is the W3C in the browser which have used camelCase.

And I have written before why TC39 continues to use UpperCamelCase even though in userland and environments de-facto standard is camelCase

Alexsey

comment created time in 25 days

issue commentdenoland/deno

Rename Deno into deno

Why is it obvious?

Because there are expectations that other people have about your code. And such things would bring confusion. And there is consistency. And you always should have a good reason to break consistency. Or it would bring even more confusion

Let me give you some real-world examples: you are not overriding ES3 array methods like sort, reverse or splice for them not to modify the array they have been called on. You are not overriding push for it to return this instead of length to make it chainable. You use typeof although it returns object for null. All these are design mistakes that TC39 cannot fix because they can not break the web and you would not solve because you don't want to bring confusion to your code. And for the same reason, you should not do const deno = Deno;

But it isn't a DOM namespace either, so it shouldn't use camelCase. Same logic.

No. The logic is that Deno is a host variable, and we have examples of host environments where host variables are used in camelCase. And camelCase is a de-facto standard in modern JavaScript. So there is no reason to break the consistency and expectations

Alexsey

comment created time in a month

issue commentdenoland/deno

Rename Deno into deno

It's still available though: const deno = Deno; and you're all set.

Yes, but you should not do that. I think it's obvious why

Casing has nothing to do with modern vs legacy.

Are you sure that is not because in Java everything is a class? Because we have words of Brendan Eich The diktat from upper engineering management was that the language must "look like Java"

The EcmaScript standard typically uses UpperCamelCase for namespaces, even those that are not classes (e.g. Reflect, Symbol, Math).

That's, right. And since Deno is not an ECMAScript module and not a constructor, it should not be in UpperCamelCase but in camelCase

Alexsey

comment created time in a month

Pull request review commentjonathantneal/array-flat-polyfill

Fix polyfill and added unit tests

+import { flat } from "./flat";++export function flatMap(callback) {

Oh, I didn't think about .length. No, you are right - polyfill should be as close to the original method as possible. Especially if it's so easy to achieve

aaronbeall

comment created time in a month

Pull request review commentjonathantneal/array-flat-polyfill

Fix polyfill and added unit tests

+import { flat } from "./flat";++export function flatMap(callback) {
export function flatMap() {
aaronbeall

comment created time in a month

issue commentdenoland/deno

Rename Deno into deno

yes, sometimes namespace objects of code JS/TS are named in PascalCase. But Deno is an env variable, like window in browsers or process in NodeJS

Alexsey

comment created time in a month

issue openeddenoland/deno

Rename Deno into deno

In TypeScript/JavaScript in almost all conventions camelCase is used for variable names except of classes/constructors and only classes/constructors are named in PascalCase. So having Deno, the core object of the infrastructure in PascalCase is breaking the common convention for no reason. How about renaming it to deno before it's not too late?

created time in a month

startedmikeal/bent

started time in a month

startedAlexNisnevich/untrusted

started time in 2 months

pull request commentsequelize/sequelize

docs(hooks): fix updatesOnDuplicate -> updateOnDuplicate

It looks like the docs had not been re-generated since this PR got merged. I can do nothing about it because I'm not an admin. @sushantdhiman, can you please re-generate the docs website?

Alexsey

comment created time in 2 months

issue commenttc39/proposal-error-stacks

Add arguments of functions in the stacktrace

Thank you for the fast reply!

Alexsey

comment created time in 3 months

issue openedtc39/proposal-error-stacks

Add arguments of functions in the stacktrace

Before going into details about how it may look like, I would like to ask, if it's the right place to discuss it?

Generally speaking, the idea is to add to each function in the stacktrace it's arguments list. I don't want to discuss right now the problem of size (e.g. string may be up to 24GB according to spec) or serialization (e.g. JSON.stringify would throw for an object with recursion), or problem that at the moment of throw some arguments may already be mutated

<a url="https://bugs.chromium.org/p/v8/issues/detail?id=2169">Example of such discussing for v8</a>

created time in 3 months

more