|
Didier Dobrovitch wrote: i am not sure this will be implemented in any "standard" language
Not sure what you consider a "standard" language, but at least Eiffel and D have it as a language feature.
|
|
|
|
|
Have you used D much? From time to time I go and visit the site to see what's new and each time I come away wishing I could use this on a professional basis. Am I the only one who thinks it's got some really fantastic, powerful and *practical* features?
¡El diablo está en mis pantalones! ¡Mire, mire!
Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
SELECT * FROM User WHERE Clue > 0
0 rows returned
Save an Orange - Use the VCF!
VCF Blog
|
|
|
|
|
Jim Crafton wrote: Have you used D much?
Not at all I learn a language either to get familiar with new concepts that would make me a better programmer (Erlang, Haskell,...) or to use them in my day-to-day job (VBA, C#, Javascript...) and D is simply "improved" C++ without any real life use.
|
|
|
|
|
Oops, I did not see there was a "DBC" reply
What I mean by a "standard" language is a language really used in companies
Are there many companies using Eiffel and D ?
|
|
|
|
|
Didier Dobrovitch wrote: Are there many companies using Eiffel
There are companies using Eiffel but not many. I don't know about D.
Kevin
|
|
|
|
|
Design By Contract would be great.
|
|
|
|
|
I agree. They already have it in Spec#. Will they roll it into C#?
Kevin
|
|
|
|
|
I do not know if Microsoft included some features of Spec# in the new C# 3.0 or in the VS2008.
And I think Spec# is not fully supported by Microsoft.
|
|
|
|
|
I don't think C# 3.0 has a single feature from Spec#. A pity.
Kevin
|
|
|
|
|
|
|
5n
Suresh
|
|
|
|
|
I don't understand them, but they seem like a good idea.
|
|
|
|
|
RAII[^] support is the very first thing I look for when evaluating a language. So far, C++ and PHP 5.2 are acceptable. Many other languages pay lip service but fall short.
|
|
|
|
|
If a base class has
public mybase ( int x ) { ... }
don't make derived classes require
public myderived ( int x ) : base ( x ) {}
when no specialization of the constructor is required.
|
|
|
|
|
I'm totally agree with you ... I always wonder why you should rewrite a constructor even if no specialization is required
Thumbs Up
|
|
|
|
|
PIEBALDconsult wrote: If a base class has
public mybase ( int x ) { ... }
don't make derived classes require
public myderived ( int x ) : base ( x ) {}
I'm confused. You can always write
public myderived () : base ( 5 ) {}
But, how else is the ctor for mybase supposed to know what to set for x?
In c++ you could use a default arg.
|
|
|
|
|
No, no, myderived should still have a constructor that takes one int, but I shouldn't have to write it.
It's probably only useful in limited situations, but here's an example;
System.Exception has four constructors, most notably System.Exception(System.String) and System.Exception(System.String,System.Exception)
If I want to write a custom Exception without actually adding any functionality I'd prefer to write
public class MyException : System.Exception {}
...
new MyException ( "Something went wrong" , innerexception ) ;
rather than
public class MyException : System.Exception
{
public MyException ( System.String Message ) : base ( Message ) {}
public MyException ( System.String Message , System.Exception InnerException ) : base ( Message , InnerException ) {}
}
...
new MyException ( "Something went wrong" , innerexception ) ;
}
Now consider having to write and maintain bunch of custom Exceptions and see how much better inheritable constructors would be:
public class MyException0 : System.Exception {}
public class MyException1 : System.Exception {}
public class MyException2 : System.Exception {}
public class MyException3 : System.Exception {}
public class MyException4 : System.Exception {}
public class MyException5 : System.Exception {}
public class MyException6 : System.Exception {}
public class MyException7 : System.Exception {}
public class MyException8 : System.Exception {}
public class MyException9 : System.Exception {}
|
|
|
|
|
This is one that the designers of C# and D took rather seriously, but in different ways.
|
|
|
|
|
It may be a source of trouble for newbies, but why punish the experts?
|
|
|
|
|
In c#, interfaces suffice.
|
|
|
|
|
|
sherifffruitfly wrote: In c#, interfaces suffice.
No they don't, because you have to implement the interface yourself in every derived class, instead of just inheriting the functionality of the base class.
- S
50 cups of coffee and you know it's on!
|
|
|
|
|
You can use composition to substitute for inheritance in 99% of cases and composition is preferred over inheritance. Why create a potentially more problematic solution using multiple inheritance when you could be using composition?
|
|
|
|
|
scoobydoo27 wrote: Why create a potentially more problematic solution using multiple inheritance when you could be using composition?
Here's why:[^]
People quite correctly say that you don't need multiple inheritance, because anything you can do with multiple inheritance you can also do with single inheritance. You just use the delegation trick I mentioned. Furthermore, you don't need any inheritance at all, because anything you do with single inheritance you can also do without inheritance by forwarding through a class. Actually, you don't need any classes either, because you can do it all with pointers and data structures. But why would you want to do that? When is it convenient to use the language facilities? When would you prefer a workaround? I've seen cases where multiple inheritance is useful, and I've even seen cases where quite complicated multiple inheritance is useful. Generally, I prefer to use the facilities offered by the language to doing workarounds.
|
|
|
|