Eregrith
@eregrith.bsky.social
What, you mean that people think full price games are too expensive, especially right now where quadruple-A games are really worth dogshit? Wow unbelievable ^^
March 21, 2025 at 6:25 PM
What, you mean that people think full price games are too expensive, especially right now where quadruple-A games are really worth dogshit? Wow unbelievable ^^
Jokes on you I only watch trailers
March 13, 2025 at 6:09 PM
Jokes on you I only watch trailers
Oh that's easy, you only need to buy one starter decks pair and go back to 1999 and you're all set
March 6, 2025 at 9:15 PM
Oh that's easy, you only need to buy one starter decks pair and go back to 1999 and you're all set
She did WHAT? Right there in the middle of the gym!?
March 6, 2025 at 9:14 PM
She did WHAT? Right there in the middle of the gym!?
Yes. Because the alternative would be that *Every caller* has to ask those questions, and you seemed to agree that duplicating the guards would be bad
February 21, 2025 at 6:23 PM
Yes. Because the alternative would be that *Every caller* has to ask those questions, and you seemed to agree that duplicating the guards would be bad
With that, I think i've explained myself. If you still don't want to understand what I mean then it's pointless to continue discussing the topic. Have a nice weekend :D
February 21, 2025 at 6:20 PM
With that, I think i've explained myself. If you still don't want to understand what I mean then it's pointless to continue discussing the topic. Have a nice weekend :D
Whatever the full runtime algorithm does will get done, what you should aim for is properly separated details of the concepts you're handling in every part of the code. One big god method doing all of it is more complex to follow, understand and maintain than properly split and architectured code
February 21, 2025 at 6:19 PM
Whatever the full runtime algorithm does will get done, what you should aim for is properly separated details of the concepts you're handling in every part of the code. One big god method doing all of it is more complex to follow, understand and maintain than properly split and architectured code
Because when you look at the code *calling* writeDb() you don't and should not *care* about these details. You are suggesting holding all the details in your mind while reading the code calling writeDb? Not only do you need to understand that code but ALSO the mixed-in code for the details of write?
February 21, 2025 at 6:14 PM
Because when you look at the code *calling* writeDb() you don't and should not *care* about these details. You are suggesting holding all the details in your mind while reading the code calling writeDb? Not only do you need to understand that code but ALSO the mixed-in code for the details of write?
public blabla writeDb(something)
{
Connection connection = GetActiveConnection();
try {
connection.SendWriteRequest(something);
}
catch (e)
{
HandleWriteFailure(e)
}
}
How is that complex??
{
Connection connection = GetActiveConnection();
try {
connection.SendWriteRequest(something);
}
catch (e)
{
HandleWriteFailure(e)
}
}
How is that complex??
February 21, 2025 at 6:00 PM
public blabla writeDb(something)
{
Connection connection = GetActiveConnection();
try {
connection.SendWriteRequest(something);
}
catch (e)
{
HandleWriteFailure(e)
}
}
How is that complex??
{
Connection connection = GetActiveConnection();
try {
connection.SendWriteRequest(something);
}
catch (e)
{
HandleWriteFailure(e)
}
}
How is that complex??
Do you know what integration testing is?
February 21, 2025 at 5:57 PM
Do you know what integration testing is?
The *details* on how to get that connection ready does not fall inside the responsibility of the writeDB
February 21, 2025 at 5:56 PM
The *details* on how to get that connection ready does not fall inside the responsibility of the writeDB
The method to write to the db also should be dealing with concepts, one level lower:
If this is a sql db implem then it should probaly use a connection concept, but does it need to care itself, in the writeDB code, if the connection is dead, reused, or other? No. It just needs an OK connection.
If this is a sql db implem then it should probaly use a connection concept, but does it need to care itself, in the writeDB code, if the connection is dead, reused, or other? No. It just needs an OK connection.
February 21, 2025 at 5:56 PM
The method to write to the db also should be dealing with concepts, one level lower:
If this is a sql db implem then it should probaly use a connection concept, but does it need to care itself, in the writeDB code, if the connection is dead, reused, or other? No. It just needs an OK connection.
If this is a sql db implem then it should probaly use a connection concept, but does it need to care itself, in the writeDB code, if the connection is dead, reused, or other? No. It just needs an OK connection.
Why put the burden of accounting for anything on the consumer of the writeDB method?
February 21, 2025 at 5:53 PM
Why put the burden of accounting for anything on the consumer of the writeDB method?
I think you would agree that if the db is a file or a sql server, that will not be part of the same Db implementation class, right?
February 21, 2025 at 5:53 PM
I think you would agree that if the db is a file or a sql server, that will not be part of the same Db implementation class, right?
The method will "abstractly" do *what* it's supposed to do, from the caller POV
The underlying code that implements that method is free to do it *how* it needs.
Db.Add()
Will deal with details that needs to be dealt with depending on what implem of "Db" you have at runtime
The underlying code that implements that method is free to do it *how* it needs.
Db.Add()
Will deal with details that needs to be dealt with depending on what implem of "Db" you have at runtime
February 21, 2025 at 5:52 PM
The method will "abstractly" do *what* it's supposed to do, from the caller POV
The underlying code that implements that method is free to do it *how* it needs.
Db.Add()
Will deal with details that needs to be dealt with depending on what implem of "Db" you have at runtime
The underlying code that implements that method is free to do it *how* it needs.
Db.Add()
Will deal with details that needs to be dealt with depending on what implem of "Db" you have at runtime
Can you read?
The code
That is supposed to write
*Should not care about these*
The code
That is supposed to write
*Should not care about these*
February 21, 2025 at 5:49 PM
Can you read?
The code
That is supposed to write
*Should not care about these*
The code
That is supposed to write
*Should not care about these*
The code calling "write to db" abstract concept *DOES NOT CARE* about reusing a connection.
So: why are you asking about naming a "getConnection" or "reuseDbConnection" ?
So: why are you asking about naming a "getConnection" or "reuseDbConnection" ?
February 21, 2025 at 5:49 PM
The code calling "write to db" abstract concept *DOES NOT CARE* about reusing a connection.
So: why are you asking about naming a "getConnection" or "reuseDbConnection" ?
So: why are you asking about naming a "getConnection" or "reuseDbConnection" ?
Exactly and I AM NOT SUGGESTING SUCH A METHOD. don't you understand??
February 21, 2025 at 5:47 PM
Exactly and I AM NOT SUGGESTING SUCH A METHOD. don't you understand??
Give me a code example if you want, i'd tell you what I honestly think. Outside of context it's harder for us to understand what we mean I guess.
February 21, 2025 at 5:47 PM
Give me a code example if you want, i'd tell you what I honestly think. Outside of context it's harder for us to understand what we mean I guess.
Do you understand what I mean by *using abstract concepts* ? A 400 lines method is probably not using abstract concepts, such a long method is probably riddled with details of lower levels
February 21, 2025 at 5:45 PM
Do you understand what I mean by *using abstract concepts* ? A 400 lines method is probably not using abstract concepts, such a long method is probably riddled with details of lower levels
The code that is supposed to "write to the db" should not have to care about the details:
Do we have a connection to a server or is the database a local file?
Do we have to do any pre- or post- treatment before or after writing?
A million examples can be found
Do we have a connection to a server or is the database a local file?
Do we have to do any pre- or post- treatment before or after writing?
A million examples can be found
February 21, 2025 at 5:43 PM
The code that is supposed to "write to the db" should not have to care about the details:
Do we have a connection to a server or is the database a local file?
Do we have to do any pre- or post- treatment before or after writing?
A million examples can be found
Do we have a connection to a server or is the database a local file?
Do we have to do any pre- or post- treatment before or after writing?
A million examples can be found
Db.Add / Db.Upsert or what have you.
February 21, 2025 at 5:42 PM
Db.Add / Db.Upsert or what have you.
It feels like you're proposing we should have very long methods that mix abstract concepts like "handling a connection to any db" with low level implem details like "should I reuse that specific handle instance", and then cover it all with comments to "make it better"
February 21, 2025 at 5:41 PM
It feels like you're proposing we should have very long methods that mix abstract concepts like "handling a connection to any db" with low level implem details like "should I reuse that specific handle instance", and then cover it all with comments to "make it better"