www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Some things to fix

reply Ary Borenszweig <ary esperanto.org.ar> writes:
1. private applied to structs, classes, etc., doesn't have any effect: I 
can access them anyway.
2. modifiers that don't make sense should be disallowed.

I think these are pretty serious bugs (specially the first one). Why new 
features are added to D and these things are not getting fixed?
Jul 30 2009
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 30 Jul 2009 12:04:54 -0400, Ary Borenszweig <ary esperanto.org.ar>  
wrote:

 1. private applied to structs, classes, etc., doesn't have any effect: I  
 can access them anyway.
 2. modifiers that don't make sense should be disallowed.

 I think these are pretty serious bugs (specially the first one). Why new  
 features are added to D and these things are not getting fixed?

1 is not a problem unless you are in the same file. Any classes/functions compiled in the same module are considered to be part of the same module of code, and therefore have access to eachothers private data. Try accessing same private fields from outside the module. -Steve
Jul 30 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Steven Schveighoffer wrote:
 On Thu, 30 Jul 2009 12:04:54 -0400, Ary Borenszweig 
 <ary esperanto.org.ar> wrote:
 
 1. private applied to structs, classes, etc., doesn't have any effect: 
 I can access them anyway.
 2. modifiers that don't make sense should be disallowed.

 I think these are pretty serious bugs (specially the first one). Why 
 new features are added to D and these things are not getting fixed?

1 is not a problem unless you are in the same file. Any classes/functions compiled in the same module are considered to be part of the same module of code, and therefore have access to eachothers private data. Try accessing same private fields from outside the module.

That's exactly what I'm saying. --- module one; private struct Foo {} --- module two; import one; Foo foo; --- Compiles without errors.
Jul 30 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Steven Schveighoffer wrote:
 On Thu, 30 Jul 2009 12:17:53 -0400, Ary Borenszweig 
 <ary esperanto.org.ar> wrote:
 
 Steven Schveighoffer wrote:
 On Thu, 30 Jul 2009 12:04:54 -0400, Ary Borenszweig 
 <ary esperanto.org.ar> wrote:

 1. private applied to structs, classes, etc., doesn't have any 
 effect: I can access them anyway.
 2. modifiers that don't make sense should be disallowed.

 I think these are pretty serious bugs (specially the first one). Why 
 new features are added to D and these things are not getting fixed?

classes/functions compiled in the same module are considered to be part of the same module of code, and therefore have access to eachothers private data. Try accessing same private fields from outside the module.

That's exactly what I'm saying. --- module one; private struct Foo {} --- module two; import one; Foo foo; --- Compiles without errors.

Oh, I read private applied to struct/class *members* sorry...

Yeah, I didn't write "from other modules", so I wasn't clear enough.
 
 I agree private classes/structs should work.  I'm sure there's a 
 bugzilla for it already.

There are several now about protection attributes not working as expected: http://d.puremagic.com/issues/show_bug.cgi?id=1161 http://d.puremagic.com/issues/show_bug.cgi?id=1567 http://d.puremagic.com/issues/show_bug.cgi?id=2225 http://d.puremagic.com/issues/show_bug.cgi?id=2830 http://d.puremagic.com/issues/show_bug.cgi?id=313 http://d.puremagic.com/issues/show_bug.cgi?id=314
Jul 30 2009
next sibling parent Jesse Phillips <jessekphillips+d gmail.com> writes:
Ary Borenszweig Wrote:

 
 There are several now about protection attributes not working as expected:
 
 http://d.puremagic.com/issues/show_bug.cgi?id=1161
 http://d.puremagic.com/issues/show_bug.cgi?id=1567
 http://d.puremagic.com/issues/show_bug.cgi?id=2225
 http://d.puremagic.com/issues/show_bug.cgi?id=2830
 http://d.puremagic.com/issues/show_bug.cgi?id=313
 http://d.puremagic.com/issues/show_bug.cgi?id=314

Added these to: http://d.puremagic.com/issues/show_bug.cgi?id=3108
Jul 30 2009
prev sibling parent Trass3r <mrmocool gmx.de> writes:
Ary Borenszweig schrieb:
 http://d.puremagic.com/issues/show_bug.cgi?id=314

That bug annoys me since 3 years! It seems like it has been (at least partly) fixed in LDC, that guy even posted the changesets...
Jul 30 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 30 Jul 2009 12:17:53 -0400, Ary Borenszweig <ary esperanto.org.ar>  
wrote:

 Steven Schveighoffer wrote:
 On Thu, 30 Jul 2009 12:04:54 -0400, Ary Borenszweig  
 <ary esperanto.org.ar> wrote:

 1. private applied to structs, classes, etc., doesn't have any effect:  
 I can access them anyway.
 2. modifiers that don't make sense should be disallowed.

 I think these are pretty serious bugs (specially the first one). Why  
 new features are added to D and these things are not getting fixed?

classes/functions compiled in the same module are considered to be part of the same module of code, and therefore have access to eachothers private data. Try accessing same private fields from outside the module.

That's exactly what I'm saying. --- module one; private struct Foo {} --- module two; import one; Foo foo; --- Compiles without errors.

Oh, I read private applied to struct/class *members* sorry... I agree private classes/structs should work. I'm sure there's a bugzilla for it already. -Steve
Jul 30 2009
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Ary Borenszweig wrote:
 2. modifiers that don't make sense should be disallowed.

There's been wars about this one. IMO, this is a good thing for writing templated/generic code -- if a modifier only makes sense in one instance of a template, all the others should not be marked as errors. I think _conflicting_ modifiers should be made an error, i.e. "public private int x;".
Jul 30 2009
parent reply Sjoerd van Leent <svanleent gmail.com> writes:
Robert Fraser Wrote:

 Ary Borenszweig wrote:
 2. modifiers that don't make sense should be disallowed.

There's been wars about this one. IMO, this is a good thing for writing templated/generic code -- if a modifier only makes sense in one instance of a template, all the others should not be marked as errors. I think _conflicting_ modifiers should be made an error, i.e. "public private int x;".

I disagree, what about: public { . . . private { } . . . } Perhaps a warning in obvious cases (public private) should be raised.
Jul 31 2009
parent Sergey Gromov <snake.scaly gmail.com> writes:
Fri, 31 Jul 2009 04:57:23 -0400, Sjoerd van Leent wrote:

 Robert Fraser Wrote:
 
 Ary Borenszweig wrote:
 2. modifiers that don't make sense should be disallowed.

There's been wars about this one. IMO, this is a good thing for writing templated/generic code -- if a modifier only makes sense in one instance of a template, all the others should not be marked as errors. I think _conflicting_ modifiers should be made an error, i.e. "public private int x;".

I disagree, what about: public { . . . private { } . . . } Perhaps a warning in obvious cases (public private) should be raised.

Even better: public: . . . private: . . .
Jul 31 2009