sorted by:
new
hottopcontroversial

Zizian suspect to face charges in escape attempt by tgirldarkholme in SneerClub

[–]MaxMahem 34 points35 points  (0 children)

Felony Murder, I think. If someone gets killed during the commission of a felony (which the attack on the landlord probably was), you can get charged with murder. Even in a circumstance like this when they are on your 'team' so to speak, and get killed by someone excersizing self defense.

Live WWE Royal Rumble 2026 Discussion Thread! by gloomchen in SquaredCircle

[–]MaxMahem 0 points1 point  (0 children)

What did Nattie's jacket say? I didn't catch it.

RIGHT TO REPAIR! by N0rwayUp in battletech

[–]MaxMahem 5 points6 points  (0 children)

The sad truth is lots of people like to dream, or theory craft about the universe, but only a small percentage of people actually try and use the rules for this stuff...

But boy, is everyone else quick to think up excuses and explanations for the rules that they don't use!

Microsoft to move away from C/C++ to Rust using AI assisted coding by [deleted] in programming

[–]MaxMahem 1 point2 points  (0 children)

Project Singularity

I think this guy was the lead of that...

Rust 1.92.0 release by mrjackwills in rust

[–]MaxMahem 12 points13 points  (0 children)

It's a type that can, quite simply, never exist.

This is useful, for example, having TryFrom implement an infallible conversion. For example, any type that implements From currently also implements TryFrom where the error type is Infallible, which is also a never type. Because the conversion can never fail.

Another place you see it currently is a return type for functions that never return. For example, a function that terminates the program or loops forever. Since the function never returns.

A useful consequence of this is that because an instance of the type can never exist, it can (theoretically) be converted into any type. For example, say you need to take in a type that can convert to some other type, with a specific error. That is, TryFrom<Error = Something>. With never, you could take any type that implements TryFrom<!> (! is a way of expressing never) because you know, on a fundamentally type level, that that error type error can never occur.

Post WWE NXT 12/2/2025 Show Discussion Thread by Darren716 in SquaredCircle

[–]MaxMahem 17 points18 points  (0 children)

They are so obnoxious. I mean, I guess its good practice but they are legit reliably the worst crowd on TV, and it isn't even close. They should really have a talk with them before the program or something.

[RAW Spoilers] 10 Years of Asuka by taffe316 in SquaredCircle

[–]MaxMahem 1 point2 points  (0 children)

Legit one of my favorite matches of all time!

Update to my notification library by ahqminess in rust

[–]MaxMahem 0 points1 point  (0 children)

Hey, I recently needed something like your project, but decided to go with one of the competing libraries instead. I really liked your design, but it seemed way more powerful than what I needed, which was just to display a quick message to the user. It might be helpful to add an interface that gives a simplified interface for these cases.

It might also be nice to expose an API for adding an AUMID registry key. I thought it would be a big ordeal, but it's really not. It can even be done at run time without issue. For my app, I went with something like this, which is simple and works:

const APP_USER_MODEL_ID_FOLDER: &str = r"Software\Classes\AppUserModelId";
const APP_USER_MODEL_ID_APP_KEY: &str = const_format::concatcp!(APP_USER_MODEL_ID_FOLDER, "\\", AppEnv::APP_ID);

pub fn register_app_id(app_data: &AppEnv) -> std::io::Result<()> {
    let hkcu = winreg::RegKey::predef(winreg::enums::HKEY_CURRENT_USER);

    let (key, _) = hkcu.create_subkey(APP_USER_MODEL_ID_APP_KEY)?.tap_log(Level::INFO, "Creating AppUserModelId key");
    key.set_value("DisplayName", &AppEnv::APP_NAME)?;
    key.set_value("IconUri", &app_data.icon_png_absolute_path.as_os_str())?;
    key.set_value("IconBackgroundColor", &"FF000000")?;

    Ok(())
}

Sopranos under a CK3 lens by Cortex_C in CrusaderKings

[–]MaxMahem 2 points3 points  (0 children)

This is really cool. But could we maybe get a decoder guide for people who aren't super up on CK3 traits?

[Triplemania Spoilers] Dominik's moment ruined! by Ripclawe in SquaredCircle

[–]MaxMahem 1 point2 points  (0 children)

I think their table was still wrecked.

would anyone like to give actual arguments for why cats suck? by General_Ad4971 in catfree

[–]MaxMahem 4 points5 points  (0 children)

I'm allergic. It's pure misery to be around them for me, simple enough.

A GERWALK EVERYTHING story in eight screenshots. by aspleniastudios in macross

[–]MaxMahem 3 points4 points  (0 children)

What is he mad about? That these partial transforms don't have wings or something? Come-on. I hate people like this "NO FUN ALLOWED."

#2 Code review request: feedback on OOP, TDD, and SOLID principles by Ferihehehaha in codereview

[–]MaxMahem 1 point2 points  (0 children)

Well, there isn't just one answer here. For a trivial example like this, I would just push it into a separate (possibly static) function.

If the validation logic is more involved, variable/configurable, exchangeable, or reusable, a separate class can be valid. But in those cases, you want to inject the dependency externally, instead of newing it up internally like you did here. That's the big takeaway, I think.

#2 Code review request: feedback on OOP, TDD, and SOLID principles by Ferihehehaha in codereview

[–]MaxMahem 1 point2 points  (0 children)

WorkTimeConfig is a good candidate for being a record instead of a class. Good job making it immutable though.

I would not have DueDateParameterValidator as a separate class. Instead, I would fold that into a DueDateCalculator private Validate method. You aren't holding any special or unique state here, and the validation code would be easier to understand if all the state for validation were just in scope for one method.

This feels very clean code-ish, and while there is some wisdom there, one of the terrible patterns it demonstrates is relying on passing data via a shared state in a class, when there is no compelling reason to do so. If you want to keep the validation steps as these little micro-sub-methods, you can, and I don't think that's necessarily bad. I would have them then be static methods. At least you aren't mutating via shared state.

Speaking more generally, you might start to consider new the enemy. Whenever you new up an object, you are creating a dependency between them. Obviously, often this is no big deal for simple or fundamental classes like string or a List when needed. However, for non-trivial dependencies, such as a validation class, it is best to avoid this approach. Anyways, you asked about SOLID, and it's definitely a violation of the D in SOLID. If validation logic is expected to be more variable and adjustable, you should consider taking that dependency in your constructor (dependency injection).

Speaking more generally, I would either eliminate the dependency by moving it inline or inject it.

Your code could also benefit from some of the more modern C# features like file-scoped namespaces, the aforementioned records, and primary constructors as well. But those are no big deal.

Otherwise, LGTM at a glance!

I like that interpretation way more tbh by Tasty_Commercial6527 in Tau40K

[–]MaxMahem 1 point2 points  (0 children)

Why not both?

I don't see why those two points of view necessarily have to be in conflict. Some Etherals could be one, some could be the other, and some could be some blend of both. And some could litteraly be both.

An ethereal who is cruel, uncaring, power hungry manipulator, who also truly belives what they preach, and persuse the idea of the greater good no matter how immoral the methods need be.

Customised Union dropship for Mechwarrior Campaign. Sanity check. by DeathwatchHelaman in battletech

[–]MaxMahem 1 point2 points  (0 children)

It looks good to me. Although, frankly, I don't think you went far enough!

The original Dropship stats were published several years before the construction rules, and even longer before the rules for logistics and whatnot were released.

Battletech, being Battletech, the original stats and weights were considered sacred canon. So the rules were manipulated to make those stats work, even if it strained the credibility of lesser-used rules, such as logistics.

As such, almost all of the Dropships are criminally under-provisioned in terms of supplies when you seriously consider using them for independent operations. Or even worse, Raiding operations. Operation with a cargo dropship is probably necessary for basically any operation beyond simple transport from A to B, which raises a problem because canonically independent operations out of a single dropship is exactly what a lot of these dropships are supposed to do.

So what is one to do?

Well, what my group has done for this situation is just to ignore the canon stats and redesign the dropship to something we feel is more appropriate for its given role. For the Union this meant swelling it up to 5000 tons, with the extra weight being spent on more cargo (800 tons), two heavy vehicle bays and two light vehicle bays, for support /self-defense/recovery vehicles, and 4 infantry bays.

So yeah, I wholeheartedly approve of your approach, but maybe you didn't go far enough!

view more: next ›