How to declare private variable in class

[viki]

Hi,

I tried declaring private variable in a class using '_' as prefix, but
I can access this variable directly from outside the class. Here is
the code:-

class A {
num _myPrivate = 5;

void show() {
print('myPrivate = $_myPrivate');
}
}

void main() {
A a = new A();
a.show();
a._myPrivate = 10;
a.show();
}

Here is the output:-
myPrivate = 5
myPrivate = 10

As you can see in main() after first show(), 'myPrivate' variable can
be changed. How to declare private variables in class.

Thanks,
Vivek

[Bob Nystrom]

On Wed, Oct 12, 2011 at 11:11 AM, viki <vivekk...@gmail.com> wrote:

Hi,

I tried declaring private variable in a class using '_' as prefix, but
I can access this variable directly from outside the class. Here is
the code:-

In Dart, privacy is at the library level, not the class level. You can access a class's private members from code outside of that class as long as that code is in the same library where the class is defined. (In Java terms, Dart has package private. In C#, internal.)

- bob

[Don]

What was the reasoning behind this decision? Why not object level
privacy?

On Oct 12, 2:14 pm, Bob Nystrom <rnyst...@google.com> wrote:

[poltomb]

They probably assume that a library writer knows what should be
modified in his/her/the team's own code. A dangerous assumption
indeed.

[Bob Nystrom]

On Wed, Oct 12, 2011 at 12:09 PM, Don <dga...@gmail.com> wrote:

What was the reasoning behind this decision?

There was a lot of discussion about this when we first started working on it, and that stuff deserves to be cleaned up and publicized but doing so will take awhile. If you can be satisfied with a shorter answer at least for now:

Why not object level privacy?

Object-level privacy has some advantages, but it has some known problems that the Smalltalk community is familiar with. For example, implementing binary operators like == is tricky when an object can't access another object's internal state even when that other object is of the same class.

Class-level privacy fixes that but it has some problems too. Off the top of my head:

1. What about things that aren't defined in a class at all? It's nice to be able to define top-level functions that are accessible from within the library, but not exported.

2. It's really convenient for subclasses within the same library to have more access to their superclass's state than external code does. Dart doesn't have protected, but this covers a lot of that use case.

I think there were also some other implementation-level motivations where library-level privacy simplified some things either for the compiler or VM (or both?) but I'm not sure about that.

- bob

[Ben Laurie]

On 12 October 2011 21:11, Bob Nystrom <rnys...@google.com> wrote:
>
>
> On Wed, Oct 12, 2011 at 12:09 PM, Don <dga...@gmail.com> wrote:
>>
>> What was the reasoning behind this decision?
>
> There was a lot of discussion about this when we first started working on
> it, and that stuff deserves to be cleaned up and publicized but doing so
> will take awhile. If you can be satisfied with a shorter answer at least for
> now:
>>
>> Why not object level privacy?
>
> Object-level privacy has some advantages, but it has some known problems
> that the Smalltalk community is familiar with. For example, implementing
> binary operators like == is tricky when an object can't access another
> object's internal state even when that other object is of the same class.
> Class-level privacy fixes that but it has some problems too. Off the top of
> my head:
> 1. What about things that aren't defined in a class at all? It's nice to be
> able to define top-level functions that are accessible from within the
> library, but not exported.
> 2. It's really convenient for subclasses within the same library to have
> more access to their superclass's state than external code does. Dart
> doesn't have protected, but this covers a lot of that use case.
> I think there were also some other implementation-level motivations where
> library-level privacy simplified some things either for the compiler or VM
> (or both?) but I'm not sure about that.

Don't forget that we also have another kind of privacy: isolate
privacy. Everything in an isolate is completely inaccessible from all
other isolates. This is the only hard privacy guarantee we currently
have. Library based privacy is not guaranteed to withstand attack, at
least at present.

[Nux]

On 12 Paź, 20:14, Bob Nystrom <rnyst...@google.com> wrote:

> On Wed, Oct 12, 2011 at 11:11 AM, viki <vivekkuma...@gmail.com> wrote:
> > Hi,
>
> > I tried declaring private variable in a class using '_' as prefix, but
> > I can access this variable directly from outside the class. Here is
> > the code:-
>
> In Dart, privacy is at the library level, not the class level. You can
> access a class's private members from code outside of that class as long as
> that code is in the same library where the class is defined. (In Java terms,
> Dart has package private. In C#, internal.)

This is bad. Very bad. I thought Dart would be a language for large
scale applications. For me the thing I miss the most in Javascript is
public/private/protected concepts and sometimes namespaces. I miss
declaring classes as classes, adding constructors and stuff like that
without all the tricks you use Javascript. I think this is the only
thing that might make Dart popular if implemented.

[Bob Nystrom]

On Sun, Oct 16, 2011 at 1:00 AM, Nux <eg...@wp.pl> wrote:

On 12 Paź, 20:14, Bob Nystrom <rnyst...@google.com> wrote:

> On Wed, Oct 12, 2011 at 11:11 AM, viki <vivekkuma...@gmail.com> wrote:
> > Hi,
>
> > I tried declaring private variable in a class using '_' as prefix, but
> > I can access this variable directly from outside the class. Here is
> > the code:-
>
> In Dart, privacy is at the library level, not the class level. You can
> access a class's private members from code outside of that class as long as
> that code is in the same library where the class is defined. (In Java terms,
> Dart has package private. In C#, internal.)

I thought Dart would be a language for large scale applications.

We think so too.

If library privacy is for some reason not tight enough for you and you really miss class-based privacy, remember you can always make your libraries as small as you want. You could break your program down into a large collection of very small isolated libraries if that's your preferred style.

Personally, I find the current level of privacy works pretty well. In general, I find a library is usually small enough that I don't have name collisions with private names within it, so I don't find a need for anything more finer-grained. I consider private in a language to be useful so minimize the amount that I need to hold in my head when working on a program. I only need to hold in my head the things that the code I'm working on has access to. With Dart, I can usually hold a library in my head, so library-scale private works pretty well.

 

For me the thing I miss the most in Javascript is public/private/protected concepts and sometimes namespaces. I miss
declaring classes as classes, adding constructors and stuff like that
without all the tricks you use Javascript.

 

Agreed. I like prototypes too, but I'm very used to thinking in terms of classes, so Dart is a nice fit there.

- bob

[Brook Monroe]

I don't know that it's as bad as you suggest where derived classes are
concerned. Where library users are concerned, however, it worries me
a little bit. While Isolates exist, it looks a little too much like
going around one's backside to get to one's elbow. Something with a
little less coding opacity might be useful.

On Oct 16, 4:00 am, Nux <e...@wp.pl> wrote:
> On 12 Paź, 20:14, Bob Nystrom <rnyst...@google.com> wrote:
>
> > On Wed, Oct 12, 2011 at 11:11 AM, viki <vivekkuma...@gmail.com> wrote:
> > > Hi,
>
> > > I tried declaring private variable in a class using '_' as prefix, but

> > > I canaccessthis variable directly from outside the class. Here is

> > > the code:-
>
> > In Dart, privacy is at the library level, not the class level. You can

> >accessa class's private members from code outside of that class as long as

> > that code is in the same library where the class is defined. (In Java terms,
> > Dart has package private. In C#, internal.)
>
> This is bad. Very bad. I thought Dart would be a language for large
> scale applications. For me the thing I miss the most in Javascript is

> public/private/protectedconcepts and sometimes namespaces. I miss

[Ben Laurie]

On 19 October 2011 15:22, Brook Monroe <brook....@gmail.com> wrote:

I don't know that it's as bad as you suggest where derived classes are
concerned.  Where library users are concerned, however, it worries me
a little bit.  While Isolates exist, it looks a little too much like
going around one's backside to get to one's elbow.  Something with a
little less coding opacity might be useful.

We are working on less painful ways to use isolates - see, for example, tests/stub-generator for an approach I've been working on.

[kkr]

On Oct 20, 2:05 pm, Ben Laurie <b...@google.com> wrote:

> On 19 October 2011 15:22, Brook Monroe <brook.mon...@gmail.com> wrote:
>
> > I don't know that it's as bad as you suggest where derived classes are
> > concerned.  Where library users are concerned, however, it worries me
> > a little bit.  While Isolates exist, it looks a little too much like
> > going around one's backside to get to one's elbow.  Something with a
> > little less coding opacity might be useful.
>
> We are working on less painful ways to use isolates - see, for example,
> tests/stub-generator for an approach I've been working on.

Sounds interesting, can you elaborate a bit on what you are aiming at
and why?

/Karl


[snip]

[0xor1]

isn't a big part of private / public / protected variables about defining their semantics and how they are to be used?

A big part of the docs I've read so far on Dart is that variables don't ever have to be declared with a type but they can be to make the intent clearer and to allow for IDE warnings etc. Which I think is great, I think that making code very clear and easy to understand as to how and why it was designed that way is a good thing, so shouldn't their be private / public  variables at the class level for this reason if no other? to make it clear that you can 'touch-this-safely' or to 'keep-your-filthy-hands-off' my variables. 

[Graham Wheeler]

Private variables start with '_'; you don't need to decorate them otherwise.

On Tue, May 7, 2013 at 3:14 PM, 0xor1 <daniel.rob...@gmail.com> wrote:

isn't a big part of private / public / protected variables about defining their semantics and how they are to be used?

A big part of the docs I've read so far on Dart is that variables don't ever have to be declared with a type but they can be to make the intent clearer and to allow for IDE warnings etc. Which I think is great, I think that making code very clear and easy to understand as to how and why it was designed that way is a good thing, so shouldn't their be private / public  variables at the class level for this reason if no other? to make it clear that you can 'touch-this-safely' or to 'keep-your-filthy-hands-off' my variables. 

--
Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart
 
 

[mezoni]

@Bob Nystrom Bob you are not right because you are narrow thinking.

Сommon truth:

1. The life is good.

2. But the good life is even better.

1. Class-level privacy has some advantages and disadvantages

2. Library-level privacy has some advantages and disadvantages

3. But when exist more than one (alternative) then this is even better.

Because in many cases it's disadvantages just the missing features.

And one complements the other.

So no matter how long you have explain how better this solution you will always be wrong because you (or others) choose only one of many but not all at once.

[mezoni]

My personal opinion (even if it does not cost anything) is as follows.

1. True: If you want recognize at a glance that you declare is a private then you can simply starts it name from underscore ('_').

2. True: If you want recognize at a glance that you declare is a private then you can simply starts it name from what you want. By eg. starts it from underscore ('m_').

3. True: If you not want use underscore as leading character for private declarations you may to not use it but use any other (from the allowed).

4. True: If you want choose level of privacy you may do it.

It is obvious that in many cases it must be true.

But just not in Dart language.

In this sense, the Dart has a very backward functionality.

This is more like as the laboratory work but not as the full-fledged language.

[mezoni]

And there is only one justification (that I can find).

The more primitive result should be the easier it can be to achieve.

Maybe the developers in the future appear free time to eliminate this misunderstanding.

There is one small example.

PHP (Personal Home Page Tools) language was not originally intended as a full-fledged language.

And what was the result?

Constant breaking from one version to another.

I'm not saying he's bad (PHP).

But it is better to do something good than to do it badly, and then redo it.

It is better to expend in the future than to break.

Especially for the grammar and syntax of the programming language.

[Filipe Morgado]

We should not, IMO, make the assumption that libraries may be broken into smaller parts.

It's sometimes difficult to do so, because of modules referencing each others, shared implementations, etc.

We often end-up with a group of modules that are dependent on each others (spaghetti), inseparable,

making it more difficult to maintain/update.

Modules should allow composition by hierarchical dependency.

Library-level privacy is enough for small projects with few programmers working on it.

When many programmers are working on the same library, it is, IMO, fundamental to differentiate between class-level and library-level privacy.

With only library-level privacy, programmers WILL end-up accessing class fields that are not meant to be accessed from outside the class.

Or they will start adding something like "class-internal" to the doc comments.

[Ladislav Thon]

1. Class-level privacy has some advantages and disadvantages

2. Library-level privacy has some advantages and disadvantages

3. But when exist more than one (alternative) then this is even better.

More complex != better.

LT

[Ladislav Thon]

Library-level privacy is enough for small projects with few programmers working on it.

When many programmers are working on the same library, it is, IMO, fundamental to differentiate between class-level and library-level privacy.

Funny that even the original architect of NetBeans, which a pretty big project, writes (in the Practical API Design book) that library-level privacy seems to be good enough. (He's pretty careful with the wording, but the idea is there.)

LT

[mezoni]

>> Or they will start adding something like "class-internal" to the doc comments.

Or (as suggested by Dart team) they can do as follows.

int _l_value = 0;

int _c_value = 0;

Where "_l_" means library-level.

And "_c_" means class-level.

>> More complex != better.

Yes.

C#, Java are ugly (with their private, protected, internal).

But Dart is beautiful (with him _).

[mezoni]

Who can explain to me what one is better than the other?

1.

private int _i;

private int m_i;

2.

int _i;

int _m_i;

Where is a benefit?

1. Savings on file size?

2. Taking care of my fingers?

3. Ideological conviction that you're smarter than everyone else?

4. More complex is not means better?

I'm so stupid that I do not understand.

[mezoni]

I understand. The care about the compiler.

In order that it is never be very complex because it will only worsen it.

Oh poor, Compiler. Who know what he has to endure during his work from the programmer.

Perhaps even sometimes obscene words caught in the source code.

Do not offend the compiler.

[Jim Trainor]

<vote>

Package level privacy is fine.

</vote>

[mezoni]

<vote>

Package level privacy is fine.

But class level privacy, library level privacy and package level privacy all together are much better.

</vote>

[mezoni]

public level - public (default)

object level - private

class hierarchy level - protected

library level - internal

package level - this is too vague (public)

[mezoni]

I like "private". They are absolutely invisible and not modifiable outside of instance.

But the Dart programmers (leaders) love only Javascript, Smalltalk, C++ and may be (forced from Eclipse) Java.

They not love any other modern languages like C#, Pascal.

And they not love (may be not knowing about the importance of) different levels of privacy.

The impression is that the language specification developed without looking to the future.

Excessive simplicity is not always justified.

The fact that the Dart is just better than the javascript tells me absolutely nothing.

I think that the javascript is outdated language.

And for me if something just better than the outdated language then for me it just means the same thing. It just better than the outdated language.

It is required to compare good language with other good languages.

As example comparing with C#.

Not all aspects but in similar situations.

[David Kerr]

If my vote counts then I vote FOR object level privacy. When I design a class I am designing at the level of the class and I want to minimise the "surface area" of it to simplify my life and the lives of maintainers that file me. That's why we have local variables, why I break down complex methods into smaller ones and why I decompose large classes into smaller ones.

Darts library concept is good, including the library privacy but it's inadequate on its own.

Give us the tools we need!

I avoid "protected" inheritance where possible but it to had its place.

[mezoni]

>> I avoid "protected" inheritance where possible but it to had its place.

class Document {

  private writeToDatabase(params...) {

  }

 

  protected internalWrite(params...) {

    writeToDatabase(params);

  }

  public Write() {

    internalWrite(params);

  }

}

class SaleOrder extends Document {

  override public Write() {

    // Sale order specific

    internalWrite(params);

  }

}

"Protected" used very often.

Hierarchy may be very deepest.

[macdevign]

As Bob has mentioned that
"

Object-level privacy has some advantages, but it has some known problems that the Smalltalk community is familiar with. For example, implementing binary operators like == is tricky when an object can't access another object's internal state even when that other object is of the same class.", and possibly due to some implementation issue.

hmmm ... It sounds like Dart is sacrificing "correctness" to ease implementation issue ?  I really think object-level privacy is the way to go for Dart as library can grow big overtime, and it often 'impractical' that developers will want to break library further down just to minimize name collision and to ease maintenance.

"There was a lot of discussion about this when we first started working on it, and that stuff deserves to be cleaned up and publicized but doing so will take awhile. "

so it sounds like object-level privacy will be implemented in just matter of time  or otherwise ?


Is there a existing feature request for object-level privacy we can vote for ?

[mezoni]

>>  but it has some known problems that the Smalltalk 

Who here used Smalltalk? I don't use. May be you?

I do not care about the problems in the the Smalltalk

>> and it often 'impractical'

Who may decide instead of me that it impractical'? 

[Ladislav Thon]

library can grow big overtime

It shouldn't. If it does, you are doing something wrong.

LT

[Ladislav Thon]

>>  but it has some known problems that the Smalltalk 

Who here used Smalltalk? I don't use. May be you?

I do not care about the problems in the the Smalltalk

Those who cannot learn from history are doomed to repeat it.

LT

[mezoni]

>> Those who cannot learn from history are doomed to repeat it.

This is your argument in defense of the "modesty" of the implementation?

Or it just what you said?

I understand that here people to like Newspeak.

I have nothing against it.

But still it is necessary not to make comparisons between Dart and Smalltalk.

[macdevign]

yes. probably one might say  is wrong but how often in practice this is done ? :}

 ...for example,  looking at existing javascript library, jquery, prototype ... and see how big they grow in one file... they can break down into multiple files but it may still be under one library, and they really grow over time.  Developers may value convenience at expense of maintenance in the real world from what I observe :} although it may not be a good practice.

at the end , I think it is not probably  one way is wrong or the another, but rather if we consider object-level privacy is something that is really helpful in code maintenance.  I really hope that object-level privacy is supported in Dart eventually.    ::}

[Ruud Poutsma]

An important realization for me was that in Dart does not inherit the Java/C# library style. That is, large and feature complete libraries. Instead, Dart inherits Javascripts small, lean-mean library style. Library-level privacy is a sane and logical choice imho. 

If I can recall correctly, Gilad was playing with the thought to use library definitions as implicit interfaces, much like Dart uses implicit interfaces of clases. This means you can "implement" a library". For this to be workable, small, focused libraries are a preferred choice.

On Wednesday, October 12, 2011 8:11:21 PM UTC+2, viki wrote:

Hi,

I tried declaring private variable in a class using '_' as prefix, but

I can access this variable directly from outside the class. Here is
the code:-

class A {
     num _myPrivate = 5;

     void show() {
           print('myPrivate = $_myPrivate');
     }
}

void main() {
    A a = new A();
   a.show();
   a._myPrivate = 10;
   a.show();
}

Here is the output:-
myPrivate = 5
myPrivate = 10

As you can see in main() after first show(), 'myPrivate' variable can
be changed. How to declare private variables in class.

Thanks,
Vivek

[Matthew Butler]

On Saturday, May 11, 2013 1:20:14 AM UTC-3, macdevign wrote:

...

"There was a lot of discussion about this when we first started working on it, and that stuff deserves to be cleaned up and publicized but doing so will take awhile. "

so it sounds like object-level privacy will be implemented in just matter of time  or otherwise ?

....

No Actually it sounds like: When developing the language we had a long discussion about various privacy options before choosing the one we did. We should go back to our notes on these discussions and clean them up to make them 1) readable and 2) ensure there is nothing in them that should not be disclosed. Once done we should make those discussion notes available publicly. 

At least that's how I understand the statement. In no way did I get the impression that the dart team was going to do an about face on something which would be a breaking change to everything in dart. I say what we have is what we'll be keeping. And I'm very ok with that.

Matt

[Ladislav Thon]

 ...for example,  looking at existing javascript library, jquery, prototype ... and see how big they grow in one file... they can break down into multiple files

They do break it down into multiple files. It's only that you can download a single file, but it's being developed as a bunch of separate "libraries". Look at https://github.com/jquery/jquery/tree/master/src, for example.

 

but it may still be under one library, and they really grow over time.

At least the jQuery guys try to keep it small all the time. The main feature of jQuery 2.0 is dropped support for IE 6, 7 and 8, resulting in much smaller code.

 

  Developers may value convenience at expense of maintenance in the real world from what I observe :} although it may not be a good practice.

Yeah, that's true. Personally, I'd say that a library can easily have up to 5k or even 10k lines of code without the need for object- or class-level privacy. And that's already quite big library.

LT

[jim.trainor.kanata]

My experience working large bodies of C/C++/Java/C# code is that most
libraries, used to build largish apps, end up being a few thousand lines
of code (not a rule, just what happens). The amount of attention that
is paid to interfaces to the library, ensuring the library is well
tested through that interface, and good management of the relationship
between the libraries, is what makes or breaks the body of code. I can't
recall significant problems caused by privacy concerns between classes
inside individual libraries.

Ladislav Thon wrote:
>
> Yeah, that's true. Personally, I'd say that a library can easily have
> up to 5k or even 10k lines of code without the need for object- or
> class-level privacy. And that's already quite big library.
>
> LT

> --
>

[Ladislav Thon]

The amount of attention that is paid to interfaces to the library, ensuring the library is well tested through that interface, and good management of the relationship between the libraries, is what makes or breaks the body of code.

+∞

LT

[kc]

Privacy at library level seems right. The alternatives are like Java/C# - too heavy.

It would be useful to be able to selectively enable production runtime checks for type annotations/asserts on library api boundaries.

If I write a library - then in production mode it's likely that that I want to check the incoming values.

K.

[Ladislav Thon]

If I write a library - then in production mode it's likely that that I want to check the incoming values.

It's likely that you will also want to do other checks on the incoming values, not only type checks. You might want to star http://dartbug.com/3049 ... or use some preconditions library.

LT

[kc]

Thanks. 

Something along along the lines I want to reuse the type annotation/assert on the library api - rather than code it again.

@contract assert (x > 1 && x < 100);

K.

[mezoni]

>> @contract assert (x > 1 && x < 100);

This is not a language feature but may be a feature available through compiler plugins.

But the Dart is not that level where it is necessary.

I don't like this features (compiler plugins).

[Ladislav Thon]

Things like this can always be done by writing a preprocessor. Web UI folks are doing it with the @observable stuff, for example.

LT

[kc]

OK. But it would be useful if it was some kind of Dart supported 'standard'.

K.

[mezoni]

>> Things like this can always be done by writing a preprocessor. Web UI folks are doing it with the @ observable stuff, for example.

1. If you want use this w / o knowing about how it works

2. If you want use this w / o running other process in any way

This may be called as the compiler plugin.

Like 'aspectj' or early implementation of 'linq'.

But preprocessor also may help.

You may call it translator if you want.

But this is not a language feature.

[Justin a]

I don't know why they did this, but it certainly makes implementing a decorator pattern a sad chore. You have to chose between tons of warnings or way more pointless code.

On Wednesday, October 12, 2011 3:09:54 PM UTC-4, Don wrote:

What was the reasoning behind this decision? Why not object level
privacy?

On Oct 12, 2:14 pm, Bob Nystrom <rnyst...@google.com> wrote:

> On Wed, Oct 12, 2011 at 11:11 AM, viki <vivekkuma...@gmail.com> wrote:
> > Hi,
>
> > I tried declaring private variable in a class using '_' as prefix, but
> > I can access this variable directly from outside the class. Here is
> > the code:-
>

> In Dart, privacy is at the library level, not the class level. You can
> access a class's private members from code outside of that class as long as
> that code is in the same library where the class is defined. (In Java terms,
> Dart has package private. In C#, internal.)
>
> - bob