You can still do that.
For example, you'd still write classes for your tables:
public class Users
{
public int Id { get; set; }
}
and then you'd just do
var query = $"select * from {(nameof(Users))} where {(nameof(Users.Id))} = 10;";
That let's you write raw sql about as close as it gets, while still having some degree of type-safety. You could drop a query like that into Dapper, and you're pretty close to just using raw sql.
I saw this video yesterday: https://www.youtube.com/watch?v=jqjtNDtbDNI
The guy describes what's going on pretty good
There's a project nix-tree that lets you see the dependency trees of Nixos.
Try that, (or post the output here). To see if firefox is referenced somewhere in the packages you're using
On the other hand, when my IDE doesn't tell me:
Build Server: "BUILD FAILED! SonarQube says that Roslyn says that you're not using one of your variables!"
Yea okay calm down, and why are you snitching now, Roslyn? Should have told me directly 🙃
You'd probably use a different approach for that. Like you'd make your program dynamically load all the .dlls in a "plugins" folder -
Then you'd provide some plugin interface for the users to create plugins, for example:
public interface IImageEditorPlugin
{
public void BeforeImageEdit(int[,] imageData);
public void AfterImageEdit(int[,] imageData);
}
And then you can load plugin classes from all the dlls with dependency injection, and execute them though something like this:
public class ImageEditor(IEnumerable<IImageEditorPlugin> plugins)
{
public void EditImage(int[,] imageData)
{
foreach (var imageEditorPlugin in plugins)
{
imageEditorPlugin.BeforeImageEdit(imageData);
// Do internal image edit function
imageEditorPlugin.AfterImageEdit(imageData);
}
}
}
This is a very simple example obviously, normally you'd send more meta-data to the plugins, or have multiple different interfaces depending on the kinda plugin it is, or have some methods to ask plugins when they're suitable to be used. But this way a user can provide compiled versions of their plugins (in the same language as the core application) - instead of having to provide something like lua scripts
Extension functions are not the same at all. Extension functions are syntactic sugar. For example if you have an extension function like
public static class ObjectExtension
{
public static void DoSomething(this object input) { }
}
You can call that function on an object by doing object.DoSomething() - Yes. But underneath it's the same as doing ObjectExtension.DoSomething(object)
That function does not actually become part of the object, and you can't use it to override existing functions
A closer example of how to do something similar in a memory safe language would be - in C# - using something like Castle DynamicProxy - where through a lot of black magic - you can create a DynamicProxy and fool the CLR into thinking it's talking to an object, while it's actually talking to a DynamicProxy instead. And so then you can actually intercept invocations to existing methods and overrule them
Generally overruling existing functions at runtime is not that easy
I think it's something similar to leetcode challenges, or adventofcode or something. I'm not associated with them, so I don't really know entirely.
Their existing problems are not behind an account wall though. You can go to any of their challenges, for example:
Then on top there's a label "Continue without an account" - and you can just try them out. I assume the challenges for this one will be something similar.
And I thought this site was pretty cool, since they actually have some graphical front-end showing what's going on, instead of just a code-only parsing kinda thing
I'm not 100% familiar with how federating works between instances - if one instance is hosting illegal content such as piracy, is that content actually federated into the databases of other instances? As in - are the other instances are now actually hosting that illegal content?
Or are the frontends (like programming.dev) just kinda proxying data without hosting it?
Just wondering at what level illegal content would exist in federated instances, since that might matter how liable other instances would be for it
I always went for bigger phones. Like I had the original Samsung Galaxy Note (This was back in 2011, so everyone was making fun of me "why is your phone so big?!")
Now I use a S23 Ultra, which is practically the same as the original note, even comes with a stylus pen again)
I just like having a lot of screen space. As long as it still fits in my pocket, why would I want a super small phone
Backend: There is a problem.
@ChatGPT: Can you turn the above sentence into 2 full paragraphs?
Frontend:
There’s a trend I’ve noticed—or at least, I think I’ve noticed. It’s the kind of thing that’s hard to be sure of; the kind that might genuinely be true, or might simply appear to be true if you look at it a certain way. I can’t tell if I’m right, or if the shapes I’m envisioning in arbitrary ink blots say more about me than they do about what I’m observing. Maybe it’s both. Maybe it’s all subjective gray area and I’m just picking a spot to draw a line. I guess you can decide for yourself.
I feel like I’m seeing a widespread diminishment of the practice of frontend. Nearly everywhere I look, I notice its importance minimized, and its challenges trivialized. This effect might be invisible to you right now. And thus, you might be reflexively inclined to say it doesn’t exist. Maybe you’re right. Maybe it doesn’t. Maybe I just need to step away from my little screens in my little basement office a little more often. Or, maybe it’s just like any other implicit bias; maybe it seems like it doesn’t exist because it feels so ordinary until you know what to look for. So: let’s talk about what I see. Maybe you’ll see it, too.
What convoluted nonsense am I even reading here
StackOverflow: Question closed as duplicate. Someone else already asked whether or not something is a nut.
Because just Dapper will perform a lot better executing raw sql queries than EF having to go through an entire expression tree builder.
Anyway, I wasn't saying that that example is a better way than doing it with EF, I was just going over your points where you mentioned that with raw SQL it's just all unreferenced magic strings with no references to tables or columns. And that you can't find where anything is used.
So that's just to explain - if you write your sql inside code in the poorest possible way - yea, you're gonna have a poor experience. But if you want to write raw sql instead of using an ORM, it's pretty easy to negate all those downsides about not having references