convore.json/groups/erlang/idiomatic-apis/messages.json

[{"user_id": 14948, "stars": [], "topic_id": 35551, "date_created": 1305578354.9701581, "message": "so here's what I think making a call could potentially look like:\ntwilio:calls(make, [{to, \"5555342412\"}, {from, \"34141321\"}]). %maybe most idiomatic?\ntwilio:calls(make,  #call(to=\"5555343412\", from=\"34141321\")). % nice but \"call\" is redundant\ntwilio:api(make, #call(to=\"5555343412\", from=\"34141321\")).  %reads nicely, too magic?", "group_id": 21, "id": 1074578}, {"user_id": 14948, "stars": [], "topic_id": 35551, "date_created": 1305578099.523551, "message": "I'm working on an Erlang API for twilio, trying to decide what I want the interface to look like, deciding between using records for arguments or proplists.  I'd like it to actually feel like Erlang, but I don't have enough experience to determine that, any recommendations?", "group_id": 21, "id": 1074529}, {"user_id": 7383, "stars": [], "topic_id": 35551, "date_created": 1305588886.6033731, "message": "These aren't tailored to Twilio but are my general preference.\n\nFor non-trivial data, if possible create an opaque type that is manipulated by a single module which exposes function for new, get, set and other operations as appropriate. This will allow you to ensure you're data is always correct (particularly if you run dialyzer).\n\nRecords are generally easier to work with if your data is nested as they can save on writing helper funs to extract data from a term. Given how short a fun to extract something and if needed provide a default is, don't be too concerned about this.\n\nFuns they are often the best way of expressing things. Often allowing a fun to be provided (whilst including a default) will be a better way to express something that otherwise might take a dozen items in a proplist or similar.\n\nSome might disagree with this but as Erlang has a flat namespace, layout your turf and stick to it. Prefixing records and modules with twilio will ensure I don't have to think about our apps clashing.\n\nThe API should be packaged up as an app (may not be obvious depending on your experience) and I don't think it's unreasonable to suggest it should work as a rebar dependancy. This will also be beneficial if you decide to use ibrowse rather than the standard httpc.\n\nFor the example you've shown I suspect I would have something like twilio_call:make(From,To). Given the type of service you offer it may also make sense to allow for multiple accounts to use the API simultaneously.", "group_id": 21, "id": 1076105}, {"user_id": 14948, "stars": [], "topic_id": 35551, "date_created": 1305610664.4670229, "message": "@andrewtj first of all thanks for the time you took to response.  Here's some more background that I hadn't mentioned. The first draft I wrote basically had a bunch of functions for doing common things, like\ntwilio:make_call(To, From, Url)\ntwilio:send_sms(To, From, Message)\nwith another function that takes an arbitrary URL and a proplist to do anything outside of the provided functions. This doesn't work well for all of the API calls because most of them have several optional arguments, and it doesn't seem reasonable to just expect a user to know which argument number some specific parameter happens to be.  This is what drew me to proplists but then records started to look a little nicer.", "group_id": 21, "id": 1079262}, {"user_id": 7383, "stars": [], "topic_id": 35551, "date_created": 1305614889.695121, "message": "@chadselph multiple definitions of a function with different arities combined with proplists are probably a good fit here, eg:\n\nmake_call(To, From) -> make_call(To, From, []).\nmake_call(To, From, Opts) ->\n\t%% stuff\n\tok.\n\nThe ibrowse API[1] or my DNSSD API[2] might give you some ideas.\n\n1. https://github.com/cmullaparthi/ibrowse/wiki/ibrowse-API\n2. https://github.com/andrewtj/dnssd_erlang/", "group_id": 21, "id": 1079504}, {"user_id": 7383, "stars": [], "topic_id": 35551, "date_created": 1305616149.449873, "message": "@chadselph also you might want to bring this up on the erlang-questions mailing list. You need to subscribe to post but I suspect the feedback you'll get will be worth the effort. http://erlang.org/mailman/listinfo/erlang-questions", "group_id": 21, "id": 1079625}, {"user_id": 19202, "stars": [], "topic_id": 35551, "date_created": 1306488361.416919, "message": "@chadselph the #call{} variant is the worst of them. It means a caller has to know about the #call{} record and that means an import just to use your library. I'd go for a property list of Options and then calls_make(To, From, Options) and calls_make(To, From) -> calls_make(To, From, []).", "group_id": 21, "id": 1202993}]