kicad-developers team mailing list archive

[Vladimir Uryvaev <vovanius@xxxxx>]

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 
associative arrays.

-- 

--- KeyFP: DC07 D4C3 BB33 E596 CF5E  CEF9 D4E3 B618 65BA 2B61