If an error message falls in a forest...



  • @this_code_sucks said:

    @ShatteredArm said:

    Unless you're suggesting that the best design is to place all of your application's classes in a single project, then your application is going to have DLLs. 

     



    How the hell did you extract this statment from what he said, which is, "in most cases don't put ui logic in a shared class library"?
     

    Different argument.  I'm debating blakeyrat's statement that there is no legitimate reason to use Console in a DLL, and that the compiler should prevent you from doing so.  My argument against that point is that not all DLLs (and, in practice, few DLLs) are actually shared libraries.  If you actually read any of my posts, you won't find any disagreement about the text you quoted.

     



  • Also, if DLLs are inherently supposed to be shared libraries, Microsoft should really consider disallowing DLLs to be used in application directories, and instead force them all to be signed and installed in the GAC.  After all, copying shared libraries around to different application directories is just asking for trouble.



  • @ShatteredArm said:

    Because each class library project in .net automatically becomes a DLL. Unless you're suggesting that the best design is to place all of your application's classes in a single project, then your application is going to have DLLs.

    Why wouldn't you put them all in the same project if they're all part of the same project? Why add complexity where it's not needed? My philosophy towards software development is and has always been KISS.

    @ShatteredArm said:

    Have you ever built a .net application in your life?

    Yes.

    @ShatteredArm said:

    I wouldn't consider something that is done in 99% of cases to be a contrived edge case.

    You do realize that one of my main themes in my posting here is how 99% of software is crap. So saying that 99% of software does X is not likely to convince me that X is the correct thing to do.



  • @ShatteredArm said:

    Different argument.  I'm debating blakeyrat's statement that there is no legitimate reason to use Console in a DLL, and that the compiler should prevent you from doing so.  My argument against that point is that not all DLLs (and, in practice, few DLLs) are actually shared libraries.  If you actually read any of my posts, you won't find any disagreement about the text you quoted.

    So...why the hell are you arguing with a statement that's been redacted?



  •  @blakeyrat said:

    @ShatteredArm said:
    Because each class library project in .net automatically becomes a DLL. Unless you're suggesting that the best design is to place all of your application's classes in a single project, then your application is going to have DLLs.

    Why wouldn't you put them all in the same project if they're all part of the same project? Why add complexity where it's not needed? My philosophy towards software development is and has always been KISS.

    @ShatteredArm said:

    Have you ever built a .net application in your life?

    Yes.

    @ShatteredArm said:

    I wouldn't consider something that is done in 99% of cases to be a contrived edge case.

    You do realize that one of my main themes in my posting here is how 99% of software is crap. So saying that 99% of software does X is not likely to convince me that X is the correct thing to do.

    Holy hell, I'd hate to work on your team if you actually put all of your classes, no matter how loosely related, into the same project.



  • @lettucemode said:

    @ShatteredArm said:
    Different argument.  I'm debating blakeyrat's statement that there is no legitimate reason to use Console in a DLL, and that the compiler should prevent you from doing so.  My argument against that point is that not all DLLs (and, in practice, few DLLs) are actually shared libraries.  If you actually read any of my posts, you won't find any disagreement about the text you quoted.

    So...why the hell are you arguing with a statement that's been redacted?

     

    At what point was "there is no legitimate reason to use Console in a DLL, and that the compiler should prevent you from doing so" redacted?



  • @ShatteredArm said:

    Holy hell, I'd hate to work on your team if you actually put all of your classes, no matter how loosely related, into the same project.

    You know, there's this fascinating new feature in C# called a namespace. It gives you a way to logically divide up your classes without creating unnecessary DLLs and projects. You should look into it.



  • @ShatteredArm said:

    Holy hell, I'd hate to work on your team if you actually put all of your classes, no matter how loosely related, into the same project.

    Why?



  • When he posted this:

    @blakeyrat said:

    A shared library should never use UI elements (including the Console) that were not passed to it by the calling code, and were not created by the library itself.

    He modified his argument to account for all the other points raised since he first made the claim that a DLL should never reference Console.

    Now we're on a slightly different topic, in which you claim that it's still ok to have DLLs that may or may not reference the Console because of multiple projects in a solution. But since namespaces exist that argument is moot.

    Have you really never looked at a C# solution and thought, "Huh. My project/namespace ratio is 1:1. Maybe I'm not using them the way they were intended."?

    EDIT: of course, since everyone's been confusing the terms "DLL" and "shared library" throughout this discussion, perhaps deliberately, maybe nothing was redacted at all, and in that case I apologize.


  • ♿ (Parody)

    @lettucemode said:

    @ShatteredArm said:
    Holy hell, I'd hate to work on your team if you actually put all of your classes, no matter how loosely related, into the same project.

    You know, there's this fascinating new feature in C# called a namespace. It gives you a way to logically divide up your classes without creating an unnecessary DLLs and projects. You should look into it.

    So, in order to reuse code, are you (and blakeyrat) arguing that you need to reuse it by putting the source all together into one "project"? Which means that it compiles into a single binary? (I don't use VS and its "projects" and "solutions" so these are honest questions.) Does that complicate the SCM situation? Keeping changes in common code synchronized?



  • @boomzilla said:

    So, in order to reuse code, are you (and blakeyrat) arguing that you need to reuse it by putting the source all together into one "project"?

    We're talking specifically about classes that aren't re-used. We're talking about classes that are only applicable to a single project.

    That invalidates the rest of your questions. Also, maybe you should spend 5 nanoseconds actually figuring out how the best IDE in the world organizes projects and solutions, although if you did that I guess you'd just go back to your Java-based shit with a deep sense of loathing that you don't currently have now.

    FOR PEOPLE WHO ARE MORONS AND HAVING TROUBLE FOLLOWING THE THREAD IT GOES LIKE THIS:

    Me: "Shared libraries should never assume a particular UI is available to use."

    "What about shared libraries that exist for the sole purpose of creating a UI! Huh? Huh? Put that in your pipe and smoke it fancy-pants!"

    Me: "Fine, here's my argument in a more specific, pedantic form which covers all of the common cases for people who are too stupid to understand the concept of a 'generalization' or 'ideal'."

    "I'm a pedantic dickweed and I love coming up with edge-cases to use in the hopes that citing them will help me sound smarter around my peers, and to boost my own ego because I found a 'gotcha' in your rules. What if the shared library is only used in a single project? Huh? Huh? Put that in your pipe and smoke it, fancy-pants!"

    Me: "But why the fuck would anybody ever do that? If you only use the classes in a single project, why would you put them anywhere other than inside the single project they're used for? What the fuck is wrong with you idiots?"

    "Because I'm a fucking idiot who likes to pointlessly complicate my life, duh! And because I'm completely ignorant of the 47,000 tools Visual Studio provides to manage that scenario in an easy, intuitive manner! Duh! Man I sure would have to work at your job, I can't believe you don't pointlessly complicate everything you touch with useless bullshit projects!"

    That brings up to the current point of the discussion, I believe.



  • @boomzilla said:

    So, in order to reuse code, are you (and blakeyrat) arguing that you need to reuse it by putting the source all together into one "project"? Which means that it compiles into a single binary? (I don't use VS and its "projects" and "solutions" so these are honest questions.) Does that complicate the SCM situation? Keeping changes in common code synchronized?

    If you have classes and code that will be reused, put them in a library (or "shared library", or "DLL"). If you have classes and code that will not be reused, put them in your main application.

    The point is that any code that makes a reference to Console necessarily goes into the application to prevent bugs and follow good practices and whatnot. If you're concerned about stuffing tons of classes into one project for some reason, like ShatteredArm here, then get over it and use namespaces. It's not like the project can "fill up" with classes.



  • @ShatteredArm said:

    Holy hell, I'd hate to work on your team if you actually put all of your classes, no matter how loosely related, into the same project.

    Holly hell, I hate to read stupid posts on this forum, no matter how low my expectation of the poster are.
    @boomzilla said:
    So, in order to reuse code, are you (and blakeyrat) arguing that you need to reuse it by putting the source all together into one "project"?

    I don't think that is what they are saying.
    @boomzilla said:
    Which means that it compiles into a single binary?

    Of course not, unless you really want it.
    @boomzilla said:
    honest questions

    Why are you here?



  • @boomzilla said:

    So, in order to reuse code, are you (and blakeyrat) arguing that you need to reuse it by putting the source all together into one "project"? Which means that it compiles into a single binary? (I don't use VS and its "projects" and "solutions" so these are honest questions.)

    Ohhh, I see what you're asking.

    A project in VS is a logical unit of code and resources that can be compiled. Maybe into a library, maybe into a .exe, whatever you want. A solution contains multiple projects and represents a complete software product.

    @boomzilla said:

    Does that complicate the SCM situation? Keeping changes in common code synchronized?

    Well, if there's a library in use in multiple solutions then hopefully it is in DLL form, not open-source form, and is sitting on a network drive somewhere so that one can easily grab the latest version if it's updated.



  • Just curious, who here does thick client and who here does web apps?

    >I do web apps


  • ♿ (Parody)

    @blakeyrat said:

    @boomzilla said:
    So, in order to reuse code, are you (and blakeyrat) arguing that you need to reuse it by putting the source all together into one "project"?

    We're talking specifically about classes that aren't re-used. We're talking about classes that are only applicable to a single project.

    OK.

    @blakeyrat said:

    That invalidates the rest of your questions. Also, maybe you should spend 5 nanoseconds actually figuring out how the best IDE in the world organizes projects and solutions, although if you did that I guess you'd just go back to your Java-based shit with a deep sense of loathing that you don't currently have now.

    Fuck, I thought that learning about that magical IDE is what I was doing. I should have known that you wouldn't answer the question, though. I will defer to your experience with VS induced self loathing.

    @lettucemode said:

    The point is that any code that makes a reference to Console necessarily goes into the application to prevent bugs and follow good practices and whatnot. If you're concerned about stuffing tons of classes into one project for some reason, like ShatteredArm here, then get over it and use namespaces. It's not like the project can "fill up" with classes.

    Yes, the Console "argument" is pretty banal. I was more interested in the larger argument about "project" management in a VS environment. I guess that in all of the back and forth, I hadn't realized that the discussion was strictly about code that only ever exists in a single project. I think the talk of "class library" was what threw me, since it seems to imply some element of reusability. I should really know better than to ask an actual question in a thread where blakeyrat is participating.



  • @blakeyrat said:

    Me: "Shared libraries should never assume a particular UI is available to use."

     Actual quote:

    @blakeyrat said:

    DLLs generally don't have UIs.

    On the other hand, I'm mildly surprised C# lets you even compile a class library with a Console call in it.


     

    You never mentioned "shared libraries" until well after your complaint that C# lets you compile a class library with a Console call in it.  I've just been pointing out that DLLs are rarely actually shared in practice.  If you don't like that, get over it.

     



  • @this_code_sucks said:

    Just curious, who here does thick client and who here does web apps?

    >I do web apps

    I do web apps backed by Windows Services. So for the benefit of Boomzilla, that means my current solution consists of five projects:

    1) A class library (basically a WorkerThread subclass and its supporting classes)

    2) A Service UI for the class library (if you can call a Service a "UI", but you get the point)

    3) A console UI for the class library (for QA purposes; Services are a pain to install, it's quicker to do a quick test using a console window)

    4) The API for the site (JSON-based REST API)

    5) The UI for the site



  •  

    @boomzilla said:

    Yes, the Console "argument" is pretty banal. I was more interested in the larger argument about "project" management in a VS environment. I guess that in all of the back and forth, I hadn't realized that the discussion was strictly about code that only ever exists in a single project. I think the talk of "class library" was what threw me, since it seems to imply some element of reusability. I should really know better than to ask an actual question in a thread where blakeyrat is participating.
     

    Class libraries do allow things like reusability, but they also allow things like modularity, if you're not an idealistic toolbag who believes that your entire application should go in a single project, which is a practice that is used by approximately zero real-life teams made up of more than one individual. Nobody builds a class library project with the thought, "Gee, I should make this windows workflow project a class library so that other applications can use the same, very application-specific, workflow project!"



  • @ShatteredArm said:

    Sure, writing to the Console is almost always completely useless, but why can't a dll be intended exclusively for use in Console applications? In that case why bother with a DLL in the first place?

    @blakeyrat said:
    A DLL is a shared library. A shared library doesn't know or care what code is calling it. It doesn't know or care whether the calling code has a console UI or not.


    Maybe this already been pointed out but this whole discussion is be based on a misconception.

    There are two things in .NET: the Console application project type and the static Console class. Other than the poorly chosen name they have little in common.

    A console application is the simplest standalone executable. Unlike what some posters believe, a console application does not have a UI. When you run it by double-clicking  it is tied to the DOS prompt UI, like any other Windows executable that does not clame a UI of its own. This is standard Windows behavior that has nothing to do with .NET. When you run it by starting it from another process, it pipes to that process. Again, standard Windows behavior. When you run it in visual studio, VS will cook a DOS look-alike window for you. This is just VS trying to make a fool of itself.

    Guess what the Console object is?

    @The Rider said:
    As far as I'm concerned, the only good solution to this issue is not to use Console directly from inside DLL code, but to pass in the stdout, stderr and/or stdin streams as parameters to the corresponding DLL methods that need to write stuff to some output device [...].


    RTFM. The Console class is the std I/O. Nothing more, nothing less. That's why it's static. Every process always has one and only one std I/O. VS or .NET would have made a big mistake if they would forbid the use of std I/O.

     EDIT: This does not imply that writing to std I/O is a sensible thing to do. But forbidding it isn't either.



  • @blakeyrat said:

    @this_code_sucks said:

    Just curious, who here does thick client and who here does web apps?

    >I do web apps

    I do web apps backed by Windows Services. So for the benefit of Boomzilla, that means my current solution consists of five projects:

    1) A class library (basically a WorkerThread subclass and its supporting classes)

    2) A Service UI for the class library (if you can call a Service a "UI", but you get the point)

    3) A console UI for the class library (for QA purposes; Services are a pain to install, it's quicker to do a quick test using a console window)

    4) The API for the site (JSON-based REST API)

    5) The UI for the site



    Your solution structure is not complicated enough; therefore you are a shitty coder.

    YOU NEED MORE PROJECTS!


  • @this_code_sucks said:

    Just curious, who here does thick client and who here does web apps?

    >I do web apps

     

    I do a WCF service.   We have the following projects:

    - A database project (doesn't really count, since it just builds tables, etc)

    - A business layer

    - A data access layer

    - An admin UI

    - A diagnostics service project

    - A windows service project for maintenance

    - A schema mapping project

    - A data model project

    - A project with IoC, WCF, etc. plumbing/utilties

    - A test project for automated functional tests

    - A test project for unit tests

    - A general utitlities project (intended to be a shared library)

    - A web project (for hosting the actual service)

    - A windows service to support the admin UI backend

    - A project containing the service model

     



  • @JvdL said:



    RTFM. The Console class is the std I/O. Nothing more, nothing less. That's why it's static. Every process always has one and only one std I/O. VS or .NET would have made a big mistake if they would forbid the use of std I/O.

     EDIT: This does not imply that writing to std I/O is a sensible thing to do. But forbidding it isn't either.

     

    Stop being so damn reasonable.  More idealism!

     



  • FTR, Console is only referenced in our test projects, which you are *forced* to make separate projects, are compiled down to DLLs, and would be totally idiotic to share.

    Also, I hope blakeyrat's team has some unit tests in a different solution somewhere, because lack of unit tests would make him a shitty coder.



  • @ShatteredArm said:

    You never mentioned "shared libraries" until well after your complaint that C# lets you compile a class library with a Console call in it. I've just been pointing out that DLLs are rarely actually shared in practice. If you don't like that, get over it.

    Then the practice is wrong. I don't know what else you want me to say. There's nothing to "get over" since "software developers almost all do stuff wrong" has long been established.



  • @ShatteredArm said:

    Also, I hope blakeyrat's team has some unit tests in a different solution somewhere, because lack of unit tests would make him a shitty coder.

    I don't have unit tests.



  • @JvdL said:

    A console application is the simplest standalone executable. Unlike what some posters believe, a console application does not have a UI.

    Yes it does. If it didn't have a UI, it wouldn't open a window when you double-clicked it.

    @JvdL said:

    When you run it by double-clicking it is tied to the DOS prompt UI, like any other Windows executable that does not clame a UI of its own.

    ... oh so it does have a UI.

    @JvdL said:

    Guess what the Console object is?

    You're not going to explain it to us? Aww.

    @JvdL said:

    RTFM. The Console class is the std I/O.

    This changes... what exactly?

    @JvdL said:

    EDIT: This does not imply that writing to std I/O is a sensible thing to do. But forbidding it isn't either.

    Except that if you're writing to Console in a shared library, that's a bug. Alternatively, if .net lets you write to the Console, but that output get black-holed and goes nowhere (like doing it in a Windows Service), that is also a bug.

    So yes, forbidding it is a sensible thing to do because it prevents bugs.



  • Well from Blakey's structure, there doesn't seem to be much worth unit testing.

    Testing the json api would be integration testing. It's pretty hard to unit test a service. Unit testing an UI is TRWTF; the level of effort of unit testing an UI exceeds the benefits by orders of magnitudes.

    That doesn't discredit unit testing, it's just not always appropriate.

    Oh wait, I forgot; all applications need to be built the same way no matter what they do. 

     



  • @blakeyrat said:

    @JvdL said:
    A console application is the simplest standalone executable. Unlike what some posters believe, a console application does not have a UI.

    Yes it does. If it didn't have a UI, it wouldn't open a window when you double-clicked it.


    OK. So a .BAT file is also a UI application. Learned something new today.

    @blakeyrat said:
    @JvdL said:
    @The Rider said:
    [...]the only good solution is not to use Console [...] but to pass in the stdout, stderr and/or stdin [...]

    RTFM. The Console class is the std I/O.

    This changes... what exactly?

    Maybe it changes The Rider's misconceived opinion. Why do you care?

    @blakeyrat said:
    @JvdL said:
    EDIT: This does not imply that writing to std I/O is a sensible thing to do. But forbidding it isn't either.

    Except that if you're writing to Console in a shared library, that's a bug.

    Why do you think this a bug? It does not crash. It writes to stdin: a black hole, port, file, pipe or UI. Who knows? Only the OS. Who cares? Not the code. Which makes std I/O so damned (re)useful.

    Do you think it a bug because a shared library doesn't know where std I/O exactly goes to? Do you believe an EXE process (with or without UI)  knows that? Run one of your console applications with an >> output.txt argument. That will clear up another misconception.



  • @this_code_sucks said:

    Well from Blakey's structure, there doesn't seem to be much worth unit testing.

    At the moment, the web UI has a page which does one of each the API calls on a "reference" database, and shows red bold numbers if the values differ from what I expect, so. More "lazy-testing" than anything official, but it works for this stage of development.

    I actually see room for a few unit tests for the Windows Service, though, since it does some non-trivial data processing. I just haven't written any tests yet.



  • @JvdL said:

    OK. So a .BAT file is also a UI application. Learned something new today.

    Of course.

    BTW, as a developer who grew up on Mac Classic, I find it amusing that so many of you just blithely assume there's such a thing as a "standard in/out", and that every app no matter its UI or method of development just naturally has access to it. We had a long-running and very successful platform that had no such concept as "standard in/out". (It really didn't have such a concept as "console UI" either, except that compiler/IDE authors usually wrote one for it to assist in porting.) Such narrow minds.

    @JvdL said:

    Do you think it a bug because a shared library doesn't know where std I/O exactly goes to?

    No; but I think it's a bug if a shared library sends something to it not knowing where it goes to. Read my more detailed description of my position again.

    @JvdL said:

    Do you believe an EXE process (with or without UI) knows that?

    Knows what?

    @JvdL said:

    Run one of your console applications with an >> output.txt argument. That will clear up another misconception.

    Which misconception are you referring to, and how do you think piping output to a file changes my argument in any way?



  • @JvdL said:

    Why do you think this a bug? It does not crash.

    I don't think that you actually want to say that bugs are program crashes only, so I'll give you the benefit of the doubt.

    It's a bug because it creates situations where the expected outcome vs. the actual outcome of writing to stdout will be different. Console might not even be pointing at stdout by the time the library calls it.



  • @this_code_sucks said:

    Just curious, who here does thick client and who here does web apps?

    >I do web apps

    Mostly web apps, but sometimes thick client.



  • @morbiuswilters said:

    sometimes thick client

    Only sometimes? No love for the chunky?



  • @JvdL said:

    Do you think it a bug because a shared library doesn't know where std I/O exactly goes to? Do you believe an EXE process (with or without UI)  knows that? Run one of your console applications with an >> output.txt argument. That will clear up another misconception.

    I think that only strengthens the point being made. OSes let the user redirect output of applications; that's because it's the user's system, the application is a guest. By the same token, libraries should not presume they own the std* streams. If you had an application that always wrote to the same, hard-coded file on disk without any way for the user to control that, you'd probably think that was a broken program (I guess, I dunno.. you people seem to think every behavior is justified). And if a library simply wrote to an arbitrary file of its choosing, instead of taking a stream (or at the very least, filename) argument, you'd think "What a piece of shit!"

    Why is stdout (or Console in this case) any different? Maybe you're writing a CLI app that uses stdout to communicate with a process; if your shared library is writing to stdout for no good reason, you could easily fuck things up, undermining the reusability of your library.



  • @ShatteredArm said:

    FTR, Console is only referenced in our test projects, which you are forced to make separate projects, are compiled down to DLLs, and would be totally idiotic to share.

    So an edge case which has already been brought up. We know there are cases that UI is required in DLLs (plugins, testing, UI frameworks). The question is: why is it being allowed in normal DLLs? Are you telling me this isn't something that could simply be fixed with a compiler directive? I mean, you don't seem to disagree that a normal application shouldn't be directly accessing UI from a library, correct?



  • @morbiuswilters said:

    @ShatteredArm said:
    FTR, Console is only referenced in our test projects, which you are *forced* to make separate projects, are compiled down to DLLs, and would be totally idiotic to share.

    So an edge case which has already been brought up. We know there are cases that UI is required in DLLs (plugins, testing, UI frameworks). The question is: why is it being allowed in normal DLLs? Are you telling me this isn't something that could simply be fixed with a compiler directive? I mean, you don't seem to disagree that a normal application shouldn't be directly accessing UI from a library, correct?

     

    I have personally never encountered a situation where writing to stdio in a class library, excluding test projects, would seem appropriate.  But the fact that the obvious example of test projects exists is evidence enough that making the compiler enforce it would be idiotic.  Let the compiler's users decide what the assemblies are used for, rather than implementing mandates based on poorly thought out ideology.



  • @morbiuswilters said:

    @JvdL said:
    Do you think it a bug because a shared library doesn't know where std I/O exactly goes to? Do you believe an EXE process (with or without UI)  knows that? Run one of your console applications with an >> output.txt argument. That will clear up another misconception.

    I think that only strengthens the point being made. OSes let the user redirect output of applications; that's because it's the user's system, the application is a guest. By the same token, libraries should not presume they own the std* streams. If you had an application that always wrote to the same, hard-coded file on disk without any way for the user to control that, you'd probably think that was a broken program (I guess, I dunno.. you people seem to think every behavior is justified). And if a library simply wrote to an arbitrary file of its choosing, instead of taking a stream (or at the very least, filename) argument, you'd think "What a piece of shit!"

    Why is stdout (or Console in this case) any different? Maybe you're writing a CLI app that uses stdout to communicate with a process; if your shared library is writing to stdout for no good reason, you could easily fuck things up, undermining the reusability of your library.

    Agree with all of but fail to see why this makes using std I/O better or worse done in a DLL than doing so in an EXE or why it should be forbidden, which are the two things I took issue with.

    Using std I/O is simple and crude and there are always better ways to accomplish it. That said, std I/O is the norm in Unix derivatives that run half the internet and about a billion smartphones, so it can't be all that bad. Personally, I apply std I/O (i.e. Console class) in development tools for personal and team use. Mostly, to transform files, to debug and to make release builds. Such tools use std I/O for a good reason. Doing something for no good reason is a WTF, period, not limited to std I/O.



  • @morbiuswilters said:

    @ShatteredArm said:
    FTR, Console is only referenced in our test projects, which you are forced to make separate projects, are compiled down to DLLs, and would be totally idiotic to share.

    So an edge case which has already been brought up. We know there are cases that UI is required in DLLs (plugins, testing, UI frameworks). The question is: why is it being allowed in normal DLLs? Are you telling me this isn't something that could simply be fixed with a compiler directive? I mean, you don't seem to disagree that a normal application shouldn't be directly accessing UI from a library, correct?

    Why does it even need fixing? How much money are we losing by not having this compiler directive? How much money would we lose by having it, setting it, and then trying to do something that it forbids and not realizing what the problem is? How much money would Microsoft have to spend to spec, implement, test, document and deploy this feature? Are there actually problems that are best solved by changing the compiler, rather that using a blunt object?

    In my opinion, the answer to the yes/no questions above are "no", and the numeric questions are "very little", "more than the problem it's solve", and "more than the problem it's solve" respectively.

    I'm not advocating doing this, but it seems like a pointless rule that doesn't actually help anything. It's like a law that says that you may not shut off water mains in cities: Sure, it's a bad idea to do this in general, but you're not going to do it anyway, and sometimes, in edge cases, you DO have to do it, and have no other choice.



  • @pkmnfrk said:

    Why does it even need fixing? How much money are we losing by not having this compiler directive? How much money would we lose by having it, setting it, and then trying to do something that it forbids and not realizing what the problem is? How much money would Microsoft have to spend to spec, implement, test, document and deploy this feature? Are there actually problems that are best solved by changing the compiler, rather that using a blunt object?

    ... and now we get to the inevitable point in the conversation where I have to define the words "should" and "ideal". Lovely.

    @pkmnfrk said:

    It's like a law that says that you may not shut off water mains in cities: Sure, it's a bad idea to do this in general, but you're not going to do it anyway, and sometimes, in edge cases, you DO have to do it, and have no other choice.

    Wow. Worst metaphor? I think so!



  • @blakeyrat said:

    Wow. Worst metaphor? I think so!

    Yes, according to TDWTF forum guidelines it should have been a car metaphor.



  • @blakeyrat said:

    @pkmnfrk said:
    Why does it even need fixing? How much money are we losing by not having this compiler directive? How much money would we lose by having it, setting it, and then trying to do something that it forbids and not realizing what the problem is? How much money would Microsoft have to spend to spec, implement, test, document and deploy this feature? Are there actually problems that are best solved by changing the compiler, rather that using a blunt object?

    ... and now we get to the inevitable point in the conversation where I have to define the words "should" and "ideal". Lovely.

     

    @blakeyrat said:

    On the other hand, I'm mildly surprised C# lets you even compile a class library with a Console call in it. 



  • Ok?



  • @blakeyrat said:

    Ok?

    He got you to argue with yourself!



  • @JvdL said:

    @morbiuswilters said:

    @JvdL said:
    Do you think it a bug because a shared library doesn't know where std I/O exactly goes to? Do you believe an EXE process (with or without UI)  knows that? Run one of your console applications with an >> output.txt argument. That will clear up another misconception.

    I think that only strengthens the point being made. OSes let the user redirect output of applications; that's because it's the user's system, the application is a guest. By the same token, libraries should not presume they own the std* streams. If you had an application that always wrote to the same, hard-coded file on disk without any way for the user to control that, you'd probably think that was a broken program (I guess, I dunno.. you people seem to think every behavior is justified). And if a library simply wrote to an arbitrary file of its choosing, instead of taking a stream (or at the very least, filename) argument, you'd think "What a piece of shit!"

    Why is stdout (or Console in this case) any different? Maybe you're writing a CLI app that uses stdout to communicate with a process; if your shared library is writing to stdout for no good reason, you could easily fuck things up, undermining the reusability of your library.

    Agree with all of but fail to see why this makes using std I/O better or worse done in a DLL than doing so in an EXE or why it should be forbidden, which are the two things I took issue with.

    Using std I/O is simple and crude and there are always better ways to accomplish it. That said, std I/O is the norm in Unix derivatives that run half the internet and about a billion smartphones, so it can't be all that bad. Personally, I apply std I/O (i.e. Console class) in development tools for personal and team use. Mostly, to transform files, to debug and to make release builds. Such tools use std I/O for a good reason. Doing something for no good reason is a WTF, period, not limited to std I/O.

    I'm not arguing against using std I/O, I'm arguing against using std I/O in a shared library. If a library needs access to something like stdout, then the linking executable should be required to provide a stream (or equivalent). That way the executable can decide where the library writes, just as the user should be able to decide where the executable writes.



  • @pkmnfrk said:

    @morbiuswilters said:
    @ShatteredArm said:
    FTR, Console is only referenced in our test projects, which you are forced to make separate projects, are compiled down to DLLs, and would be totally idiotic to share.

    So an edge case which has already been brought up. We know there are cases that UI is required in DLLs (plugins, testing, UI frameworks). The question is: why is it being allowed in normal DLLs? Are you telling me this isn't something that could simply be fixed with a compiler directive? I mean, you don't seem to disagree that a normal application shouldn't be directly accessing UI from a library, correct?

    Why does it even need fixing? How much money are we losing by not having this compiler directive? How much money would we lose by having it, setting it, and then trying to do something that it forbids and not realizing what the problem is? How much money would Microsoft have to spend to spec, implement, test, document and deploy this feature? Are there actually problems that are best solved by changing the compiler, rather that using a blunt object?

    In my opinion, the answer to the yes/no questions above are "no", and the numeric questions are "very little", "more than the problem it's solve", and "more than the problem it's solve" respectively.

    I'm not advocating doing this, but it seems like a pointless rule that doesn't actually help anything. It's like a law that says that you may not shut off water mains in cities: Sure, it's a bad idea to do this in general, but you're not going to do it anyway, and sometimes, in edge cases, you DO have to do it, and have no other choice.

    I think that's a lousy metaphor. Regardless, try linking a shared library that makes assumptions about being able to write to stdout when you really need stdout to be left alone. Here's a similar situation: should a shared library catch its own exceptions and then exit()? Would you consider a library that did that to be severely broken?



  • @Scarlet Manuka said:

    @blakeyrat said:
    Wow. Worst metaphor? I think so!

    Yes, according to TDWTF forum guidelines it should have been a car metaphor.

    Screwing around with global state in a shared library is just like a car stereo which controls the throttle.



  • @morbiuswilters said:

    @Scarlet Manuka said:
    @blakeyrat said:
    Wow. Worst metaphor? I think so!

    Yes, according to TDWTF forum guidelines it should have been a car metaphor.

    Screwing around with global state in a shared library is just like a car stereo which controls the throttle.

    A long time ago I had that feature in my Chevrolet Celebrity 86: whenever I would power on the radio, the car would start stalling and bucking, then stop. The theory was that there was an electrical/wiring problem that caused the MAP sensor (or something like that) to go nuts, a problem allegedly made worse because someone clever had replaced fuses with nails otherwise they blew all the time when the wipers were running.



  • @morbiuswilters said:

    I'm not arguing against using std I/O, I'm arguing against using std I/O in a shared library. If a library needs access to something like stdout, then the linking executable should be required to provide a stream (or equivalent). That way the executable can decide where the library writes, just as the user should be able to decide where the executable writes.

    Confession: I use std I/O in shared libraries. Beat me up and explain how to improve this.

    The system consists of about 50 DLL and  6 entry points (EXE or otherwise). It can be deployed for a variety of functional applications in a variety of UI.

    The DLL are organized in a matrix. On one axis in technical layers: data access, number cruncing, statistic analysis, services, UI rendering, configuration, logging, etc. On another axis in functional layers: generic utilities, business logic, modeling, customizations, plug-ins, etc. The majority of the DLL can be run in any UI (or no UI at all). Only DLL dedicated to rendering UI are specific to that UI.

    The system can be deployed in six environments: as a web app, as a silvelight applet, as a win forms app, as a service, as a test app and as a CLI app. The entry points are very slim: they only load the main business logic DLL, based on configuration, and then run the main UI DLL applicable the environment. Everything else is done in shared libraries.

    Std I/O is used in two ways.

    1. One DLL is dedicated to logging. It has logging categories and severity. Not satisfied with standard tools in the market, it is a re-invented wheel that can log to a variety of devices: files, databases, MS event viewer, HP openview, email, SMS, stderr or stdout. The destination depend on category and severity of the logged message and the IT environment. This is configured by the sys admin. It bootstraps autonomouly and by design it has more authority then the EXE as to where and how it logs. This reflects the requirement that a sys admin (an IT person) has more authority on logging than an app admin (usually a business person).

    A logger that would require a stream parameter, as you suggest, makes for less capable and more complex system. Logging would be practically unconfigurable. Logging to non-streams (email, SMS, event monitors) would be impossible. The EXE would need to pass a stream parameter to every method in every class in every DLL, and so forth down the chain because any method might some day want to do some logging.

    2. I'm not a big proponent of unit testing and piss on tools like NUnit but do apply testing to numeric algorithms, some of which are internal. So some DLL come with embedded unit tests. The test methods use stdout to indicate what they test, the input, the output. The DLL have one public test entry point that runs all the internal tests. To test a particular unit, one sets up data in a DB, uses the test app to run the public test of the DLL that contains the unit and pipes the output to a grepper that fishes out the results relevant to the unit. This can be done in development and in production. Std I/O makes this very easy, both to write code and to run tests.

     



  • @JvdL said:

    Confession: I use std I/O in shared libraries. Beat me up and explain how to improve this.

    No.

    Look, if you agree with my viewpoint, then fix your own goddamned code. If not, then don't.

    If you agree and want me to fix it, pay me large amounts of money to do it. If Morbs wants to advise you for free, that's his prerogative I guess.

    Those are your options.


Log in to reply