View mode: basic / threaded / horizontal-split · Log in · Help
July 28, 2009
Re: Developing a plan for D2.0: Getting everything on the table
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
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
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
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.
Next ›   Last »
1 2 3 4
Top | Discussion index | About this forum | D home