use of "_" prefix to designate "private"/"library" scope...

[Larry Cable]

While the use of the "_" prefix has a long history of being used to
designate "internal implementation" in C and its derivatives I
question the wisdom of enshrining this meaning (library private scope)
into the formal syntax of a (new) language, while its a little more
verbose I think the use of an appropriate type modifier such as
"library" or "private" improves the readability of the declaration.

I find such conventions (such as implicit variables in Fortran)
IAmAnInterface (capitial I prefix) in COM are inappropriate and
unneccessary in a modern language, with a rich WYSIWYG IDE that can
readily make the visibility or other metadata available to the
programmer as they type ...

I would vote not to enshrine this usage into Dart... or at least make
it optional and also support a type modifier also

Thanks

Larry Cable

[Seo Sanghyeon]

2011/10/11 Larry Cable <larry...@gmail.com>:

> While the use of the "_" prefix has a long history of being used to
> designate "internal implementation" in C and its derivatives I
> question the wisdom of enshrining this meaning (library private scope)
> into the formal syntax of a (new) language, while its a little more
> verbose I think the use of an appropriate type modifier such as
> "library" or "private" improves the readability of the declaration.

What do you think about their rationale? It made sense to me.

"Privacy is indicated by the name of a declaration -- hence privacy and
naming are not orthogonal. This has the advantage that both humans
and machines can recognize access to private declarations at the point
of use without knowledge of the context from which the declaration is
declared."

--
Seo Sanghyeon

[bfintal]

+1 for a "private" type modifier.

If this were to be implemented.. personally from a high level view,
I'd prefer for the private variable not to be seen at all by the
inheriting class; if accessed, it would be just like the variable was
not yet declared. and since this was the case, (this may be an obvious
implication) the same variable name can be re-declared by the
inheriting class without affecting the parent class

On Oct 11, 3:18 am, Seo Sanghyeon <sanx...@gmail.com> wrote:
> 2011/10/11 Larry Cable <larry.ca...@gmail.com>:

[RPR]

Looks like first response was lost. Otherwise sorry for double post.

The _ is commonly used by convention in other languages to denote a
private var/val identifier. In Dart _ holds for methods as well. I
write lots of little methods and tend to hide everything that I can.
As a result I'm going to have lots of code looking like this.

void _doThis (a,b,c) {
_doXA (_x,a);
_doXYC (_x,_y,c);
}

So maybe >50% of all my identifiers will be _ prefixed, but this is
just syntax and you get used to that pretty quick. A more difficult
question is what happens when I need to change (privacy) one way or
another. That is going to involve a mass search and replace to occur
would it not?

[Jan]

I'd rather want to have a 'public' modifier. All variables are private
unless explicitly exported with the 'public' keyword. I also think
that using an underscore is a bad idea because it is difficult to
change afterwards.

And the same for the 'final' keyword: all variables are final unless
explicitly declared with the 'var' keyword, like so:

String name = 'Bob';
var int age = 26;

name = 'Bill'; // error
age = age + 1; // Ok

On Oct 10, 9:42 pm, RPR <ray.rac...@gmail.com> wrote:
> Looks like first response was lost.  Otherwise sorry for double post.
>

> The _ is commonly used by convention in other languages to denote aprivatevar/val identifier.  In Dart _ holds for methods as well.  I

[Maurice Rabb]

I'm big fan of using underscores to denote private vars and functions.
However, I strongly agree with the arguments and approaches suggested by
Jan and Larry (below). I will probably still use underscores, but it is
better as a sugaring option.

Cheers,

-Maurice

On 11-11-12 9:10 AM, Jan wrote:
> I'd rather want to have a 'public' modifier. All variables are private
> unless explicitly exported with the 'public' keyword. I also think
> that using an underscore is a bad idea because it is difficult to
> change afterwards.
>
> And the same for the 'final' keyword: all variables are final unless
> explicitly declared with the 'var' keyword, like so:
>
> String name = 'Bob';
> var int age = 26;
>
> name = 'Bill'; // error
> age = age + 1; // Ok
>

On Oct 10, 3:13 pm, Larry Cable <larry.ca...@gmail.com> wrote:

[Zexx]

I wouldn't agree with Jan regarding the use of "final". In an average
program there are much more variables than constants. That means most
of declarations would have to start with a "var" followed by a type,
followed by the identifier name. Which would make code less readable.
It would be better to use the word "const" for constants (replacing
"final" and "static") and make everything else variables.

[Iph]

Couldn't the same logic be applied to public modifiers in relation to
a web programming language? The only time you should use getters /
setters is for small logical occurrences (like maybe checking if the
person entered a positive number for a setter). Anything relatively
large would be put into a function, in which case it would be public
and then having a modifier to adjust all your public needs would then
be a cumbersome approach. Therein, the recommended amount that you
~should~ be using private variables/functions is going to be much less
than how much you ~should~ be using public variables/functions. It
logically follows that if there is going to be a modifier on private/
public 'things', then it should be public, since it is used more than
that of private,which is used less.

Though, I should probably hold off on this small argument since I am
slightly biased towards the '_' private identifier. It is personally
much easier to remember which variables/functions I set to private
when they have such an easy prefix like an underscore to identify them
as such (though I guess the same argument could be made if it was a
public modifier).

[Martin Algesten]

I don't agree with Zexx. In a recent java-project I became a "final
convert" and started marking every possible class member final. My
conclusion is that most members are final. However that's just
personal experience - does anyone have a proper metric for this
statement?

[Dirk Detering]

I also don't agree with Zexx, although I do not have a proper metric.
Motivated by my Scala exploration I made exactly the same experience. When reviewing older Java code I found that very often a final keyword could be added without harm. On some few places the structure had to be changed a bit to apply a "final only" approach.  There were very few places where explicitly a non-final var was of advantage or even necessary.

So if that works in Java, it is only a matter of style and perhaps a bit support by the language (e.g. convenient loop constructs)

I strongly am of the opinion that Scala and F# will get more attention in the future, and thus the object functional approach.  Every language coming up now should try to not only appeal current average developers but support the style of the next-generation average developer. And "use final" will be on top of the best practices hints to be found in every learn-to-program tutorial.

[Jan]

My biggest problem with the underscore is that it reminds me of this
visual basic times where it was considered a good practice to prefix
your variables with their type: 'strMyString', 'dblSomeAmount',... I
think it is a bad practice to mix identifier names with semantics of a
language. The problem it tries to solve is best solved with good
tools. In stead of putting the type in the variable name, you just
hover over the variable to see it's type (in a good editor). I think
the same should apply to private/public. Your tools should tell what
is private, not your variable names.

On Nov 13, 10:20 am, Dirk Detering <mailto...@googlemail.com> wrote:
> I also don't agree with Zexx, although I do not have a proper metric.
> Motivated by my Scala exploration I made exactly the same experience. When
> reviewing older Java code I found that very often a final keyword could be
> added without harm. On some few places the structure had to be changed a
> bit to apply a "final only" approach.  There were very few places where
> explicitly a non-final var was of advantage or even necessary.
>
> So if that works in Java, it is only a matter of style and perhaps a bit
> support by the language (e.g. convenient loop constructs)
>
> I strongly am of the opinion that Scala and F# will get more attention in
> the future, and thus the object functional approach.  Every language coming
> up now should try to not only appeal current average developers but support
> the style of the next-generation average developer. And "use final" will be
> on top of the best practices hints to be found in every learn-to-program
> tutorial.

[fddima]

Lang, must have accessibility features, or doesn't have. DartSpec
defines not only underscore as private, but and 'm' prefix as library
visible.
What it is mean? 'my' << it is library scope??? It is completely
nonsense.
Use classic explicit modifiers, and let developer's choose which
naming conventions it must use. Unless, it is really doesn't differs
from JS, which in our time can be compiled from many NORMAL languages.

[Iph]

I think you are slightly confused by what the spec is saying.

" A declaration is private iff it begins with an underscore (the
character) otherwise it is public. A
declaration m is accessible to library L if m is declared in L or if m
is public."

m in this case is a variable name of a variable, not the literal
character m. Just to reiterate clarification, if I say 'var myName',
it is NOT private.

[fddima]

Thanks.
My main accent that explicit access modifiers used many languages by
many years.
public / private / protected / internal / etc...
Why re-invent same but using magic prefix?

[Iph]

I wouldn't call it a reinvention of a "magic" prefix. People have been
naming variables certain ways to distinguish their form from others
for years. anythingThatStartsWithALowercase we know to usually be a
variable while MostStuffWithPureUppercase we know to be some instance
of a class. By forcefully putting a modifier for private, we will
instantly know when we look at anyone's code base-- with or without
documentation-- whether something is public or private.

Though I do understand other people's distaste of such mechanics,
since Dart is forcefully telling them how to "write" their code, I
also understand the use of the modifier.

[Florian Loitsch]

On Mon, Nov 14, 2011 at 08:05, fddima <fdd...@gmail.com> wrote:

Thanks.
My main accent that explicit access modifiers used many languages by
many years.
public / private / protected / internal / etc...
Why re-invent same but using magic prefix?

Keywords only appear at the declaration/definition site of variables whereas the "_" prefix is also visible at the use-sites. This simplifies the semantics and implementation (thus making it more robust).

// florian

On 13 ноя, 18:20, Iph <seanmyers0...@gmail.com> wrote:
> On Nov 13, 11:00 am, fddima <fdd...@gmail.com> wrote:
>
> > Lang, must have accessibility features, or doesn't have. DartSpec
> > defines not only underscore as private, but and 'm' prefix as library
> > visible.
> > What it is mean? 'my' << it is library scope??? It is completely
> > nonsense.
> > Use classic explicit modifiers, and let developer's choose which
> > naming conventions it must use. Unless, it is really doesn't differs
> > from JS, which in our time can be compiled from many NORMAL languages.
>
> I think you are slightly confused by what the spec is saying.
>
> " A declaration is private iff  it begins with an underscore (the
> character) otherwise it is public. A
> declaration m is accessible to library L if m is declared in L or if m
> is public."
>
> m in this case is a variable name of a variable, not the literal
> character m. Just to reiterate clarification, if I say 'var myName',
> it is NOT private.

--
Give a man a fire and he's warm for the whole day,
but set fire to him and he's warm for the rest of his life. - Terry Pratchett

[Dmitry Azaraev]

On Mon, Nov 14, 2011 at 5:40 PM, Florian Loitsch <floi...@google.com> wrote:

Keywords only appear at the declaration/definition site of variables whereas the "_" prefix is also visible at the use-sites. This simplifies the semantics and implementation (thus making it more robust).

// florian

Thanks. In this case it have really sense.

--
Best regards,
   Dmitry                             mailto:fdd...@gmail.com

[Ladislav Thon]

Keywords only appear at the declaration/definition site of variables whereas the "_" prefix is also visible at the use-sites.

You can say that this is both pro and con. E.g., if you decide to change the visibility, you have to change all use-sites too. This can easily be solved by an IDE, but still.

I personally don't know what to think about this. I hate when names affect semantics, but in this case... it's just so very clear and simple, I even might start to like it :-)

LT

[Izzy]

The number of times you'll be bouncing around code to figure out if
something is public/private because you used a keyword will be far
greater than the number of times you had to find/replace a var's name
because you changed visibility later.

Besides, notepad, emacs and vim all have find/replace; you're also
probably doing something wrong if you're unhiding a private member
variable...

--izzy

[Ladislav Thon]

The number of times you'll be bouncing around code to figure out if
something is public/private because you used a keyword will be far
greater than the number of times you had to find/replace a var's name
because you changed visibility later.

Both of these are easily solved by using an IDE. I personally don't think that renaming for changing visibility is a big problem (and I even think that enforcing this particular naming convention is nice in a way), just that there are some cons. Or at least, consequences that some people may (and will) consider as cons.

You might come up with other cons as well. E.g., if you're trying to establish a proper API for a larger library, i.e. hide everything by default and let the user access only what you want, you will end up with vast majority of (top-level) identifiers prefixed with underscore. That might be ... not pretty. But we'll need to gain experience with this, it's possible that this issue will never appear (maybe by establishing a convention of separate API libraries and impl libraries? Not sure how this would work out).

Besides, notepad, emacs and vim all have find/replace;

Find and replace is wrong, it can easily change the code that shouldn't be changed. Doing this automatically requires understanding of the code, i.e. an IDE, again.

 

you're also
probably doing something wrong if you're unhiding a private member
variable...

That isn't always true. And remember that Dart is specifically meant to be used (not only, but also) for rapid prototyping...

There's this analogy coming to mind... Java people developed a habit of making all instance variables private and always generating getters and setters, just in case. You don't have to do that in Dart, you can add a getter and setter any time later without need to change a single line of code that is using it. Analogies are bad, but locality of change is always nice.

LT

[Bob Nystrom]

I'm not sure how I missed this thread the first time around, but I'll try to throw out a couple of small comments. I'll apologize first for replying to lots of different people all in one long email...

I think the use of an appropriate type modifier such as "library" or "private" improves the readability of the declaration.

It does, but it doesn't help the readability of the use site.

Even more important, privacy modifiers are much trickier to implement in a dynamic language. Privacy modifiers are almost always found in static languages. Python's concept of private is similarly name-based. Ruby and Smalltalk use object-based privacy (as opposed to class-based like most other languages) which I think has its own problems.

I'd prefer for the private variable not to be seen at all by the inheriting class; if accessed, it would be just like the variable was not yet declared. and since this was the case, (this may be an obvious implication) the same variable name can be re-declared by the inheriting class without affecting the parent class

If you inherit across library boundaries, you will get that behavior. In practice, I find that works pretty well: if my superclass is in my library I usually know what private members it has and it's not too much trouble to avoid them. If I'm inheriting from some other library I don't control, I really don't want to see its internal details at all.

And the same for the 'final' keyword: all variables are final unless explicitly declared with the 'var' keyword, like so:

You can use final and omit the type if you want that:

final name = 'Bob';

var age = 26;

We use that frequently and I find it pretty terse. Making final the default would be a much bigger change. I think it's very important for a language to support single-assignment, but making it assume that until you tell it otherwise is a different matter. We want the path to learning Dart to be as smooth as possible, and most popular languages out there don't work that way. If a new user coming from C/C#/Java/JS/etc. writes their first Dart program:

main() {

  var age = 26;

  age++;

}

And gets an error, that's an unhappy user. It's worth that pain sometimes if the feature adds enough value for experienced users, but I'm not convinced that final-by-default does. Dart already doesn't have state shared across isolates so that alleviates some of the need for final.

So maybe >50% of all my identifiers will be _ prefixed, but this is just syntax and you get used to that pretty quick.

A lot of this depends on the culture surrounding the language you use frequently. Java, C++, and C# lean heavily towards private unless you are sure you want something to be public. Most dynamic language communities seem to be more open to allowing things to be public. Dart leans towards the latter.

Keep in mind that privacy is at the library level, not class. So if the library you're working on is a standalone app that won't be #imported() by something else, there's no real need to use private names. You wouldn't be hiding those names from anything.

A more difficult question is what happens when I need to change (privacy) one way or another.  That is going to involve a mass search and replace to occur would it not?

It shouldn't. If you're going from private -> public, then the only occurrences of it will be restricted to a single library at that point, so it shouldn't be a very big change. If you're going from public -> private, you'll have to get rid of every use of that name outside the library anyway, so the name change isn't much extra work.

When reviewing older Java code I found that very often a final keyword could be added without harm.

Yup. Many if not most variables and fields are only ever assigned to once. But there's another way to phrase this: could final be omitted without harm? One reason final exists to help you trap bugs (you shouldn't be able to assign to it again, but you did). If those bugs haven't actually manifested to begin with (and I find that in nice short methods in Dart, they rarely do) then adding the final annotation starts to feel like busywork to me.

Now consider the converse, I have some local variable that I am assigning to multiple times. If I'm doing that in my code, why shouldn't the language assume I know what I'm doing and allow that? Does it add value to require me to going out of my way to tell Dart, "Hey, I'm gonna assign to this twice. Don't freak out."?

I personally don't know what to think about this. I hate when names affect semantics, but in this case... it's just so very clear and simple, I even might start to like it :-)

Many of us on the team feel the same way, and there was definitely dissent when this was first adopted in the language. So far, it actually seems to work out pretty well in practice.

- bob

[Larry Cable]

I still think it is a mistake/hack to enshrine this as a special case.

An IDE or the compiler can detect inappropriate access to methods/
fields etc as the code is written or compiled (or even executed in
checked mode or otherwise)

Any IDE worth its salt can inform the developer of the accessibility
of such as they
view it ...

I think you should avoid special casing this, or adopt "hungarian
notation" everywhere
so that developers can tell at a glance everything about the variables
they are working with!

:)

(clearly I am not seriously suggesting this, I am using it to support
the case for not special casing visibility in the naming of variables)

- Larry

> to support single-assignment, but making it *assume* that until you tell it

> otherwise is a different matter. We want the path to learning Dart to be as
> smooth as possible, and most popular languages out there don't work that
> way. If a new user coming from C/C#/Java/JS/etc. writes their first Dart
> program:
>
> main() {
>   var age = 26;
>   age++;
>
> }
>
> And gets an error, that's an unhappy user. It's worth that pain sometimes
> if the feature adds enough value for experienced users, but I'm not
> convinced that final-by-default does. Dart already doesn't have state
> shared across isolates so that alleviates some of the need for final.
>
> So maybe >50% of all my identifiers will be _ prefixed, but this is just
>
> > syntax and you get used to that pretty quick.
>
> A lot of this depends on the culture surrounding the language you use
> frequently. Java, C++, and C# lean heavily towards private unless you are
> sure you want something to be public. Most dynamic language communities
> seem to be more open to allowing things to be public. Dart leans towards
> the latter.
>
> Keep in mind that privacy is at the library level, not class. So if the
> library you're working on is a standalone app that won't be #imported() by
> something else, there's no real need to use private names. You wouldn't be

> hiding those names *from* anything.

>
> A more difficult question is what happens when I need to change (privacy)
>
> > one way or another.  That is going to involve a mass search and replace
> > to occur would it not?
>
> It shouldn't. If you're going from private -> public, then the only
> occurrences of it will be restricted to a single library at that point, so
> it shouldn't be a very big change. If you're going from public -> private,
> you'll have to get rid of every use of that name outside the library
> anyway, so the name change isn't much extra work.
>
> When reviewing older Java code I found that very often a final keyword
>
> > could be added without harm.
>
> Yup. Many if not most variables and fields are only ever assigned to once.

> But there's another way to phrase this: could final be *omitted* without

> harm? One reason final exists to help you trap bugs (you shouldn't be able
> to assign to it again, but you did). If those bugs haven't actually
> manifested to begin with (and I find that in nice short methods in Dart,
> they rarely do) then adding the final annotation starts to feel like
> busywork to me.
>

> Now consider the converse, I have some local variable that I *am* assigning

[Izzy]

> Both of these are easily solved by using an IDE.

and

> An IDE or the compiler can detect inappropriate access to methods/
> fields etc as the code is written or compiled (or even executed in
> checked mode or otherwise)

> Any IDE worth its salt can inform the developer of the accessibility
> of such as they
> view it ...

A language should not be reliant on an IDE to be used efficiently.

[Mars Saxman]

On Nov 14, 2011, at 10:49 AM, Izzy wrote:

>> Any IDE worth its salt can inform the developer of the accessibility
>> of such as they
>> view it ...
>
> A language should not be reliant on an IDE to be used efficiently.

+1. This is a clean-sheet language design - why bake in dependency on external tooling?

[Bob Nystrom]

We definitely do not think you should need an IDE to enjoy using Dart. An IDE should be a jetpack so you can fly, not a crutch just to get you back to walking after the language has hobbled you. A bunch of us on the team are using vanilla text editors (Sublime Text 2 represent!) to work with Dart all day and so far it's pretty pleasant.

- bob

[Michael Hendricks]

On Sat, Nov 12, 2011 at 8:10 AM, Jan <potom...@gmail.com> wrote:

And the same for the 'final' keyword: all variables are final unless
explicitly declared with the 'var' keyword, like so:

String name = 'Bob';
var int age = 26;

name = 'Bill'; // error
age = age + 1; // Ok

See https://code.google.com/p/dart/issues/detail?id=252 for an issue related to this and links to some earlier discussion.

I think moving "final as default" to the tools is the best approach for Dart.

-- 

Michael

[Izzy]

On the issue, you've got:

> Without changes to Dart, "final-ists" could write a static analysis tool to warn about multiple-assignment:

> int x = 7;
> int y = 1;
> x = x + y; // tool warns: multiple assignment to variable "x"

Same IDE-reliance problem as mentioned in my previous post.

Since Dart is meant to replace JavaScript/ECMAScript, I think it would
be extremely confusing for programmers to go from a var-always
language to a final-always language.

Not to mention the confusion of:

var var myNonTypedMutableVar;

for creating a typeless variable that's also.... uhm, _variable_?


On Nov 14, 3:17 pm, Michael Hendricks <mich...@ndrix.org> wrote:

> On Sat, Nov 12, 2011 at 8:10 AM, Jan <potoms....@gmail.com> wrote:
> > And the same for the 'final' keyword: all variables are final unless
> > explicitly declared with the 'var' keyword, like so:
>
> > String name = 'Bob';
> > var int age = 26;
>
> > name = 'Bill'; // error
> > age = age + 1; // Ok
>

> Seehttps://code.google.com/p/dart/issues/detail?id=252for an issue

[Izzy]

Sorry for the spam, but I did realize about 10s after sending that
last that you in fact meant this to be a language addition to wholly
facilitate static code analysis.

So let me address the full issue there:
Adding a feature to the *language* that doesn't actually do anything
and in fact could be misleading is probably not a feature Dart wants.

My "var var myVar" argument still stands as looking rather silly and
redundant in that one case, as well as being redundant in all other
cases.

Since I can still just declare this as "var myVar;", and that without
changing the way the VM interprets this to being final, it still means
"var var myVar", I think this "feature" will be easily misunderstood.

My IDE argument also still stands, since if a user doesn't code in
your IDE with static analysis, but sees 'var' being used in a way that
implies not having it means 'final'; they could mistakenly code
thinking this is the cases.

Added features should add expressiveness to the language for the
language's sake, not for the sake of tools that may or may not exist
for every user.

On Nov 14, 3:30 pm, Izzy <gtg1...@gmail.com> wrote:
> On the issue, you've got:
>
> > Without changes to Dart, "final-ists" could write a static analysis tool to warn about multiple-assignment:
> >  int x = 7;
> >  int y = 1;
> >  x = x + y;  // tool warns: multiple assignment to variable "x"
>
> Same IDE-reliance problem as mentioned in my previous post.
>
> Since Dart is meant to replace JavaScript/ECMAScript, I think it would
> be extremely confusing for programmers to go from a var-always
> language to a final-always language.
>
> Not to mention the confusion of:
>
> var var myNonTypedMutableVar;
>
> for creating a typeless variable that's also.... uhm, _variable_?
>
> On Nov 14, 3:17 pm, Michael Hendricks <mich...@ndrix.org> wrote:
>
>
>
>
>
>
>
> > On Sat, Nov 12, 2011 at 8:10 AM, Jan <potoms....@gmail.com> wrote:
> > > And the same for the 'final' keyword: all variables are final unless
> > > explicitly declared with the 'var' keyword, like so:
>
> > > String name = 'Bob';
> > > var int age = 26;
>
> > > name = 'Bill'; // error
> > > age = age + 1; // Ok
>

> > Seehttps://code.google.com/p/dart/issues/detail?id=252foran issue

[Martin Algesten]

On Nov 14, 7:26 pm, Bob Nystrom <rnyst...@google.com> wrote:
> way. If a new user coming from C/C#/Java/JS/etc. writes their first Dart
> program:
>
> main() {
>   var age = 26;
>   age++;
>
> }
>
> And gets an error, that's an unhappy user.

Using "var" was proposed to mean *variable* thus the above would
compile. however

main() {
  int age = 26;
  age++;
}

wouldn't.

> Yup. Many if not most variables and fields are only ever assigned to once.

> But there's another way to phrase this: could final be *omitted* without

> harm? One reason final exists to help you trap bugs (you shouldn't be able
> to assign to it again, but you did). If those bugs haven't actually
> manifested to begin with (and I find that in nice short methods in Dart,
> they rarely do) then adding the final annotation starts to feel like
> busywork to me.

Actually I don't buy that line of argument. I do a great deal of
things to help me trap bugs.

1. I use a typed language.
2. I make myself a straight jacket out of test cases.
3. I use final keywords.

In fact, I subject myself to a lot of extra code, just because I find
these things pay off in terms of bugs caught. For me an implicit final
unless I say so would make a terser syntax. In fact if I didn't want
these things I could just as well stick with javascript - and isn't a
big point of Dart to get me out of that particular dark place?

[chrisbuckett]

On Nov 14, 7:42 pm, Bob Nystrom <rnyst...@google.com> wrote:
> are using vanilla text editors (Sublime Text 2 represent!) to work with

I don't suppose you have any syntax highlighting files (or other
useful plugins) for Sublime Text lying around that you can share?

Cheers,
Chris.

[Bob Nystrom]

There's a basic TextMate bundle under tools/utils/textmate. You can convert that to a Sublime Bundle pretty easily. At some point, if I find the time, I'm planning to do that properly, but I haven't had a chance. I'm using a very hacked up bundle I threw together that isn't in a state where I could distribute it.

- bob

[Jan]

I don't get why this is an issue at all. Mixing variable names with
semantics is just wrong. I thought history has proven this a long time
ago. Why not do the following:
Int privateIntFinalHashableNonZeroCostumerId = 12;
So you don't forget all this shit at the call site. That's why you
have tools. To tell you that. I saw the Stanford talk. This seems to
be what is dart all abouty

On Nov 14, 8:42 pm, Bob Nystrom <rnyst...@google.com> wrote:

> On Mon, Nov 14, 2011 at 11:09 AM, Mars Saxman <marssax...@google.com> wrote:
>
> > On Nov 14, 2011, at 10:49 AM, Izzy wrote:
>
> > >> Any IDE worth its salt can inform the developer of the accessibility
> > >> of such as they
> > >> view it ...
>
> > > A language should not be reliant on an IDE to be used efficiently.
>
> > +1. This is a clean-sheet language design - why bake in dependency on
> > external tooling?
>

> We definitely do *not* think you should need an IDE to enjoy using Dart. An

[Izzy]

> I don't get why this is an issue at all. Mixing variable names with
> semantics is just wrong. I thought history has proven this a long time
> ago. Why not do the following:
> Int privateIntFinalHashableNonZeroCostumerId = 12;
> So you don't forget all this shit at the call site.

except there's a mighty big difference between

int privateHashableOverblownStrawmanArgumentExampleVar;

and

int _x;

Using _ to represent things that should be private in javascript is a
widely accepted practice.

Using ridiculous straw-man argument tactics is, on the other hand, a
widely abused practice.

No one is talking about anything else about the name being used for
meaning, making the rest of that argument null.

[Jan]

Ok, It was a bad argument, got carried away there. But I don't really
see a big difference between _myvar and intMyvar. Even if this is
widespread practice, does this mean it's a good idea? Didn't people
start to do this because privacy was missing in javascript.

On Nov 15, 5:15 am, Izzy <gtg1...@gmail.com> wrote:
> > I don't get why this is an issue at all. Mixing variable names with

> > semantics is just wrong. I thought histtory has proven this a long time

> > ago. Why not do the following:
> > Int privateIntFinalHashableNonZeroCostumerId = 12;
> > So you don't forget all this shit at the call site.
>
> except there's a mighty big difference between
>
> int privateHashableOverblownStrawmanArgumentExampleVar;
>
> and
>
> int _x;
>

> Using _ to represent things that should beprivatein javascript is a

[chrisbuckett]

> Didn't people
> start to do this because privacy was missing in javascript.

I think that using an underscore to denote private to aid readability
has been around for a while.

This google search for docs between 1990 and 2000 turns up a host of
documents on the subject:
http://goo.gl/LvSdG

Cheers,
Chris.

[Andrew]

I dislike the underscore as well. I think it makes code looks ugly. I
would prefer some kind of keyword.

On Oct 11, 5:13 am, Larry Cable <larry.ca...@gmail.com> wrote:
> While the use of the "_" prefix has a long history of being used to
> designate "internal implementation" in C and its derivatives I
> question the wisdom of enshrining this meaning (library private scope)
> into the formal syntax of a (new) language, while its a little more
> verbose I think the use of an appropriate type modifier such as

> "library" or "private" improves the readability of the declaration.
>

> I find such conventions (such as implicit variables in Fortran)
> IAmAnInterface (capitial I prefix) in COM are inappropriate and
> unneccessary in a modern language, with a rich WYSIWYG IDE that can
> readily make the visibility or other metadata available to the
> programmer as they type ...
>
> I would vote not to enshrine this usage into Dart... or at least make
> it optional and also support a type modifier also
>
> Thanks
>
> Larry Cable

[chrisbuckett]

On Nov 15, 10:29 am, Andrew <thefi...@ozemail.com.au> wrote:
> I dislike the underscore as well. I think it makes code looks ugly. I
> would prefer some kind of keyword.

The issue I have with a keyword is where you have library privacy, and
the item may be defined in a different physical file, it's not
apparently obvious without an IDE that a member is private or not.
Adding the _ means that it's becomes obvious to anyone reading the
code that it's private.

Cheers,
Chris

[Andrew]

If they think it can be used outside of the module and don't bother
checking the other file it is defined in, what is the worst that can
happen? If they assume that it can't be used outside of the module
based on no information at all, they are crazy.

[Jan]

>The issue I have with a keyword is where you have library privacy, and >the item may be defined in a different physical file, it's not >apparently obvious without an IDE that a member is private or not.

If you make it a keyword I have at least the option to not use the
underscore while you still have the option to use the underscore. I
don't like my code to explode with "dot-underscores". I would use a
decent IDE and keep my code readable. If it doesn't autocomplete, it
is private. If you work in a team and you all decide to use an
underscore then you still could.

[Ray Tayek]

At 10:00 PM 1/13/2012, you wrote:
>I have got to say, looking at the dart code samples makes me want to
>cry. The underscores everywhere just destroys the readability of the
>code.

agree. trailing_ is much easier on the eyes.

thanks

---
co-chair http://ocjug.org/

[Jay Young]

On Saturday, January 14, 2012 11:46:39 AM UTC-5, Ray Tayek wrote:

At 10:00 PM 1/13/2012, you wrote:
>I have got to say, looking at the dart code samples makes me want to
>cry. The underscores everywhere just destroys the readability of the
>code.

agree. trailing_ is much easier on the eyes.

After working with Closure code for a couple years now, i completely agree with this! 

[Dmitry Dementev]

I like prefix _, sounds like _lookThisIsPrivate (private lookThisIsPrivate); following sounds not good lookThisIsPrivate_ (lookThisIsPrivate private)

[Jay Young]

Yeah, I can understand that.  But I find the trailing "_" serves even better.  "this.descriptiveName_" tells me "This is what I am (and this is who can see me").  I find the first to be far more important when writing code.  Also, I think there's just something ugly about "._" in an identifier.

Totally subjective, paint color on the bikeshed, blah blah lbah.  Just one guy's opinion.

[Dmitry Dementev]

this.foo_ vs _foo (_ mean like this._), and _ especially throws in the eye, which is private and it is this class.

for example:

class A {

  method1() {

    this.var1_ = ...

    this.var1_ = ...

    this.var1_ = ...

    this.var1_ = ...

    ...

  }

}

or:

class A {

  method1() {

    _var1 = ..

    _var1 = ..

    _var1 = ..

    _var1 = ..

    ...

  }

}

need more typing?! more work for eyes?! more parse for compiler?!

[Dominic Hamon]

I've seen this conversation a few times but I've just had a bit of an epiphany. I think this is the wrong way around: Library private should be the default, just as class private is the default in C++, rather than everything being public. Then the user would have a choice of making something (library) public by creating a getter/setter or notating it as such using some symbol. Maybe + instead of _. I don't like _ having a special meaning as it is just another character to use in parameter/member names in my world.

Then a class might look like:

class Foo {

  // public stuff:

  int +bar;

  ...

  // private stuff;

  double buzz;

[eaz...@gmail.com]

Mmm I like dart. Please don't make me feel like coding obj-C.... ;-)

[Brook Monroe]

I don't like the underscores at all--despite the claim of "accepted
practice" in the JS community, I'm siding with Crockford on this one.
It's an arbitrary character, meaningless in other languages, and if
one of the goals of Dart was to make a language that looked like
something you're used to, then that's being flung down and danced
upon. (Dart isn't Javascript, right? The underscore hack--yes, it's
a hack--was an attempt to assert a feature that JS lacks. Why
perpetuate an ugly and useless hack?)

Anyone trying to read Dart code for the first time without benefit of
the tutorial is just going to think that the code author had a fetish
about variable names; it wouldn't immediately be obvious that a given
variable was public or private. Forcing scope by naming convention
seems as feckless a choice to me as forcing logical subordination by
indentation. (I'm lookin' at YOU, Python.)

So, what about this as a choice?

class A {
private {
this.var1 = ...
this.var2 = ...
}
this.var3 = ... // Public by default
methodAlpha() {
// By definition all of methodAlpha's members are private--or
should be (I haven't memorized the spec yet)

[eaz...@gmail.com]

Hi Brook.
I agree with you, it's an arbitrary character, but as arbitrary as any other.
I don't like the underscore either, but it is true that I would never have a public _field. And I also see that everybody uses it to name private fields, so, as a matter of convenience, I welcome it :-)
Look java, because of not having something like that it is a mess, not one, but n arbitrary chars! Some people use field1, others _field1 and a third slice uses mField1... (!!) It is a sacrifice I am willing to do avoid such a mess :-)

My two cents,
Kind regards,
Diego

[Mehmet Akin]

Hi,

Is there a bug report about this issue?

M.

[Dirk Detering]

Am 22.01.2012 14:17 schrieb "Brook Monroe" <brook....@gmail.com>:

Harsh words...

> It's an arbitrary character, meaningless in other languages,

... and wrong too. Surprisingly you are referring to python yourself, where even more than one underscore is part of the language.
It is significant in Haskell and also in Scala, both in the semantics of a placeholder (hmmm. More or less).

> and if
> one of the goals of Dart was to make a language that looked like
> something you're used to, then that's being flung down and danced
> upon.

Seems it depends on who is 'you' in the "you are used to" part, and if 'you' is willing to adapt anything new or only copying the "me like" style once more.

> Anyone trying to read Dart code for the first time without benefit of
> the tutorial is just going to think that the code author had a fetish
> about variable names;

In my experience anyone trying to read code in a language unknown to him will -without tutorial- be victim of misinterpretations, more or less, but not never. Depending on where you come from, Dart is boringly surpriseless or a big leap.
That is always true for any language.

> it wouldn't immediately be obvious that a given
> variable was public or private.  Forcing scope by naming convention
> seems as feckless a choice to me as forcing logical subordination by
> indentation.  (I'm lookin' at YOU, Python.)

Opinion.

> So, what about this as a choice?
>
> class A {
>    private {
>        this.var1 = ...
>        this.var2 = ...
>    }
>    this.var3 = ...    // Public by default

Hmmm. Looks interesting. Except for the cluttering this-dot prefix.
So you would also put private methods in there?
That looks like separating the class into two sections.
As private means library scoped in Dart, why not separate into two classes and make only one the public API?

Than we are back at the module export syntax discussion.

But: sometimes complaining with harsh words isn't enough. Perhaps -with a new language- one has to look at the problem in new ways.

My view:  I do not like the underline as modifier very much. But the leading one seems better, as it can be seen as kind of a unary operator.

[Adam Mark]

I come down on the side of explicitly declaring things private rather
than relying on conventions, because (a) people will break the
conventions, (b) JavaScript tends to fail where it is NOT explicit.
Isn't structure the whole purpose of Dart?

Adam

On Jan 22, 9:09 am, "eaz...@gmail.com" <eaz...@gmail.com> wrote:
> Hi Brook.
> I agree with you, it's an arbitrary character, but as arbitrary as any
> other.
> I don't like the underscore either, but it is true that I would never have
> a public _field. And I also see that everybody uses it to name private
> fields, so, as a matter of convenience, I welcome it :-)
> Look java, because of not having something like that it is a mess, not one,
> but n arbitrary chars! Some people use field1, others _field1 and a third
> slice uses mField1... (!!) It is a sacrifice I am willing to do avoid such
> a mess :-)
>
> My two cents,
> Kind regards,
> Diego

[Dirk Detering]

Adam, I haven't understood. You know that underscore in Dart is not simply a usage convention but a language inherent part? In this regard it is as explicit as any other solution.

[Adam Mark]

Ah, then my bad.  In that case, cool.  Although I think "private" is more readable, FWIW.

Thanks,

Adam

[Ladislav Thon]

Although I think "private" is more readable, FWIW.

I've been playing with Dart for quite some time now and I still can't decide whether I like underscore prefix for privacy or not. But I think I will eventually like it, because it is sooooo very simple to understand and reason about.

I was quite confused some time ago by this thing: how about members of private classes? Are they private? It doesn't matter if no instances ever get outside of the library, but what about private classes that implement public interfaces and their instances get out of the library? Well, I was overthinking it and I had to experiment with it a little, but then it finally clicked into place: it is all just about the names.

LT

[John Messerly]

On Mon, Jan 23, 2012 at 2:09 PM, Ladislav Thon <lad...@gmail.com> wrote:

I was quite confused some time ago by this thing: how about members of private classes? Are they private? It doesn't matter if no instances ever get outside of the library, but what about private classes that implement public interfaces and their instances get out of the library? Well, I was overthinking it and I had to experiment with it a little, but then it finally clicked into place: it is all just about the names.

Exactly. I like to think of it as "_foo" becomes "MyLibrarySecret_foo", and no other library can refer to your "MyLibrarySecret" prefix in their code. (That's more-or-less how it's implemented when compiling to JavaScript)

- John

[thebinary...@gmail.com]

Underscores are growing on me now. After porting something from Dart to Java, having to add 'private' to every declaration was annoying and it isn't as easy to tell which properties are private and which are not. Also, making the private variables ugly is maybe good as it reminds you that the interface is the pretty thing ;)

[brook....@gmail.com]

>> A language should not be reliant on an IDE to be used efficiently.

+1.

In fact, +1000.

On Monday, November 14, 2011 1:49:42 PM UTC-5, Izzy wrote:

> Both of these are easily solved by using an IDE.

and

> An IDE or the compiler can detect inappropriate access to methods/
> fields etc as the code is written or compiled (or even executed in
> checked mode or otherwise)

> Any IDE worth its salt can inform the developer of the accessibility
> of such as they
> view it ...

A language should not be reliant on an IDE to be used efficiently.

[rti...@gmail.com]

Dart reaches coding Zen in many places. I would describe it as taking the fact that code is read 10x more often then written, and reason from there.

• 2 spaces indent (easier on the eye, natural avoiding of 2+ nestings)
• Constructor(this.variable)
• simple and literate getters/setters syntax
• factories/factory constructors
• optional, named parameters
• simplistic but sufficint generics
• => shorthand for return { ... }
• removal of explicit interfaces, use implicit interfaces instead
• ... I could go on

All pragmatic choices enabling for very terse code. My personal experience has been overwhelming: reading code was never such joy before. When switching back to C# or Java, it becomes clear how fast I can build a mental model of dart code (read-think-realize). 

Using an underscore for the only available modifier (internal, protected, protected internal are factored out in favor of simplification - library privacy only) seems the simple and logical choice in the same spirit of above examples of aiming for the right level of simplicity.

I very much dig how the dart team has confirmed my presumption and currently is setting the example.

Ruud

Op maandag 10 oktober 2011 21:13:25 UTC+2 schreef Larry Cable het volgende:

[brook....@gmail.com]

I'm harsh kind of guy.  You want diplomacy, ask the U.N. for an opinion.

I'll agree that my assertion that underscore is arbitrary is wrong.  It's a mistake based on ignorance of both Haskell and Scala, as I don't program in either of them, nor will I be in the foreseeable future.  While there may be some learnings possible in the way they're designed, they're not mainstream in the way that Dart is intended to be mainstream--I'll speak to this point later.

The idea that underscore prefixing eases determination of what's private and not at a use site is interesting, but remembering that is my job as a programmer.  I'm unconvinced that it's the job of the language to bolster my memory, especially since I can adopt any strategy I like for that anyway.  (The no-doubt-jeered "p_someVar" versus plain old "someVar."  Not that I would necessarily choose that--it's an example.)  Those who hold that mixing language semantics with variable naming is a bad idea are gnashing their teeth--and I'm one of them.

For me the argument boils down to whether or not the plan is to write more code or less, and what the potential fallout is of either course.

In a library situation, making library global variables private by default and supplying exported getter/setter functions works at the expense of writing extra code.  It's at least more obvious to the untrained eye than prefix characters.  (I agree it leaves aside the question of how to declare the getters and setters as private or public; on the other hand, unless the setters have side effects [bad idea sometimes?] code internal to the library shouldn't need functions to access private library values.  I reserve the right to change my mind about this later when I have more time to think about it.)

In a class situation, making all member values private and writing public getters and setters for outside users also works (again, at the expense of writing extra code).

Given the choice of verbosity over quirky semantics (that you happen to like it in Haskell or Scala or what-have-you doesn't make it any less objectively quirky; I find the C/C++ "?:" quirky, as well), I'll choose verbosity.

So, is Dart intended to be terse?  If so, I suppose that's a vote for underscore.  Does it make the code easier to read and understand?  I don't know.  I'd have to flip a coin on that one.  What I don't like is any argument that ends with "it all makes sense once you understand what it means," which is a very long way of writing a tautology.  Of course it does.  The question is: how long does it take to understand what it means (both from the standpoints of semantics and readability)? _Is _it _easier _to _read _this _part _of _my _question, or this part?  Does anyone have a case to show that embedding semantics in naming reduces the number of software defects in code?  (Or evidence to the contrary?  Empirical data would be good either way, because then we'd be debating what works, not just what we like.)

While we're doing this, and understanding that we are each geniuses in our own right, officers and gentlepersons all, I think it's important to remember that we're arguing this not for ourselves, but for the middle of the bell curve.  MOR programmers ought to have a decent shot at getting something right the first time; while I don't think the verbosity of COBOL and Pascal are the correct answer, I'm not convinced a convenient shorthand is the answer, either.

Another way of looking at it: I've always looked at the PHP single-quoted- versus double-quoted-string situation as "just another ******* thing I have to remember" rather than as a real part of the language.  It's far from an elegant solution, and it varies a bit from what other languages do with strings.  (I don't think the perfect solution exists yet, although Dart gets closer, and the technique used in Ember [ {{value}} ] gets closer, too.)  Is the underscore prefix thing just another ******* thing I'll have to remember, or is it a natural solution to the problem?

If using the prefixed underscore reduces defects, promotes overall correctness, and generates easier-to-understand code for middle-of-the-road maintenance programmers, then I can grit my teeth and get over it.  If it's a convenience hack or the formalized acquisition of a casually adopted colloquialism, then I have to argue against it.  

I never found Humpty Dumpty's argument in Through the Looking Glass to be particularly compelling.

'When I use a word,' Humpty Dumpty said, in rather a scornful tone, 'it means just what I choose it to mean — neither more nor less.'

'The question is,' said Alice, 'whether you can make words mean so many different things.'

'The question is,' said Humpty Dumpty, 'which is to be master — that's all.'

>> Opinion. 

Like I'm the only person here with opinions?

[Bob Nystrom]

Here's one way to look at it. Let's say we did have a modifier for library-based privacy instead of using the underscores. Consider this program:

// a.dart

class PrivateInA {

  private method() => 'inside A';

}

class PublicInA {

  method() => 'inside A';

}

// b.dart

#import('a.dart');

class FromB {

  private method() => 'inside B';

}

callMethod(obj) {

  obj.method();

}

main() {

  callMethod(new FromB());

  callMethod(new PrivateInA());

  callMethod(new PublicInA());

}

So callMethod() will be invoked with three different objects. In one, method() is private but in the same library, so reachable. In one, it's public so that's OK. And in one it's private and in another library, so that needs to be a NoMethodException.

Note that call method doesn't have any type annotation, so there's no way we can statically tell which case is which here (unlike Java, C#, Scala, etc.). It has to be determined at runtime.

How would you compile this code to JavaScript?

With underscores, it's easy. Any time you see an underscore-prefixed name, you just mangle it to include the containing library. So this:

// a.dart

class PrivateInA {

  _method() => 'inside A';

}

turns into something like this:

// a.dart

class PrivateInA {

  $library_a$_method() => 'inside A';

}

You also do the same mangling when you call a private method:

callMethod(obj) {

  obj.$library_b$_method();

}

That alone is enough to get the right behavior with any real runtime overhead. It's near trivial to implement too.

We probably could get a non-name-based privacy system to work, but I'm pretty certain it would be a good bit more complex than the above simple just-mangle-the-name semantics, and I'm not confident it would have the same performance. Simple is good, so is fast. I personally find the "_" a bit ugly, but I appreciate that it does tangibly good things for the implementation(s) of the language.

Cheers!

- bob

[jbeall]

I vote for keeping traditional modifier keywords.  As countless others have pointed out, if you ever need to change visibility and visibility depends on the name of method/variable, then you're stuck with search & replace.  If you're using traditional modifier keywords, it's a simple matter of changing the keyword.

If we're going to say that using the _ prefix is helpful because it makes the visibility immediately obvious, then shouldn't we also say that type annotations should be specified by prefixing the variables?  See where this madness leads!? ;-)

  -Josh

[Christopher Wright]

jbeall, Bob Nystrom just pointed out it's impossible to implement 'private' as a keyword. Unless you want to add that at call sites as well, that is.

Well, I suppose you could mangle *all* names, and fall back to the unmangled name, but that seems pretty slow. You'd have to translate every function call:

#library('A');

foo.bar();

becomes:

if (foo.hasMethod('$library_A_bar')) foo.$library_A_bar();

else foo.bar(); // might go to noSuchMethod

You could make that faster with VM support, but it's still slow and ugly.

[Bob Nystrom]

On Mon, Jul 30, 2012 at 2:52 PM, Christopher Wright <dhas...@google.com> wrote:

jbeall, Bob Nystrom just pointed out it's impossible to implement 'private' as a keyword. Unless you want to add that at call sites as well, that is.

Exactly right. This is a case where this isn't just a pure aesthetic decision. Making privacy visible at the use site affects how easy/efficient it is to correctly implement the language semantics.

- bob

[Jaan Rett]

I realize this thread has gone stale, but I've been reading up on Dart, getting excited about it, then I find there is no object privacy. I come from a C++, C# and Java background and have been working recently with large javascript projects and can't wait to start pushing Dart.

I'm definitely in favor of a private/protected/internal/public set of keywords, like C#.

I've read lots of arguments in favor of the underscore thing, which is simply a convention adopted by javascript users who want privacy. It is a hack in my opinion and has not place in a new OOP language as the mechanism for privacy. By having Dart provide the private keyword doesn't prevent others from simply using the underscore instead of the keyword. Please add it to the language.

The argument about how do you compile to javascript with privacy that isn't supported in javascript isn't an issue either. The privacy can be enforced during compilation and does not need to exist in the javascript version. 

It's a simple solution.

Provide the private keyword, do not force people to use it so they can continue to use _

Class privacy does not need to be enforced in javascript as long as the compiler enforces it. The Dart VM should enforce it.

Any questions?

[John Messerly]

On Fri, Feb 22, 2013 at 2:57 PM, Jaan Rett <jaan...@gmail.com> wrote:

The argument about how do you compile to javascript with privacy that isn't supported in javascript isn't an issue either. The privacy can be enforced during compilation and does not need to exist in the javascript version. 

Dart has dynamic method dispatch, so you can't enforce this at compile time.

> ... then I find there is no object privacy 

Object privacy, or class privacy? IIRC C# and Java have class privacy, which is different from object privacy.

If you want class privacy in Dart, it's easy: just keep one class per library file.

- John

[Peter Jakobs]

After working with dart again with half a year of c#, I really like the simple privacy. Also the underscore makes it instand visible to me what is private and what not.

I personally don't want to support both, the keyword private and the underscore. It makes it harder to reason about code because some do the private style and some the underscore. Or maybe some mix it, which makes it even harder. So with the keyword private I always have to look up if some method or variable is private. The editor could help here as well for sure but I still love simplicity more.

Also the underscore is less typing. (At least some times :p)

[John Messerly]

FYI, an example of class-vs-object privacy (in C#). Note that "Bar" is private, but it can be read by another instance of Foo.

People often use this in implementing equality, for example.

using System;

namespace test_csharp

{

class Foo {

private int Bar;

public Foo(int bar) {

Bar = bar;

}

public void ReadTheBar(Foo foo) {

Console.WriteLine(foo.Bar);

}

public static void Main (string[] args)

{

var f = new Foo(123);

new Foo(42).ReadTheBar(f); // Prints 123

}

}

}

[Matthew Butler]

I don't think that there would be any significant gain by adding the private key word. It's darts philosophy to trust the programmer. That's why types are optional, particularly in production mode. The library level privacy supports that philosophy. That you know better than to change your variables recklessly (ie. Are aware of side-effects), but a consumer of your library cannot, as they don't share that knowledge.

As such you should know better than to recklessly change a variable that you want to use as private, and can treat it as such.

If you can't trust yourself from inadvertently changing a value you shouldn't access, then one option is to make every class it's own library and import everything. I know there are some who prefer this method, though it's not for me personally.

[mythz]

I'm also a long-time C# developer and I've come to really like the convention-based internal visibility Dart has.

It's made me re-think if we ever needed class-based privacy in the first place, and I don't miss it at all as IMO class-based privacy is at the wrong level that just adds un-necessary friction points between classes you control. Library-based privacy makes more sense since the correct unit of packaging for a feature is at the dev-configurable library level which can optionally span a suite of classes.

This is a case where less features is a win since I'm able to code freely code without wasting time on picking the best fine-grained privacy option, it's either apart of the library's public API or it's not.

[Jaan Rett]

After reading some of the recent comments, I went back to the dart web site and did some more reading there. I was under the impression that the underscore was simply a convention. I did not realize that it is actually the mechanism to enforce library level privacy. I'm good with that. This is just fine. I withdraw my objection to not having 'class' privacy.

Thanks everyone for being persistent. Sometimes I don't pay enough attention.