Food for thought [generalizing array methods]

Mike Capp mike.capp at gmail.com
Mon Feb 12 15:57:13 PST 2007


> how much machinery would it entail to make [array
> methods] available to all basic types instead of
> just arrays?

If you're going to support it for arrays and basic types, why not go the whole hog
and support it for everything? This has a number of benefits:

1) Consistency, obviously.

2) Allows you to seamlessly extend a class (possibly one for which you don't have
source) without hurting encapsulation; everything has to go through the "real"
class interface, so all invariants should be covered by existing checks. Scott
Meyers was talking about this "minimal interface" ideal ages ago.

3) Greater discoverability and convenience in IDEs etc. You can type "myFoo." and
the tool can suggest "myFuncTakingFoo()". When the function comes first the tool
is faced with a blank slate; there's nothing to hang suggestions off.

Not sure what the costs would be, but I'd expect headaches with e.g. overload
resolution. I vaguely recall that Francis Glassborow had a similar C++0x proposal
a few years back and it didn't get much traction.

I suppose there'd also be a worry that this would allow member-function syntax
where it didn't make semantic sense. You wouldn't want to call write(bool
flushBuffers, string text) as true.write("hello"); There's a similar concern
already with class property syntax.



More information about the Digitalmars-d mailing list