|
Chris Maunder wrote: and using something like UnsupportedFormatException is too hard?
Just be glad its not the usual, "Error occurred", Good luck figuring it out.
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
|
|
|
|
|
Looks like it's the same reason why renaming an EXE to COM and trying to load it generates an "Out of memory" error: Implementation details leaking to the surface.
|
|
|
|
|
I mean, not really? COM files have a size limit because they behave different from EXE files (or rather, EXE files behave different, since COM is the original). When you try to load a COM file that exceeds this limit you're really running out of memory, before the code can even start to be executed.
Could they read the file size and predict that? they couldn't (or just didn't, hard to say with stuff this old) when COM files where actually being used, so the current included loaders also don't. You don't really want to mess with those kinds of legacy systems, specially when they are useless for current developments and the alternative doesn't share the concerns.
COM file - Wikipedia
|
|
|
|
|
Don't care, I always use
catch(Exception e){..} That always works
|
|
|
|
|
I was watching a very good intro to Functional programming on PluralSight (Functional Programming with C# | Pluralsight[^]) and the author / presenter created the following method (mine has altered var names).
public static class Helper{
public static T Tee<T>(
T @inVal,
Action<T> act){
act(@inVal);
return @inVal;
}
}
Now you can call that method like the following:
Helper.Tee("test", Console.WriteLine);
Helper.Tee(3.238, Console.WriteLine);
Helper.Tee (new {garbage="super"},Console.WriteLine);
Here's the output:
test
3.238
{ garbage = super }
It's loosely based on the following idea (why it's named Tee): tee (command) - Wikipedia[^]
Just thought it was an interesting example and it made me think differently about things.
After all these years of OOP I'm beginning to see the real value in the Functional paradigm*.
*Obviously the included sample is not a huge example of Functional programming in and of itself.
|
|
|
|
|
How is that any different from calling Console.WriteLine("test"); etc.?
It's just more code to call Console.WriteLine and you aren't chaining anything or using the Tee output
Even worse, an Action<T> assumes a side-effect because it doesn't return a value.
Or is Tee used to "hide" this side-effect?
If I read the wiki page I'd suspect Tee does the Console.WriteLine and you can pass in a File.WriteText or something similar, but even then I fail to see how Tee is helping you. You could just as well call both methods.
|
|
|
|
|
I like your questions because I'm learning the concepts and determining how these things are important too. And I can tell by your questions that you have more functional experience than I do.
Here's an example that may make more sense -- it's like a before and after test.
Helper.Tee(Helper.Tee(" _ before after _ ", Console.WriteLine)
.ToUpper().Trim()
.Substring(8,6),
Console.WriteLine);
That results in an output like the following:
_ before after _
AFTER
Because the Tee method returns the value methods can be chained just like the normal string methods and so you can see the BEFORE version of your string and then the AFTER version.
I don't know if that is helpful either, but it's interesting.
This was a very small portion of an example showing how to create fluent APIs.
|
|
|
|
|
This definitely looks like a case for an extension method[^].
" _ before after _ "
.Tee(Console.WriteLine)
.ToUpper().Trim()
.Substring(8, 6)
.Tee(Console.WriteLine);
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Ah, yes, that would be even better. Makes far more sense that way.
|
|
|
|
|
That was interesting to me so I altered the Tee method to make it an extension method.
Simply add the _this_ to the first param T and your code works now.
public static class Helper{
public static T Tee<T>(
this T @inVal,
Action<T> act){
act(@inVal);
return @inVal;
}
}
" _ before after _ "
.Tee(Console.WriteLine)
.ToUpper().Trim()
.Substring(8,6)
.Tee(Console.WriteLine);
|
|
|
|
|
Like Richard, I was thinking of an extension method.
What you have there is pretty hard to read, took me a while to figure out what it does (due to the nested Tee, which is not a very helpful name either).
I'm all for chaining though, that's what LINQ does too (which is pretty functional).
Applying functional principles (but remembering C# is not a functional language) really helped me write cleaner and more succinct code.
Although not everyone agrees with me, some people prefer their foreach loops and can't read lambda's
One thing I've learned, and taken to heart, a function has input and predictable output (no side-effects or state!).
At some point you're going to have state and output, of course, but that's reserved for special classes.
To give an example (from the top of my head, ignore bad practices such as public fields):
public class BadClass
{
public string s;
public void BadClass(string s)
{
this.s = s;
}
public void DoubleString()
{
s = s + s;
}
}
var bc = new BadClass("Hello");
bs.DoubleString();
Console.WriteLine(bc.s);
public class GoodClass
{
public void DoubleString(string s)
{
return s + s;
}
}
var gc = new GoodClass();
var s = gc.DoubleString("Hello");
Console.WriteLine(s); It's a bit contrived, but you'd be amazed at how often I've seen the BadClass implementation (equivalent) of this.
People just love their state and side effects.
But then again, I've worked on old VB applications with old VB programmers...
As coincidence would have it Packt offers a free Functional C#[^] eBook today, may be interesting (haven't read it myself).
|
|
|
|
|
Hi Sander,
Evidently PackT changes which book is free every day, so that one is no longer free.
cheers, Bill
«... thank the gods that they have made you superior to those events which they have not placed within your own control, rendered you accountable for that only which is within you own control For what, then, have they made you responsible? For that which is alone in your own power—a right use of things as they appear.» Discourses of Epictetus Book I:12
|
|
|
|
|
Yeah, that's why I said "today" yesterday
|
|
|
|
|
I just ask that, if you've no state, make the damn method static.
The amount of times I had to rewrite stuff because people fumbled around with instances of a stateless object and later added state to that object, breaking half the code depending on execution order is uncanny.
It's fine to be an instance method if you class has an immutable state. At least nobody would come and remove a const or readonly from a field without the knowledge that it would break everything... I hope...
|
|
|
|
|
Sander Rossel wrote: How is that any different from calling Console.WriteLine("test"); etc.?
It's just more code to call Console.WriteLine and you aren't chaining anything or using the Tee output
Using a Hello World example would be so much more useful!
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
What a weird, but interesting, idea.
I think a better example than
Helper.Tee("test", Console.WriteLine);
could be
string result = Helper.Tee("test", Console.WriteLine).ToUpper();
That shows the "T " character of that function more clearly: since it returns the input parameter, you can chain a few functions.
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
|
|
|
|
|
You are exactly correct about the return being the important part because it allows you to chain the methods. In another post I mentioned that you can do a "before and after" type of test which might look like:
Helper.Tee(Helper.Tee(" _ before after _ ", Console.WriteLine)
.ToUpper().Trim()
.Substring(8,6),
Console.WriteLine);
That results in an output like the following:
_ before after _
AFTER
|
|
|
|
|
this example is relatively convoluted and pointless.
you find better and common use of functional programming in LINQ to Object!
|
|
|
|
|
Yes, it does look that way...and I'm learning this stuff myself.
However, I've provided a slightly better example in reply to Sander at:
The Weird and The Wonderful[^]
That at least makes a bit of sense.
|
|
|
|
|
it's cute, you are learning new stuff. that is good.
The Tee code sample is contrived though, simply because it can be rewritten much more mean and lean like
var value = ...;
action(value)
it was, to put it bluntly, grossly over engineered, and should not be done in real work project!
However here is something like the given Tee function that could be more useful
public static class Helper
{
public static IEnumerable<T> Tee(this IEnumerable<T> enumerable, Action<T> action)
{
foreach (var e in enumerable)
{
action(e);
yield return e;
}
}
}
modified 19-Mar-18 8:58am.
|
|
|
|
|
It might help if you gave the method a name!
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
oops.. corrected!
|
|
|
|
|
Ohh...look...I've really gone crazy with this now.
public static class Helper{
public static T Tee<T>(
this T @inVal,
Action<T> act){
act(@inVal);
return @inVal;
}
public static Byte[] GetBytes( this String @inVal){
Byte [] outBytes = new Byte[@inVal.Length];
int loopCount = 0;
foreach (Char c in @inVal){
outBytes[loopCount] = Convert.ToByte(c);
loopCount++;
}
return outBytes;
}
public static String DisplayBytes(this byte[] inBytes){
String outVal = String.Empty;
foreach (Byte b in inBytes){
outVal += Convert.ToString($"{b} ");
}
return outVal;
}
}
Try it like this and you get before and after again:
"What up!"
.Tee(Console.WriteLine)
.GetBytes()
.DisplayBytes()
.Tee(Console.WriteLine);
Output looks like:
What up!
87 104 97 116 32 117 112 33
Well, it's fun.
|
|
|
|
|
It doesn't copy stdin to stdout. The only thing in common with "tee" is in the amount of parameters.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Yes, you are correct. I think the point that the author/presenter was attempting to make is that you can output the value and continue processing the value as input to yet another function.
That's why the author/presenter named the method Tee (which I hadn't seen before).
I looked it up and found the associated wiki article and just thought that was an interesting piece of history.
|
|
|
|