Re: [Snowdrift-dev] Mechanism implementation

2016-03-20 Thread Bryan Richter
On Tue, Mar 15, 2016 at 12:50:00AM -0600, Peter Harpending wrote:
> I need to go to bed, but tomorrow, I'll try to work on gluing the
> mechanism to the rest of Snowdrift.

I would hold off on doing this, or at least run your plan past me
first. It involves core architecture decisions.

Thanks!


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev


Re: [Snowdrift-dev] Mechanism implementation

2016-03-19 Thread Bryan Richter
On Tue, Mar 15, 2016 at 09:13:53AM -0600, Peter Harpending wrote:
> On 03/15/2016 12:50 AM, Peter Harpending wrote:
> > code that requires one to use the feature, so I vote that
> 
> Silly me, I forgot to mention how I vote. I vote that we leave it for
> now, because it's unlikely to cause any problems. We can always remove
> it if it does.

I feel like it already has caused problems; namely, questions and
confusion. It also creates additional maintenance and testing burden.
All these problems compound with time. I feel strongly that unused
features must be removed. (This is the same exact thing Snowdrift is
grappling with as a whole.)

We can always reach into git history and bring it back if we need it.


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev


Re: [Snowdrift-dev] Mechanism implementation

2016-03-14 Thread Peter Harpending

On 03/14/2016 05:10 PM, Bryan Richter wrote:
> 1. I'm not sure the Eq instances of MechPatron and MechProject are
> sound. As defined, `==` is the moral equivalent of checking that the
> two values cannot both exist in the database at the same time
> (database uniqueness), but that's not quite the same thing as being
> the same value.

So, I think I redid this between when you wrote this review and
now. Now, the `Eq` instance makes sure the external keys are equivalent.

instance Eq MechPatron where
m1 == m2 = mechPatronExternalKey m1 == mechPatronExternalKey m2

instance Ord MechPatron where
compare = comparing mechPatronExternalKey

instance Eq MechProject where
m1 == m2 = mechProjectExternalKey m1 == mechProjectExternalKey m2

instance Ord MechProject where
compare = comparing mechProjectExternalKey

The reason I wanted to do this is so that `compare` would return `EQ`
iff `(==)` would return `True`. I can't remember why I wanted to sort
them? I think I wanted to put them in a `Set` (from the `containers`
package), and to do any nontrivial `Set` operations, the inner type must
be an instance of `Ord`.

`HashSet` or whatever from `unordered-containers` doesn't require the
inner type to have an `Ord` instance, however is does require a
`Hashable` instance, which might actually not be that bad. Sets in
mathematics do not require the concept of ordering, so `containers`
seems like an affront to basic mathematical decency. It's almost as bad
as there existing a `w : Word` such that `w + 1 = 0`.

Mathematical decency aside, I'll look in to this.

> 3. I don't think the concept of a suspended patron is necessary yet.
> I could be misremembering, but I'm pretty sure one is either a patron
> or one is not.

This is me attempting (poorly) to think ahead. The concept of a pledge
being suspended because of insufficient funds is necessary (or we could
just delete the pledges, but that seems sort of mean). Moreover, I can
imagine that Patrons would want to prioritize the projects, so if they
can only afford projects X, Y, and Z, they can exclude project W
temporarily if they want.

> 5.
>
>> he = it
>
> I get it, but it provides very little compared to the damage it
> could cause.

What damage is that? Other than quasi-feminist stuff? Would it be better
if I wrote `he = specify`?

> 6. The stuff I wrote for doing tests against a database was intended
> to be abstracted out into a standalone library. I'll still do that.
> I guess you had to rewrite it to be able to use HSpec, though, so
> *shrug*
>

FWIW, your tests are still there, in the `chreekat` directory. I sort of
ported them over to HSpec, and then figured out a rather novel way to
abuse the concept of property-based testing.

___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev