At 03:04 AM 4/20/2004, Marek Malowidzki wrote (in part)
>I believe that it happens quite often in varions object libraries that
>although they are based on interfaces or even sometimes on classes, they in
>fact only operate on objects created earlier by the library.
The genuis(es) who designed .N
hough they are based on interfaces or even sometimes on classes, they in
fact only operate on objects created earlier by the library.
Marek
> -Original Message-
> From: Marek Malowidzki [mailto:[EMAIL PROTECTED]
> Sent: 16 April 2004 08:50
> To: [EMAIL PROTECTED]
> Subje
ds not declared
in ISomeIf but no-one else will ever have visibility to what those methods
are.
-Original Message-
From: Marek Malowidzki [mailto:[EMAIL PROTECTED]
Sent: 16 April 2004 08:50
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Public abstract classes with internal
abstr
> Might be missing the point here, but why would you ever want to provide an
> interface for an assembly's client that assures its implementation will be
> of a given type?
To avoid casting errors in some cases.
Imagine you have an interface called ISomeIf. Then you have a type Type
(either interf
Might be missing the point here, but why would you ever want to provide an
interface for an assembly's client that assures its implementation will be
of a given type?
When I go to the trouble of writing a factory that returns references to a
public interface implemented in an internal class then
