On 9/27/21 9:30 AM, kyle wrote:
That'd be great. Long live Beefconf.
I miss it way too often. Gotta have some beet ready for the next
BeetConf. :p
Ali
On Monday, 27 September 2021 at 16:23:49 UTC, Adam D Ruppe wrote:
On Monday, 27 September 2021 at 16:20:59 UTC, Steven
Schveighoffer wrote:
That's a regression. In 2.092.1, it reports:
aye known bug here
https://issues.dlang.org/show_bug.cgi?id=21321
maybe once dmd can compile C code we'll f
On Monday, 27 September 2021 at 16:23:49 UTC, Adam D Ruppe wrote:
On Monday, 27 September 2021 at 16:20:59 UTC, Steven
Schveighoffer wrote:
That's a regression. In 2.092.1, it reports:
aye known bug here
https://issues.dlang.org/show_bug.cgi?id=21321
maybe once dmd can compile C code we'll f
On Monday, 27 September 2021 at 16:20:59 UTC, Steven
Schveighoffer wrote:
That's a regression. In 2.092.1, it reports:
aye known bug here
https://issues.dlang.org/show_bug.cgi?id=21321
maybe once dmd can compile C code we'll fix it so it compiles D
code correctly again.
On Monday, 27 September 2021 at 16:11:31 UTC, kyle wrote:
DMD compiles this providing no notice...
What is the version of your DMD?
On 9/27/21 12:11 PM, kyle wrote:
I'm attempting Markdown for the first time so forgive me if that doesn't
go well. Consider the following:
```d
interface A
{
bool broken();
}
abstract class B : A
{
}
class C : B
{
}
void main()
{
import std.stdio;
C test = new C();
writ
I'm attempting Markdown for the first time so forgive me if that
doesn't go well. Consider the following:
```d
interface A
{
bool broken();
}
abstract class B : A
{
}
class C : B
{
}
void main()
{
import std.stdio;
C test = new C();
writeln(test);
}
```
DMD compiles this p
On Saturday, 10 August 2019 at 08:20:46 UTC, John Colvin wrote:
On Friday, 9 August 2019 at 13:39:53 UTC, Simen Kjærås wrote:
Thanks for the extra detail.
Is there a solid reason to ever use an interface over an
abstract class? (Other than multiple inheritance).
I'm such a noob at anythin
g features with some quite arbitrary feeling
restrictions and differences. E.g. why can I not inherit from
multiple 100% abstract empty classes? Wouldn't that be the same
as inheriting from multiple interfaces?
The overlap is there, but it is not so massive, I would say. If
you inheri
ltiple 100% abstract empty classes? Wouldn't that be the same
> as inheriting from multiple interfaces?
Well, as things stand, _no_ class is 100% abstract, because they all derive
from Object, and Object has virtual functions on it with implementations,
whereas an interface _is_ 100% abstract. M
On Sunday, 11 August 2019 at 20:32:14 UTC, John Colvin wrote:
E.g. why can I not inherit from multiple 100% abstract empty
classes? Wouldn't that be the same as inheriting from multiple
interfaces?
There's kinda no such thing as 100% empty abstract classes, since
they all have th
On Sunday, 11 August 2019 at 20:15:34 UTC, Alex wrote:
On Sunday, 11 August 2019 at 16:05:20 UTC, John Colvin wrote:
I'm trying to narrow down exactly what patterns work with each
and how they overlap.
What I was trying to get at with the abstract method thing is
that
abstract class C
{
On Sunday, 11 August 2019 at 16:05:20 UTC, John Colvin wrote:
I'm trying to narrow down exactly what patterns work with each
and how they overlap.
What I was trying to get at with the abstract method thing is
that
abstract class C
{
void foo();
}
is an abstract class with a non-abstract
on a class is not inherited by its methods.
https://dlang.org/spec/attribute.html#abstract
Now, I'm confused, as you asked about abstract classes. So,
yes, you can define the abstractness of classes differently.
And what is your point?
I'm trying to narrow down exactly what patterns
g.org/spec/attribute.html#abstract
Now, I'm confused, as you asked about abstract classes. So, yes,
you can define the abstractness of classes differently. And what
is your point?
On Saturday, 10 August 2019 at 17:28:32 UTC, Alex wrote:
´´´
void main(){}
interface A { void fun(); }
abstract class B{ void fun(); }
class C : A{ void fun(){} }
class D : B{ /*override*/ void fun(){} }
´´´
case 1:
interface A and class C implementing interface A:
You don't need to "override"
On Saturday, 10 August 2019 at 17:46:37 UTC, Timon Gehr wrote:
On 10.08.19 16:29, John Colvin wrote:
Ok. What would go wrong (in D) if I just replaced every
interface with an abstract class?
interface A{}
interface B{}
class C: A,B{ }
Yes, I know, I guess it wasn't clear unless you read m
On 10.08.19 16:29, John Colvin wrote:
Ok. What would go wrong (in D) if I just replaced every interface with
an abstract class?
interface A{}
interface B{}
class C: A,B{ }
solid reason to ever use an interface over an
abstract class? (Other than multiple inheritance).
I'm such a noob at anything related to OO.
The general question is tricky, as different languages differ
in details what is forced and what is allowed for abstract
classes and interfaces.
? (Other than multiple inheritance).
I'm such a noob at anything related to OO.
The general question is tricky, as different languages differ
in details what is forced and what is allowed for abstract
classes and interfaces.
But roughly speaking, my opinion is: if you can/want to provide
class? (Other than multiple inheritance).
I'm such a noob at anything related to OO.
Hi John.
One reason could be data. Abstract classes can hold data,
interfaces can't.
Antonio
That's a reason to use an abstract class, not a reason to use an
interface.
ob at anything related to OO.
The general question is tricky, as different languages differ in
details what is forced and what is allowed for abstract classes
and interfaces.
But roughly speaking, my opinion is: if you can/want to provide
some default behavior than you are about to write an abs
ob at anything related to OO.
Hi John.
One reason could be data. Abstract classes can hold data,
interfaces can't.
Antonio
On Friday, 9 August 2019 at 13:39:53 UTC, Simen Kjærås wrote:
Thanks for the extra detail.
Is there a solid reason to ever use an interface over an abstract
class? (Other than multiple inheritance).
I'm such a noob at anything related to OO.
On Friday, 9 August 2019 at 13:39:53 UTC, Simen Kjærås wrote:
We're getting into somewhat advanced topics now. This is
described in the Application Binary Interface page of the
documentation[0]. In short: classes and interfaces both use a
vtable[1] that holds pointers to each of their methods.
On Friday, 9 August 2019 at 12:26:59 UTC, John Colvin wrote:
import std.stdio;
interface I
{
void foo();
}
class C : I
{
override void foo() { writeln("hi"); }
}
abstract class AC
{
void foo();
}
class D : AC
{
override void foo() { writeln("hi"); }
}
void main()
{
auto c
On Friday, 9 August 2019 at 13:19:14 UTC, kinke wrote:
On Friday, 9 August 2019 at 12:26:59 UTC, John Colvin wrote:
Why is there no "hi" between 0 and 1?
Because you are treating the unadjusted object pointer as
interface pointer and then call the only virtual function of
that interface, in
On Friday, 9 August 2019 at 12:26:59 UTC, John Colvin wrote:
Why is there no "hi" between 0 and 1?
Because you are treating the unadjusted object pointer as
interface pointer and then call the only virtual function of that
interface, in the 2nd vtbl slot (after the TypeInfo ptr). Casting
a c
import std.stdio;
interface I
{
void foo();
}
class C : I
{
override void foo() { writeln("hi"); }
}
abstract class AC
{
void foo();
}
class D : AC
{
override void foo() { writeln("hi"); }
}
void main()
{
auto c = new C();
writeln(0);
(cast(I)cast(void*)c).foo();
On Wednesday, 6 December 2017 at 23:16:54 UTC, Ali Çehreli wrote:
On 12/06/2017 03:01 PM, IM wrote:
> On Wednesday, 6 December 2017 at 07:54:21 UTC, Ali Çehreli
wrote:
>> On 12/05/2017 11:23 PM, IM wrote:
>>> [...]
>>
>> Just remove the override keywords in this case. No function
is
>> overriding
On 12/06/2017 03:01 PM, IM wrote:
> On Wednesday, 6 December 2017 at 07:54:21 UTC, Ali Çehreli wrote:
>> On 12/05/2017 11:23 PM, IM wrote:
>>> [...]
>>
>> Just remove the override keywords in this case. No function is
>> overriding any implementation here, they both implement an interface
>> funct
On Wednesday, 6 December 2017 at 07:54:21 UTC, Ali Çehreli wrote:
On 12/05/2017 11:23 PM, IM wrote:
[...]
Just remove the override keywords in this case. No function is
overriding any implementation here, they both implement an
interface function. The fact that override can be used for
A.fo
On Wednesday, 6 December 2017 at 07:23:29 UTC, IM wrote:
Assume the following:
interface IFace {
void foo();
void bar();
}
abstract class A : IFace {
override void foo() {}
}
class B : A {
override void bar() {}
}
Now why this fails to compiler with the following message:
--->>>
fun
On 12/05/2017 11:23 PM, IM wrote:
Assume the following:
interface IFace {
void foo();
void bar();
}
abstract class A : IFace {
override void foo() {}
}
class B : A {
override void bar() {}
}
Now why this fails to compiler with the following message:
--->>>
function bar does not
Assume the following:
interface IFace {
void foo();
void bar();
}
abstract class A : IFace {
override void foo() {}
}
class B : A {
override void bar() {}
}
Now why this fails to compiler with the following message:
--->>>
function bar does not override any function, did you mean to
Sorry, the title of the thread might be irrelevant, it's just
that I was playing around with contracts when I noticed the
problem.
I'm on ubuntu x64 using dmd 2.060 and the following gives an
exception:
rdmd --main -unittest -version=useInterface mml/sets.d
while the following runs just fine:
rdmd --main -unittest -version=useAbstractClass mml/sets.d
The exception is:
object.Exception@src/object_.d(108): need opCmp for
why have protection attributes on/in interfaces and abstract
classes/methods no effect outside a module?
module types;
private interface itest
{
private static void blub();
public void blub2();
private void blub3();
}
private class test
{
protected abstract void blub4();
public
38 matches
Mail list logo
