Caller Type ?

[Genival]

Hello all...
First sorry my bad English.
Look next code

Dim oDS as Dataset ' <= Caller
oDs = MyFunc

'other caller type
Dim i as integer = MyFunc

public MyFunc(....) as object

Question : How do to detect caller type inside a method ?
Because i need return value casted.

if ??? is GetType(DataSet ) then
return CType(ret as DataSet)
else if
bla bla bla...
End Func

Regards
Genival Carvalho

[Mattias Sjögren]

>Question : How do to detect caller type inside a method ?

The short answer is that you can't.

You could use overloaded functions and a ByRef parameter to return the
result instead.

Sub MyFunc(ByRef ds As Dataset)
Sub MyFunc(ByRef i As Integer)

....

Dim oDS As Dataset
MyFunc(oDS)

Or you could follow the pattern used by some framework classes, and
use separate methods for each possible return type

Function MyFuncDataset() As Dataset
Function MyFuncInt32() As Dataset

Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/
Please reply only to the newsgroup.

[Armin Zingler]

"Genival" <ge*****@hotmai l.com> schrieb

Hello all...
First sorry my bad English.
Look next code

Dim oDS as Dataset ' <= Caller
oDs = MyFunc

'other caller type
Dim i as integer = MyFunc

public MyFunc(....) as object

Question : How do to detect caller type inside a method ?
Because i need return value casted.

if ??? is GetType(DataSet ) then
return CType(ret as DataSet)
else if
bla bla bla...
End Func

You should not care about the caller. Write two functions. One function
returns one type, the other function returns a different type.
--
Armin

[Genival]

But...
Inside ConvertTo i have this :
InstanceDescrip tor
I can't use this feature inside my func ?

Regards
Genival Carvalho

"Genival" <ge*****@hotmai l.com> escreveu na mensagem
news:es******** *****@TK2MSFTNG P09.phx.gbl...

Hello all...
First sorry my bad English.
Look next code

Dim oDS as Dataset ' <= Caller
oDs = MyFunc

'other caller type
Dim i as integer = MyFunc

public MyFunc(....) as object

Question : How do to detect caller type inside a method ?
Because i need return value casted.

if ??? is GetType(DataSet ) then
return CType(ret as DataSet)
else if
bla bla bla...
End Func

Regards
Genival Carvalho

[Fergus Cooney]

Hi Genival,

|| Inside ConvertTo i have this :
|| InstanceDescrip tor

There's no way for us to know what you are doing with so little information. It would be better if you gave us a fuller example.
Having said that, I'll try and explain a few things.

|| Dim oDS as Dataset ' <= Caller
|| oDs = MyFunc
||
|| 'other caller type
|| Dim i as integer = MyFunc
||
|| public MyFunc(....) as object
||
|| Question : How do to detect caller type inside a method ?
|| Because i need return value casted.

There is <no way> that a function can know <anything> about its caller unless it is <told>. So while MyFunc() above could be
called, as you show, with a DatSet or an Integer, etc, it <doesn't know>.

One way round this is to add an extra parameter to MyFunc():
Public Function MyFunc (..., oCaller As Object) As Object

You would use it like so:
oDs = MyFunc (..., oDs)
Dim i as integer = MyFunc (..., i)

Then, inside MyFunc(), you would be able to test the type of this last parameter.

Public Function MyFunc (..., oCaller As Object) As Object
If TypeOf oCaller Is DataSet Then
Return <some DataSet value>
If TypeOf oCaller Is Integer Then

Return <some Integer value>

That's how you <could> do it.

=============== =============== ===
But in VB.NET that is very bad programming!!
There are much better ways to achieve the same effect.

=============== =============== ===
One approach is to do what Armin and Mattias suggested:

Public Function MyFuncForDataSe ts (...) As DataSet
Return <some DataSet value>

Public Function MyFuncForIntege rs (...) As Integer
Return <some Integer value>

You'd then call them like this:

oDS = MyFuncForDataSe ts (...)
i = MyFuncForIntege rs (...)

=============== =============== ===
Another is to use Mattias' first suggestion:

Public Sub MyFunc(ByRef ds As Dataset, ...)

ds = <some DataSet value>

Public Sub MyFunc(ByRef i As Integer, ...)

i = <some Integer value>

Notice that this time they are Subs, not Functions.
You'd call them like this:

MyFunc (oDS, ...) 'This would call the DataSet version
MyFunc (i, ...) 'This would call the Integer version.

This uses something called "overloadin g" which allows you to use the same function name for different values. The compiler sorts
out which of the several versions of the same function it should use, depending on the type of the value.

=============== =============== ===
However, as you've come back with a new query, I'm wondering whether you didn't understand the previous answers to your question
or whether they simply don't work for you??

For that you must tell us more about what you are doing.

Regards,
Fergus

[Stephany Young]

Why is passing a 'caller' object as a parameter to a procedure and testing
it's type within the procedure 'very bad programming' in VB.Net.?

It is exactly how event handlers are constructed with the sender As
System.Object parameter.

"Fergus Cooney" <fi******@tesco .net> wrote in message
news:ej******** ******@TK2MSFTN GP10.phx.gbl...

Hi Genival,

|| Inside ConvertTo i have this :
|| InstanceDescrip tor

There's no way for us to know what you are doing with so little information. It would be better if you gave us a fuller example.

Having said that, I'll try and explain a few things.

|| Dim oDS as Dataset ' <= Caller
|| oDs = MyFunc
||
|| 'other caller type
|| Dim i as integer = MyFunc
||
|| public MyFunc(....) as object
||
|| Question : How do to detect caller type inside a method ?
|| Because i need return value casted.

There is <no way> that a function can know <anything> about its caller unless it is <told>. So while MyFunc() above could be called, as you show, with a DatSet or an Integer, etc, it <doesn't know>.

One way round this is to add an extra parameter to MyFunc():
Public Function MyFunc (..., oCaller As Object) As Object

You would use it like so:
oDs = MyFunc (..., oDs)
Dim i as integer = MyFunc (..., i)

Then, inside MyFunc(), you would be able to test the type of this last parameter.
Public Function MyFunc (..., oCaller As Object) As Object
If TypeOf oCaller Is DataSet Then
Return <some DataSet value>
If TypeOf oCaller Is Integer Then

Return <some Integer value>

That's how you <could> do it.

=============== =============== ===
But in VB.NET that is very bad programming!!
There are much better ways to achieve the same effect.

=============== =============== ===
One approach is to do what Armin and Mattias suggested:

Public Function MyFuncForDataSe ts (...) As DataSet
Return <some DataSet value>

Public Function MyFuncForIntege rs (...) As Integer
Return <some Integer value>

You'd then call them like this:

oDS = MyFuncForDataSe ts (...)
i = MyFuncForIntege rs (...)

=============== =============== ===
Another is to use Mattias' first suggestion:

Public Sub MyFunc(ByRef ds As Dataset, ...)

ds = <some DataSet value>

Public Sub MyFunc(ByRef i As Integer, ...)

i = <some Integer value>

Notice that this time they are Subs, not Functions.
You'd call them like this:

MyFunc (oDS, ...) 'This would call the DataSet version
MyFunc (i, ...) 'This would call the Integer version.

This uses something called "overloadin g" which allows you to use the same function name for different values. The compiler sorts out which of the several versions of the same function it should use, depending on the type of the value.
=============== =============== ===
However, as you've come back with a new query, I'm wondering whether you didn't understand the previous answers to your question or whether they simply don't work for you??

For that you must tell us more about what you are doing.

Regards,
Fergus

[Richard Brown]

Not quite correct, events do not have different return types, which is what
the original poster is asking for.
They want to have a different return type depending on what the result of
the function 'will' be assigned to.

Notice I said 'will'.... I'm sure if someone wanted to break out the
assembler, the function is being interpreted as an expression, then the
result of that expression is being assigned to the variable. There is a
distinct boundary there where the function will NOT know what object
variable its return value 'will' be assigned to.

The only way to do this, that I can tell, is to specific a parameter to the
function saying which return type to use. I just read somewhere that VB.NET
does NOT allow overloading functions based solely on return types, however
C# and C++ does.

Now, if the original poster wanted to format their function 'like' an event,
then it would be something along MyFunc(resultva r as Object) and the
resultvar object could be queried to determine the type to assign to it,
however, I am not quite sure of the exact formatting of that to allow you to
modify the variable itself. I think it is different in VB.NET now than it
was in VB6.

"Stephany Young" <st******@sysof t.co.nz> wrote in message
news:%2******** ********@TK2MSF TNGP10.phx.gbl. ..

Why is passing a 'caller' object as a parameter to a procedure and testing
it's type within the procedure 'very bad programming' in VB.Net.?

It is exactly how event handlers are constructed with the sender As
System.Object parameter.

"Fergus Cooney" <fi******@tesco .net> wrote in message
news:ej******** ******@TK2MSFTN GP10.phx.gbl...

Hi Genival,

|| Inside ConvertTo i have this :
|| InstanceDescrip tor

There's no way for us to know what you are doing with so little information. It would be better if you gave us a fuller example.

Having said that, I'll try and explain a few things.

|| Dim oDS as Dataset ' <= Caller
|| oDs = MyFunc
||
|| 'other caller type
|| Dim i as integer = MyFunc
||
|| public MyFunc(....) as object
||
|| Question : How do to detect caller type inside a method ?
|| Because i need return value casted.

There is <no way> that a function can know <anything> about its caller unless it is <told>. So while MyFunc() above could be

called, as you show, with a DatSet or an Integer, etc, it <doesn't

know>.
One way round this is to add an extra parameter to MyFunc():
Public Function MyFunc (..., oCaller As Object) As Object

You would use it like so:
oDs = MyFunc (..., oDs)
Dim i as integer = MyFunc (..., i)

Then, inside MyFunc(), you would be able to test the type of this

last parameter.

Public Function MyFunc (..., oCaller As Object) As Object
If TypeOf oCaller Is DataSet Then
Return <some DataSet value>
If TypeOf oCaller Is Integer Then

Return <some Integer value>

That's how you <could> do it.

=============== =============== ===
But in VB.NET that is very bad programming!!
There are much better ways to achieve the same effect.

=============== =============== ===
One approach is to do what Armin and Mattias suggested:

Public Function MyFuncForDataSe ts (...) As DataSet
Return <some DataSet value>

Public Function MyFuncForIntege rs (...) As Integer
Return <some Integer value>

You'd then call them like this:

oDS = MyFuncForDataSe ts (...)
i = MyFuncForIntege rs (...)

=============== =============== ===
Another is to use Mattias' first suggestion:

Public Sub MyFunc(ByRef ds As Dataset, ...)

ds = <some DataSet value>

Public Sub MyFunc(ByRef i As Integer, ...)

i = <some Integer value>

Notice that this time they are Subs, not Functions.
You'd call them like this:

MyFunc (oDS, ...) 'This would call the DataSet version
MyFunc (i, ...) 'This would call the Integer version.

This uses something called "overloadin g" which allows you to use the

same function name for different values. The compiler sorts

out which of the several versions of the same function it should use,

depending on the type of the value.

=============== =============== ===
However, as you've come back with a new query, I'm wondering whether

you didn't understand the previous answers to your question

or whether they simply don't work for you??

For that you must tell us more about what you are doing.

Regards,
Fergus

[Fergus Cooney]

Hi Stephany,

Fergus wrote:
|| > Public Function MyFunc (..., oCaller As Object) As Object
|| >
|| > But in VB.NET that is very bad programming!!
|| > There are much better ways to achieve the same effect.

General life principle:
When there are better ways to achieve a given effect, choosing a non-better way is bad, maybe even 'very bad'.

In this case, the purpose of oCaller is solely to say what type of variable is on the receiving end of an assignment using
MyFunc(). If you read Genival's question and the answers again, and decide what solution <you> would implement, I'd be surprised if
you end up with a MyFunc like the one above.

Stephany wrote:
|| Why is passing a 'caller' object as a parameter to a procedure, and
|| testing it's type within the procedure, 'very bad programming' in VB.Net.?

My statement was referring to the code above it and was not a comment about passing Objects in general. However...

I don't think passing in Objects is good practice if it means that there must be code to work out whether it's a valid object
and what to do in each case, etc. It's fine if your method works polymorphically , although I think the object type should be as
restrictive as possible, ie using the highest possible base class or an interface.

|| It is exactly how event handlers are constructed with the
|| sender As System.Object parameter

I'd love to have event handlers that had specific types. [Not to mention a decent name. "sender" has never grabbed me as
particularly useful.] An event handler, eg KeyPress, must cater for any object that could possibly expect a key press. Plenty of
these objects have yet to be invented. Therefore the KeyPress Event Handler has to have an Object as its parameter.

If you know in advance what types a method of yours is going to have to cater for, you are in the position of using VB.NET to
its fullest and choosing one of the 'better ways'.

If overloads, virtual methods or specialised methods can be used instead of passing Objects around, then more of the the
type-checking can be left to the compiler.

Regards,
Fergus

[Stephany Young]

But ... but ... but ...

The original poster is looking for:

public MyFunc(....) as object

Which means that he is NOT interested in the type of the return value at the
point at which it is returned.

"Richard Brown" <rb****@easylif t.org> wrote in message
news:%2******** ********@TK2MSF TNGP10.phx.gbl. ..

Not quite correct, events do not have different return types, which is what the original poster is asking for.
They want to have a different return type depending on what the result of
the function 'will' be assigned to.

Notice I said 'will'.... I'm sure if someone wanted to break out the
assembler, the function is being interpreted as an expression, then the
result of that expression is being assigned to the variable. There is a
distinct boundary there where the function will NOT know what object
variable its return value 'will' be assigned to.

The only way to do this, that I can tell, is to specific a parameter to the function saying which return type to use. I just read somewhere that VB.NET does NOT allow overloading functions based solely on return types, however
C# and C++ does.

Now, if the original poster wanted to format their function 'like' an event, then it would be something along MyFunc(resultva r as Object) and the
resultvar object could be queried to determine the type to assign to it,
however, I am not quite sure of the exact formatting of that to allow you to modify the variable itself. I think it is different in VB.NET now than it
was in VB6.

"Stephany Young" <st******@sysof t.co.nz> wrote in message
news:%2******** ********@TK2MSF TNGP10.phx.gbl. ..

Why is passing a 'caller' object as a parameter to a procedure and testing

it's type within the procedure 'very bad programming' in VB.Net.?

It is exactly how event handlers are constructed with the sender As
System.Object parameter.

"Fergus Cooney" <fi******@tesco .net> wrote in message
news:ej******** ******@TK2MSFTN GP10.phx.gbl...

Hi Genival,

|| Inside ConvertTo i have this :
|| InstanceDescrip tor

There's no way for us to know what you are doing with so little

information. It would be better if you gave us a fuller example.

Having said that, I'll try and explain a few things.

|| Dim oDS as Dataset ' <= Caller
|| oDs = MyFunc
||
|| 'other caller type
|| Dim i as integer = MyFunc
||
|| public MyFunc(....) as object
||
|| Question : How do to detect caller type inside a method ?
|| Because i need return value casted.

There is <no way> that a function can know <anything> about its caller

unless it is <told>. So while MyFunc() above could be

called, as you show, with a DatSet or an Integer, etc, it <doesn't

know>.
One way round this is to add an extra parameter to MyFunc():
Public Function MyFunc (..., oCaller As Object) As Object

You would use it like so:
oDs = MyFunc (..., oDs)
Dim i as integer = MyFunc (..., i)

Then, inside MyFunc(), you would be able to test the type of this

last

parameter.

Public Function MyFunc (..., oCaller As Object) As Object
If TypeOf oCaller Is DataSet Then
Return <some DataSet value>
If TypeOf oCaller Is Integer Then

Return <some Integer value>

That's how you <could> do it.

=============== =============== ===
But in VB.NET that is very bad programming!!
There are much better ways to achieve the same effect.

=============== =============== ===
One approach is to do what Armin and Mattias suggested:

Public Function MyFuncForDataSe ts (...) As DataSet
Return <some DataSet value>

Public Function MyFuncForIntege rs (...) As Integer
Return <some Integer value>

You'd then call them like this:

oDS = MyFuncForDataSe ts (...)
i = MyFuncForIntege rs (...)

=============== =============== ===
Another is to use Mattias' first suggestion:

Public Sub MyFunc(ByRef ds As Dataset, ...)

ds = <some DataSet value>

Public Sub MyFunc(ByRef i As Integer, ...)

i = <some Integer value>

Notice that this time they are Subs, not Functions.
You'd call them like this:

MyFunc (oDS, ...) 'This would call the DataSet version
MyFunc (i, ...) 'This would call the Integer version.

This uses something called "overloadin g" which allows you to use

the same function name for different values. The compiler sorts

out which of the several versions of the same function it should use,

depending on the type of the value.

=============== =============== ===
However, as you've come back with a new query, I'm wondering

whether you didn't understand the previous answers to your question

or whether they simply don't work for you??

For that you must tell us more about what you are doing.

Regards,
Fergus

[Stephany Young]

I agree in principle with what you are saying. I was really commenting on
what appeared to be pretty broad-brush.

In my opinion it really comes down to a matter of trade-offs, which, of
course, is another general life principle.

If one has a single encapsulated function a'la:

Public MyFunc(oCaller As Object) As Object
Select Case oCaller.GetType .Name
Case "abc"
Return whatever
Case else
Return whateverelse
End Select
End Function

as opposed to a number of overloaded functions to handle all known object
types and one comes up with a new object type then I know which approach I
would rather maintain.

I believe it is more a case of 'what works for you' rather than aiming for
'acedemic correctness'.
"Fergus Cooney" <fi******@tesco .net> wrote in message
news:%2******** *******@TK2MSFT NGP11.phx.gbl.. .

Hi Stephany,

Fergus wrote:
|| > Public Function MyFunc (..., oCaller As Object) As Object
|| >
|| > But in VB.NET that is very bad programming!!
|| > There are much better ways to achieve the same effect.

General life principle:
When there are better ways to achieve a given effect, choosing a non-better way is bad, maybe even 'very bad'.
In this case, the purpose of oCaller is solely to say what type of variable is on the receiving end of an assignment using MyFunc(). If you read Genival's question and the answers again, and decide what solution <you> would implement, I'd be surprised if you end up with a MyFunc like the one above.

Stephany wrote:
|| Why is passing a 'caller' object as a parameter to a procedure, and
|| testing it's type within the procedure, 'very bad programming' in VB.Net.?
My statement was referring to the code above it and was not a comment about passing Objects in general. However...
I don't think passing in Objects is good practice if it means that there must be code to work out whether it's a valid object and what to do in each case, etc. It's fine if your method works polymorphically , although I think the object type should be as restrictive as possible, ie using the highest possible base class or an interface.
|| It is exactly how event handlers are constructed with the
|| sender As System.Object parameter

I'd love to have event handlers that had specific types. [Not to mention a decent name. "sender" has never grabbed me as particularly useful.] An event handler, eg KeyPress, must cater for any object that could possibly expect a key press. Plenty of these objects have yet to be invented. Therefore the KeyPress Event Handler has to have an Object as its parameter.
If you know in advance what types a method of yours is going to have to cater for, you are in the position of using VB.NET to its fullest and choosing one of the 'better ways'.

If overloads, virtual methods or specialised methods can be used instead of passing Objects around, then more of the the type-checking can be left to the compiler.

Regards,
Fergus