>>>>I'm not really following your logic on this. In .NET you could equally do:

>>>>object oObject = new cMyClass();

and, since you postulate later knowing what methods are available that implies that you know the actual class so what's wrong with something like:

int i = ((cMyClass)oObject).MyInt;

?
>>>
>>>Speaking hypothetically - my object may be one of a dozen of classes, sharing a few pieces of interface.
>>
>>You can't share pieces of an interface - you either implement it or you don't....
>
>Implementations, of course, vary from class to class, but the methods' names and parameters are the same, because that's how I do it. So take "share" as in "wear the same fashion", not "wear the same pants in shifts".
>
>> So I know that any of the candidate classes will have this particular method. They are, however, heirs of the same super-class - for example, I have a bunch of different controls, all of which have a .CastShadow() method, because I wrote one for each. Is there a way to tell dot net to allow using such a method without telling it "this will be one of the following thirteen classes"?
>>
>>Not sure what you're asking here. In a derived class the methods of the parent, assuming valid scope, are available by definition. If you are referring to dealing with a collection of classes derived from a common parent then sinply cast to that parent - or better, type the collection to the parent in the first place.....
>
>Dang, I wrote "They are, however, NOT heirs of the same super-class", but the message seems to lack the NOT... So, there's no common parent (other than a, say, generic Control class), and I have a checkbox, textbox, candybox, sandbox, editbox, mailbox and a boxbox which all have a .Shadow(tnHPix, tnVpix, tnRGB) method. What's cMyClass in that case? How do I tell a dot net compiler to expect one of them, or at least how do I get it to not throw a tantrum?
>
>>>My complaint about type-strict compilers is that they force me to do their job.
>>
>>They force you to provide enough information for them to do their job
>>OTOH one could argue that dynamic languages force *you* do the job of a strongly typed compiler ?
>
>One would lose the argument.

OK. Dynamic languages don't *force* you to check to type - but if you don't do so you haven't much protection against a run-time error.
The best you can do is make it non-fatal....

>I don't have to write twenty versions of the same method to accommodate all the variations in parameter types.

Writing twenty method signatures implies that all may be required. If you prefer having a single method that can handle all of those combinations then you have a *heck* of a lot of checking to make sense of the parameters that were received.
Having said that would you dream of writing a method that required twenty parameters? Unless maybe it was intended for COM I''d be wrapping them in a single manageable object.
IAC C#2010 has named parameters and default values so you could take the single signature approach if so inclined...

>There's not much of a job to reconcile the types, if we talk about the basic scalar types (I don't care what kind of number it is, for example, because conversion is automatic). If we talk about classes, well, my job is to use the interface I have, i.e. to know the method names, which parameters to pass etc - and I think it's not my job to worry if I'm using wrong size integer or wrong type of string.

So you have a method that takes twenty parameters and it's your job to remember the order and type of all of them?
Good luck. Speaking personally I've got better things to do with my time :-}

If I'm passing an object, a strict compiler may need to know too much about what I'm passing - for instance, look at General practice recursion class where the parameter is just about any contained control. Would such a beast compile under a dot net language? I don't really know if it has containership, though, but nevertheless, something that goes through a collection of various objects and does something (it still doesn't know what) to each object - can it do something like that without having to specify what classes the passed object may belong to?

I didn't look at the source on that link but from the description there doesn't appear to be anything involved that would not be easily implemented using .NET. If I get I chance I'll take a closer look.
But speaking in general if you are confronted with an unknown type in .NET then Reflection is capable of providing a lot more information about it's members than can GetPem() and PemStatus() in VFP