>>>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. I don't have to write twenty versions of the same method to accommodate all the variations in parameter types. 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. 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?