|
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.
|
|
|
|
|
raddevus wrote: 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.
Like a decorator..
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.
|
|
|
|
|
Eddy Vluggen wrote: Like a decorator..
cue Madonna ...touched for the very first time...
 I could not pass that up.
Ignoring the bad joke (if possible) I think your point is really interesting, because it is like a decorator.
Also, in an effort to completely beat this dead horse, how about the following addition?
If, nothing else, the added method has a great name : see SpaceOut.
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:D3} ");
}
return outVal;
}
public static String SpaceOut(this string @inVal){
StringBuilder spacedItem = new StringBuilder();
foreach (Char c in @inVal){
spacedItem.Append($" {c} ");
}
Console.WriteLine(spacedItem.ToString());
return @inVal;
}
}
Now you can do this:
"What up!"
.Tee(Console.WriteLine)
.SpaceOut()
.GetBytes()
.DisplayBytes()
.Tee(Console.WriteLine);
And you will get the following:
What up!
W h a t u p !
087 104 097 116 032 117 112 033
Additionally interesting (or not) is that SpaceOut simply passes the input string along with no change since you only want the input to be printed with the extra spaces but don't want the output altered in this case.
I got a million of 'em!
|
|
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
