November 22, 2022

On Tuesday, 22 November 2022 at 10:10:48 UTC, Sergey wrote:

>

..
I saw some posts at forum about private-class-scope, but community of core-D is fine with module-unit approach I think.

That's fair enough. I fully support 'majority rules' (if that's what's happening here).

But it could limit the uptake of the langauge, particulary for those software engineers who believe that when you are defining a class, you are defining a type - as Scott Myers has put it.

To such people, other code in the module shouldn't affect my type, in the same way it shouldn't affect a built-in type. At least, not unless I've authorised it, as part of the specification of my type, which presumably I have, by default, just by including any other code in a module, where a class type has been defined.

In such a module, one should annotate the class with @hereBeDragons

November 23, 2022

On Tuesday, 22 November 2022 at 21:45:29 UTC, {}() wrote:

>

On Tuesday, 22 November 2022 at 21:00:58 UTC, {}() wrote:

>

"Being able to declare a “friend” that is somewhere in some other file runs against notions of encapsulation." (This is the motivation for that article it seems).

I completely disagree with the assertion.

C++ Friend notion does not, not by any means, run against the notion of encapsulation.

Sure, it expands the perimeter (i.e. it puts a door in the wall).

But, and this is my point, there is a guard standing at the door. And that guard knows who has been authorised to pass through it. The encapsulation remains. Only its perimeter has been expanded.

One could argue that D's approach is just that. It expands the perimeter to the module level. But there's no guard at the door in D.

Surely, this 'let anyone pass through' design, decreases encapsulation? How could it possibly increase encapsulation, as claimed, by the author of that article?

If there were a means in the language for controlled sharing within a module, that would increase encapsulation.

The module is the capsule. D is simply not interested in building a capsule around a class. D does not let "anyone" pass through, it lets "anyone in the module" pass through, because the module is the wall. I think this is a stronger concept of encapsulation than C++ friends because the encapsulation is lexical rather than just declarative.

November 23, 2022

On Wednesday, 23 November 2022 at 09:51:46 UTC, FeepingCreature wrote:

>

The module is the capsule. D is simply not interested in building a capsule around a class. D does not let "anyone" pass through, it lets "anyone in the module" pass through, because the module is the wall. I think this is a stronger concept of encapsulation than C++ friends because the encapsulation is lexical rather than just declarative.

But if I write a class specification, then that class will be its own capsule.

It will be its own type, just like a built in type.

It will have its own interface by which other code can interact with it, just like a built in type.

Why then should a programming language insist that all other code in the module should be able to bypass my specification, and do as it pleases to my type?

If this applied to built in types, imagine the chaos that could follow from that.

Well, the class is a type as well.

I struggle to see how treating other code in the module as though it is a part of the specification of my type (ie. all that code is essentially inside the perimeter of my class type), benefits me as software engineer.

I am surely missing something here.

In C++, if I want another type to interact with my type, in a tightly coupled manner, then I can explicately authorise that interaction very easily, using friend. Now when I see my code, or others read my code, they know intent.

In a D module, intent cannot be discovered so easily, since it cannot be explicately declared. Not even the compiler knows your intent. It can only assume everything you typed in the module is correct. And now your counter class overflows...and boom!

November 23, 2022

On Wednesday, 23 November 2022 at 11:06:12 UTC, {}() wrote:

>

On Wednesday, 23 November 2022 at 09:51:46 UTC, FeepingCreature wrote:

>
>

Why then should a programming language insist that all other code in the module should be able to bypass my specification, and do as it pleases to my type?

Please let's not repeat previous topics

private will be enforced at module scope, for better or for worse, there has already been a 1000 post thread that resulted in basically nothing except someone creating a private this pull for curiosity that will never be accepted in the language

Look at the very last post where the moderator had to externally kill the thread to prevent it from being revived/argued further

November 23, 2022

On Thursday, 17 November 2022 at 04:39:35 UTC, thebluepandabear wrote:

>

I am creating a TUI library and I have a class with the following constant fields:

class Label : Renderable {
    const string text;
    const TextAlignment textAlignment;
    const Color color;

    this(Dimensions dimensions, string text, TextAlignment textAlignment, Color color) {
        this.dimensions = dimensions;
        this(text, textAlignment, color);
    }

    this(string text, TextAlignment textAlignment, Color color) {
        this.text = text;
        this.textAlignment = textAlignment;
        this.color = color;
    }

    override Cell[] render() const {
        Cell[] cells;

        for (int x = 0; x < 0 + text.length; ++x) {
            cells ~= Cell(Coordinates(x, 0), text[x], color);
        }

        return cells;
    }
}

I am debating whether or not I should add getter methods to these properties. On one hand, it will inflate the codebase by a lot, on the other hand -- in other languages like Java it is a good practice:

class Label : Renderable {
    private const string text;
    private const TextAlignment textAlignment;
    private const Color color;

    this(Dimensions dimensions, string text, TextAlignment textAlignment, Color color) {
        this.dimensions = dimensions;
        this(text, textAlignment, color);
    }

    this(string text, TextAlignment textAlignment, Color color) {
        this.text = text;
        this.textAlignment = textAlignment;
        this.color = color;
    }

    string getText() const {
        return text;
    }

    TextAlignment getTextAlignment() const {
        return textAlignment;
    }

    Color getColor() const {
        return color;
    }

    override Cell[] render() const {
        Cell[] cells;

        for (int x = 0; x < 0 + text.length; ++x) {
            cells ~= Cell(Coordinates(x, 0), text[x], color);
        }

        return cells;
    }
}

It's not a lot of code that has been added but if you have a class with say 10 different fields, adding getter methods would definitely increase the code size by a lot, so what are you guys thoughts on this?

Little optimization, you could prefill your cells instead of creating a new dynamic array every frames not good for the gc

class Label : Renderable {
    private const string text;
    private const TextAlignment textAlignment;
    private const Color color;
    private const Cell[] cells;

    this(Dimensions dimensions, string text, TextAlignment
textAlignment, Color color) {
        this.dimensions = dimensions;
        this(text, textAlignment, color);
    }

    this(string text, TextAlignment textAlignment, Color color)
{
        this.text = text;
        this.cells.length = test.length;
        this.textAlignment = textAlignment;
        this.color = color;

        // fill cells here
        for (int x = 0; x < text.length; x++)
            this.cells[x] = Cell(Coordinates(x, 0), text[x], color);
    }

    string getText() const {
        return text;
    }

    TextAlignment getTextAlignment() const {
        return textAlignment;
    }

    Color getColor() const {
        return color;
    }

    override Cell[] render() const {
        return cells;
    }
}

As for the get/set, i almost never use private, and i never use getter/setter to just access variables, it's pointless imo

Unless you expect your users to extend/override your types, then it make sense, but i personally prefer composition, as i'm not a fan of OOP

November 23, 2022

On Wednesday, 23 November 2022 at 13:24:37 UTC, Tejas wrote:

>

On Wednesday, 23 November 2022 at 11:06:12 UTC, {}() wrote:

>

On Wednesday, 23 November 2022 at 09:51:46 UTC, FeepingCreature wrote:

>
>

Why then should a programming language insist that all other code in the module should be able to bypass my specification, and do as it pleases to my type?

Please let's not repeat previous topics

private will be enforced at module scope, for better or for worse, there has already been a 1000 post thread that resulted in basically nothing except someone creating a private this pull for curiosity that will never be accepted in the language

Look at the very last post where the moderator had to externally kill the thread to prevent it from being revived/argued further

I wasnt discussing private, and it's rather off the point somewhat.

I was responding to the claims that were made in the blog that someone mentioned in this thread:

https://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/

The claim was, that Friends in C++ breaks encapsulation. But that is not correct. It merely expands the perimeter of that encapsulation by putting a door in the wall, along with a guard at the door. The encapsulation remains. The encapsulation itself is not enough however, hence the guard at the door.

And if you program classes 'as types' (whether you additionally do OOP or not - as that too is off the point), then coming to D and finding out that in the context of a module, your class is not even a type (because it simply has no perimeter at all in a module), then I cannot see how that enhances encapsulation, as was claimed in the blog. How can that possibly enhance encapsulation? That makes no sense.

If the blog were published in a journal.. well.. it would never get published in a journal ;-)

Critical analysis remains a great tool, even in relation to 'blogs'.

November 23, 2022

On Wednesday, 23 November 2022 at 13:24:37 UTC, Tejas wrote:

>

In fact that author of that article wrote this in his blog:

"For one, we want to ensure that private members aren’t manipulated outside of class declarations with hundreds or thousands of lines in between. "

Yes. That is where we agree.

Where we disgree, it seems, is that I do not want to have to completely refactor my modules in order to achieve this, as he explains in his blog.

This refactoring is required before you can have a true class type in a D module.

That is, a type with its own perimeter.

No wonder people are 'surprised when they come to D'.

I mean, who wouldn't be?

November 23, 2022

On Wednesday, 23 November 2022 at 22:43:54 UTC, {}() wrote:

>

My last post ;-)

It seems far too many people conflate classes and oop.

You can do oop without classes (whether you would want to is another question all together).

You can also use class-types without doing oop.

A class-type is just a type. If you're against a class-type, you must also be against an int type, a char type, a function type, and enum type.....

Now clearly many D users appear to be in the anti oop camp.

But please don't be in the anti class-type camp.

Class 'types' really are an extremely useful and important tool in software engineering, regardless of whether you use them as a tool to do oop, or not.

That the D module dissolves that perimeters of my types - in relation to other code in the same module, is a really odd design decision that I cannot, as yet, get my head around. That is, I can see no possible way in which this design decision can enhance my coding, even after having given if way more thought than it deserves.

November 23, 2022
On Wednesday, 23 November 2022 at 13:24:37 UTC, Tejas wrote:
> Please let's not repeat previous topics
>
> `private` will be enforced at module scope, for better or for worse, there has already been a [1000 post thread](https://forum.dlang.org/post/lqlllioynzfmpaozwbfj@forum.dlang.org) that resulted in basically nothing except someone creating a `private this` pull for curiosity that will never be accepted in the language
>
> Look at the very last post where the moderator had to externally kill the thread to prevent it from being revived/argued further

It's the same guy. He knows what he's doing and will not let this go, like a vengeful spirit.
November 23, 2022
>

That the D module dissolves that perimeters of my types - in relation to other code in the same module, is a really odd design decision that I cannot, as yet, get my head around. That is, I can see no possible way in which this design decision can enhance my coding, even after having given if way more thought than it deserves.

Please stop, we get it... I'm not a moderator so I cannot enforce rules but there is NO need to continue this debate here. This software 'religiousness' is too much.