June 08, 2022
On Wednesday, 8 June 2022 at 11:25:46 UTC, forkit wrote:
>
> Interesting that Scala has 'private[this]'
>
> https://stackoverflow.com/questions/9698677/privatethis-vs-private

oh.

https://docs.scala-lang.org/scala3/reference/dropped-features/this-qualifier.html

June 08, 2022

On Wednesday, 8 June 2022 at 11:25:46 UTC, forkit wrote:

>

Still, I think I'd prefer 'hidden' actually. It's pretty clear what you're stating here with that word.

It is important that it sounds like it is less accessible than "private", I guess "hidden" sends that message.

«hidden from module»

«private to module»

June 08, 2022
On Wednesday, 8 June 2022 at 11:32:48 UTC, forkit wrote:
>

Another option is:

class myClass
{
    private[myClass] int x; // private to this abstraction.
    private int y; // private to the module
}

same for a struct:

struct myStruct
{
    private[myStruct] int x;
    private int y;
}


I kinda like this.
June 08, 2022

On Wednesday, 8 June 2022 at 11:37:53 UTC, Ola Fosheim Grøstad wrote:

>

It is important that it sounds like it is less accessible than "private", I guess "hidden" sends that message.

«hidden from module»

«private to module»

hidden looks better!

June 08, 2022

On Wednesday, 8 June 2022 at 11:37:53 UTC, Ola Fosheim Grøstad wrote:

>

On Wednesday, 8 June 2022 at 11:25:46 UTC, forkit wrote:

>

Still, I think I'd prefer 'hidden' actually. It's pretty clear what you're stating here with that word.

It is important that it sounds like it is less accessible than "private", I guess "hidden" sends that message.

«hidden from module»

«private to module»

Sounds good to me.

June 08, 2022
On Wednesday, 8 June 2022 at 11:38:15 UTC, forkit wrote:
> On Wednesday, 8 June 2022 at 11:32:48 UTC, forkit wrote:
>>
>
> Another option is:
>
> class myClass
> {
>     private[myClass] int x; // private to this abstraction.
>     private int y; // private to the module
> }
>
> same for a struct:
>
> struct myStruct
> {
>     private[myStruct] int x;
>     private int y;
> }
>
>
> I kinda like this.

I don't like it, it seems to add much more clutter, like imagine some long generic type name.

June 08, 2022
On Wednesday, 8 June 2022 at 11:49:26 UTC, bauss wrote:
>
> I don't like it, it seems to add much more clutter, like imagine some long generic type name.

Yes, I agree. Too much typing ;-)

.. and what happens if you mistype??

Forget that idea ;-)

btw. interesting (but old) discussion in the scala commmunity around this idea:

I think they ended up dropping private[this] in scala 3 anyway, despite this proposal to keep it.

but the conversation is interesting.

https://contributors.scala-lang.org/t/proposal-to-retain-private-this-in-scala-3/3829

June 08, 2022
On Wednesday, 8 June 2022 at 11:52:32 UTC, forkit wrote:

> Yes, I agree. Too much typing ;-)
>

To me, it's not as much about typing as about unnecessarily using a concrete name for an abstract concept.

For example, 'this' as the name for constructors/destructors is an improvement over C++. At the same time, 'eponymous' members of templates is a regression.

June 08, 2022

On Wednesday, 8 June 2022 at 12:49:27 UTC, Max Samukha wrote:

>

For example, 'this' as the name for constructors/destructors is an improvement over C++.

I dislike the reuse of terminology for different concepts, so I prefer «constructor» like in TypeScript, although I guess the C++ solution makes sense because you can conceptualize it as a call to function with the same name as the class.

Anyway it is possible to create a parser/grammar without reserving so many keywords (or reusing them). I don't think there is a good reason for having "@safe" and "@pure", the grammar ought to be unambiguous with "safe" and "pure" without making them keywords.

June 08, 2022

On Wednesday, 8 June 2022 at 13:14:43 UTC, Ola Fosheim Grøstad wrote:

>

On Wednesday, 8 June 2022 at 12:49:27 UTC, Max Samukha wrote:

>

For example, 'this' as the name for constructors/destructors is an improvement over C++.

I dislike the reuse of terminology for different concepts, so I prefer «constructor» like in TypeScript,

It is still 'constructor' and not a different name every time.

>

although I guess the C++ solution makes sense because you can conceptualize it as a call to function with the same name as the class.

Yes, but when the name is used in the context of that class, it is redundant.

>

Anyway it is possible to create a parser/grammar without reserving so many keywords (or reusing them). I don't think there is a good reason for having "@safe" and "@pure", the grammar ought to be unambiguous with "safe" and "pure" without making them keywords.