Kris wrote:
> "Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:dn2o4p$2loa$1@digitaldaemon.com...
> 
>>"Derek Parnell" <derek@psych.ward> wrote in message news:1w14cf2n0yaen$.1fya63bj3ql24$.dlg@40tude.net...
>>
>>>There is no such thing as a final class or a
>>>private class in D.
>>
>>I really wish there were private classes..
>>
> 
> There are. You make the ctor private.
> 

Not a good solution. Conceptually, protection attributes should work the same for all named entities. (And things not being so, there are indeed practical problems that that solution does not solve.)


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

Bruno Medeiros wrote:
> Not a good solution. 

Correction, I meant: "Not a proper solution, just a workaround."


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

On Tue, 06 Dec 2005 21:34:59 +0000, Bruno Medeiros <daiphoenixNO@SPAMlycos.com> wrote:
> Kris wrote:
>> "Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:dn2o4p$2loa$1@digitaldaemon.com...
>>
>>> "Derek Parnell" <derek@psych.ward> wrote in message news:1w14cf2n0yaen$.1fya63bj3ql24$.dlg@40tude.net...
>>>
>>>> There is no such thing as a final class or a
>>>> private class in D.
>>>
>>> I really wish there were private classes..
>>>
>>  There are. You make the ctor private.
>>
>
> Not a good solution. Conceptually, protection attributes should work the same for all named entities.

While I agree with you...

<stop reading here unless you're interested in a little hair splitting>

I want to point out that I believe there is a conceptual difference between these:

int a;
class a {}

in the first an instance of an 'int' is created/requested. In the second a type 'a' is defined, but no instance is created/requested.

D seems to me to apply protection attributes to instances or parts of instances, eg.

class a {
  private int b;
}

but not to type definitions, eg.

private class a {}
private struct b {}
private typedef int mytype;
private alias int myalias;

Depending on your definition of "private" it's current behaviour can make perfect sense. Eg. "private" is an _access_ specifier it prevents _access_ to a <thing>, as a class definition is not accessed (as in, accessed in memory) thus private has no effect on it.

Compare "private" to "static" in C. Despite the documentation saying so, private is not the same as the "static" keyword in C. "static" in C prevents visibility, which in turn prevents access. "private" only prevents access, currently.

My impression is that most people would like "private" to treat instance and declarations the same. In most cases the desire is to prevent namespace pollution and/or to hide internal workings of something, which seems like a good idea to me. I can't really see the benefit in the current behaviour.

Regan

"Regan Heath" <regan@netwin.co.nz> wrote in message news:ops1dt67cg23k2f5@nrage.netwin.co.nz...
> My impression is that most people would like "private" to treat instance and declarations the same. In most cases the desire is to prevent namespace pollution and/or to hide internal workings of something, which seems like a good idea to me. I can't really see the benefit in the current behaviour.

Yeah, that's pretty much it.  I want to be able to keep certain things local to a module and not visible in any way to any other modules.  I think "private" fits the bill pretty well there.

Regan Heath wrote:
> My impression is that most people would like "private" to treat instance  and declarations the same. In most cases the desire is to prevent  namespace pollution and/or to hide internal workings of something, which  seems like a good idea to me. I can't really see the benefit in the  current behaviour.
> 
"instance and declarations" is actually a misnomer (since "instance" like "int num;" is also a declaration), but I understand what you meant.
And yes, like I said before, I think protection should work the same for all entities, whether they are runtime entities or compiletime-only entities.

>
> Compare "private" to "static" in C. Despite the documentation saying
> so,  private is not the same as the "static" keyword in C. "static" in
> C  prevents visibility, which in turn prevents access. "private" only
> prevents access, currently.
>

Yes, I understand the difference, I had read your talk about this before. This is a different issue that before, note, and here I'm not sure I agree with you. What's the difference to the programmer between:
  Error: foo.bar is not accessible.
and
  Error: foo.bar identifier not found.
?
I see no problem with the first case. Remember that protection attributes are not made for some sort of code security, permission or secrecy, they are meant simply for code conceptual abstraction.

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

On Wed, 07 Dec 2005 23:11:06 +0000, Bruno Medeiros <daiphoenixNO@SPAMlycos.com> wrote:
> Regan Heath wrote:
>> My impression is that most people would like "private" to treat instance  and declarations the same. In most cases the desire is to prevent  namespace pollution and/or to hide internal workings of something, which  seems like a good idea to me. I can't really see the benefit in the  current behaviour.
>>
> "instance and declarations" is actually a misnomer (since "instance" like "int num;" is also a declaration), but I understand what you meant.

Indeed, I may have picked the wrong words to describe what I mean. For example "defintion" seems better than "declaration", so...

"instance"   - an "entity" that "exists" in memory at runtime.
"definition" - layout of an entity, this layout never "exists" as an "entity" itself.

> And yes, like I said before, I think protection should work the same for all entities, whether they are runtime entities or compiletime-only entities.

My point was that a definition is not an "entity", it never "exists" in memory, instead instances are built in the layout it describes. As definitions never exist they need not be protected (assuming your definition of protection applies only to entities that exist at runtime, for example)

I'm splitting hairs again, because I enjoy this sort of discussion. Practically, I think we should be able to stop people using a definition. I don't have a strong opinion as to what keyword to use for it. It seems many people expect "private" to do it, so that may be a good choice.

>  > Compare "private" to "static" in C. Despite the documentation saying
>  > so,  private is not the same as the "static" keyword in C. "static" in
>  > C  prevents visibility, which in turn prevents access. "private" only
>  > prevents access, currently.
>  >
>
> Yes, I understand the difference, I had read your talk about this before. This is a different issue that before, note, and here I'm not sure I agree with you. What's the difference to the programmer between:
>    Error: foo.bar is not accessible.
> and
>    Error: foo.bar identifier not found.
> ?

The first says to me:
"I know what and where foo.bar is, but I'm not going to let you access it".

The second says to me:
"I have no idea what or where foo.bar is".

Practically there is little difference between them, they both prevent the programmer from using foo.bar. However the first error message is more specific, it tells you exactly what the problem is. The latter is less specific, it could be a number of things, typo, incorrect linkage, missing source file, ...

I think we all prefer specific error messages to vague ones. :)

> I see no problem with the first case. Remember that protection attributes are not made for some sort of code security, permission or secrecy, they are meant simply for code conceptual abstraction.

Sure, I agree. I see no reason to use less specific errors where we can be nice and specific. However, the price for being specific is that the symbol is always exported, what I mean is that...

In the case of static the C compiler does not export the symbol from the source file, this means that when compiling another file which references the symbol you get an error like the second one above.

In the case of D's protection, the compiler always exports the symbol even if it's private, this allows it to give the more specific error, the first error above.

By "export" above I mean simply that the compiler knows about a variable from "foo" when it is compiling a different module ie. "bar". Now, I'm not a compiler writer so I'm mostly guessing but doesn't this mean that the symbol must exist in foo.o? that it is always exported? even though it is private? (and actually inaccessable from anywhere outside "foo")

It seems to me that a private symbol is exported simply to give the specific error above, I find this interesting and it leads me to a new question: Does anyone have the need to actually prevent a symbol from being exported?

Regan