Until Skila I didn’t spot any language that controls whether you read the function result or not. This omission bites me usually twice a year causing a headache — I look and look at the code and everything seems peachy, yet I don’t see expected results. Consider such code:
using (var db = DataContextCreator.Instance.Create()) { IQueryable<Offer> offers = db.Offers .Where(offer => offer.Feed.website_Id == (int)website); if (ProgramDebug.OfferId.HasValue) offers.Where(it => it.offer_Id == ProgramDebug.OfferId.Value); else { if (canBeMarkedAsCompleted) offers = offers.Where(offer => offer.offer_DirtyPage == null || !offer.offer_IsDayCompleted); else offers = offers.Where(offer => offer.offer_DirtyPage == null); ...
This code gets the offers and according to some conditions filters them again and again. Do you see a bug? Since you are primed you should have no problems with it, but if you are unaware, tired, this can be a waste of time and nerves.
Thus Skila have procedures, which work like method/function in Java, C#, C++ and so on. It also have functions — the procedures which outcomes have to be read. Having LINQ in Skila, and defining Where
as function this bug couldn’t occur.
Note: a function in Skila cannot return void
, only procedure can.