Hello everyone!

I was today looking into the similarities/differences of Java and D. I experimented with the 'final' keyword. In Java, when used with class declaration, guarantees that one cannot subclass from a 'final' class. Now, I tried the similar approach in D, and to my surprise, noticed that with the code provided below, only the methods become final. This means that I can subclass a 'final' class in D with no problem. All I can't do is override the methods in that 'final' class. Is this desired behaviour, or is the something wrong with my snippet?

import std.stdio;

final class Kid
{
void a()
{
writefln("a() in Kid");
}

void b()
{
writefln("b() in Kid");
}
}

class Youngster : Kid
{
/*
void a()
{
// Uncommenting causes a compiler error.
}
*/

void c()
{
a();
}

void d()
{
b();
}
}

int main(char[][] argumentTable)
{
Kid k = new Kid();

k.a();
k.b();

Youngster g = new Youngster();

g.a();
g.b();
g.c();
g.d();

return 0;
}

Sounds useful to me. At work I code in C#, and I was a little irritated to find out that the StringBuilder class was marked 'sealed' (aka 'final'). All I wanted to do was extend it's functionality, I didn't want to override its methods. I don't see any reason why it shouldn't be possible, since the purpose of marking a class final is to prevent tampering with its implimentation. It may well be a bug though, since it is clear from your code that you don't want anyone to be able to subclass it, regardless of whether people find it irritating.

Chris

> Hello everyone!
> 
> I was today looking into the similarities/differences of Java and D. I
> experimented with the 'final' keyword. In Java, when used with class
> declaration, guarantees that one cannot subclass from a 'final' class.
> Now, I tried the similar approach in D, and to my surprise, noticed
> that with the code provided below, only the methods become final. This
> means that I can subclass a 'final' class in D with no problem. All I
> can't do is override the methods in that 'final' class. Is this
> desired behaviour, or is the something wrong with my snippet?
> 
> import std.stdio;
> 
> final class Kid
> {
> void a()
> {
> writefln("a() in Kid");
> }
> void b()
> {
> writefln("b() in Kid");
> }
> }
> class Youngster : Kid
> {
> /*
> void a()
> {
> // Uncommenting causes a compiler error.
> }
> */
> void c()
> {
> a();
> }
> void d()
> {
> b();
> }
> }
> int main(char[][] argumentTable)
> {
> Kid k = new Kid();
> k.a();
> k.b();
> Youngster g = new Youngster();
> 
> g.a();
> g.b();
> g.c();
> g.d();
> return 0;
> }

Also, 'final' I'm guessing would remove the need for methods to be virtual, thus potentially speeding up those methods, no?

-Kramer

In article <a8deea61394d8c7c7b84971d1f0@news.digitalmars.com>, Chris Lajoie says...
>
>Sounds useful to me. At work I code in C#, and I was a little irritated to find out that the StringBuilder class was marked 'sealed' (aka 'final'). All I wanted to do was extend it's functionality, I didn't want to override its methods. I don't see any reason why it shouldn't be possible, since the purpose of marking a class final is to prevent tampering with its implimentation. It may well be a bug though, since it is clear from your code that you don't want anyone to be able to subclass it, regardless of whether people find it irritating.
>
>Chris
>
>> Hello everyone!
>> 
>> I was today looking into the similarities/differences of Java and D. I experimented with the 'final' keyword. In Java, when used with class declaration, guarantees that one cannot subclass from a 'final' class. Now, I tried the similar approach in D, and to my surprise, noticed that with the code provided below, only the methods become final. This means that I can subclass a 'final' class in D with no problem. All I can't do is override the methods in that 'final' class. Is this desired behaviour, or is the something wrong with my snippet?
>> 
>> import std.stdio;
>> 
>> final class Kid
>> {
>> void a()
>> {
>> writefln("a() in Kid");
>> }
>> void b()
>> {
>> writefln("b() in Kid");
>> }
>> }
>> class Youngster : Kid
>> {
>> /*
>> void a()
>> {
>> // Uncommenting causes a compiler error.
>> }
>> */
>> void c()
>> {
>> a();
>> }
>> void d()
>> {
>> b();
>> }
>> }
>> int main(char[][] argumentTable)
>> {
>> Kid k = new Kid();
>> k.a();
>> k.b();
>> Youngster g = new Youngster();
>> 
>> g.a();
>> g.b();
>> g.c();
>> g.d();
>> return 0;
>> }
>
>

True. I was not complaining though ;) Just pointing out the function of the
'final' keyword. Actually I like it this way, because the behaviour found in
Java seems somewhat artificial to me. After all, inheritance from multiple
"physical" classes is not possible; you can have only one "physical" base class
in D, and C# and whatnot. Since abstract classes and interfaces provide certain
functionality needed for modern OOP, I'd give my votes for not even implementing
final classes the way Java does. All I want to do is protect my implementation
from tampering. In a certain way my implementation also "persists", because you
cannot override those methods.
To summarize, I can think of a few uses for this. Loud "NO" to Java-ish final
classes.

In article <a8deea61394d8c7c7b84971d1f0@news.digitalmars.com>, Chris Lajoie says...
>
>Sounds useful to me. At work I code in C#, and I was a little irritated to find out that the StringBuilder class was marked 'sealed' (aka 'final'). All I wanted to do was extend it's functionality, I didn't want to override its methods. I don't see any reason why it shouldn't be possible, since the purpose of marking a class final is to prevent tampering with its implimentation. It may well be a bug though, since it is clear from your code that you don't want anyone to be able to subclass it, regardless of whether people find it irritating.
>
>Chris
>
>> Hello everyone!
>> 
>> I was today looking into the similarities/differences of Java and D. I experimented with the 'final' keyword. In Java, when used with class declaration, guarantees that one cannot subclass from a 'final' class. Now, I tried the similar approach in D, and to my surprise, noticed that with the code provided below, only the methods become final. This means that I can subclass a 'final' class in D with no problem. All I can't do is override the methods in that 'final' class. Is this desired behaviour, or is the something wrong with my snippet?
>> 
>> import std.stdio;
>> 
>> final class Kid
>> {
>> void a()
>> {
>> writefln("a() in Kid");
>> }
>> void b()
>> {
>> writefln("b() in Kid");
>> }
>> }
>> class Youngster : Kid
>> {
>> /*
>> void a()
>> {
>> // Uncommenting causes a compiler error.
>> }
>> */
>> void c()
>> {
>> a();
>> }
>> void d()
>> {
>> b();
>> }
>> }
>> int main(char[][] argumentTable)
>> {
>> Kid k = new Kid();
>> k.a();
>> k.b();
>> Youngster g = new Youngster();
>> 
>> g.a();
>> g.b();
>> g.c();
>> g.d();
>> return 0;
>> }
>
>

In article <dn29eo$26d2$1@digitaldaemon.com>, Kramer says...
>
>Also, 'final' I'm guessing would remove the need for methods to be virtual, thus potentially speeding up those methods, no?
>
>-Kramer

Well, it says in the D spec that there is no virtual table. Or that's what it says at: http://www.digitalmars.com/d/module.html

In article <dn29he$26jp$1@digitaldaemon.com>, AjO says...
>All I want to do is protect my implementation
>from tampering. In a certain way my implementation also "persists", because you
>cannot override those methods.
>To summarize, I can think of a few uses for this. Loud "NO" to Java-ish final
>classes.

You CAN access private members (methods and data) that way.
I wouldn't call this "protection of implementation". Perhaps the
Java way is better in this respect, no?

Best regards,
Stefan

In article <dn2ar9$2887$1@digitaldaemon.com>, Stefan Zobel says...
>
>In article <dn29he$26jp$1@digitaldaemon.com>, AjO says...
>>All I want to do is protect my implementation
>>from tampering. In a certain way my implementation also "persists", because you
>>cannot override those methods.
>>To summarize, I can think of a few uses for this. Loud "NO" to Java-ish final
>>classes.
>
>You CAN access private members (methods and data) that way.
>I wouldn't call this "protection of implementation". Perhaps the
>Java way is better in this respect, no?

Tough, this actually has nothing to do with the "final" keyword.

Stefan

>You CAN access private members (methods and data) that way.
>I wouldn't call this "protection of implementation". Perhaps the
>Java way is better in this respect, no?
>
>Best regards,
>Stefan

Thanks for reminding me Stefan :) There are indeed some issues to consider in
this approach. I have to admit that the Java way is slightly better in the
respect you mentioned. Still, do remember that you can always 'final' your data
as well. But this is rather strange considering that I'm just trying to protect
my implementation. If you take a look at my code snippet, it's just a normal
inheritance where the usual measures must be taken to govern the access to the
data.
Yet, if there was such a thing as final classes in D, we could circumvent the
usual problems by using composition instead of inheritance. However, I still
maintain my opinion that the way things work now are just fine.

In article <dn2aqq$287q$1@digitaldaemon.com>, AjO says...
>
>In article <dn29eo$26d2$1@digitaldaemon.com>, Kramer says...
>>
>>Also, 'final' I'm guessing would remove the need for methods to be virtual, thus potentially speeding up those methods, no?
>>
>>-Kramer
>
>Well, it says in the D spec that there is no virtual table. Or that's what it says at: http://www.digitalmars.com/d/module.html
>
>

I was thinking of it in regards to class methods since I thought I saw somewhere in the docs that by default, they would be virtual.  Although I can't find it at the moment... argh... :<

-Kramer

In article <dn2ar9$2887$1@digitaldaemon.com>, Stefan Zobel says...
>
>In article <dn29he$26jp$1@digitaldaemon.com>, AjO says...
>>All I want to do is protect my implementation
>>from tampering. In a certain way my implementation also "persists", because you
>>cannot override those methods.
>>To summarize, I can think of a few uses for this. Loud "NO" to Java-ish final
>>classes.
>
>You CAN access private members (methods and data) that way.
>I wouldn't call this "protection of implementation". Perhaps the
>Java way is better in this respect, no?

Stupid me! That's only if they are in the same file, of course. I should think before writing ...

Sorry,
Stefan