On Thursday, 17 May 2018 at 07:36:40 UTC, arturg wrote:
>
> no, that uses type inferance.
> you have to do
> Animal dog = new Dog;

i tried it... certainly interesting.. thanks.

but, I don't recall in my opening post, saying I'm ok with having to create an interface for every class I create, just so I can go off and cast each class to that interface ;-)

The sealed attribute would not require me to go to such extravagant lengths.

Remember, the idea for discussion is about adding one single attribute 'sealed' to the class - the discussion is a lot less about 'how can we prevent having to add a this new attribute'.

On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:
> I propose an idea, for discussion (robust discussion even better ;-)
>
> Add an new attribute to class, named 'sealed'.

If class level protection is added, please do not call it sealed.
People from c++ might be suprised by 'private' already. We do not have to confuse those c#ies too.

Module level protection is enough to hide implementation details though. So while i do understand why you want this in D, i don't think it is worth it to complicate the language for something you can work around easily by putting the classes in their own modules.
I'm also not convinced think that your 'sealed' would be used much, because accessing private state in the module is actually extremly useful (e.g. unittests).

That beeing said, if you are convinced it would be a good addition, please write a DIP.
Even if it will not be accepted it will at least force a decision. And we can point to the reasons it got accepted/rejected in the future.

On Thursday, 17 May 2018 at 10:34:18 UTC, Zoadian wrote:
> On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:
>> I propose an idea, for discussion (robust discussion even better ;-)
>>
>> Add an new attribute to class, named 'sealed'.
>
> If class level protection is added, please do not call it sealed.
> People from c++ might be suprised by 'private' already. We do not have to confuse those c#ies too.

Interesting.

If only D had applied that same criteria to use of the word 'private'.

I do wonder what word could possibly suffice, to please everyone.


> Module level protection is enough to hide implementation details though. So while i do understand why you want this in D, i don't think it is worth it to complicate the language for something you can work around easily by putting the classes in their own modules.

Here, I think you are falling into the trap, of believing, that the concept of
modularity can only ever apply the way D currently applies it - at the file level.

In OOP programming, the class is the module. (yes, I know how much D programmers love OOP ;-)

When OOP programmers come to D however, they are 'forced' into the D concept of modularity, and cannot model modularity in accordance with their own problem domain - but have no choice to use one class per file - just to regain what they already have in other mainstream languages. But then, for those OOP programmer, the 'file' has little value, cause it now can only ever represent a single class.

Remember, that the idea here is not to force anyone to change how they currently think or do things. It simply extends the way in which a 'file' module can be used.


> I'm also not convinced think that your 'sealed' would be used much, because accessing private state in the module is actually extremly useful (e.g. unittests).
>

Again, what people can do, they will still be able to do. Nothing changes for them.

btw. D has less than 1000 programmers. How many OOP programmers in the world?
Build it, and they will come...perhaps.

> That beeing said, if you are convinced it would be a good addition, please write a DIP.

DIP before discussion, is not the way I do things.

> Even if it will not be accepted it will at least force a decision. And we can point to the reasons it got accepted/rejected in the future.

Again, DIP before discussion, and we all know what will happed to the DIP.

On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:
> I propose an idea, for discussion (robust discussion even better ;-)
>
> Add an new attribute to class, named 'sealed'.
>
> No, not sealed as in Scala.
>
> No, not sealed as in C#
>
> sealed as in oxford dictionary (close securely, non-porous).
>
> when sealed is applied on the class, this means the class is sealed.
>
> the sealed attribute only makes sense within a module, and affects nothing outside of the module.
>
> When sealed is applied to the class, then, interfacing to a class within a module, from code outside that class - but still within the module, can now only occur via the published interface of the class.
>
> outside code in the module, can no longer directly access your private parts!
>
> The class is sealed.

I don't think that "sealed" is the right name here. Currently C# has its sealed and Scala has its sealed - and these are different things (although I don't code C# and may be wrong, it seems like C#'s sealed is Java's or D's final). I believe that giving "sealed" keyword yet another sense in D is not the right approach.

Furthermore, I don't believe that the proposed version of sealed would be a widely-used feature that broadens the language capabilities. It solves the problem that - as discussion in my thread shown - some people consider valid, and some not.

My opinion is that it's not worth a new keyword and time for implementing. In the same manner you could ask for removing friend concept from C++ as a bad concept. I don't answer the question whether this concept is good or bad - just give an example. The difference is that you can just go without friend at all, and module-level private is forced.

The other reason I don't think it is a feature significant enough is kind of library level. I expect that only author or limited team of people will freely modify the code of module. So there is limited number of people that have a control over the module and it shouldn't be a big deal not to refer to private fields outside the class or define it as a team rule. I believe that a nice approach here would be to add a check to DScanner, so that your editor or IDE could optionally warn you if you refer to the private member from outside the class. But as module is a small unit and its code should probably be controlled/verified by the limited number of people, I don't see this as a big deal.

Note that Scala-like sealed from my proposal would have a greater impact (it blocks inheritance outside the module - helps to prevent the library code from being used in a way it is not designed to) and your proposal changes things in a very limited scope.

OFC, I am not a "compiler person", nor Walter, Andrei and anyone from the team, so my opinion is definitely not decisive in any way :)

To sum up [TLDR]: I don't see your arguments strong enough to alter the language (especially make a cross-language confusion over the "sealed" keyword), but DScaner check would still allow to track down what you consider bad.

On Thursday, 17 May 2018 at 11:56:51 UTC, Piotr Mitana wrote:
>
> My opinion is that it's not worth a new keyword and time for implementing. In the same manner you could ask for removing friend concept from C++ as a bad concept. I don't answer the question whether this concept is good or bad - just give an example. The difference is that you can just go without friend at all, and module-level private is forced.

Try telling Bjarne Stroustrup that ;-)

I still believe (like Bjarne) that friend in c++ is the right way, for those of us that believe that the defined interface is how you obtain your interface. Friend is a part of the defined interface.

Within implict friends, the interface is pretty blurry - but that's another story, and as I said, my change would not affect those who thing facebook like friendship in modules is a good approach - I think we can have it both ways really.

Although I don't suggest adding friend to D, I do like option of having static enforcement of the defined interface, as a possibilty the programmer can opt-in to.

At the moment, that can only be done by the one-class-per-module hack.

Which means, for OOP programmers, the module in D(i.e. the file), becomes nothing more than a pseudo class. This will make some (perhaps many) OOP programmers wonder why they should bother coming to D at all. It certainly is a question I keep asking myself, over and over - at some point I make a conclusion.

The capacity to have more than one class in a module, and be able to obtain static enforcement of the use of the defined interface (by restoring private to its rightful status - as an option - perhaps by the using the sealed attribute on a class), can only have a positive effect, in my view. I cannot see how it would negatively affect anyone. It's purely opt-in, not opt-out.

And yes, it's a small change, but has potential for great impact (presumably, only positive impact) - although that's why I want to have this discussion - to see how others think too.

On Thursday, 17 May 2018 at 11:18:52 UTC, KingJoffrey wrote:
> On Thursday, 17 May 2018 at 10:34:18 UTC, Zoadian wrote:
>> On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:
>>> [...]
>> People from c++ might be suprised by 'private' already. We do not have to confuse those c#ies too.
>
> Interesting.
>
> If only D had applied that same criteria to use of the word 'private'.

Have you considered the keyword `module`?

--- kings.d
class King
{
    private string _name;
    module string __name;
    public string getName()
    {
        return __name;
    }
    public void setName(string name)
    {
        __name = name;
    }
}

void main()
{
    scope king = new King();
    king._name = "me"; //ok: _name is private
    king.__name = "me"; //error: __name is of `module` scope
    king.setName("me"); //ok
}

> I do wonder what word could possibly suffice, to please everyone.

`module`

/s
>> [...]
> Again, DIP before discussion, and we all know what will happed to the DIP.

I won't oppose such an addition since it will be purely opt-in, but you will have to consider that this would add more specifiers:
`private`, `protected`, `package`, `public` and `export`.
You might also want to read these [0] past discussions on this feature. I'm not sure how up to date that doc is, but it should be a good starting point.

[0]: https://wiki.dlang.org/Access_specifiers_and_visibility#Current_state_of_affairs_in_C.2B.2B

On 5/16/18 10:32 PM, KingJoffrey wrote:
> I propose an idea, for discussion (robust discussion even better ;-)
> 
> Add an new attribute to class, named 'sealed'.
> 
> No, not sealed as in Scala.
> 
> No, not sealed as in C#
> 
> sealed as in oxford dictionary (close securely, non-porous).
> 
> when sealed is applied on the class, this means the class is sealed.
> 
> the sealed attribute only makes sense within a module, and affects nothing outside of the module.
> 
> When sealed is applied to the class, then, interfacing to a class within a module, from code outside that class - but still within the module, can now only occur via the published interface of the class.
> 
> outside code in the module, can no longer directly access your private parts!
> 
> The class is sealed.
> 

I don't think you are going to get this to fly. We already have abilities to make the details truly private. I agree it's not as straightforward as other languages, but it is possible. Lately, the chances of adding an enhancement like this is pretty slim -- we have a mechanism to do it already, but is just a little more clunky. And it's not a huge problem for most code. I'd predict that if this were to be accepted, it would seldom be used anyway. So the cost/benefit ratio is very high.

Essentially, if you put your class you want "sealed" into it's own module, and then publicly import the module from the API module, you will get the same effect. This is even easier now with the package module than it used to be.

What private currently does is rational and makes sense. It's not the same as all other languages, but it is the same as some of them. It's simply a preference, and D picked something different from what you like. There are things I would have picked differently than D also, but not much to be done about those choices at this point.

-Steve

On Thursday, 17 May 2018 at 11:56:51 UTC, Piotr Mitana wrote:
>
> To sum up [TLDR]: I don't see your arguments strong enough to alter the language (especially make a cross-language confusion over the "sealed" keyword), but DScaner check would still allow to track down what you consider bad.

'altering' the langauge is a pretty strong way to describe it.

I prefer to think of it as 'empowering the programmer'.

Now, choosing a keyword, will certainly be tricky, I accept that much. There is little consenus going to happen there, I guess.

As for your dscanner solution, that doesn't address the requirement.

And in any case, should D programmers have to rely on dscanner to pick up the problem with this?

----
module test;

void main()
{
    int var = 1;
    const int *ip = &var;

    int var2 = 2;
    ip = &var2;
}

------

On Thursday, 17 May 2018 at 13:28:19 UTC, Steven Schveighoffer wrote:
>
> Essentially, if you put your class you want "sealed" into it's own module, and then publicly import the module from the API module, you will get the same effect. This is even easier now with the package module than it used to be.

Fair enough. Now no OOP programmer has any need to take at look at D.

I can already do that in other, better known, better supported languages.

Indeed, i can put more than one class in a class file in those languages, and, I still get the guarantee of correctness at compile time.

> What private currently does is rational and makes sense. It's not the same as all other languages, but it is the same as some of them. It's simply a preference, and D picked something different from what you like. There are things I would have picked differently than D also, but not much to be done about those choices at this point.
>
> -Steve

The other persepective is also rational, and makes sense.

I believe both perspectives could be accomodated, and at the same time without breaking anything, and without affecting in any way, the way people currently use the module.

The change would be completely blind to those people, until they choose to opt in to the change.

If D is at the point where change can no longer occured, it's over for D.

On 5/17/18 9:38 AM, KingJoffrey wrote:
> On Thursday, 17 May 2018 at 13:28:19 UTC, Steven Schveighoffer wrote:
>>
>> Essentially, if you put your class you want "sealed" into it's own module, and then publicly import the module from the API module, you will get the same effect. This is even easier now with the package module than it used to be.
> 
> Fair enough. Now no OOP programmer has any need to take at look at D.
>
> I can already do that in other, better known, better supported languages.

D's main draw is not OOP. So if you are here for OOP goodies, then you are definitely better off looking elsewhere.

That being said, D does have OOP, and many OOP programmers are fine with the current state of affairs.

>> What private currently does is rational and makes sense. It's not the same as all other languages, but it is the same as some of them. It's simply a preference, and D picked something different from what you like. There are things I would have picked differently than D also, but not much to be done about those choices at this point.
>>
> 
> The other persepective is also rational, and makes sense.

Not disputing that, it's a reasonable choice either way.

> I believe both perspectives could be accomodated, and at the same time without breaking anything, and without affecting in any way, the way people currently use the module.
> 
> The change would be completely blind to those people, until they choose to opt in to the change.

Unfortunately, that fails the first time you see code that has "sealed" on it, and have to go figure out what exactly that means.

> If D is at the point where change can no longer occured, it's over for D.

That's not what was stated. This proposal is a convenience feature, because you can already accomplish what is requested (making sure private internals are inaccessible to certain parts of the code). At this point, making incremental changes like this requires a very high bar of acceptance since you would be adding another complication to a language that is fairly stable. If I were you, I would stop worrying about this and either accept the status quo or look for a language that suits your requirements more directly. I think there are probably no people here who think D is the "perfect language", or that there even exists a "perfect language", you just have to judge whether the warts are worth living with or not.

You're welcome to write a DIP, but I don't see a very good chance for acceptance given the discussions on this subject.

-Steve