On Tuesday, 24 October 2017 at 20:36:47 UTC, Walter Bright wrote:
> On 10/24/2017 3:36 AM, Satoshi wrote:
>> Can you provide an example?
>
> I'd start with https://dlang.org/spec/interface.html
>
> You'll see the same thing with Windows COM programming, and using interfaces in Java.
>
> ---- view.di ----
> interface View {
>     void render();
> }
> View createView();
>
> ---- button.di ----
> import view;
> interface Button : View {
>     void simulateClick();
> }
> Button createButton();
>
> ---- closed_src_library.d ----
> import view, button;
> private class LibraryView : View {
>    int hidden_data;
>    void render() { do something with hidden_data }
> }
>
> private class LibraryButton : Button {
>     int hidden_data;
>     void simulateClick() { .... }
> }
>
> View createView() {
>     return new LibraryView();
> }
>
> View createButton() {
>     return new LibraryButton();
> }
>
> --- my_extension.d ---
> import view, button;
> class ExtendView : View {
>     View base;
>     this() {
>         base = createView();
>     }
>     void render() {
>         base.render();
>         ... do my rendering ...
>     }
> }

Thanks, but I see there 3 problems:
1. this example enforce users to use composition instead of inheritance when they wants to create custom descendant.
2. multiple dispatch levels. Extending the ExtendView in another lib we get triple dispatch for each method.
3. 1:1 methods mapping is required? or can be there used some sort of aliasing?

interface View {
  void render();
  // another hundred methods
}

class ControlView : View {
  View parent;

  void render() { parent.render(); }
}

class ButtonView : View {
  ControlView parent;

  void render() { parent.render(); } // triple dispatch
}

On 10/25/2017 12:39 AM, Satoshi wrote:
> Thanks, but I see there 3 problems:
> 1. this example enforce users to use composition instead of inheritance when they wants to create custom descendant.

I don't see an issue with that.

> 2. multiple dispatch levels. Extending the ExtendView in another lib we get triple dispatch for each method.

That's only if you want to hide the interface base class implementation, and only if you want to *also* call the base function. There's single dispatch if overriding, or not overriding, the base function. You can also inherit directly from LibraryView, and there'd be only one dispatch.

On Tuesday, 24 October 2017 at 18:55:13 UTC, Martin Nowak wrote:
> On Monday, 23 October 2017 at 11:58:14 UTC, Laeeth Isharc wrote:
>> Bountysource went quiet, though I started contributing to it.
>> I wonder if there is a better way for commercial users to say what they might be willing to pay for and how much.
>
> At best talk to Andrei, maybe you have a good idea to do this over the Foundation.


Makes sense.

A clear, read-only view on what the D Foundation sponsors would be really helpful to incentivize sponsorship.

On Friday, 20 October 2017 at 00:26:19 UTC, bauss wrote:
> On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
>> conditional dereferencing and stuff about that (same as in C#)
>> ...
> ...
>> implement this thing from C# (just because it's cool)
>> new Foo() {
>>   property1 = 42,
>>   property2 = "bar"
>> };
>>
>>
>>
>> Thanks for your time.
>> - Satoshi
>
> I really wish this was implemented for classes too! Currently it exist for structs and it completely baffles me why it has never been implemented for structs.

maybe because of open questions. what is with private variables in a class?

At the current time i can set private variables in a D-struct from a different module:

// in amod.d

struct S
{
	private:
immutable	int a = 33;
}


// in bmod.d

S x = { a:1}; // no error
auto y = S( 1); // no error

the D-documentation doesnt tell, if this is valid behaviour of the compiler, whatever, for now I just assume it is.

maybe it is not a good thing to be able to do that. but at the same time the user should decide at object initialization what value _some_ private variables shall have. so, that's what the constructor usually is good for, too. let the user set only certain private variables one time at initialization. with the amod.d-code above there is no way to disallow resetting all private variables.

And: If i can only set public variables, it is not a perfect solution either

On Tuesday, 24 October 2017 at 08:06:55 UTC, Atila Neves wrote:
> On Tuesday, 24 October 2017 at 07:17:08 UTC, Satoshi wrote:
>> On Monday, 23 October 2017 at 21:42:03 UTC, Atila Neves wrote:
>>> On Monday, 23 October 2017 at 21:14:18 UTC, bauss wrote:
>>>> On Monday, 23 October 2017 at 12:48:33 UTC, Atila Neves wrote:
>>>>> On Monday, 23 October 2017 at 09:13:45 UTC, Satoshi wrote:
>>>>>> On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
>>>>>>> [...]
>>>>>>
>>>>>> Whats about this one?
>>>>>>
>>>>>> auto foo = 42;
>>>>>> auto bar = "bar";
>>>>>> writeln(`Foo is {foo} and bar is {bar}`);
>>>>>
>>>>> writeln("Foo is ", foo, "and bar is ", bar");
>>>>>
>>>>> Two more characters.
>>>>>
>>>>> Atila
>>>>
>>>> Okay, but what about now?
>>>>
>>>> void sendAMessage(string message)
>>>> {
>>>>     ....
>>>> }
>>>
>>> sendAMessage(text(...));
>>>
>>> Atila
>>
>> boilerplate...
>
> True, but in my opinion not enough to justify complicating the language. One could also always do:
>
> import std.conv: t = text;
> sendAMessage(t("Foo is ", foo, " and bar is ", bar"));
>
> If it were me I'd just make `sendAMessage` take a variadic template and call text internally.
>
> Atila

I agree. D MUST remain as simple as possible.

For instance I'm against forcing D programmers to use annotations which won't be implicit anymore.

Keep D's syntax as simple and concise as it is now, don't make it more complicated.

And if you add synctactic sugar constructs to make it even more concise, first make sure that this won't make D more complicated to learn and to use...

On Wednesday, 25 October 2017 at 16:07:21 UTC, ecstatic.coder wrote:
> On Tuesday, 24 October 2017 at 08:06:55 UTC, Atila Neves wrote:
>> [...]
>
> I agree. D MUST remain as simple as possible.
>
> For instance I'm against forcing D programmers to use annotations which won't be implicit anymore.
>
> Keep D's syntax as simple and concise as it is now, don't make it more complicated.
>
> And if you add synctactic sugar constructs to make it even more concise, first make sure that this won't make D more complicated to learn and to use...

Syntactic sugar is what makes a language easy to learn, because you don't have to memorize functions, their modules and whether you imported them or not, which modules imported which modules public, so you don't need to.

Ex. the example above you have to remember which module the function is stored, what the name of the function is and the exact arguments of it.

Now that may sound like "Oh it's not a big deal with such a thing", but it's still extra unnecessary work required to do something as simple as constructing a string.

You must remember to import the module too and you must also know which modules have the module imported as public import, because in those cases you don't need to import it. That's another extra thought you need to have, that must be repeated for every module.

I often tend to forget to important for format() and it's kinda tedious when you write multiple big modules and then forgot to do the correct imports and you have to go into all of them and fix it.

Of course you could just assume no modules have public imports and you won't need to worry about which modules import what, but that defeats the whole purpose of public imports in the specific modules too, which makes the module system seem complicate and kinda useless, compared to how "complicated" a simple syntactic sugar addition like string interpolation, which btw. pretty much is a feature in most modern languages these days.

String interpolation is a very handy feature to write bugless code, because it's much harder to end up writing errors in your code like Atila already showed in his example that was supposed to show why you shouldn't have the feature.

On Wednesday, 25 October 2017 at 18:54:16 UTC, bauss wrote:
> On Wednesday, 25 October 2017 at 16:07:21 UTC, ecstatic.coder wrote:
>> [...]
>
> Syntactic sugar is what makes a language easy to learn, because you don't have to memorize functions, their modules and whether you imported them or not, which modules imported which modules public, so you don't need to.
>
> [...]

Also to add on to this with having to modify the "sendAMessage()" function. What if the function is located in a 3rd party library? Then you can't do such things, where string interpolation would be the better upper-hand.