>
> 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.
