what is more practical?

[Magiaus]

I am converting a class I made in VB.Net to C#. The class exposes an overloaded set of fuctions that return 4+ types of data objects based on function parameters.

Since I am moving it over to C# I am thinking about creating a Object that implicitly converts between the 4+ objects instead of having a return type of object that then has to be cast or creating an overload for each object that the function can return.

I like the implicit conversion because it will save me some typing in the long run but I'm not sure which is really the most prcticial concept.

The Vb.Net version takes a param ReturnType and returns an object that will cast to the apropriate type. So my existing code is already geared towards returning an object and expectng the developer to cast the object to the correct type.

What do you guys think?

[wossname]

The VB way is not fully object orientated. Use the implicit method because it is! OOP is to make the developer's life easier, not necessarily about speed, but more about reliability.

[Magiaus]

I agree, although I was hoping CornedBee would say something since he is so good at pointing out thing I don't think of

[CornedBee]

I was on holiday

What happens if your implicit conversion should be to the wrong type though? I don't very much like multicast types.

What exactly is the purpose of this method?

[Magiaus]

Well, see that's actual what is holding back on it. I'm trying to find a good way to manipulate the data into all the types I want to support with out ever hitting the database again. I thought I would be able to use a dataadapter but I'm not so sure anymore.

The whole idea came to me because I kept writing the same 5 or so lines of code over and over to get diferent types of data,that was often the same or a subset of the same data, on a aspx page. Because I would bind a Control to a datatable and I would use a reader with the same data as menu text and so on, but I was hitting the db two to three times to get the same data. It may be that I just don't know everything I should about db in .net yet so it's in design and I'm researching.

I was originaly hoping to use a dataadapter to help in the implicit casting but i got side tracked and haven't looked close at the adpter yet.

The multicast to unsupported type I'm not sure about yet except I think most languages wouldn't let the code compile if it was an invalid type.

I think I'm going to go ahead with it though just to get a good understanding of operator overloading and the .net data model. I let you guys know what brick walls I slam into along the way.

[amac]

Couldn't you just overload the method and given it different out paramenters.

public void getObject(out OneObject object)

public void getObject(out TwoObject object);

public void getObject(out ThreeObject object);

Internally if the objects are somehow retrieved in the same manner you could have a private (internal???) method to retrieve it. This way you do not have to cast, you don't have to have an if statement to decide which method to call, you also do not need to use implicit conversion.

The bad thing with implicit conversion is that it can make debug a huge pain. If you are unaware of implicit conversions, you may be overlooking the problem and assuming that is right, because it should give me a compiler error if the types are wrong. Not that saying that you can't use it in your case; however, I think a general concept is to avoid them as much as you can. C++ actually offers a keyword to say what 1 parameter or less Constructors can't be used for implicit conversion.

Originally posted by wossname Use the implicit method because it is!

Implicit conversion isn't an OO principle. Implicit conversion exists in structural code too.

float aFloat = 1.13;
int anInt = aFloat;   // Implicit conversion.

Originally posted by wossnameOOP is to make the developer's life easier, not necessarily about speed, but more about reliability.

Ehh.... OOP helps improve code-reuseablilty and hide data/implementation from the "users", etc. So, I suppose if done well... things will be easier for developers and most definitely will be more reliable (as long as the objects you are using are reliable). Maybe a little too general of a statement? I don't think implicit conversions should be included.

[Magiaus]

yes I could but I want it to be grace full not clunky....
this is part of the xml documentation for the OleDBDataHandler. The whole point is to reduce the amount of effort needed to databind something and make as simplistic for the end user as possible

	/// For instance: 
	/// 
	/// [C#]
	/// -------------------------------------------------------------------------------------------
	/// OleDbDataHandler dh = new OleDbDataHandler("provider=;data source=;","SELECT * FROM tbl");
	/// OleDbReader r = dh;
	/// DataSet ds = dh;
	/// 
	/// Or
	/// 
	/// OleDbReader r = new OleDbDataHandler("provider=;data source=;","SELECT * FROM tbl");
	/// DataSet ds = new OleDbDataHandler("provider=;data source=;","SELECT * FROM tbl");
	/// 
	/// Or
	/// 
	/// OleDbDataHandler dh = new OleDbDataHandler("provider=;data source=;","SELECT * FROM tbl");
	/// OleDbReader r = dh.ToOleDbReader();
	/// DataSet ds = dh.ToDataSet();

unfortunatly there is no way that I can see to marshel the data between types without hitting the database, so that means if an idiot used this thing he could really put a hurting on the db