Re: Symbol.await proposal
> Hi,
>
> That doesn't work, kinda work in javascript world where the function has
> finite, fixed set of arguments, were there is a definition of last one.
> Typescript helps a lot with that, because
> it can ensure to a higher degree, that types are correct, js on its own,
> loose so you have less guarantees of the binding.
> Just have to assume that every function has like a callback by convention,
> if it doesn't then break things again.
> Typescript does help.
>
> function anyArguments(callback) {
> let args = [...arguments];
> // args.length > 99 and callback is the 1st parameters.
> }
>
> You can check out this is want project setup, that allow us to peace meal
> upgrade to ts.
> https://github.com/wesleyolis/configFactoryLoaderAndValidator
> Few additional pointers:
> type AnyJS = any; / this allow you keep track of intentional usage, so
> search codebase later.
> If you have old library with no types, then basically import the new
> library with types under a different alias name,
> then have both old and new versions and peace meal upgrade as required.
>
> Kind Regards,
>
> Wesley Oliver
>
>
>
> On Mon, Jun 22, 2020 at 10:13 PM Jamie wrote:
>
>> One of the common refactorings I do is:
>>
>> let file1 = await readFile(filename1)
>> let file2 = await readFile(filename2)
>> // to
>> let [file1, file2] = await Promise.all([
>> readFile(filename1),
>> readFile(filename2),
>> ])
>>
>> I would be very confused if refactoring it in this way made my code break
>> because of some implicit behavior around `await` specifically.
>>
>> I have seen some APIs that switch to promises when a callback argument is
>> not provided. Is this not a sufficient solution?
>>
>> On Mon, Jun 22, 2020 at 12:22 PM James M Snell wrote:
>>
>>> For many legacy code bases that are based on callbacks mechanisms like
>>> node.js' promisify function are required to help facilitate the transition
>>> from callback centric code to Promise-centric. A lot of the time, these can
>>> follow straightforward rules without requiring customization. However, at
>>> other times it is necessary for user code to provide custom implementations
>>> of the Promise-version of the function.
>>>
>>> In Node.js, we accomplish this by allowing a function to have a symbol
>>> attached whose value is an alternative function that is returned by the
>>> promisify function
>>>
>>> For instance,
>>>
>>> function myFunction(foo, bar, callback) {
>>> callback(null, foo, bar);
>>> }
>>> myFunction[util.customPromisifySymbol] = async function(foo, bar) {
>>> return [foo, bar];
>>> }
>>>
>>> const { promisify } = require('util');
>>> const mine = promisify(myFunction);
>>> (async () => console.log(await mine('a','b')))();
>>>
>>> As a convenience built into the language, it would be nice to be able to
>>> short-circuit the need to call promisify with a special language-level
>>> Symbol used specifically for this purpose:
>>>
>>> function myFunction(foo, bar, callback) {
>>> callback(null, foo, bar);
>>> }
>>> myFunction[Symbol.await] = async function(foo, bar) {
>>> return [foo, bar];
>>> }
>>>
>>> (async () => console.log(await myFunction('a','b')))();
>>>
>>> The idea here is that if the function being awaited has the
>>> [Symbol.await] property whose value is a function, then that function is
>>> called when the await keyword is used. That is,
>>>
>>> myFunction('a', 'b', callback); // Invokes myFunction directly
>>> await myFunction('a', 'b'); // Invokes myFunction[Symbol.await]
>>>
>>> if the Symbol.await property is not set or is not callable, then it
>>> would fallback to default behavior.
>>>
>>> Automatic handling of this binding should also happen but has some
>>> technical detail to work out:
>>>
>>> const obj = {
>>> a: 1,
>>> foo() {}
>>> };
>>> obj.foo[Symbol.await] = async function() {
>>> return this.a;
>>> }
>>> await obj.foo(); // Calls await obj.foo[Symbol.await] with bound this
>>>
>>> This approach would make it far easier for legacy code bases to make the
>>> transition to async/await syntax while maintaining legacy compat.
>>>
>>> Before writing up a formal proposal, I wanted to solicit some fe
Re: Symbol.await proposal
Hi,
The one interesting case you have to look at dealing with, is the one I
came across where by the call of a function can return a results and will
then later async call the callback in the future.
Because with the proposal above, you have lost the ability to, return the
return result and callback results you have return {execReturn:...,
awaitResult:}, this doesn't happen offen.
I think one approach that you could take but wouldn't always work, check
for additional the call back parameter, then either return Promisification
or you do the call back execution.
a wrapper would help with that.
The other could also look at a special import syntax for modules, whereby
methods are automatically promisified, with this wrap approach or shallow
copy.
The problem is that for a function that can accept in javascript any number
of parameters, arguments, were is no finite number of arguments, you can't
be certain that there is a callback or if the last parameter
is indeed a param. One could do type check on the last parameter, otherwise
you have a naming convention for functions, to avoid the confusion,
provided you could check the key(name)
Promise all suffers the same problem with the last parameter, it is a
convention.
Kind Regards,
Wesley Oliver
On Mon, Jun 22, 2020 at 9:21 PM James M Snell wrote:
> For many legacy code bases that are based on callbacks mechanisms like
> node.js' promisify function are required to help facilitate the transition
> from callback centric code to Promise-centric. A lot of the time, these can
> follow straightforward rules without requiring customization. However, at
> other times it is necessary for user code to provide custom implementations
> of the Promise-version of the function.
>
> In Node.js, we accomplish this by allowing a function to have a symbol
> attached whose value is an alternative function that is returned by the
> promisify function
>
> For instance,
>
> function myFunction(foo, bar, callback) {
> callback(null, foo, bar);
> }
> myFunction[util.customPromisifySymbol] = async function(foo, bar) {
> return [foo, bar];
> }
>
> const { promisify } = require('util');
> const mine = promisify(myFunction);
> (async () => console.log(await mine('a','b')))();
>
> As a convenience built into the language, it would be nice to be able to
> short-circuit the need to call promisify with a special language-level
> Symbol used specifically for this purpose:
>
> function myFunction(foo, bar, callback) {
> callback(null, foo, bar);
> }
> myFunction[Symbol.await] = async function(foo, bar) {
> return [foo, bar];
> }
>
> (async () => console.log(await myFunction('a','b')))();
>
> The idea here is that if the function being awaited has the [Symbol.await]
> property whose value is a function, then that function is called when the
> await keyword is used. That is,
>
> myFunction('a', 'b', callback); // Invokes myFunction directly
> await myFunction('a', 'b'); // Invokes myFunction[Symbol.await]
>
> if the Symbol.await property is not set or is not callable, then it would
> fallback to default behavior.
>
> Automatic handling of this binding should also happen but has some
> technical detail to work out:
>
> const obj = {
> a: 1,
> foo() {}
> };
> obj.foo[Symbol.await] = async function() {
> return this.a;
> }
> await obj.foo(); // Calls await obj.foo[Symbol.await] with bound this
>
> This approach would make it far easier for legacy code bases to make the
> transition to async/await syntax while maintaining legacy compat.
>
> Before writing up a formal proposal, I wanted to solicit some feedback on
> this approach to see what folks thought.
>
> - James
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
--
GitHub:https://github.com/wesleyolis
LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
Blog/Website:https://sites.google.com/site/wiprogamming/Home
Skype: wezley_oliver
MSN messenger: wesley.o...@gmail.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Symbol.await proposal
>
>
> Hi James,
>
> I did alot of upgrading of javascript codebase to typescript code base
> about 2 years ago for a year, where the goal was to get everything promised
> and then basically
> were possible ideally move to the await method. This required for us to
> come up with peace meal approach were our codebase would have all forms and
> for legacy integration of new code would have also gone back from a promise
> to the callback.
> I know we had a lot of fun and games with all different promise versions
> and interface incompatibilities. At times was good enough to just
> Promise.resolve(..promise) because that solve is matched in promise
> BlueBird and ts promise implementations and things.
>
> What I can say is if you implement a wrapper function, whereby if the call
> back is empty you return a promise and the type system typically would help
> you out here.
>
>
> https://github.com/wesleyolis/mongooseRelationalTypes/blob/master/src/mongoose.ts
>
>
>
> exec TModelParts, Populate, DeepPopulate, ArrayOfResults, Primative, Lean>) =>
> void) | undefined> (callback: TCallBack): undefined extends TCallBack ?
> Promise ArrayOfResults, Primative, Lean>> : void; I also had to write my own
> promise implementation, because we had some non-conformant callbacks, which
> in which I had to get some results out on execution and not on the async
> callback result. In this promise implementation I also typically, did some
> optimizations, which depended on how many parameters one would pass in and
> also the ordering of the terms because I wanted to make it more object
> orientation, approach. The one thing which is not in here, which I wanted
> is for the ability but I had push back is for if there where not additional
> parameters to execute immediately, which is kinda not the best, because of
> bit iffi. The other would have been that execute automatically, by you
> passing in the additional parameters as auxiliary parameters after the
> first two or one. const results = await Promisify(method)(param1, param2,
> param3, param3); I get the fact that by calling promisify on a function
> and that it then stores it in the parent scope (this) symbol, would save
> overhead when having to do it alot. As the resulting function is
> transformation is cached, however, one needs to remember that function name
> is key in the prototype or instance method. So basically the key would be
> the function name, then below that you would have two have another two
> keys, one for the async symbol and one for the normal function. So either
> the function name in my mind needs be suffix or prefix with symbol
> convention or need to figure out how introduce some other mechanism. Is
> possible mabye to overload await implementation, such that it can check for
> the existence of Symbol, if it exists then it knows to call async version.
> if it doesn't then it be call existing one. As of current the await, will
> return the promise results or just the result of a function call. So you
> could just replace that function entirely at the instance level too. Also
> look at using promiseALL and doing shallow copies and then doing
> promisifyALL on the shallow copy.
> function promisify (test) {
>
> return async function() {
> console.log('test');
> return test
> }
> }
>
> myFunction = promisify(myFunction);
>
> (async () => console.log(await myFunction('a','b')))();
>
> https://github.com/wesleyolis/BlueBirdObjectOrientatedPromisification/blob/master/src/BlueBirdPromisification.ts
> With
> only a callback will execute the promise and return the result
>
> const result = await Promisify(method)
>
>
> With
> mutiple parameters will return a promisified method
>
> const promise = Promisify(method);const results = await promise(param1,
> param2, param3, param3);
>
>
> Object
> and Method, instead of using bluebird context
>
> Will ensure that the method key exists on the object.
>
> With
> only a callback will execute the promise and return the result
>
> const result = await Promisify(object, 'method');
>
>
> With
> mutiple parameters will return a promisified method
>
> const promise = Promisify(object, 'method');const results = await
> promise(param1, param2, param3, param3);
>
>
> Promises
> Return type can also be overloaded
>
> Requires spesifying both Promise Return type and
Re: Consistency in common operators across various types.
Hi,
I have decided to put to gather a document, logically thinking about a
scripting language holistically on how to achieve
type free scripting language that is consistent and predictable regardless
of the data option which is operating.
In other words, a script problem is type invariant and input and outputs
will never differ base on any implicit, inferable, or backing types.
*Rules and constraint for writing a good scripting language or script for
that matter, such that it has consistent predictable and usable behaviour*
https://docs.google.com/document/d/1065G_MqNMFL_fBhSHSfH3ju0FUKC5iRpbj1iVwgAh3o/edit?usp=sharing
Kind Regards,
Wesley Oliver
On Fri, Apr 10, 2020 at 3:33 PM Wesley Oliver wrote:
> Hi,
>
> Just like to maybe challenge javascript here or any script language in
> that mater.
>
> The definition of comparing two variables with an operator such as
> <.<=,>,>= of the operators above definition changes depending on the left
> and right backing types.
>
> If both are strings then it does string comparison if both numbers then
> its numbers.
> Seem great but there are small gotchas.
>
> So if someone writes an algorithm and some gives them some badly formatted
> data, where some values are strings and some are numbers or what eva,
> because we are operating in type free space.
> Then sometimes the correct behaviour will be happening depending on what
> the intention is.
> string comparison or number comparison.
> Some of the loops evaluate the data going to be doing all sort wonderfully
> things, flipping between definitions. kinda works for sort single
> numerical string sort method but not for logical algorithm comparisons,
> because they may and much work from time to time depending on the input
> data.
>
> Reason for a scripting language is be free of types and not care about
> different types, that things just work, but clearly there some additional
> corner cases, we need to improve on.
>
> The problem here is that based on the types the operator behaviour is
> inconsistent.
> To write script programs the behaviour for different operators needs to
> remain the same
> regardless of types. Else can't have data streams that data types don't
> matter and when algorithms basically break, then what was the point of
> using a type language.
>
> So in future for script languages, implement functions if there is
> conflict in that operator definition is not consistent across all types.
> This would allow use to write algorithms,
> were don't care about the types, else must ensure that * 1 before
> comparison or that
> format all the data on input, which requires projection and doubles memory
> usage, which then sucks, incremental versus balk conversion.
>
> For scripting language, the operator definition should remain the same,
> regardless of the left hand or right-hand side types thought out the
> language.
>
> A scripting language should choose base type in which these operators will
> be evaluated and everything will be coerced into that base operator type
> first.
>
> You could implement scope blocks, were one could choose operator base type
> so simplify code writing and understanding.
>
> [<,<=,+.,>]:string {
>
> }
>
> [comp-ops]:number {
>
> }
> Consistency and behaviour consistent across types is key to scripting
> language becoming more powerful. Rather use the function in future if there
> is no consistency across backing types for the operator.
>
> Kind Regards,
>
> Wesley Oliver
>
> --
>
> GitHub:https://github.com/wesleyolis
> LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
> Blog/Website:https://sites.google.com/site/wiprogamming/Home
> Skype: wezley_oliver
> MSN messenger: wesley.o...@gmail.com
>
>
> --
>
> GitHub:https://github.com/wesleyolis
> LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
> Blog/Website:https://sites.google.com/site/wiprogamming/Home
> Skype: wezley_oliver
> MSN messenger: wesley.o...@gmail.com
>
--
GitHub:https://github.com/wesleyolis
LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
Blog/Website:https://sites.google.com/site/wiprogamming/Home
Skype: wezley_oliver
MSN messenger: wesley.o...@gmail.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Consistency in common operators across various types.
Hi,
Just like to maybe challenge javascript here or any script language in that
mater.
The definition of comparing two variables with an operator such as
<.<=,>,>= of the operators above definition changes depending on the left
and right backing types.
If both are strings then it does string comparison if both numbers then its
numbers.
Seem great but there are small gotchas.
So if someone writes an algorithm and some gives them some badly formatted
data, where some values are strings and some are numbers or what eva,
because we are operating in type free space.
Then sometimes the correct behaviour will be happening depending on what
the intention is.
string comparison or number comparison.
Some of the loops evaluate the data going to be doing all sort wonderfully
things, flipping between definitions. kinda works for sort single
numerical string sort method but not for logical algorithm comparisons,
because they may and much work from time to time depending on the input
data.
Reason for a scripting language is be free of types and not care about
different types, that things just work, but clearly there some additional
corner cases, we need to improve on.
The problem here is that based on the types the operator behaviour is
inconsistent.
To write script programs the behaviour for different operators needs to
remain the same
regardless of types. Else can't have data streams that data types don't
matter and when algorithms basically break, then what was the point of
using a type language.
So in future for script languages, implement functions if there is conflict
in that operator definition is not consistent across all types. This would
allow use to write algorithms,
were don't care about the types, else must ensure that * 1 before
comparison or that
format all the data on input, which requires projection and doubles memory
usage, which then sucks, incremental versus balk conversion.
For scripting language, the operator definition should remain the same,
regardless of the left hand or right-hand side types thought out the
language.
A scripting language should choose base type in which these operators will
be evaluated and everything will be coerced into that base operator type
first.
You could implement scope blocks, were one could choose operator base type
so simplify code writing and understanding.
[<,<=,+.,>]:string {
}
[comp-ops]:number {
}
Consistency and behaviour consistent across types is key to scripting
language becoming more powerful. Rather use the function in future if there
is no consistency across backing types for the operator.
Kind Regards,
Wesley Oliver
--
GitHub:https://github.com/wesleyolis
LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
Blog/Website:https://sites.google.com/site/wiprogamming/Home
Skype: wezley_oliver
MSN messenger: wesley.o...@gmail.com
--
GitHub:https://github.com/wesleyolis
LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
Blog/Website:https://sites.google.com/site/wiprogamming/Home
Skype: wezley_oliver
MSN messenger: wesley.o...@gmail.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
