protected vars and methods?

[Christian Grobmeier]

Hello,

in the spec is is said that there will be abstract classes one day in Dart.
Now I know we have private and public vars with _ or not _.

I think it will be very useful to have some kind of "protected"
variables and "protected" methods in Dart. They should imho only be
accessible from the extending class (and their descendants).

Not sure if this is already discussed or not or what your feelings are
about protected stuff.

Cheers
Christian

--
http://www.grobmeier.de
https://www.timeandbill.de

[Bob Nystrom]

On Tue, Nov 29, 2011 at 3:43 AM, Christian Grobmeier <grob...@gmail.com> wrote:

Hello,

in the spec is is said that there will be abstract classes one day in Dart.

Those should be working now as far as I know.

 

Now I know we have private and public vars with _ or not _.

Yup. Keep in mind that this is library private, not class private. So it isn't like "private" in Java and C#. It's like "internal" or package private.

 

I think it will be very useful to have some kind of "protected"
variables and "protected" methods in Dart. They should imho only be
accessible from the extending class (and their descendants).

Not sure if this is already discussed or not or what your feelings are
about protected stuff.

It's come up for discussion a few times.

I find protected handy when designing frameworks that include base classes you expect users to subclass. It lets your framework distinguish between the API it exposes to users of a class versus the one it exposes to subclassers of it.

But it also adds complexity to the language. I think for now the current plan is to try to live without it and see how it goes. Most dynamic languages don't seem to have it and still get by OK. I think we can get most of what we want just through documentation and convention: just make it clear to users which methods should be called only by subclasses and which can be called by anyone.

- bob

[Kriegy]

Welcome in the Dark Side of Dart ! ;)
I'm a Java/Flex developper and to me the privacy system in Dart is
just a (bad) joke. I cannot see it otherwise than a huge regression
compared to "traditionnals object oriented languages" such as Java /
C# / ActionScript / D...
I think that this is the worst "feature" of Dart, and more importantly
that this is a DANGEROUS thing for the popularity of the language.
When I talked about that at the office, my coworkers were not really
happy... At least this is NOT FAMILIAR for a lot of developpers.
Fortunately, the rest of the language seems to be really good and/or
familiar. I had some doubts at the beginning with the use of "_" for
privacy, but now I think it's not a big deal.
On Nov 29, 7:10 pm, Bob Nystrom <rnyst...@google.com> wrote:

> On Tue, Nov 29, 2011 at 3:43 AM, Christian Grobmeier <grobme...@gmail.com>wrote:
>
> > Hello,
>
> > in the spec is is said that there will be abstract classes one day in Dart.
>
> Those should be working now as far as I know.
>
> > Now I know we have private and public vars with _ or not _.
>

> Yup. Keep in mind that this is *library* private, not *class* private. So

> it isn't like "private" in Java and C#. It's like "internal" or package
> private.
>
>
>
> > I think it will be very useful to have some kind of "protected"
> > variables and "protected" methods in Dart. They should imho only be
> > accessible from the extending class (and their descendants).
>
> > Not sure if this is already discussed or not or what your feelings are
> > about protected stuff.
>
> It's come up for discussion a few times.
>
> I find protected handy when designing frameworks that include base classes
> you expect users to subclass. It lets your framework distinguish between

> the API it exposes to *users* of a class versus the one it exposes to *
> subclassers* of it.

[Christian Grobmeier]

On Tue, Nov 29, 2011 at 7:10 PM, Bob Nystrom <rnys...@google.com> wrote:
> On Tue, Nov 29, 2011 at 3:43 AM, Christian Grobmeier <grob...@gmail.com> wrote:
>>
>> Hello,
>>
>> in the spec is is said that there will be abstract classes one day in
>> Dart.
>
> Those should be working now as far as I know.

Excellent!!!!!

>> Now I know we have private and public vars with _ or not _.
>
> Yup. Keep in mind that this is library private, not class private. So it
> isn't like "private" in Java and C#. It's like "internal" or package
> private.

Oh- thanks for mentioning it, I actually missed that fact. But
honestly I am not very glad to hear about this. One needs to rely that
people cut out their libraries very carefully and well designed. But I
can imagine that some folks just put everything into one library just
to get done quickly. After all they have all the problems one has when
using public vars only. And they will blame Dart for it, because they
didn't understand and tweet: "privacy mechanism doesn't work"

Actually I would prefer to have private members on a class privacy
scope. Some people are even using the underscore syntax to identify
private members in code. Their expectation is of course that they are
private on class level.

That being said, I like the _ idea. It might be ok to have more suche
identifiers, similar to uml maybe.

Like:

bool _stuff; // class scope
bool *stuff; // package scope
bool +stuff; // protected scope

>> I think it will be very useful to have some kind of "protected"
>> variables and "protected" methods in Dart. They should imho only be
>> accessible from the extending class (and their descendants).

...

> But it also adds complexity to the language. I think for now the current
> plan is to try to live without it and see how it goes. Most dynamic
> languages don't seem to have it and still get by OK. I think we can get most
> of what we want just through documentation and convention: just make it
> clear to users which methods should be called only by subclasses and which
> can be called by anyone.

Yes, most dynamic languages don't have it. And I hate it. For example
PHP: they don't use protected, just private and public. Sometimes I
need to put some stuff to public, even when this is weird, just to
avoid to copy paste the same code all over again.

The conventions and documentation you mentioned might work if you have
a few hundred lines of browser side code. But you might think
different when you start to write server side code for the app engine.
At least I would love to see Dart executed on the server side and
replace Java in some cases.

Complexity in language: my argument is, not using class level privacy
might make this language more complex as necessary because in my
opinion this is what people expect.

Of course, I am not really a language designer, this is just my taste.
Thanks for your explains Bob, they are very helpful as always.

Cheers,

[Ladislav Thon]

I'm a Java/Flex developper and to me the privacy system in Dart is
just a (bad) joke. I cannot see it otherwise than a huge regression
compared to "traditionnals object oriented languages" such as Java /
C# / ActionScript / D...

I'm a (mostly) Java developer with a strong personal interest in programming languages. I've been thinking about privacy a lot and I came to the same conclusion that Dart designers came to -- the only privacy that really matters is the library interface. What is exposed to the outside world and what is not.

Libraries should generally be reasonably-sized and have well-defined interfaces. I would agree that naming convention for privacy and public-by-default isn't exactly the best way to define interfaces, but that would be the statically typed me. The culture of "expose everything by default" is pretty common in dynamic languages, if I can tell, and Dart is dynamic in its heart.

(I come from static typing camp, but I'm a big fan of Dart's optional typing. I stopped believing in safety guarantees of static typing a while ago, but I still love static types for the great tooling they allow.)

Just to let you know that there are other opinions as well.

LT

[Christian Grobmeier]

On Wed, Nov 30, 2011 at 11:41 AM, Ladislav Thon <lad...@gmail.com> wrote:
>> I'm a Java/Flex developper and to me the privacy system in Dart is
>> just a (bad) joke. I cannot see it otherwise than a huge regression
>> compared to "traditionnals object oriented languages" such as Java /
>> C# / ActionScript / D...
>
>
> I'm a (mostly) Java developer with a strong personal interest in programming
> languages. I've been thinking about privacy a lot and I came to the same
> conclusion that Dart designers came to -- the only privacy that really
> matters is the library interface. What is exposed to the outside world and
> what is not.

I agree here

> Libraries should generally be reasonably-sized and have well-defined
> interfaces. I would agree that naming convention for privacy and
> public-by-default isn't exactly the best way to define interfaces, but that
> would be the statically typed me. The culture of "expose everything by
> default" is pretty common in dynamic languages, if I can tell, and Dart is
> dynamic in its heart.

I agree there should be "good sized" libraries. But i am afraid not
every developer out there has the competence to do so.

> Just to let you know that there are other opinions as well.

Cool thank you.
Actually I have started to think about the benefits of such a behavior again.

Cheers
Christian

>
> LT

[Bob Nystrom]

On Wed, Nov 30, 2011 at 2:12 AM, Christian Grobmeier <grob...@gmail.com> wrote:

Oh- thanks for mentioning it, I actually missed that fact. But
honestly I am not very glad to hear about this. One needs to rely that
people cut out their libraries very carefully and well designed. But I
can imagine that some folks just put everything into one library just
to get done quickly. After all they have all the problems one has when
using public vars only. And they will blame Dart for it, because they
didn't understand and tweet: "privacy mechanism doesn't work"

That's a concern of mine too. The fact that we don't use a familiar "private" keyword helps a little, I think. Beyond that, the best we can do is what we're doing now: communicate it clearly and frequently.

If Dart is to have any concept of privacy, I do think that library private is more useful than class private. Privacy in Dart (and other languages) isn't for security, it's for maintainability. You mark things private to ensure that people don't need to know about them in order to use your code.

From that angle, library private makes sense to me. I consider a library to be a unit of maintenance. If you're modifying a library I think it's reasonable to expect you to understand most of its code. You should be able to load the whole library into your head, so you don't really need to make parts of it private and hidden from other parts. If you do find yourself wanting that, I think that's a sign you should break your code up into smaller libraries.

Yes, most dynamic languages don't have it. And I hate it. For example
PHP: they don't use protected, just private and public. Sometimes I
need to put some stuff to public, even when this is weird, just to
avoid to copy paste the same code all over again.

I feel weird about it too sometimes, but I think that may just be my C++/C#/Java background. People who live and breathe in dynamic languages seem to be OK with it.

 

The conventions and documentation you mentioned might work if you have
a few hundred lines of browser side code.

We've written a good bit more Dart code than that and so far privacy hasn't been a real problem. Swarm is a few thousand lines of code broken into a bunch of different libraries.

 

At least I would love to see Dart executed on the server side and
replace Java in some cases.

We would too!

- bob

[Bob Nystrom]

On Wed, Nov 30, 2011 at 2:44 AM, Christian Grobmeier <grob...@gmail.com> wrote:

I agree there should be "good sized" libraries. But i am afraid not
every developer out there has the competence to do so.

We can only do so much but I think a big part of addressing this is building a strong community and ecosystem of libraries that are nice and small. When people come to a language, I think they generally follow along with the existing practices and codebases so we can help by setting a good example.

- bob

[Dominic Hamon]

On Wed, Nov 30, 2011 at 10:44 AM, Bob Nystrom <rnys...@google.com> wrote:

On Wed, Nov 30, 2011 at 2:12 AM, Christian Grobmeier <grob...@gmail.com> wrote:

Oh- thanks for mentioning it, I actually missed that fact. But
honestly I am not very glad to hear about this. One needs to rely that
people cut out their libraries very carefully and well designed. But I
can imagine that some folks just put everything into one library just
to get done quickly. After all they have all the problems one has when
using public vars only. And they will blame Dart for it, because they
didn't understand and tweet: "privacy mechanism doesn't work"

That's a concern of mine too. The fact that we don't use a familiar "private" keyword helps a little, I think. Beyond that, the best we can do is what we're doing now: communicate it clearly and frequently.

If Dart is to have any concept of privacy, I do think that library private is more useful than class private. Privacy in Dart (and other languages) isn't for security, it's for maintainability. You mark things private to ensure that people don't need to know about them in order to use your code.

From that angle, library private makes sense to me. I consider a library to be a unit of maintenance. If you're modifying a library I think it's reasonable to expect you to understand most of its code. You should be able to load the whole library into your head, so you don't really need to make parts of it private and hidden from other parts. If you do find yourself wanting that, I think that's a sign you should break your code up into smaller libraries.

I think both are important for maintenance. It's not about what you have to remember, it's about exposing APIs for each unit. The unit can be a class, in which case class private (and protected) are important. A unit can also be a library, at which point library private is important. These are two different concepts but I think both are important.

 

Yes, most dynamic languages don't have it. And I hate it. For example
PHP: they don't use protected, just private and public. Sometimes I
need to put some stuff to public, even when this is weird, just to
avoid to copy paste the same code all over again.

I feel weird about it too sometimes, but I think that may just be my C++/C#/Java background. People who live and breathe in dynamic languages seem to be OK with it.

 

The conventions and documentation you mentioned might work if you have
a few hundred lines of browser side code.

We've written a good bit more Dart code than that and so far privacy hasn't been a real problem. Swarm is a few thousand lines of code broken into a bunch of different libraries.

How many developers are working on it and how well do you all communicate? For large projects with multiple remote developers, it may become an issue.

[Kriegy]

Defining public, private, protected and library/package levels of
privacy allow people to write their code as they want, and this
includes the ability to use only the library/package privacy. And if
you really think this is the best way to write the code, this can be
part of a style guide.
I think Google should not give developpers a not-so-bad reason for
rejecting Dart...
On Nov 30, 7:48 pm, Dominic Hamon <domin...@google.com> wrote:
> On Wed, Nov 30, 2011 at 10:44 AM, Bob Nystrom <rnyst...@google.com> wrote:

>
> > On Wed, Nov 30, 2011 at 2:12 AM, Christian Grobmeier <grobme...@gmail.com>wrote:
>
> >> Oh- thanks for mentioning it, I actually missed that fact. But
> >> honestly I am not very glad to hear about this. One needs to rely that
> >> people cut out their libraries very carefully and well designed. But I
> >> can imagine that some folks just put everything into one library just
> >> to get done quickly. After all they have all the problems one has when
> >> using public vars only. And they will blame Dart for it, because they
> >> didn't understand and tweet: "privacy mechanism doesn't work"
>
> > That's a concern of mine too. The fact that we don't use a familiar
> > "private" keyword helps a little, I think. Beyond that, the best we can do
> > is what we're doing now: communicate it clearly and frequently.
>
> > If Dart is to have any concept of privacy, I do think that library private
> > is more useful than class private. Privacy in Dart (and other languages)
> > isn't for security, it's for maintainability. You mark things private to
> > ensure that people don't need to know about them in order to use your code.
>
> > From that angle, library private makes sense to me. I consider a library

> > to be a unit of maintenance. If you're *modifying* a library I think it's

> > reasonable to expect you to understand most of its code. You should be able
> > to load the whole library into your head, so you don't really need to make

> > parts of it private and hidden from other parts. If you *do* find

[Christian Grobmeier]

On Wed, Nov 30, 2011 at 7:44 PM, Bob Nystrom <rnys...@google.com> wrote:
>
>
> On Wed, Nov 30, 2011 at 2:12 AM, Christian Grobmeier <grob...@gmail.com>
> wrote:
>>
>>
>> Oh- thanks for mentioning it, I actually missed that fact. But
>> honestly I am not very glad to hear about this. One needs to rely that
>> people cut out their libraries very carefully and well designed. But I
>> can imagine that some folks just put everything into one library just
>> to get done quickly. After all they have all the problems one has when
>> using public vars only. And they will blame Dart for it, because they
>> didn't understand and tweet: "privacy mechanism doesn't work"
>
>
> That's a concern of mine too. The fact that we don't use a familiar
> "private" keyword helps a little, I think. Beyond that, the best we can do
> is what we're doing now: communicate it clearly and frequently.
>
> If Dart is to have any concept of privacy, I do think that library private
> is more useful than class private. Privacy in Dart (and other languages)
> isn't for security, it's for maintainability. You mark things private to
> ensure that people don't need to know about them in order to use your code.
>
> From that angle, library private makes sense to me. I consider a library to
> be a unit of maintenance. If you're modifying a library I think it's
> reasonable to expect you to understand most of its code. You should be able
> to load the whole library into your head, so you don't really need to make
> parts of it private and hidden from other parts. If you do find yourself
> wanting that, I think that's a sign you should break your code up into
> smaller libraries.

Thanks for sharing your thoughts.

well in theory this is nice. You somehow "force" people to make nice
lIbraries. But there are many I know who failed already with
"separation of concerns" in Java. It will not be easier for them now,
as they need to think about libraries which I consider a core aspect
now.

>> The conventions and documentation you mentioned might work if you have
>> a few hundred lines of browser side code.
>
> We've written a good bit more Dart code than that and so far privacy hasn't
> been a real problem. Swarm is a few thousand lines of code broken into a
> bunch of different libraries.

OK I need to trust you on that atm.

It might make sense not to refer to "private members" etc to private
stuff. Guess it should be a new term, clearly showing this is not the
privacy which is known in many languages (even javascript, somehow).
For example: library scoped.

Cheers

[Christian Grobmeier]

:-)

I wish this will happen - but honestly, I have seen a great designed
system of two guys totally killed by six developers who started to the
daily business with it. i doubt that the big mainstream is really
caring on "how to do right". I think many people just want to get it
done and then move to home, grab a beer.

Anyway i will keep an eye on the developments. If you are right on
that, and people start to behave and write good encapsulated libraries
in the Dart Way, then I promise to buy you a beer on the next
conference we meet (assuming you drink beer).

Cheers
Christian

>
> - bob

[Daren Chandisingh]

> For example
> PHP: they don't use protected, just private and public.

We do use protected in PHP. \o/ Certainly in PHP 5.

Protected variables or methods can be accessed within the class
itself as well as subclasses and superclasses.

Regarding privacy in Dart, having library privacy only doesn't seem
a big deal to me. It does at least provide a way of blocking off internal
details from external use; and I think we should be able to trust
developers of a library to police their own use of "private" items within
that library itself.

And if someone mis-uses something within a library or application
and breaks something, well... that's what the unit tests are for. ;)

[denis papin]

You are absolutely right. It will be a good reason to reject Dart and it's heart breaking.

"Library private" and "class protected" have nothing to do.  Of course we can hide the inner implementation with library private, but how about giving the possibility to extend a library from another by reusing the some powerful mother methods which have not to be public at the end.

The vision of "library private" is limited to the idea that a set of classes will only be used be "final" developers as final classes. But it is not the only use of a library, we may want to extend it ! And then, it will be a pain in the a**  when we will discover that the original developer has set all the powerful methods as "_" :(

- Denis

[Ladislav Thon]

You are absolutely right. It will be a good reason to reject Dart and it's heart breaking.

If someone wants to reject Dart based on its novel approach to privacy, I have no problem with that. But I think that class-based privacy only complicates stuff in large-scale application development and that designing classes to be both subclassed and used from the outside is almost always a bad idea.

LT

P.S.: this thread is almost a year old -- what about starting a new one?

[denis papin]

On Saturday, October 20, 2012 9:12:04 PM UTC+2, Ladislav Thon wrote:

You are absolutely right. It will be a good reason to reject Dart and it's heart breaking.

If someone wants to reject Dart based on its novel approach to privacy, I have no problem with that. But I think that class-based privacy only complicates stuff in large-scale application development

I agree with that.

 

and that designing classes to be both subclassed and used from the outside is almost always a bad idea.

Why is it a bad idea ? It's the case for so many the frameworks ever built so far for C++, Java and C # .  I don't think so many people have "bad ideas".

If the solution you have in mind is about writing an extra E class  that would limit the visibility of let's say methods of  A, then to make it work with B subclass of A, E would have to be generic. Can you imagine the complexity we bring here ?  Without saying that E will not allow to use new method of B until we subclass it to F, etc, etc.

I can't see how that can work but if you have an exemple for me, I would study it with pleasure as I am really looking for a solution.

 

LT

P.S.: this thread is almost a year old -- what about starting a new one?

Ok, I will start a new one called "concrete work around for missing protected methods".

-Denis