The getter part is already how it works - you can `export let foo = false;`
and then later `foo = true`; and then `export function setFoo(v) { foo = v;
}`. Why is the getter/setter syntax a significant improvement over this?
On Thu, Sep 20, 2018 at 4:21 PM, Michael J. Ryan wrote:
> // myFoo.
// myFoo.mjs
_hiddenFoo = false;
export get foo() {
return _hiddenFoo;
}
export set foo(value) {
_hiddenFoo = !!value;
}
// main.mjs
import {foo} from './myFoo.mjs';
Not sure if this has been discussed, but would be a nice feature to have in
some cases
I could seriously use the ability to remove, relative to a module, a
loaded module from the cache.
- In my test runner, I don't want to have to append a random query
just to reload all the test files in watch mode.
- I was at one point running an experiment to try to use JS tagged
templates as a t
On Thu, Sep 20, 2018 at 12:48 PM J Decker wrote:
>
>
> That could occur in a stream. (Although if it's a stream I would expect
> it to come in on a websocket rather than any sort of request) But
>
>someText{a,b,c}[1,2,3][1,2,3]
>
> [1][2]
>
> Those are valid streams of objects... How
Could you chime in with this here as an alternative?
https://github.com/tc39/proposal-using-statement
-
Isiah Meadows
cont...@isiahmeadows.com
www.isiahmeadows.com
On Thu, Sep 20, 2018 at 7:36 AM kdex wrote:
>
> So, when is a function supposed to be invoked when `defer`red in a generator?
>
On Wed, Sep 19, 2018 at 1:46 PM Mike Samuel wrote:
>
>
> On Wed, Sep 19, 2018, 4:41 PM Mike Samuel wrote:
>
>>
>>
>> On Wed, Sep 19, 2018, 4:07 PM J Decker wrote:
>>
>>> (trimmed)
>>>
>>> On Wed, Sep 19, 2018 at 12:08 PM Mike Samuel
>>> wrote:
>>>
On Wed, Sep 19, 2018 at 12:01 P
So, when is a function supposed to be invoked when `defer`red in a generator?
On Thursday, September 20, 2018 11:21:06 AM CEST Ayush Gupta wrote:
> Hi,
>
> I would like to propose a `defer` keyword(or something else as the keyword
> name) which would allow us to "defer" a function which will b
What stops you from doing this with try...finally?
function doSomeDbWork() {
try { return databasepool.getConnection(); } finally {
connection.release(); }
}
On Thu, Sep 20, 2018 at 1:01 PM, Ayush Gupta wrote:
> Apologies, I meant to use `async-await` in the example but I missed it.
>
> Al
Apologies, I meant to use `async-await` in the example but I missed it.
Also, cleanup can be needed in all code, no matter if it's synchronous,
uses promises, callbacks, or `async-await`. I personally believe that
while we can have different mechanisms for doing cleanup in all different
cases, h
If you don't need to do anything in the catch block, you can make it a
no-op and put your cleanup statement afterward.
However framing this in terms of a synchronous use case seems odd given
that synchronous database operations (your example) are extremely rare and
in JavaScript. It seems to me li
It can be covered, but then I'll have to duplicate the
`connection.release()` call in both the try and catch blocks, (and
remember, there can be multiple resources to be cleaned up).
Plus, in case that I have a function with multiple if-else branches with
returns from multiple branches, I will hav
Hey Ayush,
That's an interesting language feature I hadn't heard of before.
Any reason your use case couldn't be covered by a try/catch in the
synchronous case, and a promise.finally() in the async case?
Ben
Le jeu. 20 sept. 2018 05 h 21, Ayush Gupta a écrit :
> Hi,
>
> I would like to propos
Hi,
I would like to propose a `defer` keyword(or something else as the keyword
name) which would allow us to "defer" a function which will be executed
once the current function either returns or throws.
The idea for this is taken from the Go programming language.
It would allow us to perform
13 matches
Mail list logo
