ProgrammerHumor
thatsNotEvenAWord
Discussion
Hmm. How about .vow() to return a Promise? Or maybe .bloodOath() with stronger type constraints…
.byTheHonorOfHouseMogh() : KlingonPromise
byTheHammerOfThor()
.onTheRiverStyx()
.byGrabtharsHammer()
.oathOfTheAncients()
Edit: for type specificity and scalability, this method is deprecated. Please use .oath(Paladin.OATHS.Ancients) as an example
Help. There are vines all over my pc.
Have you tried defoliating the hard drive?
I do really like .bloodOath() => Promise
.solemnlySwear()
There is no rejected thunk...instead...death() 😆
.vow() returning a Promise is just chef's kiss.
Borrowing it, thanks!
PromiseFactory.builder().strategy(PromiseStrtegyEnum.LET_U_DOWN).build().getPromise();
Wrong. You used a concrete PromiseFactory when you should have passed the "PromiseFactory" key to an abstract factory builder.
Software engineering is not about writing code that does something useful. It's about writing code that describes what the act of programming would look like, broadly, if one were to consider doing it.
Why does this sound like a Douglas Adams bit?
In the beginning programming was created. This has made a lot of people very angry and been widely regarded as a bad move.
How much concrete does your concrete factory produce?
Our cement is 100% abstract. It's on the customers to put in their own fine and coarse aggregates, water, binding, and admixtures. We just provide them the framework and interface.
160/minute on two refineries, dedicated to the production of molded steel pipe. Yours?
And why would anyone create an instance using new or a singleton instead of calling the DI container to get the correctly configured object?
Of course you can't get the container with a global function or static method, you should inject the container instance into the class you are using.
Touching of the container is no longer allowed. Only constructor injection should be used, with no code ever having knowledge that there is a thing called a container. We'll need to provide the correct abstract factory builder by constructing a composite builder that follows the composite design pattern. We will then register this in our composition root, so that the correct abstract factory is injected into the right factory, which in turn injects the correct instance.
But we won't register it directly. We will hide it in middleware so that no engineer will ever know where the factory came from which produced any object they will ever work with. The greatest benefit of abstraction is not knowing what is going on.
That's the point where you create a testing mock and use it in production code, right?
No. Mocking of any kind is prohibited, now. Now you must write integration tests that start containers that contain a microcosm of your organization's infrastructure.
Sadly true. Why write a unit test when you can write an integration test that takes anywhere from 10 to 100 times longer?
One previous org, our test suite was 90 minutes running on a CI build, and that’s after I spent days tweaking maven and jenkins to get it down from 3+ hours. I tried to push for more unit tests, but it’s hard when your fellow devs are afraid of mocking. It really is a whole other code skill set, though.
Sadly true.
Being sad is prohibited because it does not add shareholder value.
I tried to push for more unit tests, but it’s hard when your fellow devs are afraid of mocking.
Martin Fowler said that we should not mock every dependency, which we all know is his way of saying that absolutely nothing should be mocked, ever.
Didn’t we all get into programming to spend years of our lives trying to put the right syntax into xml files so our running code receives the right version?
It's 2025. We've moved onto the next even higher level of abstraction. Now it's about the act of describing how we'd feel if we were to describe the act of describing the act of what programming would look like if someone else were to consider doing it for us. Factories no longer create objects they summon them. Dependency injection is more like divination. Testing our code is disrespecting the process. We need to trust the code instead and not worry whether it can invoke some service but whether or not it can invoke the right vibes.
getPromise<UP>();
That method always throws a NotSupportedException. It will never give you Up.
That promise better fail, as should .GIVE_U_UP, .RUN_AROUND, and .HURT_U.
Sadly, according to the spec, those situations never gonna happen, so the case statement falls through and you get a ThisShouldNeverHappenException.
we already have \@Async though
Skill issue, real programmers don't make any promises, that way it's not our fault when the project is 420% over the deadline.
The only time I use promises is when a framework won't let me use an async function so I just end up nesting like 10 .thens in a row.
.youPromise?👉🏻👈🏻🥺🫣()
you're hired
.promiseInator3000()
No, that's a noun. That can be the name of the class that has .promiseify though, which takes something out other and converts it to a promise.
Dr. Doofenshmirtz's source code aah
Well, promisify doesn't make any Promise objects by itself, it converts callback-style function into modern one that returns Promise. It's the least misleading option.
If OP wanted a reasonable name in the vein that they provided, it'd be .convertReturnValueToPromise() and .makeReturnPromise(). Given those options, I think it's clear why they went with .promisify().
Exactly. The node:util promisify function converts a function with a standard final callback argument to - not a promise - an async function, or promisor.
asPromisor(fn) or asAsync(fn) would've been a better name for it. But whatevs. Documentation exists to need read.
[deleted]
[deleted]
Ah okay. My comment is fully redundant then. Have a great day!
.swear()
pinky.swear();
Do you also get the curse words when the promise is rejected?
There's a number of new methods for handling promises:
damnToHell()which immediately sets the computer running it on fire and is considered equivalent tofinally().fuckMyShitUp()which returns a random memory chunk cast to the expected object and is called on rejection.yourFatherSmellsOfElderberries()which abandons the promise as soon as it is resolved.snail()which attaches a process to the returned value that if it ever runs causes the death of the programmer.
And we can't forget H̶͇͈̞͔̺̗͙̰̻̽̈̓́̆͆͋͋̍͗͋̀̓͆͝e̸̦͆̃̄̄̔̍͂C̵̢̝͕͖͙̦̤͎̊̅͊̂̈̌̈́͒̂̇̅̄͝͝ǫ̵̠͍͓̤͓̦͕͇̪͂̋́̑̊͋̊̀̂͛͋͠m̷̨̡̞͕͎͉̯̦͓̞̙̱̥̞̺̤͗͂͆̀̄͂̾̏͌̈̀͘͠ȩ̵͕̳̪̳̹̖̠̩̫̦͉͇̌̚͠ͅş̵͚̟̦̬̠̥̤̤̩̠̯̇ͅ
abstractPromisseFactoryBuilder.Build().Create(abstractPromisseOptionsFactoryBuilder Build().Create())
*(promise*)
If we understand the meaning is it not now a word?
Yup. Language evolves
Didn't Webster recently add empromisification?
I love the evolviosity of language
Exactly how I read the title in my head
promisize()
Should be toPromise() or asPromise()
It would, except that this function (from util) takes in a non-promise async function and converts it so it returns a promise instead, so those options are misleading, since they imply it takes a value and uses it as a promise.
const fs = require('fs');
const util = require('util');
const readFile = util.promisify(fs.readFile);
const fileContents = await readFile("...");
Thanks I didn’t know that’s what it’s for. In that case I think it should be asAsync()
Better for sure, but the original function has to already be an asynchronous function (using a callback instead of a promise), so I can see why the Node.js people didn't go with it.
return new Promise(resolve);
I’ll nounify any noun I damn well please!
.promiseMe()
java dev forced to do frontend spotted
.prophesize()
If I can't make up words while programming then what has this all even been about.
It's a verb. .promise()
That won't confuse anyone ever. Since it's also a noun, make it a getter too, and make the result callable, such that .promise(andThen, orElse) and .promise.then(andThen, orElse) are equivalent.
That's not a bunch of excess code for the sake of magic, no siree.
Unless you're talking about util.promisify(fn) which just has an objectively incorrect name. It does not turn the passed function into a promise at all; it turns it into an async function. It should be util.asAsync(fn).
promisize_t
Someone at work wrote a function SSEfy which wraps a string with data: and \n\n 😐
🤔
promisize_me_captain()?
Noun v Verb: Dawn of Gibberish.
Release the Gerund Cut!
But it can be a startup
makePromisifier
"promise" already is a verb that means "make a promise"
firstValueFrom to all my rxjs homies.
One better,
.notDeceit()
Nah, thats a perfectly cromulent word
Wait am I a bad programmer I'd totally call it ".Promise()" because I feel it implies already that it converts it to a promise.
.makePromise() is the dumbest since promise is already a verb.
.asPromise()
im low key using that
Let’s halt for a second, why do we call it a promise, like it’s getting broken anyways
Shortest is best
Haven't you heard? Language is a living organism. It evolves.
(Never mind that the last two sentences directly contradict each other. A single organism *can not* evolve. But that's what they say!)
Promisize? Promisate?
I can probably come up with worse, if need be
all hail the og: jsonify()
Hey. It's my code. It's a word if I say it is!
this is about the util module from node.js btw (i couldn't fit the full method call without making the text too small)
.yolo .bet
promize()
Oh man, I need to add that in my current work! prePromisifing() and postPromisifing()
Given that I assume you wrap an existing value into a pre-computated promise that is already value-ready
Why not Promise.resolve(foo)
I would even say this function could flatten a promise
Promise.resolve(Promise.resolve(foo)) == Promise.resolve(foo)
I accidentally called .makePromiscuous() and it didn't end well.
.promisificamus()
ctp()
toPromise() ?
toShreds()?.toShredsYouSay()?
wife.holding_up()false
for(int i = 0; i < 4; i++) {
}
four tuts? Damn.
Forgot the space so it's just tuttuttuttut lol
wait no it's python
tut
tut
tut
tut
Wait it's not python
tuttuttuttut
But true
state.toShreds-> impl Shreddable
.hardlyEvenKnowHer()
Resolve(“I_Say”)
.shredify()
That’s the correct answer.
If it is a static method that takes an input and returns a promise, then toPromise()
If it’s an instance method that takes no arguments and translates the object into a promise, then asPromise()
If it’s an instance method that takes no arguments and returns the value of a property, then getPromise()
If it’s an instance method that takes an object and sends a promise to that object, then promise()
If for some reason you’ve created a promise factory, then makePromise() or createPromise()
If for some reason you’ve created a promise builder, then buildPromise()
If you’re creating a utility method designed to handle a wide variety of input types and turn that input into a promise, then promisify()
If you’re a self documenting clean coder who posts this meme on Reddit, then convertToPromise()
This guy promises.
Unfortunately I don’t always resolve them :/
This guy docs so good it’s on Reddit
this guy OOPs so hard
Will remember. I promise.
This
Also
.promise()Although
.promisify()is the best of the three in the picOr intoPromise(), if the initial object is consumed as a result of the conversion.
Found the rust user
That's right! I am the rust user. And it takes one to know one, fellow rust guy.
You do be looking abit rusty over there
Stringify, integerify, floatify, JSONify
Hey! I came to say that!
... fuck, I forgot to await makeComment(); >:-(
You need to
await makeComment().toPromise();100% this, I opened the comments to say this lol
What you are missing is that promisify isn’t used to turn an object into a promise, but to turn a function using the callback style for async work into a function that returns a promise.
Callback style being: the last argument of the function is a callback called with two arguments, an error and the data.
So you’d do: const readFileAsync = promisify(fs.readFile)
iPromise("trust me", "bro")
Just add a then method on it
.orNotToPromise()?