למה DoForEach לא קיים ב-LINQ?
-
@חגי כתב בלמה DoForEach לא קיים ב-LINQ?:
אכן, ToList משכפל לך את Enumatable שלך.
זה גם משכפל, אבל זה גם מכריח אחזור מיידי של האוסף עוד לפני ביצוע הפעולה הראשונה.
קח למשל כזה Enumerable:var listNumbers1to5 = new[] {1,2,3,4,5}; var enumerableCollection = listNumbers1to5.Select(n => veryLongOperation(n)); enumerableCollection.ToList().ForEach(c => Console.WriteLine("Process now element " + c))
הConsole.WriteLine הראשון יקרה רק אחרי שכל האלמנטים יעברו את veryLongOperation. משא"כ בלולאת For Each.
עריכה: שכחתי גם את עצם הקיום של האלמנטים בזיכרון. הToList מחייב אחסון בזיכרון מלא, בעוד הEnumerable המקורי יכול להיות זרם וירטואלי. זה בעצם כמו ה"שכפול" אבל זה יכול להיות יש מאין ולא רק שכפול, ואז המחיר יכול להיות יקר עוד יותר.
-
@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)
-
@קומפיונט זה שעשו מתודה למרות שיש דרך נוספת לחיסכון של פעולה זו (שבבסיסה מחייבת לולאה פלוס משתנה) זה לא מחייב שיצרו פונקציה רק לחסוך לולאה נטו.
אני כעת חיפשתי בגוגל why linq not include ForEach ומצאתי תשובות עמוקות שקשורות לפילוספיה של LINQ, אתה מוזמן לקרוא אותם, אני לא כ"כ מתעמק.
בתכלס, אני חושב שאין בLINQ מתודת קיצור שחוסכת לולאה נטו. -
@קומפיונט מצאתי תשובה רשמית של אריק ליפרט:
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 הוא להחזיר ערך כלשהו? למה לא להשתמש איתו כדי להשפיע על הרצף בלי להחזיר שום ערך? איזה דבר רע (או לא פילוסופי) יש בזה?!ועוד משהו, הכותב הנזכר בעצמו מעלה פה בסוף המאמר טיעונים חזקים המפריכים (במקצת) את התיאוריה שהוא כתב, ויש לציין שהטיעונים הללו נותרו ללא תשובות.
-
@קומפיונט
א. ToList מצריך לולאה + משתנה. זה הרבה יותר משמעותי מלולאה נטו.
ב. כנ"ל
ג. הנקודה היא לא מה חוזר. קוראים לזה תכנות פונקציונלי.
הפילוספיה היא שזה מתודות שאפשר להשתמש בהם בבטחה בלי לחשוש שהם ישפיעו על חלקים אחרים בתכנית שלך. לעולם לא יקרה שינוי לחלק בתכנית מפעולת LINQ שלא הושמה לתוך משתנה. בתוך המתודה ToList או ToArray קורה מה שקורה, אבל זה בסקופ סגור ובלתי משפיע, וזה יוצר פלט שאתה בוחר איך להשתמש בו.
פונקציה שנכתבה לפי כללי התכנות הפונקציונלי בהכרח תחזיר ערך כי אחרת מה היא עושה, כי מה שקורה בגוף הפונקציה חייב להיות פרטי ובלתי נוגע לשום דבר אחר בעולם מלבד פלט. -
@dovid כתב בלמה DoForEach לא קיים ב-LINQ?:
א. ToList מצריך לולאה + משתנה. זה הרבה יותר משמעותי מלולאה נטו.
למה ToList חוסך לולאה ומשתנה? זה לכאורה עושה
return new List<TSource>(enum)
ג. הנקודה היא לא מה חוזר. קוראים לזה תכנות פונקציונלי.
פונקציה שנכתבה לפי כללי התכנות הפונקציונלי בהכרח תחזיר ערך כי אחרת מה היא עושה, כי מה שקורה בגוף הפונקציה חייב להיות פרטי ובלתי נוגע לשום דבר אחר בעולם מלבד פלט.
אולי בגלל שלא מובן לי עד הסוף מה זה 'תכנות פונקציונלי' אז אני לא מצליח להבין מדוע חייב לחזור ערך. אין כזה דבר בתכנות פונקציונלי שחוזר ערך
void
?הפילוספיה היא שזה מתודות שאפשר להשתמש בהם בבטחה בלי לחשוש שהם ישפיעו על חלקים אחרים בתכנית שלך. לעולם לא יקרה שינוי לחלק בתכנית מפעולת LINQ שלא הושמה לתוך משתנה. בתוך המתודה ToList או ToArray קורה מה שקורה, אבל זה בסקופ סגור ובלתי משפיע, וזה יוצר פלט שאתה בוחר איך להשתמש בו.
לכאורה המתודה ForEach שומרת על הכלל הזה, מכיוון שהיא לא תוכל לשנות ערכים כל שהם, (הייעוד שלה זה לעשות פעולה חיצונית עבור כל אחד מהערכים) היא אמנם תוכל לשנות מאפיינים בתוך ערכים, אבל זה גם בעיה שנמצאת ב-Select וב-Where אם כי זה לא הייעוד שלהם, אבל הם לא מספקים את ההגנה הזאת.
אני מבין במקצת את הרעיון של ההגנה מפני שינוי על הערכים ברצף, אבל מדוע זה כלל גורף ב-LINQ? למה שלא יהיה אפשר לעשות שינוי למאפיינים באמצעות LINQ? יכול להיות שזה בהחלט הסיבה שגרמה למפתחים של LINQ לא להכניס כזאת פונקציה.
-
@חגי נכון.
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 הביא ממחישה שכשקוראים ל-
Last
אז אם האובייקט של הרצף ממש אתIList`1
אז ישר מתבצע קפיצה לאינדקס האחרון, ואם לא אז ה-Last
עובר ו'מעיר' את כל הרצף עד שחוזרfalse
מה-()MoveNext
.
אם הבנתי נכון אז אפשר לראות את זה ב-ILSpy:אגב, בדקתי, ToList לא משכפל את הרצף, הוא רק יוצר Reference חדש לערכים הקיימים.
עריכה: אפילו המתודה CopyTo ב-List`1 משכפלת רק את ה-Reference. -
@קומפיונט כתב בלמה DoForEach לא קיים ב-LINQ?:
אגב, בדקתי, ToList לא משכפל את הרצף, הוא רק יוצר Reference חדש לערכים הקיימים.
עריכה: אפילו המתודה CopyTo ב-List`1 משכפלת רק את ה-Reference.אם האלמנטים ברשימה הם לא פרימטיביים (כלומר Reference Type) ברור כשמש שתוכן הפריטים לא משוכפל. הנושא הוא הרשימה עצמה, נוצרת רשימה נוספת. כל רשימה זה מערך בזיכרון, גם שההתייחסות הם לאותם אובייקטים.
אבל כפי שציינתי לעיל, IEnumerable לא חייב להיות בכלל רשימה גשמית ולא חייבת להיות בעלת סוף כל שהוא, ובמקרים הללו מדובר ביצירת הרשימה ולא רק בהעתקת רשימת הפניות. -
@dovid כתב בלמה DoForEach לא קיים ב-LINQ?:
אם האלמנטים ברשימה הם לא פרימטיביים (כלומר Reference Type) ברור כשמש שתוכן הפריטים לא משוכפל. הנושא הוא הרשימה עצמה, נוצרת רשימה נוספת. כל רשימה זה מערך בזיכרון, גם שההתייחסות הם לאותם אובייקטים.
אז מה היתה ההוא אמינא ש-
ToList
לא משכפל?! ההו"א היתה ש-ToList מתנהג כמו Enumerator?