mergeconflict284 === [00:00:00] James: big. Thanks to our amazing sponsor this week sync fusion. That's right. Sync fusion. They've been with us since the very beginning. They've been with me for over a decade. Cause I've used them all the way back from when I worked at Canon steel, the beautiful applications for anything, whether it's web, desktop, mobile, they have all the components and widgets and gadgets and spreadsheets and all the things that you could possibly need for your application. So you don't need to build it yourself. That's right. Are you, are you using things like blazer, asp.net core angular react or Xamarin or Donna Maui or UWP or JavaScript or WPF or when you Y or flutter all the things they have a beautiful country. For absolutely anything that can integrate seamlessly into your apps. Go to sync, fusion.com/merge conflict to learn more about their awesome UI suite and so much more. Thanks to Cynthia for sponsoring this. We've had Frank Frank, Frank, Frank, Frank, Frank, Frank, Frank, Frank, Frank, thanks to sing fusion, but also to be honest, they've been with us for so long. [00:01:07] Frank: Hi, James. Hi sync fusion. Thank you. Thank you for your sharing. Yeah, absolutely. Thank you. Um, it's been wonderful. They've been with us. Uh, how many years did you say in a row? Because I just like hearing your ad reads basically at this point. So I'm just, I, I hope they're with us for the rest of you. [00:01:23] James: I do hope so upon you to contact them. See, because it's almost 20, 22, but no, let's not look here. Surprisingly, the very first episode that they sponsor was episode 32. So I mean, that's in the first. [00:01:35] Frank: Yeah. Amazing. Yeah. Well, we couldn't have done it without them. So [00:01:39] James: more importantly, we couldn't have done it with all of our amazing listeners. All of you listening right now. We super appreciate you being with us for the last five years. Whatever it's been 17 years has been amazing. All right. I got a topic, Frank. Controvert. [00:01:54] Frank: Ooh. Uh, I'm excited. This is the second week of the row where I'm going in cold. I got no idea. Oh, but controversy I'm here [00:02:02] James: for controversy. What are you got? So it's something that we've talked about already many, many, a times over on two different podcasts in the last few months. However, now that I have really gone all in on Donna six in C-sharp 10. I've been making more videos. I've been talking about the features more. I've been using the features a lot more and how much they've been improving my day to day development. However, I seem to be really big fans. I really big fan of two specific features. One is sort of at the project level and one is a language feature. They piggyback on each other, but. I'm such a big fan of it that I, you know, made a bunch of videos that did a bunch of things. I'm using it whenever I live stream and do all these things. I just love it. It just simplifies my code so much where I didn't really think it would be a debate that much or people would be really kind of give a lot of pushback on it, but they really, really have Frank, can you guess what features I'm talking about? It's [00:03:06] Frank: gotta be one of your favorites. So it's the global usings or it's the namespace with a colon. I can't see anyone having any trouble with namespace with a colon. So I'm going to go with the global usings [00:03:18] James: correct. So there's bull Hotmail, but the issues you're right on the head, the issue seems to be in and around. Not only global usings, but implicit usings, which is a flag that turns on a bunch of global usings as well. So I'll tee up this feature. It's a feature that I love and I think it's really cool. As a.net developer C-sharp developer, we've forgotten. Had to worry about namespaces and whenever you want to use a, you know, a class or a static method or static class or anything like that of something, let's say we have my app dot models. That to go to the top of my file, I have to say using my app dot model. Or I have to type monkey and then do IntelliSense to bring in the namespace, or I want to do, you know, filed out read, or I want to do task that Ron, or I want to do a link extension method in first, you know, first or default. Right. All the time. Oh. But you know, I haven't brought in the namespace, so it doesn't know about the extension methods. So I got to figure out how to write it right. Or go to the top of my file. And I got to do all these things. Um, Has annoyed me is that as you, your application grows, the top of your application files are a bunch of using statements. So these two features work in parallel. They're completely optional. You don't have to use them totally up to you. Now. Implicit usings are a flag in the project settings. You flip it on just like knowability and what that does is based on the project type, it decides, Hey. Implicitly for this project type, we are going to enable a set of namespaces everywhere in this application. So let's say you're in a council app. That's going to be your system system, um, link system collections, generic, your system dot, whatever. There's like maybe eight of them, the things that we have at the top of every single file. So that's really nice because they're like, if I'm using this in every single file, why is it. Every single file. Just get rid of it, right? Like that's the glory of implicit usings and additionally frameworks like asp.net core can bring in all that ASP and Anik core stuff. Like all the dependency injections that have extension methods adds it all in there. Now what about things that aren't in implicit usings cause it's only a set list. Well, that's where global usings come in, which enables you to do what. Bring your own using statements globally for your project. So where I would have using my app dot models, I could create another file or I can just add the keyword global in front of it. And it will light up that namespace in every single file in my entire project. It's for the project. And what that does, is it either. Shrink all of your using statements to zero, or just make them really small. Like, you know, for example, if I'm using, you know, jason.net in one file, I probably won't make that a global using, but I will, you know, just add everything else to the global using that I'm using in two or three or four more files. How did I do, did I describe the features? Correct. Frank, I've been talking, I'm passionate about this, Frank. I am passionate about. [00:06:42] Frank: You're just, you're just so over. Namespaces I think that's what I always get back to. It's a little bit of a change in culture. Um, because for a while there, we were putting a million namespaces and things, and I think we just maybe went a little too far, you know, there are ebbs and flows to everything. And I think having a list of 15 namespaces at the top of a file, isn't exactly helpful. Now, full disclosure here. Um, I haven't embraced. This new technology yet. So I'm going to be talking kind of like how I think I'm going to feel about it, which I don't know. I don't know how I actually feel, but I can give you gut reactions that yeah. Everything you described seemed fine to me, me personally, I think for the control freaks out there, the implicit usings is probably where I, if I had to guess everyone's freaking out a little bit more. Um, I was surprised when I first did it, when i.net six new console app. And all of a sudden, all these things were actually available in the IntelliSense and all that. So I was surprised I vaguely knew that that was coming, but it was still a bit of a shock. And I did have that question of like what eight namespaces or however many there are, are actually included in there. But you kept saying something that's really important. Um, static extension methods, extension methods, extension properties, hopefully someday, you know, stuff like that. I can't tell you the number of times where, like I found some random code snippet on the internet. I'm trying to make it work, but it's not working because some functions missing because we, again, a cultural shift, a little bit of a style shift in C-sharp people have really. Static extension methods and are building whole API APIs around them. They're not just like a, oh, let's add a tiny bit of functionality to an existing library. It's now I'm architecting my library around a minimal objects with vast quantities of extension methods, C asp.net and Maui. And that's kind of how the world works. And it's frustrating not to get those. So I think in a world where extension methods have become kind of a norm, we need a way to bring that stuff in a little bit more smoothly. I I've just been talking for a while, but I'm going to go back. I'm going to keep going and say that, uh, inside projects have been using Python lately, and I think Python has. Better import statements. So you can say like, from this namespace and port, these classes or these objects, whatever you want to say along those lines, it's a little more fine-grained. And I think that, um, Because, because we didn't have that fine grain imports, everyone started creating grain namespaces and then that was the explosion of namespaces that we've gone through in the last 10 years. And me personally, I don't care. I'll take a few name conflicts over, um, dealing with finding a hundred namespaces at the top of everything. [00:09:40] James: Yeah, I definitely have gone down that principle of, uh, when I do namespaces, it's very folder structure based. And in fact, in visual studio, 2022, you can right click on your solution and say, align all namespaces to like folders or whatever. And it'll streamline it all for you. But I run into that issue. Right. Which is, oh, okay. Like in. You know, file. I have using my app using my app dot models, using my app dot view models, using my app, that services using my app, that whatever. And then I'm like, okay, I have it in a bunch of files because I have a bunch of view models. So why do I have that everywhere? Now, one, one pushback on this. So there's a few backs that I would like to discuss with you, Frank, the pushback that I feel. See is, this is going to slow down my app. This is going to be a performance problem because I'm using all my namespaces. It has to bring in all of this stuff. And before you answer that, I'll, [00:10:42] Frank: I'll go my answer [00:10:44] James: before you and my response, I, I want to get like a very concrete answer from you. Cause you know, Frank's low level. He understands how things work. I just pretend like I know what I'm doing, but. When I originally came into the world of.net, like forever 15, whatever years ago, I always thought that the reason we had namespaces and there were more fine grain was. Overhead, like the more namespaces you brought in the, when you, when you nude up that class, it had to figure out a bunch of other stuff and it could be a performance implication, bottleneck. Is that true? Is that false? Like, what is, what is the runtime doing right when a namespace is used for. [00:11:26] Frank: So I'm going to say there is absolutely zero performance overhead. If what we're talking about is run time, overhead compiled, not even come out, you know, executable, running the code zero implications. You could put 8 billion usings at the top of your file and there will be an immeasurable because it's zero and difference and execution speed memory consumption all the above. With caveats star star star star star. So let's, let's go through the quick caveats here. Um, so talking about runtime performance, let's take a step back and talk about, uh, compile time and dev time. Technically the compiler has to look in more places. For every little symbol you type, especially with extension methods. So when you have a million usings that compiler has to do more work. Got it. So if you're talking about performance, okay. And you want to take into account the compiler, it matters, but let's go with, Roslyn's really efficient. It knows how to cash things. It's, it's pretty smart. So unless you've got one of those insane thousand project solutions, each one, you know, with a thousand files in it, Don't worry about it. Don't don't overthink this. By lots of Ram and just keep buying rim. Um, uh, and then there's one other one, which is I, I, we were talking about namespace, namespace conflicts, another bad version of that is IntelliSense. Because now there's just a lot more stuff listed in Intel. A sense because you have all these namespaces open. I think that that's actually a proper downside. Um, but I don't want to go too far there because you asked about performance. But to me that would be the bigger downside than performance. No. When the compiler is done, the compiler is looked up all of its symbols. It has matched names to assemblies. That's all done assemblies. Aren't loaded, unless they're needs. That assemblies are loaded dynamically. So if you don't execute the code, the assembly won't be loaded. Methods are jetted dynamically. They're not jetted unless you actually call them. So that's all you, you only pay for what you actually use. The exceptions here are iOS and because, um, what you want to run then is a linker that we'll go through, even though you opened up a million different assemblies because namespaces and assemblies, that's the real difference. Like it's assemblies that you want to avoid. Not namespaces so don't overthink the namespaces [00:14:01] James: okay. That, yeah. Cause like when I'm compiling up, my applications usually have just a few assemblies. And, you know, I use an of that name, it many namespaces right. And like I said, I don't put in every single thing when I don't don't need to. I, I, so I understand, I do understand that regard, which is like, maybe this feature would have been detrimental to performance of compile time and IntelliSense 10 years ago. Right. When maybe the IntelliSense engines weren't. They would have been under strain. Right. But now we've come a long way where like this feature is, is giving us. What I like to think of productivity and code cleanliness and things like this and the productivity of all the linking and using statements all in there, because our machines have come a long way because of the power of visual studio. And that can catch, can keep up with, with these new features that are being added, just like in Telecode. Right. And Telecode now has full line completion in visual studio, 2022, which is like beautiful. But it's only because now it's a 64 bit process. And also like our machines are a lot faster and like they can handle more things on. [00:15:10] Frank: Yeah. And, um, gosh, I've been so addicted to copilot lately. I don't have in Telecode, but I got compile it. And, uh, there's codex out there. If you, if you want to be really crazy, you can go pay for it yourself. You don't have to wait for the beta. Uh, those are out there and they're fantastic. So that problem I was talking about of your IntelliSense being a little flooded, it is a problem. It's still a bit of a problem if you're in vs code and don't have those more advanced code completion things. But honestly, everyone go get one of those advanced code completion, things, join the beta, take, do whatever it takes to get a windows machine up and running because there's so much better than, um, you know, 2010 IntelliSense is what we're all basically using. [00:15:53] James: Gotcha. Okay. [00:15:55] Frank: But, uh, okay. So zero performance. So I still, there are, I think me personally, I still wouldn't do the implicit ones because I like a little bit of control. I don't always like pull in system IO. Because I'm not because I don't use it a lot, but because I'd like to know which files actually do IO. And I think the bigger kind of conceptual problem I have with this is that it throws away layering a little bit, or it makes it easier to cross layer boundaries. So if you're trying to be like a good architect and have very clean abstraction layers in your software, like this is the UI layer is the data layer. This is a controller, the talks between them and no one else talks between. Uh, if you want to set that up and you have a million namespaces open, I think you're just a little bit more, um, enticed or it's just a little bit easier to start crossing layer boundaries. So I think about that from an architectural point, but I might just be making that up because I haven't actually used it. I haven't seen how much I'd actually be cheating. [00:16:56] James: Yeah, no, no. That does make some sense. I mean, but I do want to call out here. What I'm going to do is I'm going to pull in. Implicit usings because implicit using may sound scary. Cause you're like, oh my gosh, you're gonna bring some stuff. So here's, what's brought in Frank, [00:17:11] Frank: let's see here system, a console app. I counsel [00:17:15] James: that, but this is the default. So let's say it's a project type that doesn't specify anything. This is the, the core that's here. Uh, and they just bring in systems. So I approve [00:17:25] Frank: of system system. Sounds [00:17:26] James: good. CISM system collections. Generic. Yeah, please. This is your controversial one system. [00:17:33] Frank: Controversial, but I get where they're coming from. You do a lot of IO system.link. [00:17:39] James: Heck yeah. System that HTTP. [00:17:43] Frank: Mm. Uh, that's the asp.net team getting their way. Not all my apps do HTTP system [00:17:50] James: threading. Sure. [00:17:53] Frank: But it's kind of, it's kind of an ugly namespace system, not threading, but system not tasks. That's a much cleaner namespace and that's it. So this system I O and what was my other controversial one? I forgot already [00:18:07] James: system net HTTP. [00:18:09] Frank: Yeah. Okay. Even system that HB I'll give him that. Cause that's just like HTP client, right? That's not, that's not too bad. It's mostly [00:18:16] James: just HTTP client. Yeah. Yeah. [00:18:19] Frank: Okay. I like it. Um, you know, you need system IO for stream. I think just like string comes up a lot. Text writers. Uh, text reader, those just come up and they happen to sit in system IO. I approve of these. I'm going to use this when it use the, this [00:18:39] James: it's not that many, right? I think that's the thing. [00:18:45] Frank: It's not many, but at the same time, I don't mind having, do you call it a global using stock CS or do you just call it using stats? Yes, [00:18:53] James: that's also not controversial, but no standardization. So, um, [00:18:59] Frank: what do you prefer, James? [00:19:01] James: I do global usings because it's descriptive of what it is at the set of global usings and global using. You can also use for aliases as well, which is kind of. Yeah, [00:19:13] Frank: I kinda like it explicit if I'm honest, the implicit, it's probably going to be nice for console apps, basically.net, new little scripty things. Yeah. But I think from like my big ACQUITY apps, even though that that core list I'm pretty okay. With that core list, I think I would still dump it into my own. XSplit set global using stops. Yes. Just, just because I'm me and I want the control. [00:19:39] James: Yeah. I think that makes sense. Well, you're in control. The one nice thing is you are in control of what's happening here. I think that's one thing is if you like these features use them, if you don't like the features, don't use them. I guess that's sort of. You know my thought on it, but [00:19:55] Frank: you know what I'm actually afraid of? I have so many, um, shared projects because we've been doing this for far too long, James, um, a shared code projects, I should say, which are basically just an Ms. Built hack. It's what we had before we unified all the dot nets. Unfortunately, I have a lot of code and those things, I'm a little afraid of how all these global usings are gonna mix together, but I'm still going for, because it'll just be nice to clean up the source. [00:20:22] James: If that makes sense. Yeah, I think so. Well, that's the other thing that's controversial too. I would say on this is a lot of people have said, um, in the feedback loops is that, you know, they think it makes a code last readable because you don't know what files need, which namespaces. And I like this comment on my YouTube, but, uh, this person says, they think that this feature came about because the thought the new school or a school of thought is more lines of code. [00:20:53] Frank: I don't think it's that simple. Um, okay. This is where definitely philosophy gets involved because some people like everything explicit, some people like things implicit. It just turns out that people who like statically. Statically typed programming languages, where you explicitly state the types of things, just so happened. The Venn diagram happens to overlap with. They like explicit everything. If you like explicit types, you probably like explicit everything. Whereas the scripting languages like your pythons, it's uh, there's a lot of implicits in there. The types are certainly implicit. Uh, the imports are not though. That's very explicit. Anyway all to say. Um, I think that that's just a philosophical thing and what you're comfortable with, I get where they're coming from, but in a good idea, you, you hold command and you click and it takes you to the type or you just hover over it. And as long as you're, you know, Symantec passes compiling, you're going to know where that type is from. I don't need to write it. You know, system.link dot where I just, me personally, I, I don't want to write that. And I'm okay with the, uh, not knowing exactly where everything's from until I need to know. Uh, [00:22:10] James: I look at this other aspect of it and this is gonna be debatable too. So I'll get your input on it is for me, I feel as though I could be wrong, cause I've been using net and C-sharp for a long, long time. I feel as though this does make the. File new, um, a new user experience, a lot nicer because if you're in this world where the, my introduction to C sharp and.net is like, I still have namespaces right. They still exist when I add a new file and I see the namespace and they have these new file scope namespaces and things like that. But I see this and I sort of see this nice clean cut almost. The, to me, at least I could be wrong. Is it makes it feel more modern in a way that there's not just like this whole bunch of stuff at the top of my file and more approachable where I can just start writing code that that's my thought at least is like, and again, I'm not a new developer, so I don't know. But my hypothesis here is that if I'm a new developer, this is going to look pretty attractive to me. [00:23:16] Frank: Yeah. Um, It's hard because we can't put ourselves in that spot. Huh. It's hard as I try and want to think about it can only talk from my perspective. So my perspective is the more clutter you have in your code, the more repetitive things that you have to scroll through to find what you're actually interested in. Uh, It's a signal to noise ratio stuff. You know, I want to eliminate the noise and that doesn't mean I'm playing code golf. That doesn't mean I'm doing one letter variable names are cramming, everything onto one line of code. It just means I'm eliminating 15 lines of using at the top. And I'm curious to see how. When I first released sequel light dash, that everyone made fun of me because the entire library was one single C-sharp file. I think people still make fun of me a little bit for that. Um, because the, the style was kind of the Java style. Every class goes into a file, uh, into its own individual. File. And now it's, those files are going to be really small, especially if you're doing like interface based programming. It's just, I have like interface, Blas, uh, curly, two vines and a curly. And that's a really short file. So I'm actually curious as stylistically and especially with, um, console apps, being more scripty looking, uh, with your ability to actually put statements at the top level. I wonder if we're going to see, um, Even more condensing. I wonder if people are going to be crazy and put multiple classes in one file, you know, find a way kind of break that dogma, um, or not. I don't know. I I'm always here for stylistic changes. I don't think this hurts the language in any way. So I'm just more curious to see how other people do it. Me personally, I'm going to go for maximum signal to noise, right? [00:25:07] James: That makes sense. Yeah. I, to me, it's always been like a lot of these features to me. I never get to discover them. I feel like this is something that's very easily discoverable and something that I will use. Like a lot of times when they're like language features, you know, there's the one, well, what is the one feature it's sort of. It's like better switch cases that like return stuff, forgot what it's called. But basically I write the switch statement and then I let visual studio refactor it for me. Cause I know how to do that. I love [00:25:40] Frank: it. I love that switch expressions. Yes. The trick to remember is value first and then the word switch and then the IntelliSense will help you out. So just try to remember expression then the word switch and then start hitting. [00:25:55] James: Yeah, I, and I feel like those it's like, oh, I'm refactoring code. And that it isn't, it's like a nicety and like does make things a lot shorter and nicer. I feel like, and it does bring in stuff, uh, like, um, you know, more complex types that can be, uh, can be, can be switched, cased over and things like that. Um, Um, pattern matched as well, which is cool. That's the word I was looking for more. I feel like this feature is, oh, cool. Like it just makes my code a lot cleaner and helpful. And for me it's helpful when I find those objects automatically. Um, but you are in control. Maybe, maybe this feature isn't fine. Grain enough for some people. That's what I'd be interested in feedback for us. Like, do you want a global using like in a folder? Like, you know what I mean? Like, oh, I'm in the models folder. Let me bring. These namespaces and it's only for these, whereas like if I put it in my route, it applies to the whole thing. And maybe that's what people are looking for. I don't know. [00:26:51] Frank: Uh, yeah, that, that's interesting. That's kind of how asp.net views work. And I think you can put a different kind of usings file or it takes the one in the directory, not necessarily the one in the ancestor directory. So that kind of makes sense. I like that you should pitch that to the team. You can start your own controversy. Everyone will be blaming you for something, but. I don't even know if we need that level of detail. Um, because even if you pull in like your models, uh, folder interviews, folder, a little bit of layer, cross contamination there, you're not going to pull in. Your sub sub namespaces into your global usings, you're not going to expose those. So it'll still encourage you. Um, you'll have a set of namespaces, that'll be your good public interfaces that you do want to share between all the code files in that project, and then things that you put in esoteric or deeper namespaces hopefully just won't show up and no one will touch that code. So I think. Stylistically be good for layering, even though I said it was bad for layering earlier. [00:27:59] James: Nice. Okay. Yeah. Any other features of a C-sharp 10 that you think are controversial that you've been experimenting around with that you're like, ah, I don't know how I feel about this or things that you've heard on the, on the. [00:28:12] Frank: No, no. The, the one that me personally I'm a little nervous about is the actual Mo um, source file, top level statements where you can actually put executable code and the top level. I don't know how I feel about that one yet. I haven't, I certainly haven't taken advantage of it. It's great for scripts. No, no problem there. Um, but in really real source files, I don't know if I want it or not. It's, it's a little too tempting, like to just start throwing global variables everywhere. And I kind of liked that the C-sharp forced me to be slightly good, a slightly good programmer and not just contaminate the global namespace, but at the same time, That's it really hurt anything. Am I really, or am I just being dogmatic and maybe I should give it a whirl and things like that, but I don't see any feature of a programming language it's controversial, especially in C-sharp where they take such pains to be backwards. Like, if you don't want to use the feature, just don't use it. It's really not a big deal. Uh, disable. You can, you can create a, uh, suppression stop CS file that turns off analyzers. That'll stop bothering you about switching your switch statement to the new switch statement. Um, but in truth, um, I don't see any reason to fight it. I would brace these features. I don't know how could a feature be bad? It's just how you use it. Just make good decisions, everyone. [00:29:39] James: I like it. I like it. All right. I think that's all I got Frank. I appreciate you talking me through it and the dressing, some concerns. I don't know. I, I, I think any feature or any change, you know, people are gonna be four. People are gonna be against it, but I wanted to kind of talk through. Maybe just some of the concerns people had, right. The performance thing, or like, you know, uh, you know, different conflicts and things like that, or best practices. Cause it is a feature. So you can use it to whatever extent you may want, uh, in your application, uh, you know, analyzing your own code base. Maybe it doesn't make sense for you. Uh, back in the day, I used to have one namespace in my code. I would just be like everything. I don't care what folder it's in. Just one namespace that actually works. [00:30:24] Frank: Yeah. Or you can just put, uh, an, uh, a capital F or in your case, a capital J before every class name. And you're good to go. Yeah, homemade namespaces now it's better that the language supports this. It's not going to break down all the, all the rules in the language, but everyone. Zero zero performance overhead at runtime. I would say few little stars for AOT and all that kind of stuff. And don't worry. The compiler is fast. That's not the slow part of the compiler. The slope part of the compiler is finding all the DLLs on your machine. [00:30:58] James: Got it. Cool. All right. I think that's going to do it. It's a nice quick one this week. [00:31:03] Frank: In and out. Yes. Um, I'm sure this is like a C-sharp 10 episode. Number three. I can't wait for number [00:31:10] James: four. Uh, it's definitely been quite a bit, so. All right. Well, thanks everyone for tuning in, let us know what you think of C-sharp 10 features or using implicit usings or using global usings or like, no, that's crazy. Did we miss a concern that you may have? Let us know. We'll definitely bring it up on our nights on our next podcast or next lightening round talk, whatever we do. Um, but I think it's gonna do for this. Podcasts. So until next time I'm James. Now [00:31:36] Frank: I'm Frank Krueger from the snake. Peace.