[Exceptional C++ Style] Item 17 - Encapsulation

[Jon Jagger]

>
> I doubt item 17 will prove controversial, but agreeing that public 
> data members when const are ok will I think :) I am against them 
> (although do what I say, not what I do please!). True, they may be 
> non-modifiable, but they still cause a data dependancy, 


 >compared to what? here's a grammar_definition object...

grammar_definition js;

 >and an example of using it (to get at one of the const data members) is...

const non_terminal_definition & x = js.if_statement;

 >compared to getting at it via an accessor...

const non_terminal_definition & x = js.if_statement();

 >how is the dependency any different?


 >Consider also a typical use...

js.if_statement[0][1]

 >and compare this to...

js.if_statement()[0][1]

 >which is more idiomatic?



> and given that there is no strong reason why they are more useful 
> being public then accessed via member functions, I think they are not 
> a good idea. 


To which, of course, my reply is....Given that there is no strong reason 
why they are more useful being member functions than data members I 
think they (data members) are a good idea (in this case).

> Other reasons not to is that it can break the consistency of the code 
> style: it's harder to argue for encapsulation if you allow these 
> special cases. You also require that data member to remain const in 
> the future.

See above. I think making them data members _improves_ the consistency 
of the code.

As for remaining const. Again compared to what? The members _are_ const. 
The question is how to "expose" them! Like this...

class X_definition : public grammar_definition
{
public:
    const non_terminal_definition if_statement;
};

or like this...

class X_definition : public grammar_definition
{
public:
    const non_terminal_definition & if_statement() const;
};

They're still const...
Cheers
Jon

>
> Cheers,
>
> Daire Stockdale
>
>
> _______________________________________________
> Effective-cpp mailing list
> Effective-cpp at accu.org
> List: http://www.accu.org/mailman/listinfo/effective-cpp
> Project: http://www.paulgrenyer.dyndns.org/cppstyle/
>