|
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.
|
|
|
|
|
Excellent post.
Some people have illogical fear of multiple inheritence, they once read something bad will happen if you use it, they can't remember exactly what, but just give it a wide berth to be safe.
Really, there is one case where multiple inheritence causes problems (i.e. when you have a diamond shaped hierarchy). The solution is just to avoid using it in that specific case. Disabling the feature completely is throwing the baby out with the bathwater.
|
|
|
|
|
Its the perfect answer on "needs in multiple inheritance" question for all newbies PIEBALDconsult talked about
|
|
|
|
|
I said they sufficed. I did not say they were exactly the same thing.
|
|
|
|
|
Part of the reason is that .NET is multi-language and most OO languages don't provide MI. Not enabling it made MS's job easier. It wouldn't have been an impossible task to have it in, say, C# by itself though. The Eiffel guys have been able to support MI on .NET and still maintain language interoperability.
Having said that I think most would consider generics to be a more essential feature than MI.
Kevin
|
|
|
|
|
MI is useful, especially when you need to write code that would combine code from multiple sources.
Eiffel supports multiple inheritance using interface inheritance + composition because the .net runtime does not support MI. The only reason that MS or Sun did not include MI in their languages is that it is extremely difficult to implement a class loader that would support multiple base classes. All the other arguments against MI are artificial
|
|
|
|
|
... I would love default parameter value in a programming language.
P.S. Sorry C++
|
|
|
|
|
FYI: C++ has default parameter support, and they have to be at the end of the param list, just like optional parameters in VB.
I.e.
void Poo(int parm1 = 1, int parm2 = 42)
{
}
Usage:
Poo(); // parm1 will be 1, parm2 will be 42
Poo(29); // parm1 will be 29, parm2 will be 42
Poo(29, 33); // parm1 will be 29, parm2 will be 33
Maybe you were thinking C#, which I think doesn't have default parms?
- S
50 cups of coffee and you know it's on!
|
|
|
|
|
You can't have default parameters but you can achieve the same things in C#.
void Foo(int x, int y) {....}
void Foo(int x) { Foo(x, 5); }
void Foo() { Foo(9, ); }
|
|
|
|
|
Steve Echols wrote: C++ has default parameter support
Yes, I know that. My "Sorry C++" is meant to avoid offending those C++ guys who hate to be associated in any way with VB.
|
|
|
|
|
Why would anyone want that?
Let's say you have a function called IsUserLoggedOn which returns True or False. With the new feature, it will return { True, False, NotSure, WhateverAnswerYouWant } as the output, very helpful.
|
|
|
|
|
I think what they mean is support for something like C#'s out parameter. I always though it was better to return a single typed object with queryable properties. That way, if you need more return information, you modify the object, rather than the method signature. It, by definition, makes your code more object-oriented.
---------------------
Marshall Rosenstein
.NET Consultant
|
|
|
|