Директен линк към част 2 (mp3) (ogg)
Коментираният код:
public class Employee
{
public string Name { get; set; }
public decimal Salary { get; set; }
}
IEnumerable employees = ...; //алтернативно IQueryable;
IEnumerable names = employees.Where(e => e.Salary > 1000).Select(e => e.Name);
IEnumerable names2 = from e in employees
where e.Salary > 1000
select e.Name;
октомври 7th, 2013 at 00:47
Може би ще ви е интересно да погледнете модула Enumerable в Ruby (http://apidock.com/ruby/Enumerable). Там дефинирайки един метод за обхождане на обектите на колекция един по един и include-вайки този модул получаваш 50-тина метода, с които можеш да обработваш, филтрираш, сортираш, разделяш тази колекция.
октомври 7th, 2013 at 07:51
Ruby ми е доста слаба тема, но като гледам документацията и кода изглежда, че тези методи не са lazy, а връщат масиви.
октомври 7th, 2013 at 09:41
От Ruby 2.0, което излзе тази година можеш да напишеш:
[1,2,3].lazy.map {|x| x * 10}.take(5).to_a, където „lazy“ в началото кара всеки елемент да мине през цялата верига, а „to_a“ (to_array) на края ги „материализира“.
октомври 7th, 2013 at 09:48
Мдам това lazy би било еквивалентно на LINQ за in-memory неща. Искам да подчертая, че това има ОГРОМНО значение, въпреки че на пръв поглед изглежда, че е едва ли не същата работа.
октомври 7th, 2013 at 22:27
Това lazy-то в Ruby 2.0 така работи. Иначе преди това имаше подобна концепция, но беше леко скрита и трябваше сам да си правиш такива неща. За IQueryable в ActiveRecord-a към Rails работи по подобен начин:
User.join(:photos).where(:active => true, ‘photos.visible’ => true).order(‘created_at DESC’)
Има и един проект Ruby Object Mapper ( http://rom-rb.org/ ) който ще включва това, но за N тип структури от данни.
Иначе когато бях млад и глупав и си правих ORM за PHP. Имах подобна фунционалност и тя се постигаше много лесно с spl интефейсите ArrayAccess, Iterator и Countable и правиш evalulate като ти трябва да достъпиш елемент. Като за query ползваш array shortcuts тъй като това беше преди 5.3 дните, когато нямаше lambda, генератори и подобни.
За мен като цяло тази концепция за работа с данни е без ценна (не мога да се сетя for от кога не съм писал). Даже и да няма lazy както в javascript не е чак такъв проблем в повечето случай, според мен.
октомври 7th, 2013 at 23:11
Да, по-скоро загубата на цялото accidental complexity около циклите и допълнителните променливи е предимството и за мен. Виждаш само „важната“ част от кода, а не допълнителните 5/10/15.. реда „garbage“.
октомври 7th, 2013 at 23:21
Между другото аз в момента упражнявам слабите си C++ умения с нещо подобно: https://github.com/s2gatev/RubyInspiredCollections Все още не поддържа lazy chaining, но има време.
октомври 8th, 2013 at 00:12
„Lazy-то“ не идва от yield, а от yield return, което не е просто yield + return.
октомври 8th, 2013 at 00:32
Нещо не мога да се сетя какъв друг yield има освен yield return и yield break.
октомври 8th, 2013 at 11:42
Бе знам че има имплементация и на рнр ама не съм я ползвал ама за js това е добро: http://www.hugoware.net/projects/jlinq/
октомври 8th, 2013 at 11:49
Е то принципно може да го имплементираш навсякъде, където имаш класове + lambda или ако езикът ти е динамичен. Има едно подобно нещо за Java в библиотеката Guava на Google. Но тъй като там lambda се имплементира с анонимни класове е зверски грозно.. Когато функционалните езици превземат света отново, всички ще пишем по този начин 😀
октомври 8th, 2013 at 12:53
Както казах е напълно възможно в различните езици това нещо което е директен порт на LINQ да не е най-доброто за съответния език. Примерно Guava не е директен порт на LINQ и се опитва много хитро да прикрие някои неща, които биха довели до много грозно количество анонимни класове. Разбира се Guava ще е obsolete след 4-5 месеца като все пак пуснат ламбдите в Java.