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