On Wednesday, 10 March 2021 at 18:08:24 UTC, H. S. Teoh wrote:
> (Although its value is debatable.)

You use my jni.d... it uses this to store the java methodIds it looks up in the generated binding class. This feature makes that very, very easy to implement and use. I'm not sure how I'd do it without that... maybe a string mixin or something, like I'm sure I'd figure it out, but it is really nice when these things actually just work.

On Wednesday, 10 March 2021 at 17:59:56 UTC, VF wrote:
> [snip]
>
> I think the biggest reasons are bugginess and instability. Those are my reasons for wanting to get out of D, and also feature bloat. I want a simpler language, but am not seeing good options...
>
> Speaking of bugginess, here's the latest bug that I noticed (dmd 2.094):
>
> mixin template X() { int x; }
>
> struct A { mixin X; int x; } // <- that compiles!
>
> int main() {
>     import std.stdio;
>     writeln(A.sizeof);       // => 8
>     writeln(A.id.offsetof);  // => 4
> }

I couldn't get this exact thing to run (the A.id.offsetof part and using int main instead of void main), but in general if you come across a bug you should file it in bugzilla.

You need to be specific about what you think the bug actually is. According to the spec
https://dlang.org/spec/template-mixin.html#mixin_scope
there is no reason why this shouldn't compile as int x overrides the mixin.

A reasonable question might be "if int x overrides what is in X, then why is it still a part of A"? There might be good reasons for why A.sizeof is 8 instead of 4.

On Wednesday, 10 March 2021 at 18:08:24 UTC, H. S. Teoh wrote:
> On Wed, Mar 10, 2021 at 05:59:56PM +0000, VF via Digitalmars-d wrote: [...]
>> Speaking of bugginess, here's the latest bug that I noticed (dmd 2.094):
>> 
>> mixin template X() { int x; }
>> 
>> struct A { mixin X; int x; } // <- that compiles!
>
> This is not a bug. It's a feature. (Although its value is debatable.) Mixins exist in separate namespaces, which can be useful if you have multiple mixins that declare the same identifier. Note that there's an optional identifier after `mixin X` that can be used to disambiguate between the two instances of `x`, e.g.:
>
> 	struct A {
> 		mixin X x2;
> 		int x;
> 	}
>
> 	A.x2.x = 1;
> 	a.x = 2;
>

If there is no optional identifier x2,

a.x = 2;

will change which x? and how to disambiguate the two x in such case?

On Wednesday, 10 March 2021 at 18:13:09 UTC, Adam D. Ruppe wrote:
> On Wednesday, 10 March 2021 at 18:08:24 UTC, H. S. Teoh wrote:
>> (Although its value is debatable.)
>
> You use my jni.d... it uses this to store the java methodIds it looks up in the generated binding class. This feature makes that very, very easy to implement and use. I'm not sure how I'd do it without that... maybe a string mixin or something, like I'm sure I'd figure it out, but it is really nice when these things actually just work.

What is the exact usage of this feature?

Can you give an example of your usage?

On Wednesday, 10 March 2021 at 18:17:19 UTC, jmh530 wrote:
> On Wednesday, 10 March 2021 at 17:59:56 UTC, VF wrote:
>> [snip]
>>
>> I think the biggest reasons are bugginess and instability. Those are my reasons for wanting to get out of D, and also feature bloat. I want a simpler language, but am not seeing good options...
>>
>> Speaking of bugginess, here's the latest bug that I noticed (dmd 2.094):
>>
>> mixin template X() { int x; }
>>
>> struct A { mixin X; int x; } // <- that compiles!
>>
>> int main() {
>>     import std.stdio;
>>     writeln(A.sizeof);       // => 8
>>     writeln(A.id.offsetof);  // => 4
>> }
>
> I couldn't get this exact thing to run (the A.id.offsetof part

I think he mean: A.x.offsetof

On Wed, Mar 10, 2021 at 09:49:12PM +0000, mw via Digitalmars-d wrote:
> On Wednesday, 10 March 2021 at 18:08:24 UTC, H. S. Teoh wrote:
[...]
> > 	struct A {
> > 		mixin X x2;
> > 		int x;
> > 	}
> > 
> > 	A.x2.x = 1;
> > 	a.x = 2;
> > 
> 
> If there is no optional identifier x2,
> 
> a.x = 2;
> 
> will change which x? and how to disambiguate the two x in such case?
[...]

IMO this should generate an ambiguity error.  But I don't know the current behaviour.


T

-- 
Perhaps the most widespread illusion is that if we were in power we would behave very differently from those who now hold it---when, in truth, in order to get power we would have to become very much like them. -- Unknown

On Wednesday, 10 March 2021 at 21:51:43 UTC, mw wrote:
> What is the exact usage of this feature?

http://dpldocs.info/experimental-docs/source/arsd.jni.d.html#L1358

That _jmethodID is unique for each method added. So when you follow the example code:

http://dpldocs.info/experimental-docs/arsd.jni.html

and have like

	@Export void hi(string name) {
		import std.stdio;
		writefln("hello from D, %s", name);
        }

	// D can also access Java methods
	@Import void printMember();


Then hi and printMember both get their own private copy of the id. No conflict regardless of how many methods you mixin.

Notice too how these mixin static constructors too, which are all combined per language rules, allowing me to actually concatenate the lists at startup for a one-go load of metadata at runtime.

http://dpldocs.info/experimental-docs/source/arsd.jni.d.html#L1790


For the other side, adrdox uses that:

https://github.com/adamdruppe/adrdox/blob/master/doc2.d#L3169

That's a mixin template with semi-specialized implementations of the abstract interface.

But there's also cases like here:

https://github.com/adamdruppe/adrdox/blob/master/doc2.d#L3028

That override the mixed in override, letting you accept the default implementations in some places, and selectively override them for other methods, without having to create another child class to do it.


Now take a look at this line:
https://github.com/adamdruppe/adrdox/blob/master/doc2.d#L3158

Notice the explicit usage of `this` there. Without it, it would use the local name inside the mixin template and NOT respect the override; this is good when you want to use a private member like in the jni example. But with it, it looks up one level above which means the user can easily override it and then it respects this, similar to a virtual vs static lookup in oop (which itself can get a bit nuts if you use the curiously-recurring template pattern, which I do here for reflection of a child class inside the base class http://dpldocs.info/experimental-docs/source/arsd.cgi.d.html#L8288 - the mixin template version is kinda the same idea.)

On Wednesday, 10 March 2021 at 22:08:43 UTC, H. S. Teoh wrote:
> IMO this should generate an ambiguity error.  But I don't know the current behaviour.

At the top level, it will always use the top-level name. This allows for easy overriding, like with the adrdox `declarationType` method in my previous message.

mixin templates seem to be fairly poorly understood in the community. I wrote a little about them here:

http://dpldocs.info/this-week-in-d/Blog.Posted_2020_01_20.html#understanding-mixin-templates

about a year ago, but perhaps more needs to be written.

They are NOT copy/pasted code, that's closer to what string mixin is (and it isn't copy/pasted code either, but rather copy/pasted AST nodes but I digress). The common name "mixin" makes you think they're the same, but they are very different beasts.

Template mixins are more like a separate struct that allows name as well as virtual slot forwarding to the surrounding context (but notably operator overloading is NOT considered, and function overloading is not automatic, requiring an `alias` bridge since the mixin template and the parent are two separate contexts with name-based overriding, not signature-based). It is a fairly unique concept but the behaviors are all there for a reason and once you know those reasons, you can do a lot of cool things with them.

The biggest worry is overloading constructors, there I'd argue it is a bug / oversight. You can alias in __ctor... sometimes. Otherwise the `this` keyword isn't allowed by the syntax meaning the proper procedure doesn't work.

But most everything else works well once you get to know it.

On 3/10/2021 10:08 AM, H. S. Teoh wrote:
> On Wed, Mar 10, 2021 at 05:59:56PM +0000, VF via Digitalmars-d wrote:
> [...]
>> Speaking of bugginess, here's the latest bug that I noticed (dmd 2.094):
>>
>> mixin template X() { int x; }
>>
>> struct A { mixin X; int x; } // <- that compiles!
> 
> This is not a bug. It's a feature. (Although its value is debatable.)
> Mixins exist in separate namespaces, which can be useful if you have
> multiple mixins that declare the same identifier. Note that there's an
> optional identifier after `mixin X` that can be used to disambiguate
> between the two instances of `x`, e.g.:
> 
> 	struct A {
> 		mixin X x2;
> 		int x;
> 	}
> 
> 	A.x2.x = 1;
> 	a.x = 2;

You're right, it's quite deliberate. Template mixins would be fairly crippled if it didn't.

On Tuesday, 9 March 2021 at 21:06:46 UTC, Imperatorn wrote:
> On Tuesday, 9 March 2021 at 20:56:12 UTC, H. S. Teoh wrote:
>> On Tue, Mar 09, 2021 at 04:48:28PM
>
> 💡
>
> Great summary! I don't understand why D isn't used more. Maybe it's *too* flexible for some people? 🤔

There is PL adoption research:
https://lmeyerov.github.io/projects/socioplt/papers/oopsla2013.pdf

In this study they found the following drivers:
1. Open source libs
2. Extending existing code
3. Already used in group

See that "Particular language feature" and "Simplicity" are not really ranked high.

It seems over and over the one driver of PL adoption is always availability of "open-source libraries".

In pure cynical terms it can be seen is a capital transfert between those maintaining the open source corpus vs those reaping added value with the open-source code ; in that it's code you can rely on, but don't pay for maintenance (or barely).

But it can also signal a thriving/collaborating community (like with CPAN Perl).

In many of the new "weaponized" languages created by Big Corp, a large corpus of the open-source ecosystem is created/maintained by the Corp ; value is instead seeked in the lockin that language provides.