www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Partial class implementation

reply Robert Fraser <fraserofhtenight gmail.com> writes:
Random, C#-inspired thought:

It would be nice if it were possible to implement parts of classes in different
modules than other parts. This would allow logical grouping of methods for a
set of related classes.

This is already possible via template mixins (sort of, but alias template
params are required to access fields), but explicit partials might be quite
helpful.
Jul 16 2007
next sibling parent reply Tristam MacDonald <swiftcoder gmail.com> writes:
This might be an interesting perspective on the kind of harm such an option
might cause:
http://www.ddj.com/dept/cpp/184401197

Robert Fraser Wrote:

 Random, C#-inspired thought:
 
 It would be nice if it were possible to implement parts of classes in
different modules than other parts. This would allow logical grouping of
methods for a set of related classes.
 
 This is already possible via template mixins (sort of, but alias template
params are required to access fields), but explicit partials might be quite
helpful.
Jul 16 2007
next sibling parent janderson <askme me.com> writes:
Tristam MacDonald wrote:
 This might be an interesting perspective on the kind of harm such an option
might cause:
 http://www.ddj.com/dept/cpp/184401197
 
 Robert Fraser Wrote:
 
 Random, C#-inspired thought:

 It would be nice if it were possible to implement parts of classes in
different modules than other parts. This would allow logical grouping of
methods for a set of related classes.

 This is already possible via template mixins (sort of, but alias template
params are required to access fields), but explicit partials might be quite
helpful.
I thought it was possible to do something like: void foo(A a) { } ... a.foo(); I tried it out and it didn't work. Sigh, it would be awesome for many reasons if D did support this. -Joel
Jul 16 2007
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
That article is indeed well-reasoned, however it fails to take into account
other features. In particular (this may come off as Java-fanboy nitpicking):

1. It encourages a large public interface: if functions that depend soley on
the "public interface" are non-members, to achieve the same level of
accessibility, the initial public interface of a class may need to be expanded.
In particular the getter/setter/property pattern is encouraged by such a
design, and overuse of this pattern can degrade a class to a simple aggregation
of data, defeating the purpose of encapsulation entirely.

2. The architecture is less nimble for client code. If a function that at one
time needed only access to the public interface later needs member access, the
non-member function will become a simple proxy for the member function, or,
worse, the public interface could be expanded.

3. Sending messages directly to a class is (IMO) clearer, prettier, and better
for auto-complete tools & lookup (manual or go-to-definition) than a free
function.

But to each his own, I guess. That article certainly had some good points.

That said, I was thinking about partial class implementation mainly with
regards to related virtual functions (i.e. Implementing the same
abstract/interface/override function across multiple subclasses all in the same
file, while other parts of those clases are defined elsewhere. This will help
logically group large clas hirearchies, IMO.

Tristam MacDonald Wrote:

 This might be an interesting perspective on the kind of harm such an option
might cause:
 http://www.ddj.com/dept/cpp/184401197
 
 Robert Fraser Wrote:
 
 Random, C#-inspired thought:
 
 It would be nice if it were possible to implement parts of classes in
different modules than other parts. This would allow logical grouping of
methods for a set of related classes.
 
 This is already possible via template mixins (sort of, but alias template
params are required to access fields), but explicit partials might be quite
helpful.
Jul 16 2007
parent reply janderson <askme me.com> writes:
Robert Fraser wrote:
 That article is indeed well-reasoned, however it fails to take into
account other features. In particular (this may come off as Java-fanboy nitpicking):
 
 1. It encourages a large public interface: if functions that depend
soley on the "public interface" are non-members, to achieve the same level of accessibility, the initial public interface of a class may need to be expanded.
Classes should be small and as minimal as possible. I think this is part of Meyers argument. Anything that can be placed outside the class should be. If it can't because that gives assess to something that could potentially be misused by the world outside the class, thats a case to make it a member. Therefore you get this highly easy to use class that is less bug prone. It knows what is job is, its small so its easy to maintain.
 In particular the getter/setter/property pattern is
 encouraged by such a design, and overuse of this pattern can degrade a
 class to a simple aggregation of data, defeating the purpose of
 encapsulation entirely.
 
This is true. I don't think the example of a point was the best example. Herb Sutter and Bjarne Stroustrup's often argue that if the class variables have not constraints (invariants) then the class should really be a C struct (where everything is public).
 2. The architecture is less nimble for client code. If a function
 that at one time needed only access to the public interface later
 needs member access, the non-member function will become a simple
 proxy for the member function, or, worse, the public interface could
 be expanded.
But this is a good thing. It means you either have to go back to the drawing board with the class interface or add the non-member into the interface. Its pretty easy to remove a non-member function. Its much harder to remove a function once it becomes part of a class. Note that if you want to extend a class there are other ways to do it (namely using a component). Also if you find your creating proxies, then there was probably something wrong with the design in the first place.
 
 3. Sending messages directly to a class is (IMO) clearer, prettier,
 and better for auto-complete tools & lookup (manual or
 go-to-definition) than a free function.
There is no real point in arguing this. My main argument is based on code refactorbility and design. I find free functions are much more reuseable then member functions, look at algorithms in std (find, sort ect...).
 
 But to each his own, I guess. That article certainly had some good
 points.
 
 That said, I was thinking about partial class implementation mainly
 with regards to related virtual functions (i.e. Implementing the same
 abstract/interface/override function across multiple subclasses all
 in the same file, while other parts of those clases are defined
 elsewhere. This will help logically group large clas hirearchies,
 IMO.
While I'm not against the idea. I think, its a much better idea to have lots of small cohesive component classes rather then a large class. I've seen so many large classes and I've always been able to break them down into small chunks. I must admit though it can sometimes be quicker in the short run to simply throw everything into the same class. Here's some more information: http://www.artima.com/intv/goldilocks.html
 Tristam MacDonald Wrote:
 
 This might be an interesting perspective on the kind of harm such an option
might cause:
 http://www.ddj.com/dept/cpp/184401197

 Robert Fraser Wrote:

 Random, C#-inspired thought:

 It would be nice if it were possible to implement parts of classes in
different modules than other parts. This would allow logical grouping of
methods for a set of related classes.

 This is already possible via template mixins (sort of, but alias template
params are required to access fields), but explicit partials might be quite
helpful.
Jul 16 2007
next sibling parent janderson <askme me.com> writes:
I want to extend what I was saying about components.

If you have a class and you want to break it up into several files based 
on methods, why not use components instead.  You end up with a much more 
flexible design.

ie Say I have:

class Boat
{
public:
	string GetName();
	string GetOwner();
//ect...

	point GetLocation();
	point Facing();
	float GetSpeed();
//ect...
};

If you went for component design you would probably do something like:

class Info
{
public:
	string GetName();
	string GetOwner();
//ect...
};

class PhysicsObj
{
public:
	point GetLocation();
	point Facing();
	float GetSpeed();
//ect...
};

struct Boat
{
	Info info = new Info();
	PhysicsObj physicsObj = new PhysicsObj();
};


Immediately more reusable and maintainable.

Now like you said, you could use mixins.  This is a nicety of D however 
components offer a few advantages as well like a nice way to break up 
the namespaces, are easier to refactor and allow for more cohesive code.

-Joel
Jul 16 2007
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
janderson wrote:
 Robert Fraser wrote:
 There is no real point in arguing this.  My main argument is based on 
 code refactorbility and design.  I find free functions are much more 
 reuseable then member functions, look at algorithms in std (find, sort 
 ect...).
Does that really hold true for D though? Without Koenig lookup, free functions don't have the same flexibility they do in C++. You can write generic template functions like find, sort, etc, where there is a single implementation and callers have to implement the concept it requires. But something like 'toString' as a non-member is pretty much impossible in D. --bb
Jul 16 2007
parent reply Reiner Pope <some address.com> writes:
Bill Baxter wrote:
 janderson wrote:
 Robert Fraser wrote:
 There is no real point in arguing this.  My main argument is based on 
 code refactorbility and design.  I find free functions are much more 
 reuseable then member functions, look at algorithms in std (find, sort 
 ect...).
Does that really hold true for D though? Without Koenig lookup, free functions don't have the same flexibility they do in C++. You can write generic template functions like find, sort, etc, where there is a single implementation and callers have to implement the concept it requires. But something like 'toString' as a non-member is pretty much impossible in D. --bb
I didn't realise there was an issue here, before; can you tell me if this is what you are talking about? --- module a.b.c; struct A {...} string toString(A) {...} --- module a.b; import a.b.c; class B { A getInstanceOfA() {...} } --- module b; import a.b; void main() { B b = new B(); auto a = b.getInstanceOfA(); string s = toString(a); // doesn't work } --- In this case, I can see it might be a surprise that it doesn't work, but is there anything worse than that? What's wrong with just importing a.b.c and carrying on? If you did any serious manipulations of 'a', then you would have to declare the type 'A' *sometime*; so you'd end up importing a.b.c anyway... I'm just taking a guess at what you mean, though; if I'm completely off, can you please explain? -- Reiner
Jul 17 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Reiner Pope wrote:
 Bill Baxter wrote:
 janderson wrote:
 Robert Fraser wrote:
 There is no real point in arguing this.  My main argument is based on 
 code refactorbility and design.  I find free functions are much more 
 reuseable then member functions, look at algorithms in std (find, 
 sort ect...).
Does that really hold true for D though? Without Koenig lookup, free functions don't have the same flexibility they do in C++. You can write generic template functions like find, sort, etc, where there is a single implementation and callers have to implement the concept it requires. But something like 'toString' as a non-member is pretty much impossible in D. --bb
I didn't realise there was an issue here, before; can you tell me if this is what you are talking about? --- module a.b.c; struct A {...} string toString(A) {...} --- module a.b; import a.b.c; class B { A getInstanceOfA() {...} } --- module b; import a.b; void main() { B b = new B(); auto a = b.getInstanceOfA(); string s = toString(a); // doesn't work } --- In this case, I can see it might be a surprise that it doesn't work, but is there anything worse than that? What's wrong with just importing a.b.c and carrying on? If you did any serious manipulations of 'a', then you would have to declare the type 'A' *sometime*; so you'd end up importing a.b.c anyway... I'm just taking a guess at what you mean, though; if I'm completely off, can you please explain?
I think that's ok, insofar as what you've written. What you can't do is import more than one version of toString, even if they are unabmiguous w.r.t. the usual overloading rules: ---- module a; struct A { ... } string toString(A) { ... } ---- module b; struct B { ... } string toString(B) { ... } ---- import a; import b; void main() { } ---- That fails just importing the two modules, so I didn't bother actually trying to call the toString methods. The above would work fine if you had the two flavors of 'toString' all consolidated in one module. It would also work fine with 'static import' and explicit use of a.toString and b.toString. But what doesn't work is resolving an overload to different modules based on the argument type. Apparently it's a big hairy deal to implement and the bane of compiler-writers' existence. But C++ allows it. Walter believes it's not necessary, though. And so far he seems right. But it does mean you need to put some things inside classes (like toString) that could be free functions if protection levels were the only concern. --bb
Jul 17 2007
prev sibling next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Robert,

 This is already possible via template mixins (sort of, but alias
 template params are required to access fields), but explicit partials
 might be quite helpful.
IIRC this works. Or did I misread you? template Foo() { int get(){ return foo; } void set foo(int i){foo = i;} } class Bar { int foo; mixin foo!(); }
Jul 17 2007
parent Robert Fraser <fraserofthenight gmail.com> writes:
BCS Wrote:

 Reply to Robert,
 
 This is already possible via template mixins (sort of, but alias
 template params are required to access fields), but explicit partials
 might be quite helpful.
IIRC this works. Or did I misread you? template Foo() { int get(){ return foo; } void set foo(int i){foo = i;} } class Bar { int foo; mixin foo!(); }
Yup; that's what I'm doing now.
Jul 17 2007
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
janderson Wrote:

 Classes should be small and as minimal as possible.  I think this is 
 part of Meyers argument.  Anything that can be placed outside the class 
 should be.  If it can't because that gives assess to something that 
 could potentially be misused by the world outside the class, thats a 
 case to make it a member.  Therefore you get this highly easy to use 
 class that is less bug prone.  It knows what is job is, its small so its 
 easy to maintain.
 
I agree so far...
 In particular the getter/setter/property pattern is
 encouraged by such a design, and overuse of this pattern can degrade a
 class to a simple aggregation of data, defeating the purpose of
 encapsulation entirely.
 
This is true. I don't think the example of a point was the best example. Herb Sutter and Bjarne Stroustrup's often argue that if the class variables have not constraints (invariants) then the class should really be a C struct (where everything is public).
I disagree here, because you are making the assumption that there will never be a need to refactor (with D's property syntax, this is somewhat mitigated since a public field can be turned into a method without breaking client code, however if something that was a stack-allocated class later needs to be given dynamic dispatch, this is not as much as possibility). Further, however, this mindset encourages thinking of classes/structs as aggregations of data. For a better example than a point, think about an AST node in a compiler (what I was thinking about when I wrote the OP, though now we're pretty off-topic). A generalized AST node will have a set of children and a parent, and a subclass implementing a conditional expression may have a condition, a then expresson and an else expression. It's possible that all this should be properties with getters and setters. However, if you think more deeply about it (I'd suggest staring at a picture of a bonsai tree...), the parent, condition, then expression and else expression will only be set once, and, depending on how you generate the tree, this may be at construction time. So, having setters for these properties is unnecessary and potentially dangerous if other coders will be using your class. In fact, very few classes I write have explicit getters/setters/properties. Classes, IMO, are aggregations of methods, not data, and the data serves to hold state relating to invocations of those methods. Which, I guess, is the main philosophical difference between the ways we approach defined types. I (coming from a Java/C# background), quite simply don't use free functions except in very rare situations where they don't fit within a class. There's room for two different kinds of programmers in this world.
 2. The architecture is less nimble for client code. If a function
 that at one time needed only access to the public interface later
 needs member access, the non-member function will become a simple
 proxy for the member function, or, worse, the public interface could
 be expanded.
But this is a good thing. It means you either have to go back to the drawing board with the class interface or add the non-member into the interface. Its pretty easy to remove a non-member function. Its much harder to remove a function once it becomes part of a class. Note that if you want to extend a class there are other ways to do it (namely using a component).
Why is it easier to remove a non-member function than a member function? Client code relying on the function will break either way.
 Also if you find your creating proxies, then there was probably 
 something wrong with the design in the first place.
Initially, yes. But if you're refactoring your code and something that was a free function needs to become a method (needs access to private members), what other choice do you have (if client code is already using the function)?
 But to each his own, I guess. That article certainly had some good
 points.
 
 That said, I was thinking about partial class implementation mainly
 with regards to related virtual functions (i.e. Implementing the same
 abstract/interface/override function across multiple subclasses all
 in the same file, while other parts of those classes are defined
 elsewhere. This will help logically group large class hierarchies,
 IMO.
While I'm not against the idea. I think, its a much better idea to have lots of small cohesive component classes rather then a large class. I've seen so many large classes and I've always been able to break them down into small chunks. I must admit though it can sometimes be quicker in the short run to simply throw everything into the same class.
I didn't mean a large class, I meant a large class _hierarchy_ (of smaller classes). I was thinking specifically about how, in the DMD source code, Walter added the inlineCost method to every AST node in a single file (inline.c), which, IMO, is cleaner than implementing the inlineCost method along with all the other stuff relating to that AST node. Simpler example, to make it clear what I meant (assume these classes are large enough to justify being in separate modules): Version 1 (now): ------------- module animals.core; interface IHungryAnimal { public void eat(); } ---------- module animals.mammals; class Bat : IHungryAnimal { public void fly() { ... } public void eat() { ... } } -------------- module animals.anphibiphans; class Frog : IHungryAnimal { public void ribbit() { ... } public void eat() { ... } } ++++++++++++++++ ++++++++++++++++ ++++++++++++++++ Version 2 (With partial classes): -------------- module animals.mammals; partial class Bat { void fly() { ... } } -------------- module animals.anphibiphans; partial class Frog { void ribbit() { ... } } ------------- module animals.eating; interface IHungryAnimal { public void eat(); } partial class Bat : IHungryAnimal { public void eat { ... } } partial class Frog : IHungryAnimal { public void eat { ... } }
Jul 17 2007
next sibling parent reply James Dennett <jdennett acm.org> writes:
Robert Fraser wrote:
 janderson Wrote:
 
 Classes should be small and as minimal as possible.  I think this is 
 part of Meyers argument.  Anything that can be placed outside the class 
 should be.  If it can't because that gives assess to something that 
 could potentially be misused by the world outside the class, thats a 
 case to make it a member.  Therefore you get this highly easy to use 
 class that is less bug prone.  It knows what is job is, its small so its 
 easy to maintain.
I agree so far...
 In particular the getter/setter/property pattern is
 encouraged by such a design, and overuse of this pattern can degrade a
 class to a simple aggregation of data, defeating the purpose of
 encapsulation entirely.
This is true. I don't think the example of a point was the best example. Herb Sutter and Bjarne Stroustrup's often argue that if the class variables have not constraints (invariants) then the class should really be a C struct (where everything is public).
I disagree here, because you are making the assumption that there will never be a need to refactor
No such assumption is present. In fact, quite the reverse; KISS helps to keep refactoring easy, by dumping unnecessary complexity that impedes change. And also for one more reason, that you touch on further down...
 (with D's property syntax, this is somewhat mitigated since a
 public field can be turned into a method without breaking client
 code, however if something that was a stack-allocated class later
 needs to be given dynamic dispatch, this is not as much as possibility).
 
 Further, however, this mindset encourages thinking of classes/structs
 as aggregations of data.
It doesn't, but that's the reason why it's helpful when keeping code amenable to refactoring. Sometimes types are present to express behavior. Those should be designed in terms of operations, with the representaton of their state hidden. Other types genuinely are just collections of data. Such are rarer than beginner programmers tend to think, but more common than many OO textbooks would tend to admit. It's the "mere aggregations of data" that are mostly clearly expressed in terms of data. It's true that once in a while, during evolution of a system, something that was just dumb data turns out to be usefully converted into a smarter object. If you ruthlessly kept your code simple (e.g., by using simple structs where appropriate) then (in C++ at least) it's trivial to make such a change (as C++ has less difference between struct and class than current D). If you build in speculative complexity in case of change, you ironically end up making evolution harder. (This is one of the pieces of XP that I've found has held up well in the face of experience and experimentation.)
 For a better example than a point, think
 about an AST node in a compiler (what I was thinking about
 when I wrote the OP, though now we're pretty off-topic).
 A generalized AST node will have a set of children and a
 parent, and a subclass implementing a conditional expression
 may have a condition, a then expresson and an else expression.
 It's possible that all this should be properties with getters
 and setters. However, if you think more deeply about it (I'd
 suggest staring at a picture of a bonsai tree...), the parent,
 condition, then expression and else expression will only be set
 once, and, depending on how you generate the tree, this may be
 at construction time. So, having setters for these properties
 is unnecessary and potentially dangerous if other coders will
 be using your class.
Right; a bunch of setters/getters is worse than either (a) a simple data object or (b) an object exposing behavior and hiding unnecessary access to its state.
 In fact, very few classes I write have explicit getters/setters
 /properties. Classes, IMO, are aggregations of methods, not data,
 and the data serves to hold state relating to invocations of
 those methods.
That's the common case; I think Bjarne, Herb, Scott etc. are assuming that you know this, and highlighting the exceptions. -- James
Jul 17 2007
parent janderson <askme me.com> writes:
James Dennett wrote:
 Robert Fraser wrote:
 janderson Wrote:

 Classes should be small and as minimal as possible.  I think this is 
 part of Meyers argument.  Anything that can be placed outside the class 
 should be.  If it can't because that gives assess to something that 
 could potentially be misused by the world outside the class, thats a 
 case to make it a member.  Therefore you get this highly easy to use 
 class that is less bug prone.  It knows what is job is, its small so its 
 easy to maintain.
I agree so far...
 In particular the getter/setter/property pattern is
 encouraged by such a design, and overuse of this pattern can degrade a
 class to a simple aggregation of data, defeating the purpose of
 encapsulation entirely.
This is true. I don't think the example of a point was the best example. Herb Sutter and Bjarne Stroustrup's often argue that if the class variables have not constraints (invariants) then the class should really be a C struct (where everything is public).
I disagree here, because you are making the assumption that there will never be a need to refactor
No such assumption is present. In fact, quite the reverse; KISS helps to keep refactoring easy, by dumping unnecessary complexity that impedes change. And also for one more reason, that you touch on further down...
 (with D's property syntax, this is somewhat mitigated since a
 public field can be turned into a method without breaking client
 code, however if something that was a stack-allocated class later
 needs to be given dynamic dispatch, this is not as much as possibility).

 Further, however, this mindset encourages thinking of classes/structs
 as aggregations of data.
It doesn't, but that's the reason why it's helpful when keeping code amenable to refactoring. Sometimes types are present to express behavior. Those should be designed in terms of operations, with the representaton of their state hidden. Other types genuinely are just collections of data. Such are rarer than beginner programmers tend to think, but more common than many OO textbooks would tend to admit. It's the "mere aggregations of data" that are mostly clearly expressed in terms of data. It's true that once in a while, during evolution of a system, something that was just dumb data turns out to be usefully converted into a smarter object. If you ruthlessly kept your code simple (e.g., by using simple structs where appropriate) then (in C++ at least) it's trivial to make such a change (as C++ has less difference between struct and class than current D). If you build in speculative complexity in case of change, you ironically end up making evolution harder. (This is one of the pieces of XP that I've found has held up well in the face of experience and experimentation.)
 For a better example than a point, think
 about an AST node in a compiler (what I was thinking about
 when I wrote the OP, though now we're pretty off-topic).
 A generalized AST node will have a set of children and a
 parent, and a subclass implementing a conditional expression
 may have a condition, a then expresson and an else expression.
 It's possible that all this should be properties with getters
 and setters. However, if you think more deeply about it (I'd
 suggest staring at a picture of a bonsai tree...), the parent,
 condition, then expression and else expression will only be set
 once, and, depending on how you generate the tree, this may be
 at construction time. So, having setters for these properties
 is unnecessary and potentially dangerous if other coders will
 be using your class.
Right; a bunch of setters/getters is worse than either (a) a simple data object or (b) an object exposing behavior and hiding unnecessary access to its state.
 In fact, very few classes I write have explicit getters/setters
 /properties. Classes, IMO, are aggregations of methods, not data,
 and the data serves to hold state relating to invocations of
 those methods.
That's the common case; I think Bjarne, Herb, Scott etc. are assuming that you know this, and highlighting the exceptions. -- James
I couldn't have put it better. Thanks James.
Jul 19 2007
prev sibling parent reply janderson <askme me.com> writes:
Robert Fraser wrote:
 janderson Wrote:
 
 Classes should be small and as minimal as possible.  I think this is 
 part of Meyers argument.  Anything that can be placed outside the class 
 should be.  If it can't because that gives assess to something that 
 could potentially be misused by the world outside the class, thats a 
 case to make it a member.  Therefore you get this highly easy to use 
 class that is less bug prone.  It knows what is job is, its small so its 
 easy to maintain.
I agree so far...
 In particular the getter/setter/property pattern is
 encouraged by such a design, and overuse of this pattern can degrade a
 class to a simple aggregation of data, defeating the purpose of
 encapsulation entirely.
This is true. I don't think the example of a point was the best example. Herb Sutter and Bjarne Stroustrup's often argue that if the class variables have not constraints (invariants) then the class should really be a C struct (where everything is public).
 
 I disagree here, because you are making the assumption that there
 will
never be a need to refactor (with D's property syntax, this is somewhat mitigated since a public field can be turned into a method without breaking client code, however if something that was a stack-allocated class later needs to be given dynamic dispatch, this is not as much as possibility). Your right that this is a difference from C++ and D. However its still possible to make the struct a component of a class. That way you still keep the functionality of the struct. Actually this is the recommend way of solving that problem in C++.
 
 Further, however, this mindset encourages thinking of classes/structs
 
 as aggregations of data. For a better example than a point, think about
 an AST node in a compiler (what I was thinking about when I wrote the
 OP, though now we're pretty off-topic). A generalized AST node will have
 a set of children and a parent, and a subclass implementing a
 conditional expression may have a condition, a then expresson and an
 else expression. It's possible that all this should be properties with
 getters and setters. However, if you think more deeply about it (I'd
 suggest staring at a picture of a bonsai tree...), the parent,
 condition, then expression and else expression will only be set once,
 and, depending on how you generate the tree, this may be at construction
 time. So, having setters for these properties is unnecessary and
 potentially dangerous if other coders will be using your class.
Yes this is a reasonable example. The use of getters/setters is useful for restricting use of the data to prevent bugs. Its also useful for changing the integrals of the object but keeping the same interface. For instance if you decide that you wish to change your internal matrix representation to a quaternion and a vector. A great thing about D (and C#) is that you can add them properties later.
 
 In fact, very few classes I write have explicit
 getters/setters/properties. Classes, IMO, are aggregations of methods,
 not data, and the data serves to hold state relating to invocations of
 those methods.
 
 Which, I guess, is the main philosophical difference between the ways
 we approach defined types. I (coming from a Java/C# background), quite
 simply don't use free functions except in very rare situations where
 they don't fit within a class. There's room for two different kinds of
 programmers in this world.
Although you can simulate free functions in these languages they don't make it easy. In my option its not wrong to use a highly OO techniques can get you where u want to go. However if you have a multi-paradigm language like D or C++ you can take advantage of both sides.
 
 2. The architecture is less nimble for client code. If a function
 that at one time needed only access to the public interface later
 needs member access, the non-member function will become a simple
 proxy for the member function, or, worse, the public interface could
 be expanded.
But this is a good thing. It means you either have to go back to the drawing board with the class interface or add the non-member into the interface. Its pretty easy to remove a non-member function. Its much harder to remove a function once it becomes part of a class. Note that if you want to extend a class there are other ways to do it (namely using a component).
Why is it easier to remove a non-member function than a member function? Client code relying on the function will break either way.
1) free-functions are not tied to their data types. You can easily change the parameters to meet the goals of the function. For instance if you decide you don't need that class anymore, you may still beable to change the function to something without that class. 2) Consider a function that takes 2 or more classes, which object does it belong to? 3) Templates are a great example of the reusabilty of free functions. It should be possible to replace any free-function with a template or overload (one nasty thing about D is you have to either create different names for overloads or alias them in). 4) When you inherit from a class if you have a lot of publics that should be free functions then your going to have to maintain them in the child class as well. (I also recommend not using inheritance for reuse, but for polymorphic type operations.) 5) Putting a method inside a class gives you access to all of its private data. Now if you choose to go completely though the public data and are rigorous about that then the class will be less error prone because your sub-set of methods you call should be really solid. However how do you tell which is your subset if they are all in the same class? How do ensure that a method doesn't suddenly . Free functions automatically have this constraint. When you've got a solid subset that you don't have to worry about that abstraction any more. 6) Adding member functions that really should be free functions will increase the size of the class. Its harder to unit test large classes. 7) You can't take the class and use it in another project so easily because the member-functions (which should be free) may be coupling it to other things. There's a couple of more points I think I've missed. If you want an in depth look into this I'd recommend Exceptional C++ by Herb Sutter. -- Now I should point out like I said before, if you don't have access to the internals of a class because they are being protected for integrity reasons (this is a good thing) then it should be private.
 
 Also if you find your creating proxies, then there was probably 
 something wrong with the design in the first place.
Initially, yes. But if you're refactoring your code and something that was a free function needs to become a method (needs access to private members), what other choice do you have (if client code is already using the function)?
Normally this would only occur of the interface of the class changes. If the interface of the class does change you'll be told about possible issues like this from the compiler. If it was inside the class, its possible the code code may become invade without your knowledge (since it seems like a reasonable large change to the interface of the class). You can as you suggested always write a wrapper if necessary. However a free-function will normally be doing more then a simple operation. Normally you'll find you'll need to provide a way to modify or read this internal value one way or another from the outside (note I'm not saying directly). I could make the argument the other way what if the class changed you want to do the operations on. Do you remove the method from the other class and create a new one in the new class?
 
 But to each his own, I guess. That article certainly had some good
 points.
This walking-the-OO-line a well known C++ verse Java debate. I can't say I side with the Java side because most of the opponents haven't used C++ at least in this way (the same can't be said about C++ programmers). I used to be very OO but personally I've come to see this sort of coding works a lot better for me. Its a big learning step, which requires an adjustment in thinking. Its also a common interview question. So I'm no saying your wrong, I'm just saying this is why I code this way. Either way its always good to have a overall plan when you code. And its great that your thinking about this sort of high level stuff. This is the sort of thing I think "style-guides" should be about rather then how many spaces you put in front of your methods ;) I hope that helps.
Jul 18 2007
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Hi Joel,

This is quite the interesting thread; these are the sort of issues I'd like to
confront before I start on a larger D project.

 Yes this is a reasonable example.  The use of getters/setters is useful 
 for restricting use of the data to prevent bugs.  Its also useful for 
 changing the integrals of the object but keeping the same interface. 
 For instance if you decide that you wish to change your internal matrix 
 representation to a quaternion and a vector.
 
 A great thing about D (and C#) is that you can add them properties later.
Indeed, my company style guide requires that getters/setters exist for all variables, most of which are private and used internally by other methods of the class. These and the constructors are the only methods allowed to refer to the variables directly. Personally, I find this going _way_ overboard (plus, the class internals start to get out of sync if legacy properties are supported for non-existent fields), but it's actually saved me once or twice.
 4) When you inherit from a class if you have a lot of publics that 
 should be free functions then your going to have to maintain them in the 
 child class as well. (I also recommend not using inheritance for reuse, 
 but for polymorphic type operations.)
Agreed. IMO, composition is almost always preferable to inheritance if virtual dispatch is not necessary.
 This walking-the-OO-line a well known C++ verse Java debate.  I can't 
 say I side with the Java side because most of the opponents haven't used 
 C++ at least in this way (the same can't be said about C++ programmers).
 
It's true I haven't used C++ outside a couple projects for school. I have used C before (since the tender age of 12; it was the first language I learned), and found the organizational benefits offered by OO very compelling. But since I haven't used a strongly-typed language supporting both free functions and class methods for any appreciable project (well, I'm working on one medium-sized one in D right now using only classes so far), I don't really know what I'm talking about. So I'm willing to give this whole free-function thing a try and see how it goes. Thanks for walking me through all that.
 Its also a common interview question.
So am I supposed to say "OO all the way!" or "free functions need love, too"? - Fraser
Jul 19 2007
next sibling parent janderson <askme me.com> writes:
Robert Fraser wrote:
 Its also a common interview question.
So am I supposed to say "OO all the way!" or "free functions need love, too"?
It depends where your interviewing, the style the company uses. They simply want to know how well you'll work the the teams style. Most C++ companies will want you to explain when free-functions are useful and when methods are more useful. To show that you understand how to maximize their benefits and design strongly typed code. "OO all the way!" would be a big mark (at the least) against getting a more senior position.
 
 - Fraser
Jul 20 2007
prev sibling parent reply janderson <askme me.com> writes:
Robert Fraser wrote:
 Hi Joel,
 
 Indeed, my company style guide requires that getters/setters exist for all
variables, most of which are private and used internally by other methods of
the class. These and the constructors are the only methods allowed to refer to
the variables directly. Personally, I find this going _way_ overboard (plus,
the class internals start to get out of sync if legacy properties are supported
for non-existent fields), but it's actually saved me once or twice.
 
Personally I hate writing tons of getter setters. Its like smashing my head against concrete. I hate having to write 5 lines simply to add a new variable. Then if anything changes you've got 5 more lines per getter/setter to maintain. So I try to keep the number of setters low, most data private and have actually useful functions for managing them instead. Sometimes its possible to use a strut component (as a param to a setter or getter) to minimize getters setters. Many times I return a object which can be modified. That object has its own set of validations. Although I can see setter/getter they add superior interface benefits. I think programming is a balancing act in every reguard. -Joel
Jul 20 2007
parent Robert Fraser <fraserofthenight gmail.com> writes:
I agree, but with a good IDE, this is a non-issue. I refer to the fields
directly when I'm coding and run a 30 second refactoring in Eclipse to generate
getters and setters and refer to them instead of the field before I do a
check-in.

Still, there's something to be said for abstracting field access within a class
(although, again, D's property syntax makes this unnecessary.)

janderson Wrote:

 Robert Fraser wrote:
 Hi Joel,
 
 Indeed, my company style guide requires that getters/setters exist for all
variables, most of which are private and used internally by other methods of
the class. These and the constructors are the only methods allowed to refer to
the variables directly. Personally, I find this going _way_ overboard (plus,
the class internals start to get out of sync if legacy properties are supported
for non-existent fields), but it's actually saved me once or twice.
 
Personally I hate writing tons of getter setters. Its like smashing my head against concrete. I hate having to write 5 lines simply to add a new variable. Then if anything changes you've got 5 more lines per getter/setter to maintain. So I try to keep the number of setters low, most data private and have actually useful functions for managing them instead. Sometimes its possible to use a strut component (as a param to a setter or getter) to minimize getters setters. Many times I return a object which can be modified. That object has its own set of validations. Although I can see setter/getter they add superior interface benefits. I think programming is a balancing act in every reguard. -Joel
Jul 20 2007
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
James Dennett Wrote:

 That's the common case; I think Bjarne, Herb, Scott etc. are
 assuming that you know this, and highlighting the exceptions.
 
 -- James
Indeed, for the exceptional (mostly-data) types, working with external functions is probably better coding style. But this doesn't preclude partial class implementation.
Jul 18 2007
parent Robert Fraser <fraserofthenight gmail.com> writes:
Thinking about it more, though, this might break the existing module concept,
so... proposal retracted.

Robert Fraser Wrote:

 James Dennett Wrote:
 
 That's the common case; I think Bjarne, Herb, Scott etc. are
 assuming that you know this, and highlighting the exceptions.
 
 -- James
Indeed, for the exceptional (mostly-data) types, working with external functions is probably better coding style. But this doesn't preclude partial class implementation.
Jul 18 2007