If an error message falls in a forest...
-
@morbiuswilters said:
@SEMI-HYBRID code said:
Calling console is not a fucking bug. If it causes it to throw an exception, etc., then yes, it's a bug. Is it stupid? Of course, but it's not a bug. At least not by any normal definition.@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.
afaik you can theoretically have your whole application with all the forms and logic coded in DLL, with the actual .exe just making it run by calling some function along the lines MyDll.RunApp().
i once coded a custom electronic trading strategy system, which was done by coding a C# dll and then sticking it into the trading app. i needed to see some debug info and have many extra settings, so i made the dll instantiate a console and a winforms form in the Init() function that the trading app was calling when starting up the strategy. it worked with no problems at all.
He's not saying you can't do that; he's saying it's wrong. And, so far, I haven't seen any good argument to refute his claim.
Let me ask it a different way: if the line just before Console.WriteLine, he wrote the exception to a logger, is it still a bug? Why is it a bug? Again, I'd remove it because it's just stupid to have there, but technically, it is not incorrect.
-
First of all:
What if you decide to put your awesome Text User Interface framework in a library so that other console applications may use them?
Explication of why it compiles, what should be so that it wouldn't, and how it would solve both problems:
The Console class is in one of the two "core" assemblys: mscorlib.dll and system.dll. That's why building a DLL doesn't reject the Console reference (there isn't an attribute "ExesOnlyAttribute" either).
The Console class should be in a separate assembly that a DLL doesn't reference by default. It would solve both problems because if you make a DLL that actually has to do with the console, you can explicitly reference that assembly.
-
Why did you remove your original bit about preventing developers from using pointers? Just because it would have been stupidly easy to refute? Aw.
@C-Octothorpe said:
Calling console is not a fucking bug.
No, but it could be a bug. Using the Console in a shared library is almost certainly a bug. I love repeating myself.
@C-Octothorpe said:
Let me ask it a different way: if the line just before Console.WriteLine, he wrote the exception to a logger, is it still a bug?
Depends. Was the logger passed to the library from the calling code? If so, then it's fine. If not, then not. I love repeating myself.
-
@Helix said:
blakeyrant is running to run the worlds first nanny-state compiler
Clearly you've never heard of Haskell. ;)
-
@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.
i wholly agree. which turns us (or at least me) back to the question, what in the code snippet in OP made you assume the DLL haven't actually prepared the console for use* in its init function prior to assuming it exists and is usable.
to me, this discussion went kind of offtopic when we concentrated on the console itself. i consider handling the exception in the DLL (at least in this specific way) to be a bad idea/worse than just letting it bubble up to the app itself, but that doesn't make the use of console itself from DLL stupid. as one wise man said a few times , back in the old days, programmers were trusted to know what they were doing/to do the right thing. and it's an issue of programmers, not language/api designers that they mostly can't be trusted in this way anymore. moreover, language/api designers preventing programmers from shooting themselves in the foot doesn't help this, but makes the issue worse. our apps should be let to crash and burn and explode in the most horrible manner if we screw up, otherwise how will we learn that we're doing it wrong™ and how to do it right™ ?
*which may mean creating it in an environment where it can be created, aquiring its handle in an environment where it is static, or just writing to it in an environment where the first write does all the necessary setup stuff (if such environments exist)
-
@blakeyrat said:
I think the critics here are disagreeing with me because they see "Blakeyrat" in the name field, and (hopefully!) not because they genuinely feel that my idea is a bad one.
i'm not good with remembering names so i don't (pre)judge people on forums based on their nick unless it's fun in the specific occasion, so yes, this was a part of the reason, but not an important one.
-
@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.
Why are you so hell-bent on this idea of a shared library? Are you conflating dynamically-linked libraries with shared libraries? I think it's a safe bet that 99% of DLLs out there are used in exactly one piece of software.
Your insistence that using Console in a DLL is always wrong simply paints you as one of those overly-opinionated morons who prattle on about "best practices" but couldn't code their way out of a cardboard box. In the case of Console, you're wrong because Console is not a UI, but a specific stream, which can be redirected to something other than an actual console window (there are much better ways to do this than Console, but I'm just pointing out that Console is not just "a UI element").
Remember, kids: if someone takes a strong, unyielding position on something (especially if it's something frivolous, like Console references), that person is probably an idiot. This rule applies to everything from software, to politics, to philosophy, etc.
-
@ShatteredArm said:
In the case of Console, you're wrong because Console is not a UI,
Yes it is. This is the point at which I declare you an idiot, and tell you to go dig ditches for a living because you're obviously not equipped for writing software.
-
@blakeyrat said:
Why did you remove your original bit about preventing developers from using pointers? Just because it would have been stupidly easy to refute? Aw.
No, because it would have taken this more off-topic than it already is, but I'm sure you knew that already.@blakeyrat said:No, but it could be a bug
I love this. You're so convinced it's a bug, but it's not. You're talking about IOC, which is a fucking design decision and is just slightly outside the domain of the compiler/IDE's responsibility. Would you also expect the compiler/IDE to tell you that placing the last name field before the first name field is bad, so every time you build, it throws up that helpful warning?
Don't get me wrong, I do see what you're saying that it's likely a bug and except for certain edge cases, you shouldn't do it. The problem I have with what you're saying is that it should fall onto the shoulders of the compiler/IDE. I'd rather have the compiler generate build errors when fuckwits write variable names like sName, or s1, s2, etc.
-
@blakeyrat said:
@ShatteredArm said:
In the case of Console, you're wrong because Console is not a UI,
Yes it is. This is the point at which I declare you an idiot, and tell you to go dig ditches for a living because you're obviously not equipped for writing software.
No, it's not. Just look up the official msdn documentation on the Console class:
Console.Write Method (System)
Writes the text representation of the specified value or values to the standard output stream.
All Console.Write does is write to the standard output stream. The standard output stream may or may not be written to the console. If you want proof of that, look up the following MSDN entry:
http://msdn.microsoft.com/en-us/library/system.diagnostics.process.standardoutput.aspx - How to capture the standard output from a spawned process.
-
@Jaime said:
I won't argue that it makes sense to access the console from a DLL, but there are some common and useful patterns where DLLs create UIs. Applications that have a plug-in system need to load the plug-in into the current process and if the plug-in is a wizard or a property page, then its whole purpose in life is to display a user interface. Sometimes the DLLs are masked a bit - for example, .ocx files (COM controls) are really just COM DLLs that implement a specific interface. Sometimes, they have a plain DLL file extension, like MMC snap-ins (example here).
Those seem like reasonable examples (and thanks for actually coming up with examples). It seems like this could be addressed by having two kinds of DLLs: functional and interface, with the compiler making a distinction between the two and not permitting UI libraries to be linked into functional DLLs.
And I still don't see the need for Console in any DLL. Windows isn't a CLI system so it doesn't need Console for creating UIs. Most likely the only reason people use Console is for lame anti-debugging, which definitely does not belong in any DLL.
-
@SEMI-HYBRID code said:
we may have different definitions of "doing stuff" then, because to me "displaying the data" falls into this cathegory just fine. besides, what is DirectX? Managed DirectX? OpenGL? And about every other presentation LIBRARY out there? worse than that, these DLLs interface directly with your hardware (as a fuckload of other does), making assumptions and/or requirements about its capabilities, which to me would be even worse than making a simple assumption that (software) console is present. if the reasoning behind why having DLL handle presentation layer (or using one) would be right, then innumerable libraries would become "incorrect", or unusable/futile, in a pursuit to make them "correct". including all the drivers that your computer uses.
I think you're taking things a bit far. To me it was obvious Blakey wasn't saying that things like DirectX shouldn't be in libraries, nor that the .NET UI code shouldn't be in libraries, and not even that third-party UI libraries (shudder) shouldn't be DLLs.. he's saying that normal applications should not be cramming UI into DLLs. Now, some good counter-examples have been produced (like systems that load all of your code as a plugin DLL) but those seem like exceptions that could easily be accounted for.
-
@that really other guy said:
OK, quick 2 cents... everything has stdout available....that is what Console is a wrapper for...
(Stdout, stderr and stdin)Booo... editing on android is aweful
.
I'm not even sure that's correct on Windows, but it definitely isn't on Unix: you can close those fds. And even then, those descriptors do different things in different contexts--in most CGI implementations a library that blithely writes to stdout is going to fuck up the output stream. Same thing for inetd programs.
-
@C-Octothorpe said:
@morbiuswilters said:
@blakeyrat said:
Christ, if you're going to give blackey a beejer, at least have the decency to not do it in public...Jesus fucking shit, do you people ever turn it off? Ever?
I suspect most of them are Irritation Vampires who feed on the irritated feelings of Normals.
But the thrill of getting caught is, like, 99% of the fun.
Okay, fine, 100%.
-
@C-Octothorpe said:
Calling console is not a fucking bug. If it causes it to throw an exception, etc., then yes, it's a bug. Is it stupid? Of course, but it's not a bug. At least not by any normal definition.
Let me ask it a different way: if the line just before Console.WriteLine, he wrote the exception to a logger, is it still a bug? Why is it a bug? Again, I'd remove it because it's just stupid to have there, but technically, it is not incorrect.Shouldn't a logger be passed into a DLL, too? Regardless, what's "stupid" about logging an exception? And finally, how is having Console there stupid if it's not incorrect? And it is incorrect, because there are contexts where writing to the Console would fuck things up.
-
@SEMI-HYBRID code said:
as one wise man said a few times , back in the old days, programmers were trusted to know what they were doing/to do the right thing. and it's an issue of programmers, not language/api designers that they mostly can't be trusted in this way anymore. moreover, language/api designers preventing programmers from shooting themselves in the foot doesn't help this, but makes the issue worse. our apps should be let to crash and burn and explode in the most horrible manner if we screw up, otherwise how will we learn that we're doing it wrong™ and how to do it right™ ?
People still produced shitty software under The Old Way. And fewer standards and warnings and best practices meant that even the best programmers often produced unmaintainable shit, simply because they had to re-discover all of this on their own. It's like "Remember when doctors could just treat their patients and didn't have to worry about keeping up-to-date with training and accreditation and worrying about a malpractice review boards?" Shit's there for a reason.
I don't totally disagree, though; I think having smart programmers is far, far more important than having warnings in your tools (but it's not an either-or and you know it). Regardless, 95% (possibly more--I'm not convinced it's not 100%) of programmers are bad at what they do and M$ has to make their tools work for those companies that are unfortunate to have some bad programmers.
-
@ShatteredArm said:
@blakeyrat said:
@ShatteredArm said:
In the case of Console, you're wrong because Console is not a UI,
Yes it is. This is the point at which I declare you an idiot, and tell you to go dig ditches for a living because you're obviously not equipped for writing software.
No, it's not. Just look up the official msdn documentation on the Console class:
Writes the text representation of the specified value or values to the standard output stream.
All Console.Write does is write to the standard output stream. The standard output stream may or may not be written to the console. If you want proof of that, look up the following MSDN entry:
http://msdn.microsoft.com/en-us/library/system.diagnostics.process.standardoutput.aspx - How to capture the standard output from a spawned process.
That seems like really flimsy reasoning. So you're saying if there was a way to suppress or redirect dialog boxes from an application then those would stop being a UI component? And even if we accept that stdout isn't a UI element, that doesn't change the fact that it's a static resource that can cause problems when interacted with, so directly referencing it in a shared library is problematic.
-
@C-Octothorpe said:
You're talking about IOC, which is a fucking design decision and is just slightly outside the domain of the compiler/IDE's responsibility.
It is IOC, technically, but not relying on writing to stdout in shared libraries far predates the modern concept of IOC. As I've said, writing to stdout from a library can call all sorts of problems and should be the exception rather than the rule.
@C-Octothorpe said:
I'd rather have the compiler generate build errors when fuckwits write variable names like sName, or s1, s2, etc.
These aren't mutually exclusive.
-
@morbiuswilters said:
@that really other guy said:
OK, quick 2 cents... everything has stdout available....that is what Console is a wrapper for...
(Stdout, stderr and stdin)Booo... editing on android is aweful
.
I'm not even sure that's correct on Windows, but it definitely isn't on Unix: you can close those fds. And even then, those descriptors do different things in different contexts--in most CGI implementations a library that blithely writes to stdout is going to fuck up the output stream. Same thing for inetd programs.I'm not 100% confident, but I'm 99% sure that's not true on Windows. Windows Services don't have a "stdout" or, if they do, it's redirected to a blackhole like in the C# "there's no Console available" handling. That applies regardless of language. (Think about it: if Windows Services had a "stdout", where would the text appear?)
-
I believe the CRT systematically creates the POSIX descriptors and standard C streams on the Win32 "standard handles" regardless of whether these handles are valid, but writing to them probably yields an error (unless you manually open a file or something).
Plus, console handles are not handles to file: They are handles to a "console input buffer" (in) and a "console screen buffer" (out, error). That said, they accept the regular ReadFile()/WriteFile() methods; at least, I know the output does.
PS: Blakey, you didn't answer my question.
-
Console.write in C# = System.out.ln in java.
Is perfectly OK to be called in an exception handler in java.
-
What we don't see:
public static void Main(string[] args) { using(var log = new StreamWriter("output.log")) { Console.SetOut(log); KnownBuggyAssembly.DoSomethingThatOutputsToTheConsole(); //etc } }
-
@Medinoc said:
PS: Blakey, you didn't answer my question.
This question?
@Medinoc said:
What if you decide to put your awesome Text User Interface framework in a library so that other console applications may use them?
-
The problem with the C# Console is that it cannot be passed. It's a static class, and passing the streams in it just doesn't cut it if you want fancy stuff like color.
It cannot be created either, since a process is limited to zero or one console.
-
@Medinoc said:
As much as this pains me, I'm starting to agree with blakey and morbs. Although it should be incorrect to do this, the implementation of these safeguards would be nearly impossible (imagine false positives/negatives, dynamically resolved references, etc.). I think my defensive "shit, I'm going to be asked to write this" side kicked in...The problem with the C# Console is that it cannot be passed. It's a static class, and passing the streams in it just doesn't cut it if you want fancy stuff like color.
It cannot be created either, since a process is limited to zero or one console.
-
@blakeyrat said:
I think the critics here are disagreeing with me because they see "Blakeyrat" in the name field, and not because they genuinely feel that my idea is a bad one.
You just described the entire Internet.
-
@morbiuswilters said:
That seems like really flimsy reasoning. So you're saying if there was a way to suppress or redirect dialog boxes from an application then those would stop being a UI component? And even if we accept that stdout isn't a UI element, that doesn't change the fact that it's a static resource that can cause problems when interacted with, so directly referencing it in a shared library is problematic.
Your analogy is faulty. A dialog box is different than an output stream. The dialog box is an implementation; it's a specific way of displaying output. It's not an interface. stdout, on the other hand, is simply an output stream, which is typically directed to the console, but can be easily read by a different process and displayed however you see fit. It doesn't have a built-in display mechanism.
Also: which problems does interacting with Console cause? Nothing happening is not a problem; I can write to a specialized (static resource) logging framework that is configured to do nothing, and most would correctly argue that the problem is incorrect configuration, and not the actual logging framework. Hell, if you want, you could write all your logs to Console, and make a custom logging framework that reads stdout in a separate thread and disposes of them as it wishes. There are plenty of better ways to accomplish the same thing, but it underscores the fact that stdout is just a stream, and not a UI element.
-
@Nagesh said:
Console.write in C# = System.out.ln in java.
Is perfectly OK to be called in an exception handler in java.
Maybe if you're some incompetent, off-shore developer who wouldn't know his ass from a hole in the ground.
-
I already agree with you when it comes to internal workings anyway, and already follow this principle.
Especially if console helper libraries are considered "nitpicky edge cases".
-
@ShatteredArm said:
@morbiuswilters said:
That seems like really flimsy reasoning. So you're saying if there was a way to suppress or redirect dialog boxes from an application then those would stop being a UI component? And even if we accept that stdout isn't a UI element, that doesn't change the fact that it's a static resource that can cause problems when interacted with, so directly referencing it in a shared library is problematic.
Your analogy is faulty. A dialog box is different than an output stream. The dialog box is an implementation; it's a specific way of displaying output. It's not an interface. stdout, on the other hand, is simply an output stream, which is typically directed to the console, but can be easily read by a different process and displayed however you see fit. It doesn't have a built-in display mechanism.
Also: which problems does interacting with Console cause? Nothing happening is not a problem; I can write to a specialized (static resource) logging framework that is configured to do nothing, and most would correctly argue that the problem is incorrect configuration, and not the actual logging framework. Hell, if you want, you could write all your logs to Console, and make a custom logging framework that reads stdout in a separate thread and disposes of them as it wishes. There are plenty of better ways to accomplish the same thing, but it underscores the fact that stdout is just a stream, and not a UI element.
It's a stream that is primarily meant for writing to a goddamn text-based UI. Your distinction between a dialog and stdout seems ridiculous; I could simply apply your reasoning and say that a dialog is really just an abstract object and doesn't become a UI element until it is rendered by the OS, output to a screen and viewed by a user. Can you do things other than output to a screen with stdout? Sure. Which is why you shouldn't assume that it's always there as a UI element for your little debug messages. It may be outputting to a CGI or God knows what else.
You completely ignored my second point which is even if you don't consider it UI writing to it is still a problem because it's not your resource and you don't know what side-effects writing to it from a shared library might cause. (Of course, someone will then say "Well, what if you're just shoving your application code into a shared library and it's not shared with anything else so the resource kind of belongs to it?" The problem there being that you have a lot of portability problems if you do want to reuse your library--why not just do things correctly in the first place?)
-
@morbiuswilters said:
You completely ignored my second point which is even if you don't consider it UI writing to it is still a problem because it's not your resource and you don't know what side-effects writing to it from a shared library might cause. (Of course, someone will then say "Well, what if you're just shoving your application code into a shared library and it's not shared with anything else so the resource kind of belongs to it?" The problem there being that you have a lot of portability problems if you do want to reuse your library--why not just do things correctly in the first place?)
Seconded. I have seen the mess that anything can do to cout in C++. Whose bright idea was it to keep the formating info that can change from one data to another in the stream itself?
-
@Nagesh said:
Console.write in C# = System.out.ln in java.
Not heard of that in Java. It sounds a bit like
System.out.println(), but then you're the java expert and not I, so I'll bow to your greater experience.@Nagesh said:
Is perfectly OK to be called in an exception handler in java.
... and there was me foolishly thinking logger frameworks were the way forwards when I could have just squirted my messages to this
System.out.Inof yours.
-
@Cassidy said:
Not heard of that in Java. It sounds a bit like
System.out.println(), but then you're the java expert and not I, so I'll bow to your greater experience.He said "java" not "Java". Clearly "java" is a cheap Indian knock-off of "Java", just like Nagesh is a cheap Indian knock-off of a real programmer.
@Cassidy said:
... and there was me foolishly thinking logger frameworks were the way forwards when I could have just squirted my messages to this
System.out.Inof yours.Dear Cassidy,
Please refrain from ever using the word "squirted" again. Thank you.
Sincerely,
TDWTF Forums
-
@morbiuswilters said:
Please refrain from ever using the word "squirted" again.
Sharn't. Dhromed blushing is your problem, not mine.
-
@morbiuswilters said:
It's a stream that is primarily meant for writing to a goddamn text-based UI. Your distinction between a dialog and stdout seems ridiculous; I could simply apply your reasoning and say that a dialog is really just an abstract object and doesn't become a UI element until it is rendered by the OS, output to a screen and viewed by a user. Can you do things other than output to a screen with stdout? Sure. Which is why you shouldn't assume that it's always there as a UI element for your little debug messages. It may be outputting to a CGI or God knows what else.
You completely ignored my second point which is even if you don't consider it UI writing to it is still a problem because it's not your resource and you don't know what side-effects writing to it from a shared library might cause. (Of course, someone will then say "Well, what if you're just shoving your application code into a shared library and it's not shared with anything else so the resource kind of belongs to it?" The problem there being that you have a lot of portability problems if you do want to reuse your library--why not just do things correctly in the first place?)
So it's primary meant for writing to a text-based UI, but you can't assume it's there as a UI element. Got it.
stdout is an interface. It is well-defined what it is there for, even if you can't assume it will be used in a certain way. Thus, you can write to stdout if you damn well please, and you don't have to care about what happens with the result. It's no longer your responsibility. If you're doing something where the result needs to be handled in a certain way, then you'd be an idiot to use a stream you don't have direct control over.
You've stated at least twice that writing to some well-defined stream can have side effects... It might be interesting to know if you would, perhaps, point out what one of these side effects are. Or what these portability problems are (portability is actually one of the benefits of using a standard stream). The fricking point of having an interface is so you don't have to worry what, if anything, it does when you write to it.
Finally, consider a hypothetical environment wherein standard output is the only stream made available to a .net program. Such an environment would be impossible to use if your nazi compiler doesn't allow you to write to stdout. Sure, there is no foreseeable reason for such an environment to exist and use .net, but the "let the developers tell .net what it should do" is a much better paradigm than "make .net determine what the developers are allowed to do." The latter assumes that all problems that may be encountered have already been discovered.
Again, I'm not arguing that using Console in a DLL is often, or even ever, an appropriate solution to any technical problems... Just that it's totally moronic to take such an unyielding philosophical position on something as frivolous as using Console.Out in a DLL. Such positions are for the type of buffoons who probably also think there's an obvious and failsafe way to painlessly shore up the economy. The world is too complex for such blanket idealism.
-
@ShatteredArm said:
So it's primary meant for writing to a text-based UI, but you can't assume it's there as a UI element. Got it.
Yes. Is there anything incorrect about that?
@ShatteredArm said:
You've stated at least twice that writing to some well-defined stream can have side effects... It might be interesting to know if you would, perhaps, point out what one of these side effects are. Or what these portability problems are (portability is actually one of the benefits of using a standard stream). The fricking point of having an interface is so you don't have to worry what, if anything, it does when you write to it.
I already mentioned two (CGIs and inetd programs, both of which use stdin and stdout to communicate with network clients--if your dumbass library writes to them it will fuck shit up).
@ShatteredArm said:
Finally, consider a hypothetical environment wherein standard output is the only stream made available to a .net program.
What in the fuck are you talking about? Nobody is saying programs shouldn't write to stdout you dipshit, we're saying shared libraries should not be writing directly to stdout but instead should take a stream as an argument. That stream can be stdout, if the executable likes, but that is not a decision that is up to the library. Libraries should not simply assume that they can write to a global resource like stdout.
-
@SEMI-HYBRID code said:
we may have different definitions of "doing stuff" then, because to me "displaying the data" falls into this cathegory just fine. besides, what is DirectX? Managed DirectX? OpenGL? And about every other presentation LIBRARY out there? worse than that, these DLLs interface directly with your hardware (as a fuckload of other does), making assumptions and/or requirements about its capabilities, which to me would be even worse than making a simple assumption that (software) console is present. if the reasoning behind why having DLL handle presentation layer (or using one) would be right, then innumerable libraries would become "incorrect", or unusable/futile, in a pursuit to make them "correct". including all the drivers that your computer uses.
Funnily enough, to have DirectX use the UI you have to give it a window handle (EG: Your display code has explicitly said "Please, draw all over this part of the UI"). OpenGL I don't have a great deal of experience with, but if I recall correctly once again you have to provide it with some kind of window or explicitly instruct it to create it's own. This falls under the "The UI has explicitly asked the DLL to do this, therefore go nuts" heading. As far as interfacing directly with the hardware... that's hardly the same as the UI. Unless you're referring to input hardware such as the keyboard etc, in which case most input libraries from these require the UI to explicitly tell them they want them to take over that input device. So those fit within the paradigm me and blakey were suggesting.
I don't think anyone's trying to say that DLL's should never touch the UI, moreso that they should not do so without the application explicitly requesting that they do and that wherever possible this interaction should be via an abstraction layer (Which in some cases like 3D graphics can not be an option due to performance).
@SEMI-HYBRID code said:
okay, then there's a question - does writing to console prevent the library from being a black box/working in a black box? how do you know the dll is not writing into console it has created for itself in the init function? what part of the snippet presented in the OP definitely says that it's using a console that it assumes is already there, created by someone else in advance?
Well, System.Console is a static class without a constructor in .NET, so I guess I'd have to say I don't know explicitly that this code hasn't already called SetOut on the standard console prior to doing this, but what I do know is that if the DLL in case of error without informing the application updates where the shared static class for writing to the console puts it's output then that would be even worse
-
If it falls in the forest, there ought to be logs anyway.
I'll get me coat.
-
It is println() and not ln(), but this is prehistory java app when log4j is not yet born.
-
@Nagesh said:
It is println() and not ln(), but this is prehistory java app when log4j is not yet born.
You could still have your own logging framework instead of just printing out. And regardless, even if System.out.println was your only option at one point, it isn't now so it's bad to be using it in a library.
-
I could, but will client pay for this?
-
@Nagesh said:
I could, but will client pay for this?
Sadly, no, customers rarely care about quality, which is why you have a job in the first place.
-
@Ibix said:
If it falls in the forest, there ought to be logs anyway.
This is quite possibly the worst pun I've seen in 2012... even if I've read a few Lawrence Block books, such as Burglars Can't Be Choosers or The Cancelled Czech. Shame on you.
-
@morbiuswilters said:
@ShatteredArm said:
Finally, consider a hypothetical environment wherein standard output is the only stream made available to a .net program.
What in the fuck are you talking about? Nobody is saying programs shouldn't write to stdout you dipshit, we're saying shared libraries should not be writing directly to stdout but instead should take a stream as an argument. That stream can be stdout, if the executable likes, but that is not a decision that is up to the library. Libraries should not simply assume that they can write to a global resource like stdout.
Again, "shared libraries" != "dynamically linked libraries." A small minority of .net DLLs are ever intended to be used by more than one application. blakeyrat's idealistic argument was that the compiler should prevent you from referencing Console within a class library.
Also, if writing to stdout breaks something, the WTF is with the broken application, not the library writing to stdout. If something written to a standard interface breaks your stuff, it is your responsibility to avoid using the library, not the author of the libary's responsibility to avoid writing to a standard interface.
-
@ShatteredArm said:
@morbiuswilters said:
@ShatteredArm said:
Finally, consider a hypothetical environment wherein standard output is the only stream made available to a .net program.
What in the fuck are you talking about? Nobody is saying programs shouldn't write to stdout you dipshit, we're saying shared libraries should not be writing directly to stdout but instead should take a stream as an argument. That stream can be stdout, if the executable likes, but that is not a decision that is up to the library. Libraries should not simply assume that they can write to a global resource like stdout.
Again, "shared libraries" != "dynamically linked libraries." A small minority of .net DLLs are ever intended to be used by more than one application. blakeyrat's idealistic argument was that the compiler should prevent you from referencing Console within a class library.
Also, if writing to stdout breaks something, the WTF is with the broken application, not the library writing to stdout. If something written to a standard interface breaks your stuff, it is your responsibility to avoid using the library, not the author of the libary's responsibility to avoid writing to a standard interface.
Actually, I will agree with them on one point: If your library is designed to be used by more than your own project (in which case you can do whatever you like), then the onus is on you, the library designer, to not rely on global state to the extent that can be reasonable. Using stdout as your logging mechanism is fine for debugging, but your clients might be using it for something else.
But, that said, if the library is designed for internal use only, then you can do whatever you want, including changing global state, scribbling on stdout, opening windows, etc, because you control both sides of the library/application relationship.
-
@ShatteredArm said:
Again, "shared libraries" != "dynamically linked libraries." A small minority of .net DLLs are ever intended to be used by more than one application.
If those classes are only used by one application, why the fuck are they in a .DLL in the first place? Why not just put those classes in the application itself and save everybody headaches?
Warning: incredibly contrived edge-case rebuttals to my statement below -\/
-
@ShatteredArm said:
Again, "shared libraries" != "dynamically linked libraries." A small minority of .net DLLs are ever intended to be used by more than one application. blakeyrat's idealistic argument was that the compiler should prevent you from referencing Console within a class library.
Why are you writing a DLL that violates the principles of shared libraries?
@ShatteredArm said:
Also, if writing to stdout breaks something, the WTF is with the broken application, not the library writing to stdout. If something written to a standard interface breaks your stuff, it is your responsibility to avoid using the library, not the author of the libary's responsibility to avoid writing to a standard interface.
No, you are wrong and I'm starting to suspect a fucking idiot. stdout belongs to the application, not the library. And if your definition of "broken application" includes CGI and inetd, then you are TRWTF.
-
@blakeyrat said:
@SEMI-HYBRID code said:
First of all, I don't give a shit about MVC and I generally don't use it. That out of the way...we may have different definitions of "doing stuff" then, because to me "displaying the data" falls into this cathegory just fine. besides, what is DirectX? Managed DirectX? OpenGL? And about every other presentation LIBRARY out there? worse than that, these DLLs interface directly with your hardware (as a fuckload of other does), making assumptions and/or requirements about its capabilities, which to me would be even worse than making a simple assumption that (software) console is present. if the reasoning behind why having DLL handle presentation layer (or using one) would be right, then innumerable libraries would become "incorrect", or unusable/futile, in a pursuit to make them "correct". including all the drivers that your computer uses.
i can't help myself but see this argument as a battle between "MVC IS TEH ONLY WAY!" and "what's wrong with using the tools at your disposal in a way you can use them to produce desired results?
I've been thinking about this this morning, and so I've come up with a rephrasing that should make even the most dickweedy of the dickweeds happy:
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.
This excuses WinForms and DirectX, since they create their UI (at the urging from the calling code) before displaying anything on them, and also still demonizes shared libraries that contain the Console class, or call MessageBox.Show() in the middle of a function.
I'm sure you're all itching at the bit to pedantic dickweed away and fine some obscure edge-case that this phrasing doesn't cover. Go for it. Knock yourself out. I'll be over here getting wasted on whiskey.
I prefer black lager. whiskey just makes me more pissed off
-
@blakeyrat said:
@ShatteredArm said:
Again, "shared libraries" != "dynamically linked libraries." A small minority of .net DLLs are ever intended to be used by more than one application.
If those classes are only used by one application, why the fuck are they in a .DLL in the first place? Why not just put those classes in the application itself and save everybody headaches?
Warning: incredibly contrived edge-case rebuttals to my statement below -\/
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. Have you ever built a .net application in your life?
I wouldn't consider something that is done in 99% of cases to be a contrived edge case.
-
@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"?
