Okay - now it is rock'n'roll time!
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 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 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...
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.
