1 |
On 14/10/16 10:04 AM, Raymond Jennings wrote: |
2 |
> On Fri, Oct 14, 2016 at 6:55 AM, Ian Stakenvicius <axs@g.o |
3 |
> <mailto:axs@g.o>> wrote: |
4 |
> |
5 |
> On 14/10/16 09:46 AM, Rich Freeman wrote: |
6 |
> > On Fri, Oct 14, 2016 at 9:07 AM, Raymond Jennings <shentino@×××××.com <mailto:shentino@×××××.com>> wrote: |
7 |
> >> That's why I made my own proposal. |
8 |
> >> |
9 |
> >> class supporter |
10 |
> > |
11 |
> > If you change supporter to always be a foundation member (ie make |
12 |
> > membership activation/removal simultaneous with instantiation) it |
13 |
> > could work. However, I still question the need for a 3rd tier. |
14 |
> |
15 |
> My C++ is a little rusty but if I'm reading it right, all the |
16 |
> 'supporter' class does is provide a container of inheritance that (a) |
17 |
> allows you to revoke everything when someone stops being a supporter |
18 |
> (or stops agreeing to the COC), and (b) allows the separation of |
19 |
> foundation-member from the dev and staff classes. It also seems to |
20 |
> allow there to be foundation members that are neither staff nor dev's. |
21 |
> |
22 |
> |
23 |
> Exactly. |
24 |
> |
25 |
> So it's not a class that would be instantiated in and of itself I |
26 |
> don't think. |
27 |
> |
28 |
> |
29 |
> It is an abstract virtual base class...virtual because we could well |
30 |
> have supporters who are staff AND dev, but we'd only need to check |
31 |
> their supporter credietnails (coc compliance etc) once. |
32 |
> |
33 |
> |
34 |
|
35 |
AND, the important bit, separates foundation membership from both |
36 |
classes; right? |