Ok, that works fine. When we get something lets sync back up so we know we are going in the same direction.
On Thu, Mar 17, 2011 at 3:34 PM, Torben Hoffmann <[email protected]> wrote: > Leave the dict implementation to me - I need something to work out the > properties with. > > On Thu, Mar 17, 2011 at 21:32, Eric Merritt <[email protected]> wrote: >> >> I will get this backed out and the behaviours implemented against >> ec_dictionary for gb_tress and dict while you work on the PropEr >> stuff. Then in a day or two we can try running them against each >> other. How does that sound? >> >> On Thu, Mar 17, 2011 at 3:26 PM, Torben Hoffmann >> <[email protected]> wrote: >> > >> > >> > On Thu, Mar 17, 2011 at 20:19, Eric Merritt <[email protected]> >> > wrote: >> >> >> >> > >> >> > The behaviour should be just the behaviour_info/1 function for the >> >> > time >> >> > being. >> >> > >> >> > We use the specs in ec_dictionary as our guiding light for the >> >> > implementation of the functions - simplified a bit to match the >> >> > simple >> >> > starting implementation. >> >> > >> >> > I suggest that we use a record defined in ec_dictionary.hrl for the >> >> > common >> >> > data structure between the different implementations. >> >> > >> >> > -record(dict_data, { mod, data }). >> >> > >> >> > Where mod is the module implementing the ec_dictionary behaviour and >> >> > data is >> >> > the current value. >> >> > With the record it will be easier to extend the functions later on. >> >> >> >> I am assuming that this will eventually be used by the abstraction >> >> layer. Is there any reason for us to expose this to the >> >> implementations? I can't think of a good reason for the >> >> implementations to have knowledge of the abstractions structures (I >> >> hope that makes sense). >> > >> > You are right - I just want to build the layers of abstraction >> > gradually. >> > When we are ready it will go away from the implementing modules. >> > >> >> >> >> > I am okay with cloning your repo, but wouldn't it be just as easy (or >> >> > easier) to make the current repo writable by me and work on separate >> >> > branches? >> >> >> >> I would rather work between us until we got something publishable, >> >> pulling from peer repos is the same as pulling from a central repo in >> >> git ;). However, I am more then happy to open up the canonical if you >> >> would like. >> > >> > Point taken - I will clone and then we take it from there. >> > >> > Cheers, >> > Torben >> > >> >> >> >> > >> >> > I will start looking into how PropEr works - I am sure there are some >> >> > subtle >> >> > differences from QuickCheck that needs a loving hand before I can get >> >> > it >> >> > rolling... >> >> >> >> Sweet, When I get the chance I will back out the current abstraction >> >> implementation until we are ready for that. >> >> >> >> > Cheers, >> >> > Torben >> >> > >> >> > On Thu, Mar 17, 2011 at 16:30, Eric Merritt <[email protected]> >> >> > wrote: >> >> >> >> >> >> 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 >> >> >> > >> >> > >> >> > >> >> > >> >> > -- >> >> > http://www.linkedin.com/in/torbenhoffmann >> >> > >> > >> > >> > >> > -- >> > 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.
