On Thursday, 19 March 2015 at 23:02:07 UTC, w0rp wrote:
On Thursday, 19 March 2015 at 20:43:55 UTC, Almighty Bob wrote:
On Thursday, 19 March 2015 at 10:07:06 UTC, John Colvin wrote:
On Tuesday, 17 March 2015 at 18:29:20 UTC, Almighty Bob wrote:
On Tuesday, 17 March 2015 at 11:48:15 UTC, Nick Treleaven
wrote:
On 17/03/2015 10:31, Almighty Bob wrote:
It's far more useful for csvReader to return a type I know
and
can use than it is to obscure the return type for the sake
of
some philosophical ideal of increasing encapsulation.
Part of the art of API design is to hide implementation
where it's not necessarily needed. Designers might err on
the side of hiding things, because how you expose something
is important as it has to be maintained indefinitely. If
they expose everything then the internals can never be
redesigned for better performance, etc.
They don't increase encapsulation. The public members of a
voldomort type are still public, you still have to code to
the API of the return type whether it's a regular or
voldomort type. You can keep as much private or public in
either case as you like.
All they do take the typename out of circulation, they make
life harder for the user. There's no benefit. None.
But at least the library author can stroke his chin a feel
smug that there's one less type in the modules' namespace.
Totally missing the point. The crux of the matter is this:
changing a voldemort type (assuming the public semantics are
the same) is not a breaking API change, because no-one else's
code ever names it.
Seriously? You cant have a public API and private
implementation with a regular type? That's something specific
to voldomort types?
Ask yourself what exactly do voldomort types enable you to
hide that cant be hidden with a regular type? Just one thing.
Their name. As you said no one else can ever name the type.
That is no benefit to me the user. No-one has been able to
even describe a benefit. Walters article on Dr Dobbs doesn't
describe a benefit. It "increases encapsulation" you all
squawk.
No it doesn't. The private bits are still private, the public
bits are still public.
All it does is complicate the user side.
Its the emperor's new clothes.
It's not possible to construct a voldemort type outside of the
function where it was declared, and you can't know what that
type is, just what the API is. You can force type deduction so
the type returned can be changed without breaking code, so long
as the API is the same. That's how it increases encapsulation.
voldemort types sort of feel like a hack to work around the lack
of real compile-time interfaces(concepts,) the same thing IMO
currently plaguing template constraints and honestly causes a lot
of compiler errors to be confusing.
I believe a few major patches in phobos were related to removing
constraints and rewriting them as static asserts for better error
handling.
see:
http://forum.dlang.org/thread/jronroxajqkrqitxw...@forum.dlang.org
