• sighoya (62/62) Dec 15 2019 I know there is already a package available from atila neves
• sighoya (10/10) Dec 15 2019 and collision by multiple inheritance wasn't ever an issue which
• sighoya (4/68) Dec 15 2019 Dup of

sighoya <sighoya gmail.com> writes:

I know there is already a package available from atila neves 
about concepts, but despite being a neat workaround, it delivers 
not the full opportunities we know from type classes.

Why?
TypeClasses aren't a static solution only, they can also be used 
as existentials allowing dynamic dispatch implying that you can 
change the underlying implementation at runtime:
function(Concept c):Concept{...}

Further, implementing concepts over inner fields is limited, 
usually assoc functions are used (UFCS in case of D) which may 
can be covered with the concepts package of atila over dlang's 
compiletime reflection library "traits".
However, how instance resolution works then? Functions associated 
to types are local only, so if we import the concept from another 
module how can we check satisfyability if the needed 
ufcs/associated functions aren't imported likewise to the concept?

I know, introducing a new entity to existing entities like 
interfaces unnecessarily increases the complexity but how about 
reusing existing interfaces for that purpose?

For instance:

interface A
{
void method1();
}

interface B
{
void method2();
}

class C implements A //structural implements (valid D)
{
void method1() {...}
}

implement B for C //implement is a block keyword like class for 
posthoc implementation
{
method2(){...}
}

Another solution would be a pseudoclass:

class D implements B for C
{
method2(){...}
}

Now passing a C to B requires not only too look for C's 
definition but also for instances either globally in the project 
(preferred) or with special import for instances.

Another point to consider struct implementations via autoboxing, 
is it that hard to implement?
Also allowing fields in interfaces would complete the usefulness 
of concepts.

A possible look how flexible it can be taken from the nim language
Link:
https://nim-lang.org/docs/manual_experimental.html#concepts

I donna want to rant about D, I love it, really. But introducing 
classes separate to interfaces irks me and was in my eyes a 
failure from Java and all languages which follow them.

Why?
Because it introduces a biworld, both concepts overlap and you 
have to decide which to choose which is further complicated by 
availability of abstract classes, so why not unify all of them 
into a single concept?
Class methods were always default methods akin to default methods 
in interfaces and

sighoya <sighoya gmail.com> writes:

and collision by multiple inheritance wasn't ever an issue which 
can be easily solved by scoping the super interfaces.
Another biworld are final classes and structs which seemingly 
equal in ther purpose, from a type theoretic viewpoint they 
represent the same type, so why have to version of the 
abstraction, choosing only structs as value or reference type 
would excitingly solve the issue.

Nevertheless, w can't changed everything in a backward-compatible 
way. I hope some of you are happy to discuss ideas about concepts 
in this thread.

sighoya <sighoya gmail.com> writes:

On Sunday, 15 December 2019 at 13:06:52 UTC, sighoya wrote:
 I know there is already a package available from atila neves 
 about concepts, but despite being a neat workaround, it 
 delivers not the full opportunities we know from type classes.

 Why?
 TypeClasses aren't a static solution only, they can also be 
 used as existentials allowing dynamic dispatch implying that 
 you can change the underlying implementation at runtime:
 function(Concept c):Concept{...}

 Further, implementing concepts over inner fields is limited, 
 usually assoc functions are used (UFCS in case of D) which may 
 can be covered with the concepts package of atila over dlang's 
 compiletime reflection library "traits".
 However, how instance resolution works then? Functions 
 associated to types are local only, so if we import the concept 
 from another module how can we check satisfyability if the 
 needed ufcs/associated functions aren't imported likewise to 
 the concept?

 I know, introducing a new entity to existing entities like 
 interfaces unnecessarily increases the complexity but how about 
 reusing existing interfaces for that purpose?

 For instance:

 interface A
 {
 void method1();
 }

 interface B
 {
 void method2();
 }

 class C implements A //structural implements (valid D)
 {
 void method1() {...}
 }

 implement B for C //implement is a block keyword like class for 
 posthoc implementation
 {
 method2(){...}
 }

 Another solution would be a pseudoclass:

 class D implements B for C
 {
 method2(){...}
 }

 Now passing a C to B requires not only too look for C's 
 definition but also for instances either globally in the 
 project (preferred) or with special import for instances.

 Another point to consider struct implementations via 
 autoboxing, is it that hard to implement?
 Also allowing fields in interfaces would complete the 
 usefulness of concepts.

 A possible look how flexible it can be taken from the nim 
 language
 Link:
 https://nim-lang.org/docs/manual_experimental.html#concepts

 I donna want to rant about D, I love it, really. But 
 introducing classes separate to interfaces irks me and was in 
 my eyes a failure from Java and all languages which follow them.

 Why?
 Because it introduces a biworld, both concepts overlap and you 
 have to decide which to choose which is further complicated by 
 availability of abstract classes, so why not unify all of them 
 into a single concept?
 Class methods were always default methods akin to default 
 methods in interfaces and

Dup of 
https://forum.dlang.org/post/tnzjbkdysfopowwmfzns forum.dlang.org

Please delete this thread, it was misplaced.