A few notes on choosing between Go and D for a quick project
weaselcat via Digitalmars-d
digitalmars-d at puremagic.com
Thu Mar 19 16:29:20 PDT 2015
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
>>>>> On 17/03/2015 10:31, Almighty Bob wrote:
>>>>>> It's far more useful for csvReader to return a type I know
>>>>>> can use than it is to obscure the return type for the sake
>>>>>> 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
>> 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
More information about the Digitalmars-d