That is the canonical. On Thu, Mar 17, 2011 at 3:07 PM, Martin Logan <[email protected]> wrote: > 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.
