IRC Logs for #io Saturday, 2014-06-14

*** hashmal has quit IRC00:02
prologicwell first class methods01:27
prologicblocks are just scoped differently01:27
robonerdwhat do you mean?01:28
prologicit'e a little complicated01:32
prologicand I'm not sure I have scoping rules all figured out in mio yet01:33
prologicbut needless to say01:33
prologicblocks receive the context as self01:33
prologicand methods receive the receiver as self01:33
prologici.e: foo = block(x = 1; block(x)); foo() == 101:33
prologicvs: x = 1; foo = method(x); foo() == 101:34
*** hashmal has joined #io02:03
*** hashmal has quit IRC02:08
*** stapler has joined #io02:12
*** stapler has quit IRC02:15
*** stapler has joined #io02:15
stapleri am back02:15
*** gatesphere has joined #io02:24
staplerhello, gatesphere 02:24
*** springbok has joined #io02:52
staplerhello, springbok 03:03
*** bjz has joined #io03:24
*** gatesphere has quit IRC03:27
*** hashmal has joined #io04:04
prologicback too04:08
*** hashmal has quit IRC04:08
staplerwelcome back, prologic 04:30
*** mal`` has quit IRC05:09
*** mal`` has joined #io05:12
*** hashmal has joined #io06:05
*** hashmal has quit IRC06:09
*** robonerd has quit IRC06:14
*** robonerd has joined #io06:16
staplerhi, robonerd 06:57
*** c74d has quit IRC07:59
*** c74d has joined #io08:03
*** hashmal has joined #io08:06
*** stapler has quit IRC08:10
*** hashmal has quit IRC08:10
*** hashmal has joined #io09:44
*** ElMonkey_ has joined #io09:58
*** TheMonkey has quit IRC10:01
*** hashmal has quit IRC12:07
*** gatesphere has joined #io13:10
*** gatesphere has quit IRC13:15
*** pchalupa has joined #io14:26
jerurgh, i really really find it ridiculous api design when an api uses exceptions to signal errors15:08
jerbecause now, to fit some third party library into my own stack, i need to wrap it, catching exceptions to every function that throws them, and return a Maybe monad15:09
jeror an Either monad, depending on what makes sense15:09
pdurbinjer: are you looking at an Io project? or you just mean in general?15:15
jerwell in this case, it's a C++ project15:19
jerbut i'm speaking more generally15:19
pdurbinjer: so you wouldn't like how throws IllegalCommandException?15:22
jerpdurbin, i'm not anti all exceptions, i'm anti-using exceptions to report general errors. if the programmer has done something that has violated the contract of the api, then by all means, blow up with an exception15:23
jerotherwise, give the programmer an indication of some error condition w/o using setjmp/longjmp, i.e., give them some data structure they can react to15:23
pdurbinok. that's what we're doing. trying to15:23
jerandi t also kinda pisses me off that so many api developers don't think about how their apis should look 2 levels outwards15:32
jeri.e., first level outwards from you, is the consumer, their requirements, second level is what their client expects15:32
jerwhat's useful for their client15:32
jerbuild for their client, not for them.15:33
jerright now i'm converting an objc backend library i wrote to C++ for use in an upcoming set of android projects15:34
pdurbinjer: and you're making an awesome api? :)15:35
jerwell, the objc backend when i started writing it, internal politics got in the way of me doing it the way i had hoped15:36
jerso it ended up reasonable (clean, performant, easy to follow and sufficient for the purpose)15:36
jerbut it wasn't great15:36
jernow i'm trying to abstract out a lot of methods like: -[QRKShopController listCartWithCompletion:] into something more resembling a property on a shop controller, like: Channel<QRKCartItem*> cartItems;15:37
jermy channel implementation is basically a list of items + notification of completion15:37
jerthe problem i have is indicating error, but i can do that with: Channel<Either<QRKCartItem*, Error>> cartItems15:38
jerthen you effectively subscribe to the results that come back, and until the channel is closed, or an error is received, you're taking in new items15:38
jerso consumers of the api then treat this like their data store15:38
jernow the major problem i'm having is when i go into how we build up these views tha say, presents a shopping cart15:39
jerwell shopping cart is a bad example actually, let's take a products list instead15:39
jerthe products list gets cached (since it doesn't change frequently) but we still do the request, and then fit the new items in wherever they have to be15:39
jersince my channel is a linear stream of data, this becomes problematic. I'd only ever be able to put items at the end, not at the start, like how the spec is written.15:40
jerso i'm trying to think of ways around this w/o increasing boilerplate at my consumer, which is still useful for the expectation of the client15:40
jerbasically, trying to make the consumer's job easy15:40
jerwe have junior devs working on the frontend15:40
jerso i want to make sure that they can't ignore errors, for instance, but the api isn't burdensome15:41
jerit's tricky15:41
jernow i suppose i could have that be a smart result set instead, which acts like a channel of either expected values or errors, has a notion of "no more data is coming down" and is able to be given commands (things like invalidate caches and refetch all, try next page, etc) and this abstracts away caching from the frontend, leaves the strategy entirely up to my library.15:46
jera smart result set would capture the request being made, the set of parameters, a current page if applicable, expect specific type of good result to come back, and an error, know whether it's completed, or waiting on more pages...15:47
pdurbinjer: I'm interested but I'm cleaning. Friends coming over.16:27
*** arprez has joined #io17:00
*** bjz has quit IRC17:15
*** levitation[A] has quit IRC18:59
*** levitation[A] has joined #io19:03
*** robonerd has quit IRC19:20
*** robonerd has joined #io19:21
*** robonerd has quit IRC19:21
*** robonerd has joined #io19:21
*** codestorm has quit IRC19:26
*** codestorm has joined #io19:26
prologicwow hot debate here :)21:08
*** c74d has quit IRC21:15
*** c74d has joined #io21:19
pdurbinprologic: good stuff from jer. wish I had ideas for him21:28
jerstill truggling with it, but here's what i've got right now...21:36
jermodelling the data as a stream of results where new values can be delivered after some delay21:37
jerthat stream knows about errors, and about completion, as well it can be instructed to proactively 'seek additional data' upon which time the channel could be closed if there is no more21:37
jercache is looked up and sent down the channel first, each record has an "order" number of some sort -- where it should be in the stream21:37
jerduring this time, the network call is kicked off, and new results come in -- the data cached is known, so can be easily compared; and any values that came down which are not in the cache, can be cached, and old values can be expired. any data that's changed, can also be invalidated in the cache and resent with the same id21:38
jerin this sense, the user of the api doesn't know (nor has any guarantees) when data will come in, only that it has guarantees of getting some indicator that something happened (be it values, errors, closed channel) which all make sense for things it'll want to do with it21:39
jerthe client never has to maintain its own caching strategy, simplifying frontend code21:39
jerdownside is the backend maintains its own caching strategy, which may not be ideal for the purpose21:39
jeradditionally, it introduces some overhead for single value fetches21:39
pdurbinjer: when you say "channel" do you mean something like a channel in Go?21:40
jernot exactly21:41
jermore precisely i mean a one-way communication link between two arbitrary points where the 'channel'21:42
jerthough two arbitrary points is a little less precise; it's really 3 points, 2 producers, 1 consumer21:42
pdurbinok. producers and consumers21:42
jerbut the producers never talk to one another21:42
jerthe 'channel' is probably more accurately described as a pipe21:43
jeras a pipe may have multiple fittings21:43
pdurbinsure :)21:43
jerit's a really silly problem, but right now in our app backend is all rather dumb21:43
jerand it puts a cognitive overhead on the frontend when interacting with the backend21:44
jeri'm trying to remove that burden by placing it all within the realm of the backend21:44
jerand really thinking about it, it's a limited bidirectional pipe actually21:45
pdurbinmakes sense. especially since more junior people are working on your front end21:45
jeras the client has a control channel back into the non-cached producer21:45
jeri spread all our apps, because i build and maintain the backend, i also work on integration into the frontends21:45
jerwe've got 2 other frontend devs who take the designs from our design team and make them pretty on device, but at the end of the day, their shit needs data21:46
jerand currently they're maintaining things like (for scrollable list views) pagination behaviour in the view model or view controller21:46
jerwhich is a lot of cross responsibility work being done in those places21:46
jerbut i also want something robust enough that when talking about data fed back from a device, like an Aros air conditioner (feedback from a real device, not a web service) that i can model that the same way21:47
jeractually i suppose i can support errors inline to values. just make my values like i said earlier, Either<QRKIdea, Error> for instance. then the client can filter out an errors needed, or present proper contextual informaiton as appropriate21:52
jerlast thing i think i need to solve is the ability to cancel an in flight request21:52
jerclient knows nothing about that, so how do i have them inform me to cancel the request?21:53
jersuppose i could require them to close their channels21:53
jerand when a channel is closed, cancel the in flight request21:53
pdurbinjer: what about latency? do you cancel the request after a long timeout?21:56
jerpdurbin, well that's another issue. a network request that times out, would close the channel22:06
jeror a wire connection whose socket is closed, would close the channel22:06
jerthe downside to that is, there's no feedback that this has happened -- so it's not transparent to a frontend22:07
pdurbinjust thinking about Latency Monkey :)22:07
jerthey still have to check if the channel is closed at various points wherever they interact with it22:07
jerless than ideal22:07
jeractually closing the channel on network/socket closure is probably not a good idea -- crafting a new error and pushing it down is22:09
jerand if i make errors unrecoverable (indicate so in the error) then upon receiving one of those, close the channel automatically22:09
jerthinking about client code; something like: Either<Value, Error> result = channel->get(); if(left(result) != nullptr) { /* happy path */ } else { /* error path */ /* channel->isClosed() == true */ }22:10
jerthis does mean a bit of boierlplate just by design though; while(!channel.isEmpty()) { Either<Value, Error> result = channel->get(); ... }22:14
*** TheMonkey has joined #io22:27
*** ElMonkey_ has quit IRC22:31
*** hashmal has joined #io23:48

Generated by 2.11.0 by Marius Gedminas - find it at!