FWIW, I agree with Addam. One of the things I like in D is that the
langage is designed so that interpretations are made based on what you
intend, and what you intend to do is checked. That is exactly what is
done by using overwrite keyword. If you intend to make a non-abstract
class, the
On Fri, 02 Dec 2011 17:28:33 -0500, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Friday, December 02, 2011 21:13:45 Adam wrote:
Anyway, I have my answer, and I know that D *does* have a reason for
this implicitism.
Okay. Maybe I've been skimming over this thread too much, but I don't
mta`chrono Wrote:
Even if the current behavior (what Adam mentioned) is not a bug, I think
it seems to be a pitfall for std::programmer. The language/compiler
should be more restrictive in this case.
If you think so, then write it in Bugzilla :-)
Bye,
bearophile
On Fri, 02 Dec 2011 03:06:37 -0500, mta`chrono
chr...@mta-international.net wrote:
Even if the current behavior (what Adam mentioned) is not a bug, I think
it seems to be a pitfall for std::programmer. The language/compiler
should be more restrictive in this case.
No, this is not a matter
To sort of put my two cents back in, and also to be one of those D
should be like Java! advocates, the problem is largely that a class
that inherits from an abstract and does *not* override some abstract
member becomes implicitly (to the user) abstract.
The way abstracts work in Java is that, in
On Fri, 02 Dec 2011 09:54:10 -0500, Adam a...@anizi.com wrote:
To sort of put my two cents back in, and also to be one of those D
should be like Java! advocates, the problem is largely that a class
that inherits from an abstract and does *not* override some abstract
member becomes implicitly
I'm not sure how the fact that a class can be abstract with defined
functions impacts the case either way.
It's caught at compile time, but it requires explicitly testing that
any given time is or is not instantiable - how else would you test
for this particular case? It seems to be adding an
On Friday, December 02, 2011 14:54:10 Adam wrote:
To sort of put my two cents back in, and also to be one of those D
should be like Java! advocates, the problem is largely that a class
that inherits from an abstract and does *not* override some abstract
member becomes implicitly (to the user)
Ok, let me give a more *specific* case of why this is a problem.
Suppose we have our Parent and Child cases from before
Parent exists in Library A
Child exists in my library, B
Library C, used by some developer, uses my library, B.
My Child is not meant to be abstract - it's intended to me
How can you put out a library where you don't even test your classes?
That's just bad programming, period.
Ok, fine, let me put it THIS way.
Suppose I use a parent library, and *I* don't update it.
The USER of my library provides an updated version for some
unrelated reason.
So, NOT testing that something is instantiable or not - JUST that
it's instantiable - is bad programming...
...but requiring
On Fri, 02 Dec 2011 17:24:11 -, Adam a...@anizi.com wrote:
Ok, fine, let me put it THIS way.
Suppose I use a parent library, and *I* don't update it.
The USER of my library provides an updated version for some
unrelated reason.
So, NOT testing that something is instantiable or not - JUST
I grant you that I should test it, and I never said otherwise. If
I'm attacking a strawman, it's the same one that was just put in
front of me as a misinterpretation of my argument.
What I contest and addressed was a test for the sole purpose of
determining if my class, assumed to be non-abstract,
Or I provide it as source, in which case, D *can* check it.
But it means that when the parent is changed, my class type and
instantiability implicitly changes, too.
On Fri, 02 Dec 2011 17:24:11 -, Adam a...@anizi.com wrote:
Ok, fine, let me put it THIS way.
Suppose I use a parent library, and *I* don't update it.
The USER of my library provides an updated version for some
unrelated reason.
So.. the user has:
Parent.dll
Your.dll
Their.exe
and
On Fri, 02 Dec 2011 17:43:04 -, Adam a...@anizi.com wrote:
I grant you that I should test it, and I never said otherwise. If
I'm attacking a strawman, it's the same one that was just put in
front of me as a misinterpretation of my argument.
Well, I believe I understand your argument and I
On Fri, 02 Dec 2011 17:44:44 -, Adam a...@anizi.com wrote:
Or I provide it as source, in which case, D *can* check it.
But it means that when the parent is changed, my class type and
instantiability implicitly changes, too.
True. This is a case I hadn't considered before. In this case
Well, I believe I understand your argument and I admit that I did
find it
odd that the error was not detected until the class was
instantiated.
But, once I thought about it I understood why this is the case,
and I
believe you understand it as well. I also understand that you'd
rather it
On Fri, 02 Dec 2011 11:05:00 -0500, Adam a...@anizi.com wrote:
I'm not sure how the fact that a class can be abstract with defined
functions impacts the case either way.
It's caught at compile time, but it requires explicitly testing that
any given time is or is not instantiable - how else
Your presumption is that someone is required to run tests just to
ensure that their class definition is what they expect. If I define
a class and it's concrete (because I've defined everything), and
later someone changes the parent class, my class is no longer
concrete (it no longer conforms to my
On 12/02/2011 05:05 PM, Adam wrote:
To step back a bit, what is the *benefit* of not requiring a class
to be declared abstract if it does not override an abstract member?
It introduces implicit behavior and the potential for an additional
test case (in *what* sane world should I even HAVE to
A second possible use case:
class C(T): T{
// some declarations
}
Now you really want that template to be instantiable with T being
either
an abstract or a concrete class. Anything else is bound to become
extremely annoying.
Could you expand on this case a bit? I'm not sure I
On 12/02/2011 08:10 PM, Adam wrote:
A second possible use case:
class C(T): T{
// some declarations
}
Now you really want that template to be instantiable with T being
either
an abstract or a concrete class. Anything else is bound to become
extremely annoying.
Could you expand on
On 12/02/2011 09:05 PM, Timon Gehr wrote:
On 12/02/2011 08:10 PM, Adam wrote:
A second possible use case:
class C(T): T{
// some declarations
}
Now you really want that template to be instantiable with T being
either
an abstract or a concrete class. Anything else is bound to become
So this pattern allows you to provide partial implementations of an
abstract, and use template specialization to provide a sort of
multiple inheritance rather than strict class definition /
extension. That's important in Scala because of the lack of multiple
inheritance (as I understand it).
Am I
On Fri, 02 Dec 2011 14:06:00 -0500, Adam a...@anizi.com wrote:
Your presumption is that someone is required to run tests just to
ensure that their class definition is what they expect. If I define
a class and it's concrete (because I've defined everything), and
later someone changes the parent
You're being a bit dramatic, no? The code didn't compile, the
compiler
caught it, and you have invented this theoretical case (which did
*not*
occur) to try and make your point. I don't deny that requiring
'abstract'
has some value, but what I question is how much is that value?
Since a
On 12/02/2011 09:27 PM, Adam wrote:
So this pattern allows you to provide partial implementations of an
abstract, and use template specialization to provide a sort of
multiple inheritance rather than strict class definition /
extension. That's important in Scala because of the lack of multiple
On Fri, 02 Dec 2011 16:13:45 -0500, Adam a...@anizi.com wrote:
You're being a bit dramatic, no? The code didn't compile, the
compiler
caught it, and you have invented this theoretical case (which did
*not*
occur) to try and make your point. I don't deny that requiring
'abstract'
has
On Friday, December 02, 2011 21:13:45 Adam wrote:
Anyway, I have my answer, and I know that D *does* have a reason for
this implicitism.
Okay. Maybe I've been skimming over this thread too much, but I don't
understand what forcing the programmer to mark an abstract class as abstract
would do.
Ok, starting to feel like I'm missing something obvious...
The abstract keyword in the language reference states:
Functions declared as abstract can still have function bodies. This
is so that even though they must be overridden, they can still
provide �base class functionality.�
So, they must
On Thu, 01 Dec 2011 17:50:48 -, Adam a...@anizi.com wrote:
Ok, starting to feel like I'm missing something obvious...
This:
void main() {
Child child = new Child;
}
also produces the (expected) error. Basically dmd was letting you get
away with the abstract class
I saw that a few minutes after posting as well, but if the only time
it's going to actually check the definition is if I instantiate it,
well... that's not so good for me if I'm writing implementations to be
used at a later date.
Hm. Guess we'll see. :)
On Thu, 01 Dec 2011 18:50:48 +0100, Adam a...@anizi.com wrote:
Ok, starting to feel like I'm missing something obvious...
The abstract keyword in the language reference states:
Functions declared as abstract can still have function bodies. This
is so that even though they must be overridden,
On Thu, 01 Dec 2011 12:58:24 -0500, Regan Heath re...@netmail.co.nz
wrote:
On Thu, 01 Dec 2011 17:50:48 -, Adam a...@anizi.com wrote:
Ok, starting to feel like I'm missing something obvious...
This:
void main() {
Child child = new Child;
}
also produces the
I can see the case for a grand-child, but if a class does not provide
a definition for an abstract member, is that class not, by
association, abstract?
Classes become abstract if they are defined within an abstract
attribute, or if any of the virtual member functions within it are
declared as
Because the function in this case has no definition in the base
abstract class (Parent), but is referenced / called by Parent's
members. I did not want Parent to provide a default definition for the
function precisely because a large point of the abstract was that
method.
On Thu, 01 Dec 2011 19:19:49 +0100, Adam a...@anizi.com wrote:
I can see the case for a grand-child, but if a class does not provide
a definition for an abstract member, is that class not, by
association, abstract?
Of course. That's what I said. Or meant, at any rate.
Classes become
On 2011-12-01 19:18, Steven Schveighoffer wrote:
On Thu, 01 Dec 2011 12:58:24 -0500, Regan Heath re...@netmail.co.nz
wrote:
On Thu, 01 Dec 2011 17:50:48 -, Adam a...@anizi.com wrote:
Ok, starting to feel like I'm missing something obvious...
This:
void main() {
Child child = new Child;
On 2011-12-01 19:14, Simen Kjærås wrote:
On Thu, 01 Dec 2011 18:50:48 +0100, Adam a...@anizi.com wrote:
Ok, starting to feel like I'm missing something obvious...
The abstract keyword in the language reference states:
Functions declared as abstract can still have function bodies. This
is so
40 matches
Mail list logo
