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