On Tue, 30 Aug 2011 17:41:46 -0400, Jonathan M Davis
wrote:
On Tuesday, August 30, 2011 11:35 Steven Schveighoffer wrote:
On Tue, 30 Aug 2011 14:30:42 -0400, Timon Gehr
wrote:
> On 08/30/2011 07:50 PM, Steven Schveighoffer wrote:
>> We could find cases like this all day.
>>
>> Make I a cl
On Tuesday, August 30, 2011 11:35 Steven Schveighoffer wrote:
> On Tue, 30 Aug 2011 14:30:42 -0400, Timon Gehr wrote:
> > On 08/30/2011 07:50 PM, Steven Schveighoffer wrote:
> >> We could find cases like this all day.
> >>
> >> Make I a class, and this problem also occurs.
> >>
> >> Without the
Personnally, I would like override to be used when implementing
interfaces too, because there is really some hooking happening (and
thus hijacking risks), regardless of the presence of a previous method
or not.
If the problem is that you may have a method witch overrides an abstract
class C wh
On Tue, 30 Aug 2011 14:56:46 -0400, Timon Gehr wrote:
On 08/30/2011 08:35 PM, Steven Schveighoffer wrote:
On Tue, 30 Aug 2011 14:30:42 -0400, Timon Gehr
wrote:
On 08/30/2011 07:50 PM, Steven Schveighoffer wrote:
We could find cases like this all day.
Make I a class, and this problem al
On 08/30/2011 08:35 PM, Steven Schveighoffer wrote:
On Tue, 30 Aug 2011 14:30:42 -0400, Timon Gehr wrote:
On 08/30/2011 07:50 PM, Steven Schveighoffer wrote:
We could find cases like this all day.
Make I a class, and this problem also occurs.
Without the compiler having access to the *chan
On 08/30/2011 08:32 PM, Steven Schveighoffer wrote:
On Tue, 30 Aug 2011 14:27:25 -0400, Timon Gehr wrote:
What I was saying is not that there is no specific layout, just that
an interface by itself does not need to be represented in the object
file. All interface vtbls are part of the classinf
On Tue, 30 Aug 2011 14:30:42 -0400, Timon Gehr wrote:
On 08/30/2011 07:50 PM, Steven Schveighoffer wrote:
We could find cases like this all day.
Make I a class, and this problem also occurs.
Without the compiler having access to the *changes* it cannot be perfect
in detecting refactoring er
On Tue, 30 Aug 2011 14:27:25 -0400, Timon Gehr wrote:
What I was saying is not that there is no specific layout, just that an
interface by itself does not need to be represented in the object file.
All interface vtbls are part of the classinfo of the implementing
classes.
in
interface I
On 08/30/2011 07:50 PM, Steven Schveighoffer wrote:
We could find cases like this all day.
Make I a class, and this problem also occurs.
Without the compiler having access to the *changes* it cannot be perfect
in detecting refactoring errors.
-Steve
Chances are that it will detect more erro
On 08/30/2011 07:29 PM, Steven Schveighoffer wrote:
On Tue, 30 Aug 2011 13:21:09 -0400, Timon Gehr wrote:
On 08/30/2011 07:06 PM, Steven Schveighoffer wrote:
On Tue, 30 Aug 2011 12:55:30 -0400, Timon Gehr
wrote:
On 08/30/2011 06:23 PM, Steven Schveighoffer wrote:
On Tue, 30 Aug 2011 12:18
On Tue, 30 Aug 2011 13:39:35 -0400, Timon Gehr wrote:
On 08/30/2011 07:16 PM, Steven Schveighoffer wrote:
On Tue, 30 Aug 2011 13:06:02 -0400, Timon Gehr
wrote:
On 08/30/2011 06:43 PM, Steven Schveighoffer wrote:
On Tue, 30 Aug 2011 12:29:59 -0400, Andrei Alexandrescu
wrote:
On 8/30/11
On 08/30/2011 07:16 PM, Steven Schveighoffer wrote:
On Tue, 30 Aug 2011 13:06:02 -0400, Timon Gehr wrote:
On 08/30/2011 06:43 PM, Steven Schveighoffer wrote:
On Tue, 30 Aug 2011 12:29:59 -0400, Andrei Alexandrescu
wrote:
On 8/30/11 11:06 AM, Steven Schveighoffer wrote:
When I write code t
On Tue, 30 Aug 2011 13:21:09 -0400, Timon Gehr wrote:
On 08/30/2011 07:06 PM, Steven Schveighoffer wrote:
On Tue, 30 Aug 2011 12:55:30 -0400, Timon Gehr
wrote:
On 08/30/2011 06:23 PM, Steven Schveighoffer wrote:
On Tue, 30 Aug 2011 12:18:32 -0400, Timon Gehr
wrote:
On 08/30/2011 06:00
On Tuesday, August 30, 2011 10:06 Timon Gehr wrote:
> On 08/30/2011 06:43 PM, Steven Schveighoffer wrote:
> > On Tue, 30 Aug 2011 12:29:59 -0400, Andrei Alexandrescu
> >
> > wrote:
> >> On 8/30/11 11:06 AM, Steven Schveighoffer wrote:
> >>> When I write code that derives from a base class, I'm de
On 08/30/2011 07:06 PM, Steven Schveighoffer wrote:
On Tue, 30 Aug 2011 12:55:30 -0400, Timon Gehr wrote:
On 08/30/2011 06:23 PM, Steven Schveighoffer wrote:
On Tue, 30 Aug 2011 12:18:32 -0400, Timon Gehr
wrote:
On 08/30/2011 06:00 PM, Steven Schveighoffer wrote:
On Tue, 30 Aug 2011 11:58
On Tue, 30 Aug 2011 13:06:02 -0400, Timon Gehr wrote:
On 08/30/2011 06:43 PM, Steven Schveighoffer wrote:
On Tue, 30 Aug 2011 12:29:59 -0400, Andrei Alexandrescu
wrote:
On 8/30/11 11:06 AM, Steven Schveighoffer wrote:
When I write code that derives from a base class, I'm declaring with
ove
On Tue, 30 Aug 2011 13:16:58 -0400, Steven Schveighoffer
wrote:
On Tue, 30 Aug 2011 13:06:02 -0400, Timon Gehr wrote:
I don't think that you can change a widely used interface into an
abstract class and not introduce annoyances much larger than override
is capable of creating.
interfa
"Timon Gehr" wrote in message
news:j3j4m4$2l0u$1...@digitalmars.com...
> And I am quite certain that what exactly is in the table is actually
> decided at link time.
At object file generation time generally.
On Tue, 30 Aug 2011 12:55:30 -0400, Timon Gehr wrote:
On 08/30/2011 06:23 PM, Steven Schveighoffer wrote:
On Tue, 30 Aug 2011 12:18:32 -0400, Timon Gehr
wrote:
On 08/30/2011 06:00 PM, Steven Schveighoffer wrote:
On Tue, 30 Aug 2011 11:58:43 -0400, Timon Gehr
wrote:
On 08/30/2011 05:49
On 08/30/2011 06:43 PM, Steven Schveighoffer wrote:
On Tue, 30 Aug 2011 12:29:59 -0400, Andrei Alexandrescu
wrote:
On 8/30/11 11:06 AM, Steven Schveighoffer wrote:
When I write code that derives from a base class, I'm declaring with
override that I want to implement the base class' function.
On 08/30/2011 06:23 PM, Steven Schveighoffer wrote:
On Tue, 30 Aug 2011 12:18:32 -0400, Timon Gehr wrote:
On 08/30/2011 06:00 PM, Steven Schveighoffer wrote:
On Tue, 30 Aug 2011 11:58:43 -0400, Timon Gehr
wrote:
On 08/30/2011 05:49 PM, Christophe wrote:
The fact that the code compile only
On Tue, 30 Aug 2011 12:29:59 -0400, Andrei Alexandrescu
wrote:
On 8/30/11 11:06 AM, Steven Schveighoffer wrote:
When I write code that derives from a base class, I'm declaring with
override that I want to implement the base class' function.
When I write code that implements an interface, I'm
On 8/30/11 10:49 AM, Christophe wrote:
The fact that the code compile only if all interface methods are
implemented does not imply that the programmer knows which method he
implemented hooks and which does not.
It does mean the programmer implemented all methods of the interface.
Andrei
On 8/30/11 11:06 AM, Steven Schveighoffer wrote:
When I write code that derives from a base class, I'm declaring with
override that I want to implement the base class' function.
When I write code that implements an interface, I'm declaring with
override that I want to implement the interface's fu
On Tue, 30 Aug 2011 12:18:32 -0400, Timon Gehr wrote:
On 08/30/2011 06:00 PM, Steven Schveighoffer wrote:
On Tue, 30 Aug 2011 11:58:43 -0400, Timon Gehr
wrote:
On 08/30/2011 05:49 PM, Christophe wrote:
The fact that the code compile only if all interface methods are
implemented does not
On 08/30/2011 06:00 PM, Steven Schveighoffer wrote:
On Tue, 30 Aug 2011 11:58:43 -0400, Timon Gehr wrote:
On 08/30/2011 05:49 PM, Christophe wrote:
The fact that the code compile only if all interface methods are
implemented does not imply that the programmer knows which method he
implemented
On Tue, 30 Aug 2011 11:40:40 -0400, Andrei Alexandrescu
wrote:
On 8/30/11 7:45 AM, Steven Schveighoffer wrote:
On Tue, 30 Aug 2011 08:26:17 -0400, Andrei Alexandrescu
wrote:
On 08/30/2011 07:13 AM, Timon Gehr wrote:
If there already is an implementation, it overrides it, otherwise it
imp
On Tue, 30 Aug 2011 11:58:43 -0400, Timon Gehr wrote:
On 08/30/2011 05:49 PM, Christophe wrote:
The fact that the code compile only if all interface methods are
implemented does not imply that the programmer knows which method he
implemented hooks and which does not.
interface I{
void m
On 08/30/2011 05:49 PM, Christophe wrote:
The fact that the code compile only if all interface methods are
implemented does not imply that the programmer knows which method he
implemented hooks and which does not.
interface I{
void method();
}
class C: I{
void method() {} // not a hook
The fact that the code compile only if all interface methods are
implemented does not imply that the programmer knows which method he
implemented hooks and which does not.
On 8/30/11 7:45 AM, Steven Schveighoffer wrote:
On Tue, 30 Aug 2011 08:26:17 -0400, Andrei Alexandrescu
wrote:
On 08/30/2011 07:13 AM, Timon Gehr wrote:
If there already is an implementation, it overrides it, otherwise it
implements it.
That's pretty much it. The entire purpose of the "over
I'm not sure what I am talking about (I have never used interfaces so
far), but if a interface developper adds a method foo, she expects every
developper of derived class to get an error because they don't implement
this new method yet.
But if a derived class unfortunately already has a method
On Tue, 30 Aug 2011 08:26:17 -0400, Andrei Alexandrescu
wrote:
On 08/30/2011 07:13 AM, Timon Gehr wrote:
If there already is an implementation, it overrides it, otherwise it
implements it.
That's pretty much it. The entire purpose of the "override" keyword is
to prevent silent bugs of tw
On 08/30/2011 07:13 AM, Timon Gehr wrote:
If there already is an implementation, it overrides it, otherwise it
implements it.
That's pretty much it. The entire purpose of the "override" keyword is
to prevent silent bugs of two kinds:
(a) User thinks she hooks a specific method but instead in
On 08/30/2011 01:48 PM, Marco Leise wrote:
Am 29.08.2011, 22:24 Uhr, schrieb Jonathan M Davis :
It's _not_ overriding. It's implementing an interface method. Those
are two
totally different things. And I think that it's horrible that Java
considers
implementing an interface method as overriding
On 08/29/2011 10:24 PM, Jonathan M Davis wrote:
On Monday, August 29, 2011 14:09 Mariusz Gliwiński wrote:
interface Interface {
Interface method();
}
class Class : Interface {
override Class method() {}
}
DMD complains it isn't overriding. How should it be according to
specification, and how
Am 29.08.2011, 22:24 Uhr, schrieb Jonathan M Davis :
It's _not_ overriding. It's implementing an interface method. Those are
two
totally different things. And I think that it's horrible that Java
considers
implementing an interface method as overriding it. I'd _hate_ to see
that in
D.
- J
On Tue, 30 Aug 2011 07:04:27 -0400, Jonathan M Davis
wrote:
On Tuesday, August 30, 2011 06:47:03 Steven Schveighoffer wrote:
On Mon, 29 Aug 2011 16:24:46 -0400, Jonathan M Davis
wrote:
> On Monday, August 29, 2011 14:09 Mariusz Gliwiński wrote:
>>
>> interface Interface {
>> Interface m
On Tuesday, August 30, 2011 06:47:03 Steven Schveighoffer wrote:
> On Mon, 29 Aug 2011 16:24:46 -0400, Jonathan M Davis
>
> wrote:
> > On Monday, August 29, 2011 14:09 Mariusz Gliwiński wrote:
> >>
> >> interface Interface {
> >> Interface method();
> >> }
> >> class Class : Interface {
> >> ove
On Mon, 29 Aug 2011 16:24:46 -0400, Jonathan M Davis
wrote:
On Monday, August 29, 2011 14:09 Mariusz Gliwiński wrote:
interface Interface {
Interface method();
}
class Class : Interface {
override Class method() {}
}
DMD complains it isn't overriding. How should it be according to
specifi
On Tuesday, August 30, 2011 12:42:04 Mariusz Gliwiński wrote:
> Jonathan M Davis wrote:
> > On Tuesday, August 30, 2011 08:57:53 Mariusz Gliwiński wrote:
> >>[...]
> >>
> >>
> >> interface Interface
> >> {
> >> void method(Interface);
> >> }
> >> class Class : Interface
> >> {
> >> void method(Cla
Jonathan M Davis wrote:
> On Tuesday, August 30, 2011 08:57:53 Mariusz Gliwiński wrote:
>>[...]
>>
>> interface Interface
>> {
>> void method(Interface);
>> }
>> class Class : Interface
>> {
>> void method(Class) {}
>> }
>>
>> void main() {}
>>
>
> This particular example is not a bug. [...]
Y
On Tuesday, August 30, 2011 08:57:53 Mariusz Gliwiński wrote:
> I'm sorry - i provided wrong example. I had property in my code, and he
> didn't complained about getter, but setter (of course he can't diversify by
> different return values).
>
>
> interface Interface
> {
> void method(Inter
Jonathan M Davis wrote:
> This seems to compile just fine:
>
> interface Interface
> {
> Interface method();
> }
> class Class : Interface
> {
> Class method() {return new Class;}
> }
>
> The problem is the override keyword. _No_ overriding is going on. _That's_
> why it's complaining.
I'm sor
On Monday, August 29, 2011 15:18 Mariusz Gliwiński wrote:
> Jonathan M Davis wrote:
> > It's _not_ overriding. It's implementing [...]
>
> Whether it's called overriding or implementing isn't a big deal for me. In
> D we *already* write _override_ keyword to _implement_ method (IMO it's
> good cho
Jonathan M Davis wrote:
> It's _not_ overriding. It's implementing [...]
Whether it's called overriding or implementing isn't a big deal for me. In D
we *already* write _override_ keyword to _implement_ method (IMO it's good
choice, to match with overriding class methods).
But back to the topi
On Monday, August 29, 2011 14:09 Mariusz Gliwiński wrote:
>
> interface Interface {
> Interface method();
> }
> class Class : Interface {
> override Class method() {}
> }
>
>
> DMD complains it isn't overriding. How should it be according to
> specification, and how about making it legal?
It's
interface Interface {
Interface method();
}
class Class : Interface {
override Class method() {}
}
DMD complains it isn't overriding. How should it be according to
specification, and how about making it legal?
48 matches
Mail list logo