Wed Oct 17 - Avoiding Code Smells by Walter Bright

FooledDonor fooleddonor at gmail.com
Mon Nov 5 09:43:06 UTC 2018


On Monday, 5 November 2018 at 09:03:59 UTC, Stanislav Blinov 
wrote:
> On Monday, 5 November 2018 at 05:55:02 UTC, unprotected-entity 
> wrote:
>> On Saturday, 3 November 2018 at 21:28:22 UTC, Stanislav Blinov 
>> wrote:
>>>
>>> The only difference is that `func` became a member function. 
>>> And now what? You can just as easily "forget" what's in your 
>>> struct/class as in your whole module.
>>
>> ok. Now, what are your options then (assuming you want an 
>> independent type)?
>>
>> (option 1) define one encapsulated type, per module.
>> (option 2) have a means for type independence within a module 
>> - i.e. selective hiding.
>
> Option 3 - don't access private state unless you intend to. 
> That's literally how you write implementations, in pretty much 
> any language that has access modifiers.
>
>> D only gives you one choice here, not two.
>
> Nope. You can have a type spanning several modules. That's what 
> packages do, among other things.
>
>> I would say, that your response backs up my argument, that is, 
>> a second option might actually be worthwhile. perhaps, 
>> something like: __private
>
> No, it really doesn't. Your argument was that the programmer 
> might accidentally forget, and I've shown quite clearly that no 
> keyword is going to protect them from that. If you can forget 
> in module scope, you can forget in class scope. There can be 
> only one solution: don't forget. As in: stop inventing 
> imaginary examples. People, in practice, don't "accidentally" 
> modify the guts of their own types. That horse is quite dead, 
> I'm afraid.
>
>> (now __private is everything private already is, but 
>> additionally, its private outside the scope of the type 
>> declaring it, and now, you'd get a compile time guarantee of  
>> correctness - e.g. if you accidently tried to ignore that 
>> types independence.
>
> No, you do not. You still have that same "problem" inside the 
> type's definition.
>
>> It's call 'type encapsulation' ;-)
>
> If you're afraid of implicit conversions, define your own type 
> that disallows them, problem solved. Has nothing to do with 
> private. That is what's called 'type encapsulation'.

I'm glad you've worked only with excellent programmers, who in 
solitary write code in a module, knowing it to perfection, until 
the end of time.

And I'm also glad you did not have to debug inherited code, maybe 
before the packages existed, tens of thousands of lines, and to 
make sure you do not start you had to cut and sew classes and 
private structures, just to check that the intentions of the 
programmer, who perhaps was not as good as you are.

This your reiterate to every topic, thread, or question post on 
these forums with a "NO", is simply pathetic, as Manu has 
expounded a few weeks ago.

Get off your pedestal, and drop into the real life of those who 
program in D with colleagues not as perfect as you are.


More information about the Digitalmars-d-announce mailing list