You might want to check out the proposal's repo and make the suggestion
there (it's been considered already IIRC, and I believe it was already
noted in the repo as a possible future extension):
https://github.com/tc39/proposal-pattern-matching
On Mon, Oct 22, 2018 at 15:38 Matthew Robb wrote:
>
Perhaps the following form could eventually make sense for pattern matching
in function declarations:
```js
function sum_list(input, result = 0) case (input) {
when [head, ...tail] -> {
return sum_list(input, result + head);
},
when _ -> { return result; }
}
```
- Matthew
The use is with integers 2^53 and above in general: most non-JS JSON
clients (like Java and C++) can correctly interpret 64-bit integers
and some can even represent arbitrary-size integers (like Python), but
JS can't. This can come up sometimes in math/science contexts, where
numbers can often get
As mentioned previously, the pattern matching proposal does a lot to help here:
```js
function sum_list(input, result = 0) {
case (input) {
when [head, ...tail] -> return sum_list(input, result + head),
when _ -> return result,
};
}
```
-
Isiah Meadows
hi Oliver, a practical solution to your nested-validation-problem is to use a
recursive tree-walker that keeps track of depth. here's a real-world example
that limits the depth (to 3) for auto-generating swagger-data from
nested-schemas using technique [1].
```javascript
Ahh yes, the updating aspect is tricky (call it an early-morning oversight),
and not one that I think could have a practical solution if spreading out the
calculation over the life of the object is not viable. Maybe my Array
comparison was being a bit too optimistic about this usefulness of
On Mon, Oct 22, 2018 at 2:42 AM Rob Ede wrote:
> Calculating this on plain objects could be a O(1) operation:
>
> Empty objects are initialized with maxDepth 0 and are set to 1 when a
> primitive property is added.
> If an object property is added the maxDepth is set to 1 +
>
Calculating this on plain objects could be a O(1) operation:
Empty objects are initialized with maxDepth 0 and are set to 1 when a primitive
property is added.
If an object property is added the maxDepth is set to 1 +
maxDepth(newObjectProperty)`instead of it being calculated Ïevery time
i'm against all these proposals. JSON.parse should remain zero-config and
idiot-proof. you will *always* need a second-pass in product-development to
revive non-JSON datatypes anyways, like Date, and thats where reviving BigInt
should take place as well.
again, i'm ok with working on
Hi Kai Zhu,
I agree with you the new proposition should be of value to a web developer
in daily work. If we observe the pattern it more closely resembles a more
declarative form of solution implementation which is easy to code and
understand. For example lets consider below piece of code:
```js
10 matches
Mail list logo
