למה DoForEach לא קיים ב-LINQ?

חגי

@dovid
ניסיתי לבדוק באמצעות Queue ו-List, וקראתי להם בצורה הזו:

TestQueue t = new TestQueue();
Console.WriteLine(t.Select(t =>
{
    Console.WriteLine(t.i);
    return t;
}).Last().i);
TestList t2 = new TestList();
Console.WriteLine(t2.Select(t =>
{
    Console.WriteLine(t.i);
    return t;
}).Last().i);

בפועל זאת התוצאה:

got here 1
1
got here 2
2
got here 3
3
got here 4
4
got here 5
5
got here 5
5
got here 1
1
got here 2
2
got here 3
3
got here 4
4
got here 5
5
got here 5
5

ההנחה שלי היתה שזאת בדיקה טובה בגלל שselect לא חייב לרוץ על שום אלמנט חוץ מהאחרון, ובqueue אי אפשר לגשת לפי אינדקס.
אז אני מניח שהבדיקה שלי היא הבעייתית, למה בList לא היתה טעינה עצלה רק של הערך האחרון?

קומפיונט

@חגי תודה על התשובות המקצועיות.

אני לא יודע אם Enumerable ו-LINQ קשורים בהכרח אחד לשני, אבל בכל מקרה יש הרבה הרחבות במחלקה Enumerable שלא מקיימות את התנאי הזה, קח לדוגמא את ()ToArray שזו נטו חיסכון בקוד. אז אם כן שאלתי עדין במקומה עומדת מדוע 'חסרה' פונקציה שתעשה איטרציה על כל הרצף?

זה שיש את זה ב-List זה מחזק את השאלה מדוע לא הוסיפו את זה גם ל-Enumerable כמו שלדוגמה ()ToArray מופיע בשניהם.

ודרך אגב, הרעיון המרכזי ב-LINQ הוא להפסיק לכתוב "איך" ולהתחיל לכתוב "מה", וגם לפי זה ההיגיון הפשוט הוא היה להוסיף פונקציית עזר כדוגמת ForEach.

קומפיונט

@dovid כתב בלמה DoForEach לא קיים ב-LINQ?:

גם אני לעיתים מתחשק לי ForEach כמתודה במקום בלולאה, אבל אני לא מוצא לזה ייתרון שכלי, זה סה"כ נטיה רגשית לזרום יותר מידי עם תכנות פונקציונלי.

אני מסכים עם דבריך, אבל לפי זה מדוע המפתחים טרחו לכתוב את ההרחבה ()ToList?! לכאורה גם לה אין שום יתרון שכלי. כי אפשר לקבל את אותה התוצאה באמצעות הכתיבה הזאת:

var list = new List<int>(enumerable)

dovid

@חגי בשני המקרים, עצם הSelect הופך אותם חזרה לEnumerable חסר אינדקס.

dovid

@קומפיונט זה שעשו מתודה למרות שיש דרך נוספת לחיסכון של פעולה זו (שבבסיסה מחייבת לולאה פלוס משתנה) זה לא מחייב שיצרו פונקציה רק לחסוך לולאה נטו.
אני כעת חיפשתי בגוגל why linq not include ForEach ומצאתי תשובות עמוקות שקשורות לפילוספיה של LINQ, אתה מוזמן לקרוא אותם, אני לא כ"כ מתעמק.
בתכלס, אני חושב שאין בLINQ מתודת קיצור שחוסכת לולאה נטו.

קומפיונט

@dovid אבל ב-<>List זה כן קיים, אז משמע שיש לזה יתרון כלשהו.

dovid

@קומפיונט מצאתי תשובה רשמית של אריק ליפרט:
https://docs.microsoft.com/en-us/archive/blogs/ericlippert/foreach-vs-foreach
הוא בעצם אומר:
א. יש לזה מעט מידי תועלת
ב. לכל מתודה (בפרט מיותרת) יש עלות ונזק
ג. זה נוגד את הפרנציפ של כל המתודות בLINQ שהם לא משפיעות כלום על כלום רק מחזירות ערך.

(מצאתי את זה דרך פוסט בסטאק: Executing a certain action for all elements in an Enumerable)

בקשר לFoEach של List, זה לא כ"כ קשה למה עשו את זה, זה נחמד ויפה, אך מצאתי גם דיון ביתרונות מעשיים: https://stackoverflow.com/q/225937/1271037
הכי התחברתי לטקסט הזה:

List.ForEach() says what you want done. foreach(item in list) also says exactly how you want it done. This leaves List.ForEach free to change the implementation of the how part in the future. For example, a hypothetical future version of .Net might always run List.ForEach in parallel, under the assumption that at this point everyone has a number of cpu cores that are generally sitting idle.

קומפיונט

@dovid
אכן קראתי התשובה הוא מסביר שם נפלא למה ForEach אין מקומו ב-LINQ.
אבל עדיין יש כמה תמיהות כדלהלן:

בקשר לטענות הכותב:
א. למה דווקא ForEach מיותר וכי ה-ToList לא מיותר?! אדרבה, בעידן הנוכחי שהתכנות הפונקציונלי די פופולרי, קטע הקוד הבא יכול להיות מאוד אלגנטי:

Enumerable.Range(1, 20)
          .Select(n => n * 3)
          .Where(n => n % 2 == 0)
          .DoForEach(n => Console.WriteLine(n));

הדרך המקבילה ב-foreach אמורה להיות קצת יותר מעצבנת... ובפרט כשהשרשור של האופרטורים יותר ארוך מהדוגמה.

ב. כנ"ל.

ג. זה באמת הנקודה שהכי דגדגה לי, כי היות והערך המוחזר מ-ForEach הוא void יוצא שהיא המתודה היחידה שלא מחזירה ערך כלשהו. אבל גם על זה אפשר להתפלסף, כי הרעיון של ForEach זהה לרעיון של ToList ו-ToArray אלא שספציפית הפעולה של ForEach לא אמורה להחזיר ערך כלשהו.
וחוץ מזה מדוע העיקרון הגורף של LINQ הוא להחזיר ערך כלשהו? למה לא להשתמש איתו כדי להשפיע על הרצף בלי להחזיר שום ערך? איזה דבר רע (או לא פילוסופי) יש בזה?!

ועוד משהו, הכותב הנזכר בעצמו מעלה פה בסוף המאמר טיעונים חזקים המפריכים (במקצת) את התיאוריה שהוא כתב, ויש לציין שהטיעונים הללו נותרו ללא תשובות.

dovid

@קומפיונט
א. ToList מצריך לולאה + משתנה. זה הרבה יותר משמעותי מלולאה נטו.
ב. כנ"ל
ג. הנקודה היא לא מה חוזר. קוראים לזה תכנות פונקציונלי.
הפילוספיה היא שזה מתודות שאפשר להשתמש בהם בבטחה בלי לחשוש שהם ישפיעו על חלקים אחרים בתכנית שלך. לעולם לא יקרה שינוי לחלק בתכנית מפעולת LINQ שלא הושמה לתוך משתנה. בתוך המתודה ToList או ToArray קורה מה שקורה, אבל זה בסקופ סגור ובלתי משפיע, וזה יוצר פלט שאתה בוחר איך להשתמש בו.
פונקציה שנכתבה לפי כללי התכנות הפונקציונלי בהכרח תחזיר ערך כי אחרת מה היא עושה, כי מה שקורה בגוף הפונקציה חייב להיות פרטי ובלתי נוגע לשום דבר אחר בעולם מלבד פלט.

קומפיונט

@dovid כתב בלמה DoForEach לא קיים ב-LINQ?:

א. ToList מצריך לולאה + משתנה. זה הרבה יותר משמעותי מלולאה נטו.

למה ToList חוסך לולאה ומשתנה? זה לכאורה עושה return new List<TSource>(enum)

ג. הנקודה היא לא מה חוזר. קוראים לזה תכנות פונקציונלי.

פונקציה שנכתבה לפי כללי התכנות הפונקציונלי בהכרח תחזיר ערך כי אחרת מה היא עושה, כי מה שקורה בגוף הפונקציה חייב להיות פרטי ובלתי נוגע לשום דבר אחר בעולם מלבד פלט.

אולי בגלל שלא מובן לי עד הסוף מה זה 'תכנות פונקציונלי' אז אני לא מצליח להבין מדוע חייב לחזור ערך. אין כזה דבר בתכנות פונקציונלי שחוזר ערך void?

הפילוספיה היא שזה מתודות שאפשר להשתמש בהם בבטחה בלי לחשוש שהם ישפיעו על חלקים אחרים בתכנית שלך. לעולם לא יקרה שינוי לחלק בתכנית מפעולת LINQ שלא הושמה לתוך משתנה. בתוך המתודה ToList או ToArray קורה מה שקורה, אבל זה בסקופ סגור ובלתי משפיע, וזה יוצר פלט שאתה בוחר איך להשתמש בו.

לכאורה המתודה ForEach שומרת על הכלל הזה, מכיוון שהיא לא תוכל לשנות ערכים כל שהם, (הייעוד שלה זה לעשות פעולה חיצונית עבור כל אחד מהערכים) היא אמנם תוכל לשנות מאפיינים בתוך ערכים, אבל זה גם בעיה שנמצאת ב-Select וב-Where אם כי זה לא הייעוד שלהם, אבל הם לא מספקים את ההגנה הזאת.

אני מבין במקצת את הרעיון של ההגנה מפני שינוי על הערכים ברצף, אבל מדוע זה כלל גורף ב-LINQ? למה שלא יהיה אפשר לעשות שינוי למאפיינים באמצעות LINQ? יכול להיות שזה בהחלט הסיבה שגרמה למפתחים של LINQ לא להכניס כזאת פונקציה.

חגי

@dovid
בכולל אחה"צ באמצע תוס' קשה פתאום עלה לי הרעיון שבשביל לבדוק את זה, אפשר לממש את הIEnumerator לבד.

dovid

@חגי נכון.

void Main()
{
    var test = new testList();
    Console.WriteLine("ILIST ACCESS:");
    Console.WriteLine(test.Last());

    var test2 = test.Select(t => t * 2);
    Console.WriteLine("IENUMERABLE ACCESS:");
    Console.WriteLine(test2.Last());
}


public class ProxyIEnumerator :IEnumerator<int>
{
    IEnumerator<int> targetEnum;
    public ProxyIEnumerator(IList<int> _source) => targetEnum = _source.GetEnumerator();

    public bool MoveNext()
    {
        Console.WriteLine("MoveNext call");
        return targetEnum.MoveNext();
    }

    public void Reset() => targetEnum.Reset();
    public int Current => targetEnum.Current;

    object IEnumerator.Current => targetEnum.Current;
    public void Dispose() => targetEnum.Dispose();

}



class testList : IList<int>
{
    private int[] source = new int[] { 1, 2, 3, 4, 5, 6, 7, 8, 9 };

    public int Count => source.Length;

    public int this[int index]
    {
        get
        {
            Console.WriteLine("access " + index);
            return source[index];
        }
        set => throw new NotImplementedException();
    }

    public IEnumerator<int> GetEnumerator() => new ProxyIEnumerator(source);


    public bool IsReadOnly => throw new NotImplementedException();
    IEnumerator IEnumerable.GetEnumerator() => throw new NotImplementedException();
    public void Add(int item) => throw new NotImplementedException();
    public void Clear() => throw new NotImplementedException();
    public bool Contains(int item) => throw new NotImplementedException();
    public void CopyTo(int[] array, int arrayIndex) => throw new NotImplementedException();
    public int IndexOf(int item) => throw new NotImplementedException();
    public void Insert(int index, int item) => throw new NotImplementedException();
    public bool Remove(int item) => throw new NotImplementedException();
    public void RemoveAt(int index) => throw new NotImplementedException();
}

פלט:

ILIST ACCESS:
access 8
9
IENUMERABLE ACCESS:
MoveNext call
MoveNext call
MoveNext call
MoveNext call
MoveNext call
MoveNext call
MoveNext call
MoveNext call
MoveNext call
MoveNext call
18

קומפיונט

@חגי + @dovid

אם אני מבין נכון אז הדוגמא ש @dovid הביא ממחישה שכשקוראים ל-Last אז אם האובייקט של הרצף ממש את IList`1 אז ישר מתבצע קפיצה לאינדקס האחרון, ואם לא אז ה-Last עובר ו'מעיר' את כל הרצף עד שחוזר false מה-()MoveNext.
אם הבנתי נכון אז אפשר לראות את זה ב-ILSpy:

אגב, בדקתי, ToList לא משכפל את הרצף, הוא רק יוצר Reference חדש לערכים הקיימים.
עריכה: אפילו המתודה CopyTo ב-List`1 משכפלת רק את ה-Reference.

dovid

@קומפיונט כתב בלמה DoForEach לא קיים ב-LINQ?:

אגב, בדקתי, ToList לא משכפל את הרצף, הוא רק יוצר Reference חדש לערכים הקיימים.
עריכה: אפילו המתודה CopyTo ב-List`1 משכפלת רק את ה-Reference.

אם האלמנטים ברשימה הם לא פרימטיביים (כלומר Reference Type) ברור כשמש שתוכן הפריטים לא משוכפל. הנושא הוא הרשימה עצמה, נוצרת רשימה נוספת. כל רשימה זה מערך בזיכרון, גם שההתייחסות הם לאותם אובייקטים.
אבל כפי שציינתי לעיל, IEnumerable לא חייב להיות בכלל רשימה גשמית ולא חייבת להיות בעלת סוף כל שהוא, ובמקרים הללו מדובר ביצירת הרשימה ולא רק בהעתקת רשימת הפניות.

קומפיונט

@dovid כתב בלמה DoForEach לא קיים ב-LINQ?:

אם האלמנטים ברשימה הם לא פרימטיביים (כלומר Reference Type) ברור כשמש שתוכן הפריטים לא משוכפל. הנושא הוא הרשימה עצמה, נוצרת רשימה נוספת. כל רשימה זה מערך בזיכרון, גם שההתייחסות הם לאותם אובייקטים.

אז מה היתה ההוא אמינא ש-ToList לא משכפל?! ההו"א היתה ש-ToList מתנהג כמו Enumerator?

yossiz

האם שכחתם שדוטנט הוא בקוד פתוח היום? או שיותר קל לבדוק תיאוריות עם טסטים מאשר לקרוא את קוד המקור?

dovid

@yossiz
א. לפחות עבורי זה יותר ממחיש
ב. יש לי טראומות לפעמים כשאני מבקר בקוד המקור.
(עריכה: בקשר לILSpy הGo To Definition בינתיים מוליך אליו, ולא עשו עוד קיצור כזה ישר לגיטאב).

תחומים - פורום חרדי מקצועי

למה DoForEach לא קיים ב-LINQ?