I am moving this back to the dev list. I suspect it might be interesting and useful for those folks.
On Thu, Mar 17, 2011 at 3:47 AM, Torben Hoffmann <[email protected]> wrote: > Didn't get much done yesterday - my knee was hurting after my operation on > it last Thursday. No worries, we aren't on a time line here and this is something I would like to get right. > But I did get around to looking at some of your code, so I have a few > questions/observations. Sweet, this is what I really wanted. > > ec_implements puzzles me a bit. Unless I am misreading things it has a big > overlap with how behaviours work in Erlang and I think it would be better to > create a proper behaviour and avoid creating functions like > has_all_callbacks/2. I agree, thats why I created ec_dictionary. I expect things to be based around behaviours. The main reason the check functions are there is just to give the callee the ability to verify that a module implements a behaviour at runtime. This is just an optional verification step. I suspect this is over-engineering on my part, any time you implement something for other to use that you don't use yourself its a bad smell. I do wish that Erlang had a simple call to see if a module implemented a behaviour. > Since you are aiming at making ec_dictionary the behaviour then you get the > has_all_callbacks/2 functionality for free when you put > -behaviour(ec_dictonary) into the implementing module. This is true an compile time of the implementor, but on the 'user' side there is no guarantee that the thing being passed to you implements that behaviour. We can probably drop that functionality though. The errors if that is the case should be pretty obvious. > ec_assoc_list doesn't really leverage the behaviour code, which is fine for > a first stab at it, but I think a more iterative approach to the creation of > this library will keep us saner compared to go for the big thing in the > first iteration. It existed mostly as a quick example I could through together. N > > I would suggest that we start with a simplified ec_dictionary behaviour that > merely defines the behaviour_info/1 function. > Then we implement two different dictionary implementations, say lists and > orddict, plus a temporary module to instantiate them. This without the > abstract type info for starters. That seems reasonable to me. If nothing else it validates the interface for dictionary we come up with. > > Then we create a PropEr specification of how a dictionary should behave and > test the hell out of our pathetic code! That sounds like a damn good idea to me. Once we get things along and I understand PropEr I may add support for it in sinan, depends on how useful it would be. > > When that is in place we start working on putting real code into the > behaviour and continuously re-run our specification after each little > change. > > Then we can re-introduce the abstract typing and then we should be done. Except then we get to do the same thing for sets and a handful of other types. ;) > > It might be a bit of a detour compared to the code base you have put in > place, but I think that it will be easier for us to get a good PropEr > specification that works by working on simple implementations before we > start throwing in the behaviour code. It might be that we should focus on > one dictionary implementation first and get a specification that works > before we start adding another implementation. > > I am a total chicken when it comes to these things, which is why I like to > get a functional base in place very early and then improve it along the way. > Especially with so many things on the table as we have here. > > Does this sound reasonable to you? It does. To get concrete. Lets start by defining the behaviour and the PropEr spec then wrap gb_trees and dicts as or first set up implementations. Assuming we did everything right both of our implementations should pass the PropEr spec. I like this approach for types in any case. What do you think? > > If so I suggest we create a temporary github repo for the code and work it > from there. I don't see a whole lot of need to create a new repo. Just clone commons and we can easily work between us there. When we have it worked out we can move it up to canonical pretty trivially. > Cheers, > Torben > > On Wed, Mar 16, 2011 at 14:38, Eric Merritt <[email protected]> wrote: >> >> Sweet man. Thats great news. I am *very* interested in your opinion >> of the code I sent out last night and I am very interested in learning >> PropEr as well. >> >> >> >> On Wed, Mar 16, 2011 at 4:00 AM, Torben Hoffmann >> <[email protected]> wrote: >> > Hi Eric, >> > >> > I was trying to set up PropEr last night on my home machine, but since >> > PropEr is based on rebar I had to go through a massive update of my tool >> > chain. And I was behind on erlware so I ended up spending the entire >> > night >> > upgrading. >> > >> > I will get on with the code tonight! >> > >> > Cheers, >> > Torben >> > -- >> > http://www.linkedin.com/in/torbenhoffmann >> > > > > > -- > http://www.linkedin.com/in/torbenhoffmann > -- You received this message because you are subscribed to the Google Groups "erlware-dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/erlware-dev?hl=en.
