Re: Class and Interface Fun
On Sun, 25 Jan 2009 08:38:18 +0300, Tim M a...@b.com wrote:
On Sun, 25 Jan 2009 17:56:03 +1300, John Reimer
terminal.n...@gmail.com wrote:
Hello tim,
On Sun, 25 Jan 2009 16:43:55 +1300, John Reimer
terminal.n...@gmail.com wrote:
With this code:
module test5;
interface I
{
void foo();
}
class A : I {
void foo() { }
}
class B : A, I
{
alias A.foo foo;
}
void main()
{
}
I get this error:
class test5.B interface function I.foo is not implemented
Does this make sense? I mean, shouldn't the explicit reuse of A.foo
in B be sufficient indication to the compiler that B is satisfying
the contract I? I'm hoping to make use of such subtleties in some
code, but first I have to understand the reasoning behind this. :)
Note that this works if I remove the interface I from B's declaration
-- ie class B: A -- since, in the D language, B is not required to
fulfull A's interface contract even though it inherits from it. -JJR
It look like the real bug is re-allowing B to implement interface I
but
sometimes bug do get reported differently. Why don't you remove I from
B's
declaration like you said that works. It actually says here
http://www.digitalmars.com/d/1.0/interface.html Classes cannot derive
from an interface multiple times.
Yes, please check the link again (further down the page).D allows
you to reimplement the interface as long as class B provides a new
implementation:
A reimplemented interface must implement all the interface functions,
it does not inherit from a super class...
That probably could be stated a little more clearly, but that's what it
says. As for why I'm doing it, I assure you that there's a very
specific reason why I'm trying this: it is a possible interfacing
mechansim for ported software of a much more complicated nature than
this simple reduction; I reduced it to this in order to try to
understand potential iteractions between class and interface layers.
The question here was to figure out the reasoning behind the language
design, not necessarily whether I should be doing it or not. ;-)
-JJR
This works btw:
module test;
interface I
{
void foo();
}
class A : I {
void foo() { }
}
class B : A,I
{
void foo() { A.foo(); }
}
void main()
{
}
It is too verbose and makes twice an overhead. I'd like to avoid this solution.
In fact, I believe that class B : A, I {} should just work.
Re: Class and Interface Fun
On Mon, 26 Jan 2009 00:18:28 +1300, Denis Koroskin 2kor...@gmail.com
wrote:
On Sun, 25 Jan 2009 08:38:18 +0300, Tim M a...@b.com wrote:
On Sun, 25 Jan 2009 17:56:03 +1300, John Reimer
terminal.n...@gmail.com wrote:
Hello tim,
On Sun, 25 Jan 2009 16:43:55 +1300, John Reimer
terminal.n...@gmail.com wrote:
With this code:
module test5;
interface I
{
void foo();
}
class A : I {
void foo() { }
}
class B : A, I
{
alias A.foo foo;
}
void main()
{
}
I get this error:
class test5.B interface function I.foo is not implemented
Does this make sense? I mean, shouldn't the explicit reuse of A.foo
in B be sufficient indication to the compiler that B is satisfying
the contract I? I'm hoping to make use of such subtleties in some
code, but first I have to understand the reasoning behind this. :)
Note that this works if I remove the interface I from B's
declaration
-- ie class B: A -- since, in the D language, B is not required to
fulfull A's interface contract even though it inherits from it. -JJR
It look like the real bug is re-allowing B to implement interface I
but
sometimes bug do get reported differently. Why don't you remove I from
B's
declaration like you said that works. It actually says here
http://www.digitalmars.com/d/1.0/interface.html Classes cannot derive
from an interface multiple times.
Yes, please check the link again (further down the page).D allows
you to reimplement the interface as long as class B provides a new
implementation:
A reimplemented interface must implement all the interface functions,
it does not inherit from a super class...
That probably could be stated a little more clearly, but that's what
it says. As for why I'm doing it, I assure you that there's a very
specific reason why I'm trying this: it is a possible interfacing
mechansim for ported software of a much more complicated nature than
this simple reduction; I reduced it to this in order to try to
understand potential iteractions between class and interface layers.
The question here was to figure out the reasoning behind the language
design, not necessarily whether I should be doing it or not. ;-)
-JJR
This works btw:
module test;
interface I
{
void foo();
}
class A : I {
void foo() { }
}
class B : A,I
{
void foo() { A.foo(); }
}
void main()
{
}
It is too verbose and makes twice an overhead. I'd like to avoid this
solution.
In fact, I believe that class B : A, I {} should just work.
why? I think it is perfect how it is. You can either leave A as the class
that implements I and B would implement it through inheritance or you can
to re implement I define all new implementations and put in return
super.foo(); where needed. It is also possible to reimplement one
interface function without re implementing the whole interface.
Re: Class and Interface Fun
On Mon, 26 Jan 2009 00:48:21 +1300, Tim M a...@b.com wrote:
On Mon, 26 Jan 2009 00:18:28 +1300, Denis Koroskin 2kor...@gmail.com
wrote:
On Sun, 25 Jan 2009 08:38:18 +0300, Tim M a...@b.com wrote:
On Sun, 25 Jan 2009 17:56:03 +1300, John Reimer
terminal.n...@gmail.com wrote:
Hello tim,
On Sun, 25 Jan 2009 16:43:55 +1300, John Reimer
terminal.n...@gmail.com wrote:
With this code:
module test5;
interface I
{
void foo();
}
class A : I {
void foo() { }
}
class B : A, I
{
alias A.foo foo;
}
void main()
{
}
I get this error:
class test5.B interface function I.foo is not implemented
Does this make sense? I mean, shouldn't the explicit reuse of
A.foo
in B be sufficient indication to the compiler that B is satisfying
the contract I? I'm hoping to make use of such subtleties in some
code, but first I have to understand the reasoning behind this. :)
Note that this works if I remove the interface I from B's
declaration
-- ie class B: A -- since, in the D language, B is not required
to
fulfull A's interface contract even though it inherits from it. -JJR
It look like the real bug is re-allowing B to implement interface I
but
sometimes bug do get reported differently. Why don't you remove I
from
B's
declaration like you said that works. It actually says here
http://www.digitalmars.com/d/1.0/interface.html Classes cannot
derive
from an interface multiple times.
Yes, please check the link again (further down the page).D allows
you to reimplement the interface as long as class B provides a new
implementation:
A reimplemented interface must implement all the interface
functions, it does not inherit from a super class...
That probably could be stated a little more clearly, but that's what
it says. As for why I'm doing it, I assure you that there's a very
specific reason why I'm trying this: it is a possible interfacing
mechansim for ported software of a much more complicated nature than
this simple reduction; I reduced it to this in order to try to
understand potential iteractions between class and interface layers.
The question here was to figure out the reasoning behind the language
design, not necessarily whether I should be doing it or not. ;-)
-JJR
This works btw:
module test;
interface I
{
void foo();
}
class A : I {
void foo() { }
}
class B : A,I
{
void foo() { A.foo(); }
}
void main()
{
}
It is too verbose and makes twice an overhead. I'd like to avoid this
solution.
In fact, I believe that class B : A, I {} should just work.
why? I think it is perfect how it is. You can either leave A as the
class that implements I and B would implement it through inheritance or
you can to re implement I define all new implementations and put in
return super.foo(); where needed. It is also possible to reimplement one
interface function without re implementing the whole interface.
If you are really needing to write least code you could also do something
like this but not very nice to read:
module test;
template II(char[] func)
{
const char[] II = typeof(super. ~ func ~ ()) ~ ~ func ~ ()
{ return super. ~ func ~ (); } ;
}
interface I
{
void foo();
int bar();
}
class A : I
{
void foo() { }
int bar() { return 1; }
}
class B : A,I
{
//void foo() { return super.foo(); }
mixin(II!(foo));
mixin(II!(bar));
}
void main()
{
}
Re: Class and Interface Fun
On Sun, 25 Jan 2009 15:06:23 +0300, Tim M a...@b.com wrote:
On Mon, 26 Jan 2009 00:48:21 +1300, Tim M a...@b.com wrote:
On Mon, 26 Jan 2009 00:18:28 +1300, Denis Koroskin 2kor...@gmail.com
wrote:
On Sun, 25 Jan 2009 08:38:18 +0300, Tim M a...@b.com wrote:
On Sun, 25 Jan 2009 17:56:03 +1300, John Reimer
terminal.n...@gmail.com wrote:
Hello tim,
On Sun, 25 Jan 2009 16:43:55 +1300, John Reimer
terminal.n...@gmail.com wrote:
With this code:
module test5;
interface I
{
void foo();
}
class A : I {
void foo() { }
}
class B : A, I
{
alias A.foo foo;
}
void main()
{
}
I get this error:
class test5.B interface function I.foo is not implemented
Does this make sense? I mean, shouldn't the explicit reuse of
A.foo
in B be sufficient indication to the compiler that B is satisfying
the contract I? I'm hoping to make use of such subtleties in
some
code, but first I have to understand the reasoning behind this. :)
Note that this works if I remove the interface I from B's
declaration
-- ie class B: A -- since, in the D language, B is not required
to
fulfull A's interface contract even though it inherits from it.
-JJR
It look like the real bug is re-allowing B to implement interface I
but
sometimes bug do get reported differently. Why don't you remove I
from
B's
declaration like you said that works. It actually says here
http://www.digitalmars.com/d/1.0/interface.html Classes cannot
derive
from an interface multiple times.
Yes, please check the link again (further down the page).D
allows you to reimplement the interface as long as class B provides
a new implementation:
A reimplemented interface must implement all the interface
functions, it does not inherit from a super class...
That probably could be stated a little more clearly, but that's what
it says. As for why I'm doing it, I assure you that there's a very
specific reason why I'm trying this: it is a possible interfacing
mechansim for ported software of a much more complicated nature than
this simple reduction; I reduced it to this in order to try to
understand potential iteractions between class and interface
layers. The question here was to figure out the reasoning behind
the language design, not necessarily whether I should be doing it
or not. ;-)
-JJR
This works btw:
module test;
interface I
{
void foo();
}
class A : I {
void foo() { }
}
class B : A,I
{
void foo() { A.foo(); }
}
void main()
{
}
It is too verbose and makes twice an overhead. I'd like to avoid this
solution.
In fact, I believe that class B : A, I {} should just work.
why? I think it is perfect how it is. You can either leave A as the
class that implements I and B would implement it through inheritance or
you can to re implement I define all new implementations and put in
return super.foo(); where needed. It is also possible to reimplement
one interface function without re implementing the whole interface.
If you are really needing to write least code you could also do
something like this but not very nice to read:
module test;
template II(char[] func)
{
const char[] II = typeof(super. ~ func ~ ()) ~ ~ func ~
() { return super. ~ func ~ (); } ;
}
interface I
{
void foo();
int bar();
}
class A : I
{
void foo() { }
int bar() { return 1; }
}
class B : A,I
{
//void foo() { return super.foo(); }
mixin(II!(foo));
mixin(II!(bar));
}
void main()
{
}
Not only I want to write less, I want my code be cleaner and run faster.
why? I think it is perfect how it is. You can either leave A as the
class that implements I and B would implement it through inheritance or
you can to re implement I define all new implementations and put in
return super.foo(); where needed. It is also possible to reimplement one
interface function without re implementing the whole interface.
That what /my/ solution do.
class B : A, I {}
is *absolutely* same as
class B : A, I
{
override void foo() { super.foo(); }
override int bar() { return super.bar(); }
}
Except that when you call B.foo, there is no damn double virtual function call.
B inherits all the functions from A implicitly. You stil may override any of
the I interface functions if need be:
class B : A, I
{
override void foo() { ... }
// int bar() is inherited from A
}
Having B explicitly override all the base class virtual functions and forward
them to A implementation just to make compiler happy is unintuitive and plain
dumb to me.
C# allows that and I see absolutely no reason why D doesn't.
Re: Class and Interface Fun
On Mon, 26 Jan 2009 01:14:10 +1300, Denis Koroskin 2kor...@gmail.com
wrote:
On Sun, 25 Jan 2009 15:06:23 +0300, Tim M a...@b.com wrote:
On Mon, 26 Jan 2009 00:48:21 +1300, Tim M a...@b.com wrote:
On Mon, 26 Jan 2009 00:18:28 +1300, Denis Koroskin 2kor...@gmail.com
wrote:
On Sun, 25 Jan 2009 08:38:18 +0300, Tim M a...@b.com wrote:
On Sun, 25 Jan 2009 17:56:03 +1300, John Reimer
terminal.n...@gmail.com wrote:
Hello tim,
On Sun, 25 Jan 2009 16:43:55 +1300, John Reimer
terminal.n...@gmail.com wrote:
With this code:
module test5;
interface I
{
void foo();
}
class A : I {
void foo() { }
}
class B : A, I
{
alias A.foo foo;
}
void main()
{
}
I get this error:
class test5.B interface function I.foo is not implemented
Does this make sense? I mean, shouldn't the explicit reuse of
A.foo
in B be sufficient indication to the compiler that B is
satisfying
the contract I? I'm hoping to make use of such subtleties in
some
code, but first I have to understand the reasoning behind this.
:)
Note that this works if I remove the interface I from B's
declaration
-- ie class B: A -- since, in the D language, B is not
required to
fulfull A's interface contract even though it inherits from it.
-JJR
It look like the real bug is re-allowing B to implement interface I
but
sometimes bug do get reported differently. Why don't you remove I
from
B's
declaration like you said that works. It actually says here
http://www.digitalmars.com/d/1.0/interface.html Classes cannot
derive
from an interface multiple times.
Yes, please check the link again (further down the page).D
allows you to reimplement the interface as long as class B provides
a new implementation:
A reimplemented interface must implement all the interface
functions, it does not inherit from a super class...
That probably could be stated a little more clearly, but that's
what it says. As for why I'm doing it, I assure you that there's a
very specific reason why I'm trying this: it is a possible
interfacing mechansim for ported software of a much more
complicated nature than this simple reduction; I reduced it to this
in order to try to understand potential iteractions between class
and interface layers. The question here was to figure out the
reasoning behind the language design, not necessarily whether I
should be doing it or not. ;-)
-JJR
This works btw:
module test;
interface I
{
void foo();
}
class A : I {
void foo() { }
}
class B : A,I
{
void foo() { A.foo(); }
}
void main()
{
}
It is too verbose and makes twice an overhead. I'd like to avoid this
solution.
In fact, I believe that class B : A, I {} should just work.
why? I think it is perfect how it is. You can either leave A as the
class that implements I and B would implement it through inheritance
or you can to re implement I define all new implementations and put in
return super.foo(); where needed. It is also possible to reimplement
one interface function without re implementing the whole interface.
If you are really needing to write least code you could also do
something like this but not very nice to read:
module test;
template II(char[] func)
{
const char[] II = typeof(super. ~ func ~ ()) ~ ~ func ~
() { return super. ~ func ~ (); } ;
}
interface I
{
void foo();
int bar();
}
class A : I
{
void foo() { }
int bar() { return 1; }
}
class B : A,I
{
//void foo() { return super.foo(); }
mixin(II!(foo));
mixin(II!(bar));
}
void main()
{
}
Not only I want to write less, I want my code be cleaner and run faster.
why? I think it is perfect how it is. You can either leave A as the
class that implements I and B would implement it through inheritance or
you can to re implement I define all new implementations and put in
return super.foo(); where needed. It is also possible to reimplement
one interface function without re implementing the whole interface.
That what /my/ solution do.
class B : A, I {}
is *absolutely* same as
class B : A, I
{
override void foo() { super.foo(); }
override int bar() { return super.bar(); }
}
Except that when you call B.foo, there is no damn double virtual
function call.
B inherits all the functions from A implicitly. You stil may override
any of the I interface functions if need be:
class B : A, I
{
override void foo() { ... }
// int bar() is inherited from A
}
Having B explicitly override all the base class virtual functions and
forward them to A implementation just to make compiler happy is
unintuitive and plain dumb to me.
C# allows that and I see absolutely no reason why D doesn't.
I think you are missing somethinghere. Change the B definition from:
class B : A, I
to just:
class B : A
then
C++ operator new
Hi,
I wonder if this is doable in D ?
class Cpp
{
public:
void* operator new(size_t n);
void* operator new(size_t n, void* p)
{ return p; }
}
Just guessing that operator new means this in D
class D
{
new(uint n);
new(uint n,void* p)
{ return p; }
}
Am I wrong ?
TIA, Bjoern
Re: Class and Interface Fun
On Sun, 25 Jan 2009 15:20:19 +0300, Tim M a...@b.com wrote:
On Mon, 26 Jan 2009 01:14:10 +1300, Denis Koroskin 2kor...@gmail.com
wrote:
On Sun, 25 Jan 2009 15:06:23 +0300, Tim M a...@b.com wrote:
On Mon, 26 Jan 2009 00:48:21 +1300, Tim M a...@b.com wrote:
On Mon, 26 Jan 2009 00:18:28 +1300, Denis Koroskin
2kor...@gmail.com wrote:
On Sun, 25 Jan 2009 08:38:18 +0300, Tim M a...@b.com wrote:
On Sun, 25 Jan 2009 17:56:03 +1300, John Reimer
terminal.n...@gmail.com wrote:
Hello tim,
On Sun, 25 Jan 2009 16:43:55 +1300, John Reimer
terminal.n...@gmail.com wrote:
With this code:
module test5;
interface I
{
void foo();
}
class A : I {
void foo() { }
}
class B : A, I
{
alias A.foo foo;
}
void main()
{
}
I get this error:
class test5.B interface function I.foo is not implemented
Does this make sense? I mean, shouldn't the explicit reuse of
A.foo
in B be sufficient indication to the compiler that B is
satisfying
the contract I? I'm hoping to make use of such subtleties in
some
code, but first I have to understand the reasoning behind this.
:)
Note that this works if I remove the interface I from B's
declaration
-- ie class B: A -- since, in the D language, B is not
required to
fulfull A's interface contract even though it inherits from it.
-JJR
It look like the real bug is re-allowing B to implement interface
I
but
sometimes bug do get reported differently. Why don't you remove I
from
B's
declaration like you said that works. It actually says here
http://www.digitalmars.com/d/1.0/interface.html Classes cannot
derive
from an interface multiple times.
Yes, please check the link again (further down the page).D
allows you to reimplement the interface as long as class B
provides a new implementation:
A reimplemented interface must implement all the interface
functions, it does not inherit from a super class...
That probably could be stated a little more clearly, but that's
what it says. As for why I'm doing it, I assure you that there's
a very specific reason why I'm trying this: it is a possible
interfacing mechansim for ported software of a much more
complicated nature than this simple reduction; I reduced it to
this in order to try to understand potential iteractions between
class and interface layers. The question here was to figure out
the reasoning behind the language design, not necessarily whether
I should be doing it or not. ;-)
-JJR
This works btw:
module test;
interface I
{
void foo();
}
class A : I {
void foo() { }
}
class B : A,I
{
void foo() { A.foo(); }
}
void main()
{
}
It is too verbose and makes twice an overhead. I'd like to avoid
this solution.
In fact, I believe that class B : A, I {} should just work.
why? I think it is perfect how it is. You can either leave A as the
class that implements I and B would implement it through inheritance
or you can to re implement I define all new implementations and put
in return super.foo(); where needed. It is also possible to
reimplement one interface function without re implementing the whole
interface.
If you are really needing to write least code you could also do
something like this but not very nice to read:
module test;
template II(char[] func)
{
const char[] II = typeof(super. ~ func ~ ()) ~ ~ func ~
() { return super. ~ func ~ (); } ;
}
interface I
{
void foo();
int bar();
}
class A : I
{
void foo() { }
int bar() { return 1; }
}
class B : A,I
{
//void foo() { return super.foo(); }
mixin(II!(foo));
mixin(II!(bar));
}
void main()
{
}
Not only I want to write less, I want my code be cleaner and run faster.
why? I think it is perfect how it is. You can either leave A as the
class that implements I and B would implement it through inheritance
or you can to re implement I define all new implementations and put in
return super.foo(); where needed. It is also possible to reimplement
one interface function without re implementing the whole interface.
That what /my/ solution do.
class B : A, I {}
is *absolutely* same as
class B : A, I
{
override void foo() { super.foo(); }
override int bar() { return super.bar(); }
}
Except that when you call B.foo, there is no damn double virtual
function call.
B inherits all the functions from A implicitly. You stil may override
any of the I interface functions if need be:
class B : A, I
{
override void foo() { ... }
// int bar() is inherited from A
}
Having B explicitly override all the base class virtual functions and
forward them to A implementation just to make compiler happy is
unintuitive and plain dumb to me.
C# allows that and I see absolutely no reason why D doesn't.
I think you are missing somethinghere. Change the B
Re: Class and Interface Fun
On Sun, 25 Jan 2009 17:06:50 +0300, Denis Koroskin 2kor...@gmail.com wrote:
On Sun, 25 Jan 2009 15:20:19 +0300, Tim M a...@b.com wrote:
On Mon, 26 Jan 2009 01:14:10 +1300, Denis Koroskin 2kor...@gmail.com
wrote:
On Sun, 25 Jan 2009 15:06:23 +0300, Tim M a...@b.com wrote:
On Mon, 26 Jan 2009 00:48:21 +1300, Tim M a...@b.com wrote:
On Mon, 26 Jan 2009 00:18:28 +1300, Denis Koroskin
2kor...@gmail.com wrote:
On Sun, 25 Jan 2009 08:38:18 +0300, Tim M a...@b.com wrote:
On Sun, 25 Jan 2009 17:56:03 +1300, John Reimer
terminal.n...@gmail.com wrote:
Hello tim,
On Sun, 25 Jan 2009 16:43:55 +1300, John Reimer
terminal.n...@gmail.com wrote:
With this code:
module test5;
interface I
{
void foo();
}
class A : I {
void foo() { }
}
class B : A, I
{
alias A.foo foo;
}
void main()
{
}
I get this error:
class test5.B interface function I.foo is not implemented
Does this make sense? I mean, shouldn't the explicit reuse of
A.foo
in B be sufficient indication to the compiler that B is
satisfying
the contract I? I'm hoping to make use of such subtleties in
some
code, but first I have to understand the reasoning behind
this. :)
Note that this works if I remove the interface I from B's
declaration
-- ie class B: A -- since, in the D language, B is not
required to
fulfull A's interface contract even though it inherits from it.
-JJR
It look like the real bug is re-allowing B to implement
interface I
but
sometimes bug do get reported differently. Why don't you remove
I from
B's
declaration like you said that works. It actually says here
http://www.digitalmars.com/d/1.0/interface.html Classes cannot
derive
from an interface multiple times.
Yes, please check the link again (further down the page).D
allows you to reimplement the interface as long as class B
provides a new implementation:
A reimplemented interface must implement all the interface
functions, it does not inherit from a super class...
That probably could be stated a little more clearly, but that's
what it says. As for why I'm doing it, I assure you that there's
a very specific reason why I'm trying this: it is a possible
interfacing mechansim for ported software of a much more
complicated nature than this simple reduction; I reduced it to
this in order to try to understand potential iteractions between
class and interface layers. The question here was to figure out
the reasoning behind the language design, not necessarily
whether I should be doing it or not. ;-)
-JJR
This works btw:
module test;
interface I
{
void foo();
}
class A : I {
void foo() { }
}
class B : A,I
{
void foo() { A.foo(); }
}
void main()
{
}
It is too verbose and makes twice an overhead. I'd like to avoid
this solution.
In fact, I believe that class B : A, I {} should just work.
why? I think it is perfect how it is. You can either leave A as the
class that implements I and B would implement it through inheritance
or you can to re implement I define all new implementations and put
in return super.foo(); where needed. It is also possible to
reimplement one interface function without re implementing the whole
interface.
If you are really needing to write least code you could also do
something like this but not very nice to read:
module test;
template II(char[] func)
{
const char[] II = typeof(super. ~ func ~ ()) ~ ~ func
~ () { return super. ~ func ~ (); } ;
}
interface I
{
void foo();
int bar();
}
class A : I
{
void foo() { }
int bar() { return 1; }
}
class B : A,I
{
//void foo() { return super.foo(); }
mixin(II!(foo));
mixin(II!(bar));
}
void main()
{
}
Not only I want to write less, I want my code be cleaner and run
faster.
why? I think it is perfect how it is. You can either leave A as the
class that implements I and B would implement it through inheritance
or you can to re implement I define all new implementations and put
in return super.foo(); where needed. It is also possible to
reimplement one interface function without re implementing the whole
interface.
That what /my/ solution do.
class B : A, I {}
is *absolutely* same as
class B : A, I
{
override void foo() { super.foo(); }
override int bar() { return super.bar(); }
}
Except that when you call B.foo, there is no damn double virtual
function call.
B inherits all the functions from A implicitly. You stil may override
any of the I interface functions if need be:
class B : A, I
{
override void foo() { ... }
// int bar() is inherited from A
}
Having B explicitly override all the base class virtual functions and
forward them to A implementation just to make compiler happy is
unintuitive and plain dumb to me.
C# allows that and I see absolutely no
Re: Class and Interface Fun
[snip]
B inherits all the functions from A implicitly. You stil may
override any of the I interface functions if need be:
class B : A, I
{
override void foo() { ... }
// int bar() is inherited from A
}
Having B explicitly override all the base class virtual functions
and forward them to A implementation just to make compiler happy is
unintuitive and plain dumb to me.
C# allows that and I see absolutely no reason why D doesn't.
I think you are missing somethinghere. Change the B definition from:
class B : A, I
to just:
class B : A
then interfaces become impicit.
No, I don't:
class B : private A, public I
{
}
Other example:
interface IOStream : InputStream, OutputStream
{
}
class A : InputStream
{
// implement InputStream
}
class B : A, IOStream
{
// implement OutputStream interface *only*
}
You can't define B like this: class B : A, OutputStream { ... } because
this way it won't be castable to IOStream.
I believe the rationale behind this is so that you can't implement an
interface by accident. For example, you might be implementing an
interface, miss one method, and not know because the base class
implements it.
Alternately, you might be relying on such inheritance. Then, the base
class changes, and you're left with compile errors and wondering why it
doesn't work.
Forcing you to specify each method removes this ambiguity from the code.
That said, I could have SWORN that aliasing a method from the superclass
worked. If this isn't a bug, it should be.
Personally, yes it is a bit tedious, but this is why we have templates
and mixins...
-- Daniel
Re: C++ operator new
This might also be of interest, as it has an example of overriding allocation/deallocation to use malloc: http://digitalmars.com/d/1.0/memory.html#newdelete
Re: Class and Interface Fun
Hello Daniel,
[snip]
B inherits all the functions from A implicitly. You stil may
override any of the I interface functions if need be:
class B : A, I
{
override void foo() { ... }
// int bar() is inherited from A
}
Having B explicitly override all the base class virtual functions
and forward them to A implementation just to make compiler happy
is unintuitive and plain dumb to me.
C# allows that and I see absolutely no reason why D doesn't.
I think you are missing somethinghere. Change the B definition
from:
class B : A, I
to just:
class B : A
then interfaces become impicit.
No, I don't:
class B : private A, public I
{
}
Other example:
interface IOStream : InputStream, OutputStream
{
}
class A : InputStream
{
// implement InputStream
}
class B : A, IOStream
{
// implement OutputStream interface *only*
}
You can't define B like this: class B : A, OutputStream { ... }
because this way it won't be castable to IOStream.
I believe the rationale behind this is so that you can't implement an
interface by accident. For example, you might be implementing an
interface, miss one method, and not know because the base class
implements it.
Alternately, you might be relying on such inheritance. Then, the base
class changes, and you're left with compile errors and wondering why
it doesn't work.
Forcing you to specify each method removes this ambiguity from the
code.
That said, I could have SWORN that aliasing a method from the
superclass worked. If this isn't a bug, it should be.
Personally, yes it is a bit tedious, but this is why we have templates
and mixins...
-- Daniel
Yes, that seems to be the reason. I actually want it to work the way it
does, other than that I can't figure out why the aliasing doesn't work.
The way it works now, I'm not forced to implement A's Interface if I only
inherit from A. Explicit extension of a class with the same interface is
necessary, and I /think/ this is the way it should be... but I'll lay claim
to the I'm not an expert clause. :)
-JJR
-JJR
Re: Class and Interface Fun
Hello tim, It not a bug though. It's all here http://www.digitalmars.com/d/1.0/interface.html and it works like it says. Is there a problem? The only thing that might be close to a bug, I think, is the inability of the alias to satisfy the interface contract reimplementation. -JJR
Re: Class and Interface Fun
Hello Daniel,
[snip]
B inherits all the functions from A implicitly. You stil may
override any of the I interface functions if need be:
class B : A, I
{
override void foo() { ... }
// int bar() is inherited from A
}
Having B explicitly override all the base class virtual functions
and forward them to A implementation just to make compiler happy
is unintuitive and plain dumb to me.
C# allows that and I see absolutely no reason why D doesn't.
I think you are missing somethinghere. Change the B definition
from:
class B : A, I
to just:
class B : A
then interfaces become impicit.
No, I don't:
class B : private A, public I
{
}
Other example:
interface IOStream : InputStream, OutputStream
{
}
class A : InputStream
{
// implement InputStream
}
class B : A, IOStream
{
// implement OutputStream interface *only*
}
You can't define B like this: class B : A, OutputStream { ... }
because this way it won't be castable to IOStream.
I believe the rationale behind this is so that you can't implement an
interface by accident. For example, you might be implementing an
interface, miss one method, and not know because the base class
implements it.
Alternately, you might be relying on such inheritance. Then, the base
class changes, and you're left with compile errors and wondering why
it doesn't work.
Forcing you to specify each method removes this ambiguity from the
code.
That said, I could have SWORN that aliasing a method from the
superclass worked. If this isn't a bug, it should be.
Personally, yes it is a bit tedious, but this is why we have templates
and mixins...
-- Daniel
Incidentally, concerning having to explicitly alias superclass methods to
make them visible in the subclass, I used to dislike it greatly in D. But
now, I've come to appreciate it more since it /clearly/ specifies which mehtods
of the superclass you want to use in the subclass. For example, in Java,
this isn't necessary... and in a very large project like the swt (java) port
to D, there have been times that it's been a major pain trying to track a
call made in a subclass method that references an implicitly inherited superclass
method.
To me, the D alias system doesn't always look that pretty in this context...
but it is certainly very useful.
-JJR
Re: Class and Interface Fun
Denis Koroskin wrote:
On Sun, 25 Jan 2009 08:38:18 +0300, Tim M a...@b.com wrote:
class B : A,I
{
void foo() { A.foo(); }
}
void main()
{
}
It is too verbose and makes twice an overhead. I'd like to avoid this
solution.
Any reasonable compiler would inline the call to A.foo.
In fact, I believe that class B : A, I {} should just work.
I think that's something like checked exceptions: a wonderful idea in
small examples, but it can cause problems in larger bodies of code.
I haven't ever encountered this problem, but I've heard about it twice,
I think, so maybe my coding is just a bit simpler than other people's.
Re: Class and Interface Fun
On Mon, 26 Jan 2009 04:58:57 +1300, John Reimer terminal.n...@gmail.com
wrote:
Hello tim,
On Mon, 26 Jan 2009 01:14:10 +1300, Denis Koroskin 2kor...@gmail.com
wrote:
On Sun, 25 Jan 2009 15:06:23 +0300, Tim M a...@b.com wrote:
On Mon, 26 Jan 2009 00:48:21 +1300, Tim M a...@b.com wrote:
On Mon, 26 Jan 2009 00:18:28 +1300, Denis Koroskin
2kor...@gmail.com wrote:
On Sun, 25 Jan 2009 08:38:18 +0300, Tim M a...@b.com wrote:
On Sun, 25 Jan 2009 17:56:03 +1300, John Reimer
terminal.n...@gmail.com wrote:
Hello tim,
On Sun, 25 Jan 2009 16:43:55 +1300, John Reimer
terminal.n...@gmail.com wrote:
With this code:
module test5;
interface I
{
void foo();
}
class A : I {
void foo() { }
}
class B : A, I
{
alias A.foo foo;
}
void main()
{
}
I get this error:
class test5.B interface function I.foo is not implemented
Does this make sense? I mean, shouldn't the explicit reuse of
A.foo
in B be sufficient indication to the compiler that B is
satisfying
the contract I? I'm hoping to make use of such subtleties
in
some
code, but first I have to understand the reasoning behind
this.
:)
Note that this works if I remove the interface I from B's
declaration
-- ie class B: A -- since, in the D language, B is not
required to
fulfull A's interface contract even though it inherits from
it.
-JJR
It look like the real bug is re-allowing B to implement
interface I
but
sometimes bug do get reported differently. Why don't you remove
I
from
B's
declaration like you said that works. It actually says here
http://www.digitalmars.com/d/1.0/interface.html Classes cannot
derive
from an interface multiple times.
Yes, please check the link again (further down the page).D
allows you to reimplement the interface as long as class B
provides a new implementation:
A reimplemented interface must implement all the interface
functions, it does not inherit from a super class...
That probably could be stated a little more clearly, but that's
what it says. As for why I'm doing it, I assure you that
there's a very specific reason why I'm trying this: it is a
possible interfacing mechansim for ported software of a much
more complicated nature than this simple reduction; I reduced
it to this in order to try to understand potential iteractions
between class and interface layers. The question here was to
figure out the reasoning behind the language design, not
necessarily whether I should be doing it or not. ;-)
-JJR
This works btw:
module test;
interface I
{
void foo();
}
class A : I {
void foo() { }
}
class B : A,I
{
void foo() { A.foo(); }
}
void main()
{
}
It is too verbose and makes twice an overhead. I'd like to avoid
this
solution.
In fact, I believe that class B : A, I {} should just work.
why? I think it is perfect how it is. You can either leave A as the
class that implements I and B would implement it through
inheritance or you can to re implement I define all new
implementations and put in return super.foo(); where needed. It is
also possible to reimplement one interface function without re
implementing the whole interface.
If you are really needing to write least code you could also do
something like this but not very nice to read:
module test;
template II(char[] func)
{
const char[] II = typeof(super. ~ func ~ ()) ~ ~ func ~
() { return super. ~ func ~ (); } ;
}
interface I
{
void foo();
int bar();
}
class A : I
{
void foo() { }
int bar() { return 1; }
}
class B : A,I
{
//void foo() { return super.foo(); }
mixin(II!(foo));
mixin(II!(bar));
}
void main()
{
}
Not only I want to write less, I want my code be cleaner and run
faster.
why? I think it is perfect how it is. You can either leave A as the
class that implements I and B would implement it through inheritance
or you can to re implement I define all new implementations and put
in return super.foo(); where needed. It is also possible to
reimplement one interface function without re implementing the
whole interface.
That what /my/ solution do.
class B : A, I {}
is *absolutely* same as
class B : A, I
{
override void foo() { super.foo(); }
override int bar() { return super.bar(); }
}
Except that when you call B.foo, there is no damn double virtual
function call.
B inherits all the functions from A implicitly. You stil may override
any of the I interface functions if need be:
class B : A, I
{
override void foo() { ... }
// int bar() is inherited from A
}
Having B explicitly override all the base class virtual functions and
forward them to A implementation just to make compiler happy is
unintuitive and plain dumb to me.
C# allows that and I see absolutely no reason why D doesn't.
I think you are missing somethinghere. Change the B definition from:
class B : A, I
to just:
class B : A
then interfaces become impicit.
What do you mean? In your example above, B does not have to implement
Re: Class and Interface Fun
Hello tim,
On Mon, 26 Jan 2009 04:58:57 +1300, John Reimer
terminal.n...@gmail.com wrote:
Hello tim,
On Mon, 26 Jan 2009 01:14:10 +1300, Denis Koroskin
2kor...@gmail.com wrote:
On Sun, 25 Jan 2009 15:06:23 +0300, Tim M a...@b.com wrote:
On Mon, 26 Jan 2009 00:48:21 +1300, Tim M a...@b.com wrote:
On Mon, 26 Jan 2009 00:18:28 +1300, Denis Koroskin
2kor...@gmail.com wrote:
On Sun, 25 Jan 2009 08:38:18 +0300, Tim M a...@b.com wrote:
On Sun, 25 Jan 2009 17:56:03 +1300, John Reimer
terminal.n...@gmail.com wrote:
Hello tim,
On Sun, 25 Jan 2009 16:43:55 +1300, John Reimer
terminal.n...@gmail.com wrote:
With this code:
module test5;
interface I
{
void foo();
}
class A : I {
void foo() { }
}
class B : A, I
{
alias A.foo foo;
}
void main()
{
}
I get this error:
class test5.B interface function I.foo is not implemented
Does this make sense? I mean, shouldn't the explicit reuse
of
A.foo
in B be sufficient indication to the compiler that B is
satisfying
the contract I? I'm hoping to make use of such subtleties
in
some
code, but first I have to understand the reasoning behind
this.
:)
Note that this works if I remove the interface I from B's
declaration
-- ie class B: A -- since, in the D language, B is not
required to
fulfull A's interface contract even though it inherits from
it.
-JJR
It look like the real bug is re-allowing B to implement
interface I
but
sometimes bug do get reported differently. Why don't you
remove
I
from
B's
declaration like you said that works. It actually says here
http://www.digitalmars.com/d/1.0/interface.html Classes
cannot
derive
from an interface multiple times.
Yes, please check the link again (further down the page).D
allows you to reimplement the interface as long as class B
provides a new implementation:
A reimplemented interface must implement all the interface
functions, it does not inherit from a super class...
That probably could be stated a little more clearly, but
that's
what it says. As for why I'm doing it, I assure you that
there's a very specific reason why I'm trying this: it is a
possible interfacing mechansim for ported software of a much
more complicated nature than this simple reduction; I reduced
it to this in order to try to understand potential
iteractions
between class and interface layers. The question here was to
figure out the reasoning behind the language design, not
necessarily whether I should be doing it or not. ;-)
-JJR
This works btw:
module test;
interface I
{
void foo();
}
class A : I {
void foo() { }
}
class B : A,I
{
void foo() { A.foo(); }
}
void main()
{
}
It is too verbose and makes twice an overhead. I'd like to avoid
this
solution.
In fact, I believe that class B : A, I {} should just work.
why? I think it is perfect how it is. You can either leave A as
the class that implements I and B would implement it through
inheritance or you can to re implement I define all new
implementations and put in return super.foo(); where needed. It
is also possible to reimplement one interface function without
re implementing the whole interface.
If you are really needing to write least code you could also do
something like this but not very nice to read:
module test;
template II(char[] func)
{
const char[] II = typeof(super. ~ func ~ ()) ~ ~ func ~
() { return super. ~ func ~ (); } ;
}
interface I
{
void foo();
int bar();
}
class A : I
{
void foo() { }
int bar() { return 1; }
}
class B : A,I
{
//void foo() { return super.foo(); }
mixin(II!(foo));
mixin(II!(bar));
}
void main()
{
}
Not only I want to write less, I want my code be cleaner and run
faster.
why? I think it is perfect how it is. You can either leave A as
the class that implements I and B would implement it through
inheritance or you can to re implement I define all new
implementations and put in return super.foo(); where needed. It
is also possible to reimplement one interface function without re
implementing the whole interface.
That what /my/ solution do.
class B : A, I {}
is *absolutely* same as
class B : A, I
{
override void foo() { super.foo(); }
override int bar() { return super.bar(); }
}
Except that when you call B.foo, there is no damn double virtual
function call.
B inherits all the functions from A implicitly. You stil may
override
any of the I interface functions if need be:
class B : A, I
{
override void foo() { ... }
// int bar() is inherited from A
}
Having B explicitly override all the base class virtual functions
and
forward them to A implementation just to make compiler happy is
unintuitive and plain dumb to me.
C# allows that and I see absolutely no reason why D doesn't.
I think you are missing somethinghere. Change the B definition from:
class B : A, I
to just:
class B : A
then interfaces become impicit.
What do you mean? In your example above, B does not have to
implement the interface
Re: how to use dll
Wed, 21 Jan 2009 23:19:48 -0500, reimi gibbons wrote: I'm currently developing a software with D and Tango. I don't have much knowledge on DLL, but i do know when linking to static lib you need a .h header file, but do i need .h for linking with DLL as well? also can anybody please provide a quick and small example to link with DLL. The easiest way is to link with an import library. It's exactly like linking with a static library. Actually you *are* linking with a static library, but that's a special kind of static library which forwards your calls to a DLL. This way runtime automatically loads the DLL before your program starts and unloads it after main() terminates, so you don't need to bother yourself with details. As Daniel pointed out, you can try to convert an existing .h file into a .d file using htod: http://www.digitalmars.com/d/2.0/htod.html The most reliable way to get an import library for your DLL is to get a .lib file in COFF format provided with the DLL and convert it into OMF format using coffimplib: ftp://ftp.digitalmars.com/coffimplib.zip
Re: Is there a way to remove the requirement for parenthesis?
Wed, 21 Jan 2009 09:24:01 -0800, Charles Hixson wrote:
In this test I'm trying to emulate how I want a typedef to act, but I
run into a problem:
import std.stdio;
struct BlockNum
{ uint value;
uint opCast() { return value; }
void opAssign (uint val) { value = val; }
uint opCall() { return value; }
}
void main()
{ BlockNum test;
test = 42;
uint tst2 = test(); // == if I don't have the parenthesis I
//get a compiler error (cast
//required).
// kfile.d(15): Error: cannot implicitly convert expression
// (test) of type BlockNum to uint
writef (tst2 = %d\n, tst2);
}
It seemed to me as if the parens shouldn't be required here, but I seem
mistaken. Which leads to ugly code. Is there a way around this?
test is an expression of type BlockNum. opCall() is called when you use
parentheses syntax on it. opCast() is called when you use cast() syntax
for it. Otherwise it stays BlockNum and therefore is not convertible to
uint.
Re: loop through specific class members
Wed, 21 Jan 2009 12:48:07 +0100, Trass3r wrote:
Christopher Wright schrieb:
On the other hand, you can get the non-final, non-private methods of a
class with something like:
foreach (member; __traits (allMembers, Class))
{
foreach (overload; __traits (getVirtualFunctions, Class, member))
{
// do stuff
}
}
Naturally, __traits and foreach don't mix, so you'll have to use
template recursion. This is pretty damn ugly.
But why doesn't that work? It doesn't even work when forced to run at
compile time by CTFE.
Had a look at the compiler code, it uses the same mechanism as
pragma(msg, for example, so shouldn't something like the above
theoretically be possible?
foreach() is a runtime construct. It may be *interpreted* at
compile-time, but it's interpreted as if it were run time nevertheless.
It dynamically changes the value of 'member' variable.
pragma() and __traits() are compile-time constructs. They are fully and
statically expanded before anything is being interpreted and cannot
handle dynamically changing variables.
Re: loop through specific class members
Hello Sergey, foreach() is a runtime construct. It may be *interpreted* at compile-time, but it's interpreted as if it were run time nevertheless. It dynamically changes the value of 'member' variable. OTOH a foreach on a tuple is a compile time construct, but it is a distinct construct from the array foreach and is not what you are using (If i'm reading stuff correctly)
