July 28, 2009 Re: Developing a plan for D2.0: Getting everything on the table | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | Mon, 27 Jul 2009 07:59:40 -0500, Andrei Alexandrescu wrote:
>> Is it appropriate to define multiple classes, structs, templates, etc within a single module? What considerations should inform the decision regarding the placement of module boundaries?
>
> I think it's appropriate because many pieces of functionality come as a bundle. The rule of thumb is, module provides the functionality, and it's up to the designer to decide what that entails.
That's the problem. On one hand, it's desirable to see a module as a functionality bundle. On the other hand, module is the smallest available unit of encapsulation. That is, if you have a class and change its private implementation, this may affect *anything* in the same module. Hence Tango's hundreds of modules in dozens of packages, I think.
It also adds to the problem that most people familiar with OO paradigm consider classes to be such encapsulation units. Surprizes are inevitable.
|
July 28, 2009 Re: Developing a plan for D2.0: Getting everything on the table | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sergey Gromov | Sergey Gromov wrote: > Mon, 27 Jul 2009 07:59:40 -0500, Andrei Alexandrescu wrote: > >>> Is it appropriate to define multiple classes, structs, templates, etc within a single module? What considerations should inform the decision regarding the placement of module boundaries? >> I think it's appropriate because many pieces of functionality come as a bundle. The rule of thumb is, module provides the functionality, and it's up to the designer to decide what that entails. > > That's the problem. On one hand, it's desirable to see a module as a > functionality bundle. On the other hand, module is the smallest > available unit of encapsulation. That is, if you have a class and > change its private implementation, this may affect *anything* in the > same module. Hence Tango's hundreds of modules in dozens of packages, I > think. I guess that's meant to encourage you to keep your modules small enough that you know what you're doing. At the smallest level, it would be a matter of: If in C++ you would declare Qwert to be a friend of Yuiop, then in D you put Qwert and Yuiop in the same module. You could implement the converse as well, but for a bunch of small classes it usually isn't worth it. > It also adds to the problem that most people familiar with OO paradigm > consider classes to be such encapsulation units. Surprizes are > inevitable. I once came up with the idea a 'veryprivate' protection attribute that would do this, but I can't seem to find the post now. Stewart. |
July 28, 2009 Re: Developing a plan for D2.0: Getting everything on the table | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stewart Gordon | On Tue, Jul 28, 2009 at 4:42 PM, Stewart Gordon<smjg_1998@yahoo.com> wrote:
> Sergey Gromov wrote:
>>
>> Mon, 27 Jul 2009 07:59:40 -0500, Andrei Alexandrescu wrote:
>>
>>>> Is it appropriate to define multiple classes, structs, templates, etc within a single module? What considerations should inform the decision regarding the placement of module boundaries?
>>>
>>> I think it's appropriate because many pieces of functionality come as a bundle. The rule of thumb is, module provides the functionality, and it's up to the designer to decide what that entails.
>>
>> That's the problem. On one hand, it's desirable to see a module as a functionality bundle. On the other hand, module is the smallest available unit of encapsulation. That is, if you have a class and change its private implementation, this may affect *anything* in the same module. Hence Tango's hundreds of modules in dozens of packages, I think.
>
> I guess that's meant to encourage you to keep your modules small enough that you know what you're doing.
>
> At the smallest level, it would be a matter of: If in C++ you would declare Qwert to be a friend of Yuiop, then in D you put Qwert and Yuiop in the same module. You could implement the converse as well, but for a bunch of small classes it usually isn't worth it.
>
>> It also adds to the problem that most people familiar with OO paradigm consider classes to be such encapsulation units. Surprizes are inevitable.
>
> I once came up with the idea a 'veryprivate' protection attribute that would do this, but I can't seem to find the post now.
"super private" :-)
Sorry I just can't let that old idea to call immutable "super const" die. It was just too darn cute.
--bb
|
July 29, 2009 Re: Developing a plan for D2.0: Getting everything on the table | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stewart Gordon | Wed, 29 Jul 2009 00:42:31 +0100, Stewart Gordon wrote: > Sergey Gromov wrote: >> Mon, 27 Jul 2009 07:59:40 -0500, Andrei Alexandrescu wrote: >> >>>> Is it appropriate to define multiple classes, structs, templates, etc within a single module? What considerations should inform the decision regarding the placement of module boundaries? >>> I think it's appropriate because many pieces of functionality come as a bundle. The rule of thumb is, module provides the functionality, and it's up to the designer to decide what that entails. >> >> That's the problem. On one hand, it's desirable to see a module as a functionality bundle. On the other hand, module is the smallest available unit of encapsulation. That is, if you have a class and change its private implementation, this may affect *anything* in the same module. Hence Tango's hundreds of modules in dozens of packages, I think. > > I guess that's meant to encourage you to keep your modules small enough that you know what you're doing. Yes you can do a finer-grained encapsulation, but then you end up without "functionality bundle." And even if you create a collective import module I think there is no way to make it stand out as such. Though this is no different from C. > At the smallest level, it would be a matter of: If in C++ you would declare Qwert to be a friend of Yuiop, then in D you put Qwert and Yuiop in the same module. You could implement the converse as well, but for a bunch of small classes it usually isn't worth it. This is understandable. >> It also adds to the problem that most people familiar with OO paradigm consider classes to be such encapsulation units. Surprizes are inevitable. > > I once came up with the idea a 'veryprivate' protection attribute that would do this, but I can't seem to find the post now. I wonder how much code will break if "private" keyword becomes really private. You can always implement tight coupling with package visibility which C++ lacks. |
Copyright © 1999-2021 by the D Language Foundation