kicad-developers team mailing list archive
Mailing list archive
Re: Concerns about clearing disagreements before committing.
At Friday 25 of November 2011 11:49:01 from Lorenzo Marcantonio:
> On Fri, Nov 25, 2011 at 01:01:19AM +0400, Vladimir Uryvaev wrote:
> > Though accessors it widely used way, they're not self worth feature.
> Especially when they're simply getter/setter. But at least compiler
> should be smart enough to inline then. Also slotted object model simply
> don't have the concept of access protection (and IMHO they generally
> work better).
That's true, but programmer waste a time when write unneeded work.
There's also con, that accessor methods do not provide references to members
(so you cannot pass it as a writable argument or use RMW operators: += *= etc)
> > Accessors are useful when:
> > - Class should re-render (cache, graphic or whatever) on its attribute
> > change. - Notifications about changes should be sent to another object.
> > - Other attributes should change coherently.
> > - I forget.
> - (forgot item) Internal representation is subject to change (i.e. array
> vs list vs something else)
For POD representation is a matter of member classes. If it is subject to
change, underlying classes should provide the same interface.
> > There are two data storage 'paradigms':
> > - true object having designed interface with all its internals hidden,
> > - plain old data type with free access.
> > In most cases it is good to head toward one of them. Accessors are seem
> > to be emulation of POD in true object.
> C++ and message passing languages are toward the first. Generics
> oriented languages (CLOS and functionals) are toward the second (simply
> because objects haven't member functions :D)
C++ have them both, as second one has come from C. In (primarily scripting)
languages without external access to members, PODs are mainly emulated by
--- KeyFP: DC07 D4C3 BB33 E596 CF5E CEF9 D4E3 B618 65BA 2B61