On Wednesday, 6 November 2013 at 07:46:00 UTC, Jacob Carlborg
wrote:
> Which other languages? "private" in Ruby and Java is not the same.

The one's which implement private as meaning accessible to the
class only.

On Tue, 05 Nov 2013 16:00:41 -0000, bearophile <bearophileHUGS@lycos.com> wrote:

> 1) I usually write more than one class or struct inside each D module, unlike in Java. But sometimes when I move that class or struct elsewhere (during refactoring, or in other situations) I get access errors to private fields. Those errors were already in my code, but I didn't see them because "private" in D means module-private.
>
> 2) My unittests are useful to catch bugs when I run them at run-time, but they are also use to exercise code, this means to actually use it, and catch some bugs statically (instantiating templates, etc). But unfortunately such unittests can't catch protection bugs because most of my unittests are inside the same module, so "private" gets ignored.
>
> 3) A third problem with module-private is that newbies coming from Python, C, and other languages that don't have private/protected attributes and write little experimental D programs, have less chances to _learn_ the true semantics of the privacy attributes until they start to spread their classes in different modules.
>
> How to solve such little troubles? A possible idea is to add to D another attribute, a kind of "private private" that is enforced inside the same module. It could be named "super private" because D has the "super" keyword :-) But this idea doesn't solve all the problems, because sometimes you don't want to use a super private attribute.

I think a compiler flag is the best option.  The flag would cause warnings to appear for each "violation" of strict privacy between classes in the same module.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On 11/05/2013 05:00 PM, bearophile wrote:
> 1) I usually write more than one class or struct inside each D module,
> unlike in Java. But sometimes when I move that class or struct elsewhere
> (during refactoring, or in other situations) I get access errors to
> private fields. Those errors were already in my code, but I didn't see
> them because "private" in D means module-private.
>
> 2) My unittests are useful to catch bugs when I run them at run-time,
> but they are also use to exercise code, this means to actually use it,
> and catch some bugs statically (instantiating templates, etc). But
> unfortunately such unittests can't catch protection bugs because most of
> my unittests are inside the same module, so "private" gets ignored.
>
> 3) A third problem with module-private is that newbies coming from
> Python, C, and other languages that don't have private/protected
> attributes and write little experimental D programs, have less chances
> to _learn_ the true semantics of the privacy attributes until they start
> to spread their classes in different modules.
>
> How to solve such little troubles? A possible idea is to add to D
> another attribute, a kind of "private private" that is enforced inside
> the same module. It could be named "super private" because D has the
> "super" keyword :-) But this idea doesn't solve all the problems,
> because sometimes you don't want to use a super private attribute.
>
> Bye,
> bearophile

How about just adding full granularity?

By condition:

@visibleIf!true                         // public
@visibleIf!(isSubtypeOf!(typeof(this))) // protected

By explicit enumeration:

@visible!(getModule!(typeof(this))) // private
@visible!(typeof(this), T) // visible to type 'T'
@visible!(typeof(this)) // 'super private'
@visible!foo // only (member) function 'foo' can access it
@visible!() // nobody can access it

On Tuesday, 5 November 2013 at 21:01:40 UTC, John J wrote:
> On 11/05/2013 11:00 AM, bearophile wrote:
>> How to solve such little troubles? A possible idea is to add to D
>> another attribute, a kind of "private private" that is enforced inside
>> the same module. It could be named "super private" because D has the
>> "super" keyword :-) But this idea doesn't solve all the problems,
>> because sometimes you don't want to use a super private attribute.
>>
>
>
> How about "strict private"

I think "static private" is the best option (just kidding).

On Wednesday, 6 November 2013 at 12:19:26 UTC, Timon Gehr wrote:
> How about just adding full granularity?
>
> By condition:
>
> @visibleIf!true                         // public
> @visibleIf!(isSubtypeOf!(typeof(this))) // protected
>
> By explicit enumeration:
>
> @visible!(getModule!(typeof(this))) // private
> @visible!(typeof(this), T) // visible to type 'T'
> @visible!(typeof(this)) // 'super private'
> @visible!foo // only (member) function 'foo' can access it
> @visible!() // nobody can access it

Dear Santa,
...

On Tuesday, 5 November 2013 at 16:00:43 UTC, bearophile wrote:
> How to solve such little troubles? A possible idea is to add to D another attribute, a kind of "private private" that is enforced inside the same module. It could be named "super private" because D has the "super" keyword :-) But this idea doesn't solve all the problems, because sometimes you don't want to use a super private attribute.
>
> Bye,
> bearophile

I don't think such problems are valuable to solve.