Option Strict and late binding problem

[Daniel Klein]

I think I've done my homework and checked around on Google Groups but this
seems to be a situation not yet covered.

Here is the scenario...

There are two classes, Foo and Bar (actually there are more than two
classes involved but two will suffice to explain the problem), and each
class has a Copy() method as follows:

Public Function Copy() As Object Implements ICloneable.Clon e
' returns a copy of a Foo object
End Function

Public Function Copy() As Object Implements ICloneable.Clon e
' returns a copy of a Bar object
End Function

I have another class that subclasses ArrayList. This class allows the list
to contain Foo and Bar objects.

With me so far? Here comes the kicker...

I then iterate over the ArrayList as follows making a copy of the array
list:

Dim objekt, objcopy As Object
For Each objekt In myArrayListInst ance
objcopy = objekt.Copy() ' Each objekt is either a Foo object or a Bar
object
' build another ArrayList with copies of all objects from the original
ArrayList
Next

With 'Option Strict On' this produces a compiler error.

How can I achieve this kind of polymorphism with 'Option Strict On' ?

Thanks for your consideration,

Daniel Klein
Cuyahoga Falls, OH

[Daniel Klein]

IClonaeable.Clo ne() will never work in this instance due the the 'extra
work' the Copy() methods have to do. However the ICopiable solution has
possibilities, I'll let you know. Thanks.

What I was 'knocking' was the if/then logic, not .NET. Apology accepted ;-)

Dan
On Tue, 01 Feb 2005 12:22:16 -0500, Samuel R. Neff
<bl****@newsgro up.nospam> wrote:

The IClonable.Clone () example shown earlier is exactly what you need,
but if you can't see how calling Clone() actually calls Copy() through
explicit interface implementation then you can create your own
interface and use it as follows

Interface ICopiable
Function Copy() As Object
End Interface

Class Foo
Implements ICopiable

Function Copy() Implements ICopiable.Copy
...
End Function
End Class

Class Bar
Implements ICopiable

Function Copy() Implements ICopiable.Copy
...
End Function
End Class

Sub Test()
Dim al As New ArrayList
al.Add(new Foo)
al.Add(new Bar)

For Each obj as ICopiable in al
Dim newObj = obj.Copy()
Next
End Sub

Of course since all the Copy methods you mentioned already implement
IClonable.Clon e, then calling Clone is the exact same thing, but if
using a custom ICopiable interface is somehow cleaner or more
understandable , then use that. But don't knock .NET's OOD techniques
when you don't understand how to use them.

Best regards,

Sam

Sorry, but no...at least not in this manner :-(

I thought the purpose of polymorphism was to eliminate cumbersome if/then
logic. Besides, there are more classes that implement the Copy() method,
which means the if/then logic would have to be modifed every time a new
class was created that implements the Copy() method. This goes against the
grain of OOD techniques.

I still maintain that late binding is the only solution to 'pure'
polymorphic behavior such as this.

Daniel Klein
Cuyahoga Falls, OH

[Samuel R. Neff]

The thing is, ICloneable.Clon e() and Copy() are the exact same method.
When you declare

Function Copy() As Object Implements ICloneable.Clon e

Then you can execute this method via

obj.Copy()

or

DirectCast(obj, ICloneable).Clo ne()

And it calls the exact same method. This is called explicit interface
implementation where you're implementing an interface method but
internally using a different method name. This way when the object is
declared as the type that defined it, "Clone" is not accessible, but
"Copy" is. But you can cast it to ICloneable and then "Clone" is
accessible. But no matter what you do, it calls the exact same code,
the contents of the function.

Sam
On Wed, 02 Feb 2005 15:13:18 GMT, Daniel Klein
<da***********@ hotmail.com> wrote:

IClonaeable.Cl one() will never work in this instance due the the 'extra
work' the Copy() methods have to do. However the ICopiable solution has
possibilitie s, I'll let you know. Thanks.

What I was 'knocking' was the if/then logic, not .NET. Apology accepted ;-)

Dan

[Daniel Klein]

Just to put some closure on this, the piece I was missing was to do:

For Each objekt As ICloneable In myArrayList

It was the 'As ICloneable' that was missing.

Thanks Samuel, I has been educational to say the least.

Daniel Klein
On Wed, 02 Feb 2005 10:21:51 -0500, Samuel R. Neff
<bl****@newsgro up.nospam> wrote:

The thing is, ICloneable.Clon e() and Copy() are the exact same method.
When you declare

Function Copy() As Object Implements ICloneable.Clon e

Then you can execute this method via

obj.Copy()

or

DirectCast(obj , ICloneable).Clo ne()

And it calls the exact same method. This is called explicit interface
implementati on where you're implementing an interface method but
internally using a different method name. This way when the object is
declared as the type that defined it, "Clone" is not accessible, but
"Copy" is. But you can cast it to ICloneable and then "Clone" is
accessible. But no matter what you do, it calls the exact same code,
the contents of the function.

Sam
On Wed, 02 Feb 2005 15:13:18 GMT, Daniel Klein
<da*********** @hotmail.com> wrote:

IClonaeable.C lone() will never work in this instance due the the 'extra
work' the Copy() methods have to do. However the ICopiable solution has
possibilities , I'll let you know. Thanks.

What I was 'knocking' was the if/then logic, not .NET. Apology accepted ;-)

Dan