Menu
Search

Forums

Forum Index

June 18, 2022
Gravatar of Max SamukhaPosted by Max Samukha
in reply to Walter Bright		Reply
Max Samukha
Gravatar of Max Samukha
Posted in reply to Walter Bright


Reply
On Saturday, 18 June 2022 at 05:50:56 UTC, Walter Bright wrote:
> On 6/17/2022 10:14 PM, Max Samukha wrote:
>> On Friday, 17 June 2022 at 21:40:58 UTC, Walter Bright wrote:
>>> Not the least of which is there is no such thing as a correct language design. There are only tradeoffs.
>> 
>> There is an inconsistent language design. If the main paradigm the language is built around is class-based OOP, then it is reasonable to expect that 'private' is class-private (or at least there is a way to express class-private).
>
> Consistency is a worthy goal, but as I explained in my recent Code Europe presentation, too much consistency leads to undesirable results, too.
>
> For example:
>
>     for (int i = 0; i; ++i);
>     {
>         ...
>     }
>
> D adds grammatical inconsistency to reject that.

Yes, that's a good one. I still believe it wasn't worth the special case. Such special cases tend to cause other issues, which are often disregarded (like highly annoying hindrances to generic programming).

>
> And then there's that famously inconsistent symbol table lookup that D does that everyone but me insisted is intuitive :-)

You might have based your decisions on the feedback by the vociferous few while there is the silent majority whose opinion is unknown. I've been familiar with D since around 2006 and never voiced my opinion about the module-level private until now.
June 18, 2022
Gravatar of Max SamukhaPosted by Max Samukha
in reply to FeepingCreature		Reply
Max Samukha
Gravatar of Max Samukha
Posted in reply to FeepingCreature


Reply
On Saturday, 18 June 2022 at 07:46:27 UTC, FeepingCreature wrote:

>
> D is not built around a class-based OOP paradigm. D includes class OOP as one paradigm among many.

I think 'main' still applies to D1.
June 18, 2022
Gravatar of Paulo PintoPosted by Paulo Pinto
in reply to Dukc		Reply
Paulo Pinto
Gravatar of Paulo Pinto
Posted in reply to Dukc


Reply

On Friday, 17 June 2022 at 11:10:39 UTC, Dukc wrote:

>

On Friday, 17 June 2022 at 06:18:30 UTC, Paulo Pinto wrote:

>

Where is the DIP for ImportC

According to Walter in last DConf online ImportC is supposed to be compiler-specific thing, not part of the language. Of course this means it's description should not be in the spec. It belongs to the dmd manual.

>

or @live?

here, well not quite but kind of. The attribute itself is not part of that DIP but at least it describes an important part of @live.

But I get your point, that the language maintainers have not always gone through the DIP process when adding new functionality. IMO it should not be a requirement for them to do so when there is no reason to, but it should be the standard procedure when designing something major. I share your viewpoint that Walter has sometimes cowboyed past the process (or tried to) when it'd been better to write a DIP or at least discuss the issue before acting. His track record is not all bad though. The bottom type DIP Walter submitted was rejected, but a revision of that by Dennis was later accepted.

In other language communities, compiler changes are also driven by DIPs like processes.

Anyway, you got my point.

June 18, 2022
Gravatar of DennisPosted by Dennis
in reply to Max Samukha		Reply
Dennis
Gravatar of Dennis
Posted in reply to Max Samukha


Reply

On Saturday, 18 June 2022 at 09:42:40 UTC, Max Samukha wrote:

>

Yes, that's a good one. I still believe it wasn't worth the special case.

What special case? Using ; as an empty statement instead of {} is not allowed anywhere in D as far as I can tell.

June 18, 2022
Gravatar of Salih DincerPosted by Salih Dincer
in reply to Dennis		Reply
Salih Dincer
Gravatar of Salih Dincer
Posted in reply to Dennis


Reply

On Saturday, 18 June 2022 at 15:01:16 UTC, Dennis wrote:

>

On Saturday, 18 June 2022 at 09:42:40 UTC, Max Samukha wrote:

>

Yes, that's a good one. I still believe it wasn't worth the special case.

What special case? Using ; as an empty statement instead of {} is not allowed anywhere in D as far as I can tell.

No conflicts...

Scope Example:

void main()
{
  import std.stdio;
  {
    enum ver = 1;  // (!)
  }

  enum ver = 208;  // (!)
  double d = ver;

  while (d++ <= ver)
  {
    "Hello!".write(" D Compiler v");
  }

  {
    d /= 100;
    double subVer = 0.1; // (?)
    d.writeln(subVer);
  }

  double subVer = 0.9; // what?
  writeln(d + subVer); // next deneration D3
} /* Prints:
Hello! D Compiler v2.10.1
3
*/
June 18, 2022
Gravatar of DennisPosted by Dennis
in reply to Salih Dincer		Reply
Dennis
Gravatar of Dennis
Posted in reply to Salih Dincer


Reply

On Saturday, 18 June 2022 at 15:58:45 UTC, Salih Dincer wrote:

>

No conflicts...

Scope Example:

I don't follow, what is the example demonstrating?

June 18, 2022
Gravatar of deadalnixPosted by deadalnix
in reply to FeepingCreature		Reply
deadalnix
Gravatar of deadalnix
Posted in reply to FeepingCreature


Reply

On Saturday, 18 June 2022 at 08:04:55 UTC, FeepingCreature wrote:

>

I mean, I think it's important in this case because aiui private is ignored in modules because modules are the more central unit of abstraction than classes; a function in a module is "on the same level" as a method in the class. So in that specific sense, it's more correct to call D a module-based language than a class-based one.

More importantly, modules are the unit of abstraction over implementation. When I open a module, I see all the code that implement everything that's in the module. If there is something in there that I shouldn't see, then it shouldn't be in the module.

It's very simple really.

June 18, 2022
Gravatar of Max SamukhaPosted by Max Samukha
in reply to FeepingCreature		Reply
Max Samukha
Gravatar of Max Samukha
Posted in reply to FeepingCreature


Reply

On Saturday, 18 June 2022 at 08:04:55 UTC, FeepingCreature wrote:

>

a function in a module is "on the same level" as a method in the class.

If it is on the same level, then I would expect 'foo' below to lock the mutex and run the invariant check:

synchronized class C
{
    private int x;
    private int y = 1;

    invariant() { assert(y == x + 1); }
}

void foo(C c, int x)
{
    c.x = x;
    c.y = x + 1;
}
June 18, 2022
Gravatar of Max SamukhaPosted by Max Samukha
in reply to Max Samukha		Reply
Max Samukha
Gravatar of Max Samukha
Posted in reply to Max Samukha


Reply

On Saturday, 18 June 2022 at 18:02:08 UTC, Max Samukha wrote:

>

void foo(C c, int x)

should be shared(C)

June 18, 2022
Gravatar of deadalnixPosted by deadalnix
in reply to Max Samukha		Reply
deadalnix
Gravatar of deadalnix
Posted in reply to Max Samukha


Reply

On Saturday, 18 June 2022 at 18:02:08 UTC, Max Samukha wrote:

>

On Saturday, 18 June 2022 at 08:04:55 UTC, FeepingCreature wrote:

>

a function in a module is "on the same level" as a method in the class.

If it is on the same level, then I would expect 'foo' below to lock the mutex and run the invariant check:

synchronized class C
{
    private int x;
    private int y = 1;

    invariant() { assert(y == x + 1); }
}

void foo(C c, int x)
{
    c.x = x;
    c.y = x + 1;
}

If the argument is that synchronized and invariant are messed up, yes.

« First   ‹ Prev
… 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Next ›   Last »