On Fri, Sep 13, 2013 at 10:49:23PM -0400, Jonathan M Davis wrote: > On Saturday, September 14, 2013 04:10:09 Jesse Phillips wrote: > > Anyway, my recommendation isn't to build up a class structure > > just because that is what you would do in another language. > > Figure out if the usability provided by inheritance is what you > > want, if not struct with helper functions seems to be simplest in > > development and maintenance. Destroy. > > I find that I use classes very rarely in D. Once in a while, I need > polymorphism, and in that situation, I use classes, but at least in > the types of programs that I've usually been writing, polymorphism has > rarely made much sense. Structs deal with most everything just fine. > > Classes definitely have their uses, but IMHO, they should not be the > first tool to pull out of your toolbox when writing a D program. Just > use them when you actually need them. [...]
I've found myself hovering between structs and classes when writing D code. I almost always use structs for ranges, just because value types incur less overhead, which does add up when you use a lot of UFCS chaining. OTOH, I find myself switching to classes just to get the reference semantics in other cases, even if I never actually do any inheritance. Trying to do reference semantics with structs, while certainly possible, is just too error-prone IME. Just a few days ago, I encountered what looked like a nasty functionality bug in my program, only to eventually discover that it was caused by a missing 'ref' in a function's struct parameter, so updates to the struct didn't persist as the code assumed it would. I found myself seriously considering using classes instead, just for the default ref semantics. While D's decision to make structs value-only and classes ref-only is certainly clever, it also introduces some tricky gotchas for the unwary. T -- May you live all the days of your life. -- Jonathan Swift
