race condition transfer

[toxic kettle]

Did a quick implementation for the proposed idea, it doesn't work at all. Somehow there's still two threads in the end. Assuming i mostly managed to implement it correctly.

[upper moss]

<@&987246924425994290> please have a look, thanks.

[upper moss]

While you are waiting for getting help, here are some tips to improve your experience:

Code is much easier to read if posted with syntax highlighting and proper formatting.

If nobody is calling back, that usually means that your question was not well asked and hence nobody feels confident enough answering. Try to use your time to elaborate, provide details, context, more code, examples and maybe some screenshots. With enough info, someone knows the answer for sure.

Don't forget to close your thread using the command </help-thread close:1027500463647621170> when your question has been answered, thanks.

[toxic kettle]

private boolean isAlreadyHandled(String messageId, TextChannel channel) {
        AtomicBoolean messageDeleted = new AtomicBoolean(false);

        channel.retrieveMessageById(messageId).queue(ignore -> {}, 
onFailure -> {
            if (onFailure instanceof ErrorResponseException responseException
                    && responseException.getErrorResponse() == ErrorResponse.UNKNOWN_MESSAGE) {
                messageDeleted.set(true);
            }

        });

        return messageDeleted.get();
    }```

@pastel iris thoughts? UNKNOWN_MESSAGE is for deleted messages btw. This is checked right at the start of onModalSubmit method.

[silent phoenix]

it seems you're assuming AtomicBoolean will block on get, waiting for queue to process the request before returning the result of messageDeleted

there's no guarentee that queue will finish processing, or even begin to process, before return messageDeleted.get() occurs

[toxic kettle]

oh

that makes sense

[silent geode]

what you are trying to do

is basically .complete

which you shouldn't do at the first place

[toxic kettle]

what are the alternatives then?

[silent geode]

return a rest action

and continue using callbacks

[silent geode]

also, starts from the principle that whenever you try to abuse a mutable object to get data to outside of the lambda, you are doing something wrong
there is a reason why a lambda cannot modify outside local variables nor can access mutable outside local variables

[toxic kettle]

ye lol i tried to be sneaky👀

[silent phoenix]

keep in mind, the java architects are very smart. they get paid tons of money for the experience they have. instead of fighting the language, you should try to understand why they did what they did

and what problems could occur by trying to out-smart their system

once you have that level of understanding, THEN you can do hackish implementations without worrying about backfires

[toxic kettle]

Yea i remember zabu also mentioned something about flighting the design a couple of times is always bad, i didn't actually know i was doing that until alath mentioned it.

is this what they mean by "lambdas should be pure" ?

[silent phoenix]

depends on who "they" are, and what they mean by "pure"

[toxic kettle]

do you have a quick example for me? by callback you mean do the retrieve and pass a failure callback just like i did here ?

[toxic kettle]

i vaguely remember this phrase from one of the venkat's talks

[silent phoenix]

lambdas are a functional paradigm, and functional constructs typically imply "stateless"

java is multi-paradigm, so there's some lee-way on "stateless" when it comes to lambdas

for example, Stream, which primarily uses lambdas for operations

intermediate operations are expected to be stateless, as per the specification. but terminal operations, such as forEach (which uses a lambda) can be stateful

so if "pure" means "stateless", saying "all lambdas should be pure" in Java would go against the philosophy of Java, based on the spec

[silent geode]

well no, it depends of the operation

[silent phoenix]

the only intermediate operation that is expected to be stateful would be peek, and thats only used for debugging

[silent geode]

among terminal operations, findFirst is stateless, forEach is statefull
among intermediate operations, map is stateless, sorted is statefull

ah

I see

you are talking about user side statefullness

[silent phoenix]

yeah, sorted isnt stateful, it returns a new object

[silent phoenix]

yup

side-effects

[silent geode]

then outside forEach/peek, then nothing has side effect

they are the only two operations should are supposed to have side effects

in peek case, it's only for debugging
in forEach case, yes you can use it, but most of the time, there is a better option

[silent geode]

just return the result of queue

[silent phoenix]

yeah, even for terminal operations, its only when specified

[silent geode]

so no, forEach is more an exception that anything else

[silent phoenix]

This means that side-effects of behavioral parameters may not always be executed and should not be relied upon, unless otherwise specified (such as by the terminal operations forEach and forEachOrdered).

[silent geode]

unless i am missing something

there is only foreach

[silent phoenix]

for the time being

[silent geode]

pretty sure they won't add any other

[silent phoenix]

theres a JEP for expanding upon streams

[silent geode]

since side effects are dangerous

[silent phoenix]

cant really say "this wont be impacted in the future; itll always be this that one method"

[silent geode]

yes, collectors but as intermediate, there is no side effect here

[silent geode]

it won't, foreach is a very special case

[silent phoenix]

i dont believe thats true, but only time will tell

no reason to argue it, since we can only assume the future

[toxic kettle]

i think i repeat this one often, always forget how async works until it clicks. I think i got it right tho. Thank you lovely folks for your time.