Re: Small troubles with private
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.
Re: Small troubles with private
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.
Re: Small troubles with private
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.
Re: Small troubles with private
On Tue, 05 Nov 2013 16:00:41 -, bearophile bearophileh...@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/
Re: Small troubles with private
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
Re: Small troubles with private
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).
Re: Small troubles with private
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, ...
Small troubles with private
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
Re: Small troubles with private
On Tuesday, 5 November 2013 at 16:59:09 UTC, Gary Willoughby wrote: IMHO private should mean private as enforced by other languages and use another keyword for module level privacy. 'internal' springs to mind. This will of course cause breakage! :/
Re: Small troubles with private
On Tuesday, 5 November 2013 at 16:00:43 UTC, 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 IMHO private should mean private as enforced by other languages and use another keyword for module level privacy. 'internal' springs to mind.
Re: Small troubles with private
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
Re: Small troubles with private
On 2013-11-05 17:40, bearophile wrote:
void foo() {
...
} unittest {
...
}
As soon as you want to do something more advanced than plain unit tests
that doesn't scale very well.
Even doing unit tests it's harder to take advantage of setting up before
and after callbacks that are shared between many tests.
--
/Jacob Carlborg
Re: Small troubles with private
On 2013-11-05 17:59, Gary Willoughby wrote: IMHO private should mean private as enforced by other languages and use another keyword for module level privacy. 'internal' springs to mind. Which other languages? private in Ruby and Java is not the same. -- /Jacob Carlborg
