Is the canonical not erlware/erlware_commons? On Thu, Mar 17, 2011 at 2:19 PM, 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). > > >> 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. > >> >> 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 >> > > -- > 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. > >
-- Martin Logan Erlang & OTP in Action (Manning) http://manning.com/logan http://twitter.com/martinjlogan http://erlware.org -- 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.
