473,472 Members | 2,184 Online
Bytes | Software Development & Data Engineering Community
Create Post

Home Posts Topics Members FAQ

Language Proposal (Strong Interfaces)

Often you don't wish that clientcode does not depend on a certain
implementation of your methods:

class MyClass
{
public IList DoIt(){return new ArrayList();}
}

clientcode could now cast the return value in Arraylist. In a later version
you may find it more effective that your method returns an Array. This
change would break client code.

another example:

you want a list returned as readonly and, since wrappers are slow you simply
cast it to a interface that doesn't provide any modification methods.

IReadonlyList
{
public object this { get; }
}

INormalList : IReadonlyList
{
public object this { get; set;}
}

but now the problem is that the client could simply cast it back to a normal
list and modify it.

Now my proposal.

A modifier that, applied to a variable declaration or interface definition
forbids upcasting.
The result is an so called "strong interface" that cannot be upcasted no
matter what type the object is.

so that:

IReadonlyList r;
INormalList n = (INormalList)r;

will be caught by the compiler.
whereas

IReadonlyList r;
object o = r;
INormalList n = (INormalList)o;

cannot be detected at runtime, it has to throw an exception.

What do you think about this idea?

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
Nov 15 '05 #1
8 1406
codymanix <do*********************@gmx.de> wrote:
Often you don't wish that clientcode does not depend on a certain
implementation of your methods:
<snip>
What do you think about this idea?


Well, it sounds (with your example) as though you're basically
advocating const-correctness, but in a different way - and one which
violates Liskov's Substitutability Principle.

I believe it's tackling a valid problem, but in an inappropriate way.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #2
"codymanix" <do*********************@gmx.de> wrote in message
news:uA**************@tk2msftngp13.phx.gbl...
Often you don't wish that clientcode does not depend on a certain
implementation of your methods:

class MyClass
{
public IList DoIt(){return new ArrayList();}
}

clientcode could now cast the return value in Arraylist. In a later version you may find it more effective that your method returns an Array. This
change would break client code.


This whole perception is wrong. You are basically saying "Type safety is
inflexible, we should toss around pointers and have the client decide what
type/interface to slap onto it. Far more convenient"

Then you go

"There is a problem with this though, it's not type safe. So let's disable
casting to fix that.".
If I cast a null to string and attempt to assign a value to it "my code will
break" (your words). I do not consider that a problem.

Designing any interface for casting is bad. Casting is something you do to
cut corners when things cannot possibly go wrong and all is determined. Your
example makes no sense whatsoever, if a method explicitely returns
ArrayList, casting it back to IList is as bad as returning a pointer. A
client receiving a (base) type can not nor should make any assumptions as to
the received type being anything more than that base type.

You may want to read about template classes, that may be the answer to your
problem.

Martin.
Nov 15 '05 #3

"Martin Maat [EBL]" <du***@somewhere.nl> wrote in message
news:10*************@corp.supernews.com...
"codymanix" <do*********************@gmx.de> wrote in message
news:uA**************@tk2msftngp13.phx.gbl...

<snip>
Your
example makes no sense whatsoever, if a method explicitly returns
ArrayList, casting it back to IList is as bad as returning a pointer.

Casting ArrayList to IList is a not necessary since it's an implicit
conversion and quite safe and appropriate. Perhaps you meant that if a
method signatures declares it to return an IList and the actual
implementation returns an ArrayList, upcasting the IList to ArrayList would
be a very bad idea since you are not using the exposed interface and the
internal implementation may change in the future.

/Magnus Lidbom

Nov 15 '05 #4

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
codymanix <do*********************@gmx.de> wrote:
Often you don't wish that clientcode does not depend on a certain
implementation of your methods:
<snip>
What do you think about this idea?


Well, it sounds (with your example) as though you're basically
advocating const-correctness, but in a different way - and one which
violates Liskov's Substitutability Principle.

I don't see it. How does his examples violate LSP? Implementations of
non-modifiable collections where the non-modifiable version inherits the
modifiable version most certainly does, but his examples deal only with
interfaces, and those he derives in the proper order.
I believe it's tackling a valid problem, but in an inappropriate way.

Agreed, but for other reasons:
http://groups.google.com/groups?q=g:...lin.de&rnum=38
/Magnus Lidbom


Nov 15 '05 #5

"Magnus Lidbom" <ma***********@hotmail.com> wrote in message
news:bv************@ID-204195.news.uni-berlin.de...

"Martin Maat [EBL]" <du***@somewhere.nl> wrote in message
news:10*************@corp.supernews.com...
"codymanix" <do*********************@gmx.de> wrote in message
news:uA**************@tk2msftngp13.phx.gbl...

<snip>
Your
example makes no sense whatsoever, if a method explicitly returns
ArrayList, casting it back to IList is as bad as returning a pointer.

Casting ArrayList to IList is a not necessary since it's an implicit
conversion and quite safe and appropriate. Perhaps you meant that if a
method signatures declares it to return an IList and the actual
implementation returns an ArrayList, upcasting the IList to ArrayList

would be a very bad idea since you are not using the exposed interface and the
internal implementation may change in the future.


Just to nitpick a bit: casting from a type to a more specific subtype is
actually called downcasting (at least in C++, don't know if C# parlance has
this reversed for some reason?). Upcasting goes from a subtype to a base
class, and the compiler can do this implicitly. I.e., casting an IList to an
ArrayList is a downcast.
Nov 15 '05 #6

"Sami Vaaraniemi" <sa***************@jippii.fi> wrote in message
news:bv**********@phys-news1.kolumbus.fi...

"Magnus Lidbom" <ma***********@hotmail.com> wrote in message
news:bv************@ID-204195.news.uni-berlin.de...

"Martin Maat [EBL]" <du***@somewhere.nl> wrote in message
news:10*************@corp.supernews.com...
"codymanix" <do*********************@gmx.de> wrote in message
news:uA**************@tk2msftngp13.phx.gbl...

<snip>
Your
example makes no sense whatsoever, if a method explicitly returns
ArrayList, casting it back to IList is as bad as returning a pointer.

Casting ArrayList to IList is a not necessary since it's an implicit
conversion and quite safe and appropriate. Perhaps you meant that if a
method signatures declares it to return an IList and the actual
implementation returns an ArrayList, upcasting the IList to ArrayList

would
be a very bad idea since you are not using the exposed interface and the
internal implementation may change in the future.


Just to nitpick a bit: casting from a type to a more specific subtype is
actually called downcasting (at least in C++, don't know if C# parlance

has this reversed for some reason?).


Mea culpa.

/Magnus Lidbom

Nov 15 '05 #7
Magnus Lidbom <ma***********@hotmail.com> wrote:
I don't see it. How does his examples violate LSP? Implementations of
non-modifiable collections where the non-modifiable version inherits the
modifiable version most certainly does, but his examples deal only with
interfaces, and those he derives in the proper order.


You're right - oops :)
I believe it's tackling a valid problem, but in an inappropriate way.

Agreed, but for other reasons:


<snip>

Sure.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #8
> > Often you don't wish that clientcode does not depend on a certain
implementation of your methods:

class MyClass
{
public IList DoIt(){return new ArrayList();}
}

clientcode could now cast the return value in Arraylist. In a later version
you may find it more effective that your method returns an Array. This
change would break client code.


This whole perception is wrong. You are basically saying "Type safety is
inflexible, we should toss around pointers and have the client decide what
type/interface to slap onto it. Far more convenient"


Huh? Since when does the client determine the type/interface?
Then you go

"There is a problem with this though, it's not type safe. So let's disable
casting to fix that.".
If I cast a null to string and attempt to assign a value to it "my code will break" (your words). I do not consider that a problem.

Designing any interface for casting is bad. Casting is something you do to
cut corners when things cannot possibly go wrong and all is determined. Your example makes no sense whatsoever, if a method explicitely returns
ArrayList, casting it back to IList is as bad as returning a pointer. A
client receiving a (base) type can not nor should make any assumptions as to the received type being anything more than that base type.

You may want to read about template classes, that may be the answer to your problem.

You did not fully understand my proposal. How could template classes help
here?
I *wish* to hide the implementation from the client so I return a generic
list but I *don't*
want that the client is able to upcast the IList to ArrayList or whatever
the certain implemenation is.

Additionally this technique can be useful when you want to return a
interface that doesn't allow
modification on the object, and you don't want that the client simply
upcasts your IReadOnlyList to IWriteableList.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
Nov 15 '05 #9

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

49
by: Ville Vainio | last post by:
I don't know if you have seen this before, but here goes: http://text.userlinux.com/white_paper.html There is a jab at Python, though, mentioning that Ruby is more "refined". -- Ville...
14
by: Otis Green | last post by:
Vote for or against a new newsgroup proposal. To summarize what you need to do, just send an empty e-mail to postgresql-ballot@netagw.com You'll receive a ballot by e-mail. Follow the...
16
by: Merlin | last post by:
I believe that interfaces are one of the more useful design constructs available in C#. However, there's one thing that I feel is missing in them. I propose that interfaces be expanded to allow...
7
by: Fred Mellender | last post by:
I would like to make a library (dll) that contains a number of classes and interfaces for use by other implementers. One of the interfaces I want to define is: public interface Foo { Bar...
28
by: C# Learner | last post by:
Note ---- Please use a fixed-width font to view this, such as Courier New. Problem
8
by: Tamir Khason | last post by:
Following the code: Assembly myAssembly = Assembly.LoadFrom(FileName); foreach (Type myType in myAssembly.GetTypes()) {Do_whatever()}
4
by: Marshal | last post by:
Sure... IEnumerable was inconvenient suggesting a separate class to service the enumeration, IEnumerator, and multiple operations: Current, MoveNext, Reset. (I'll warp the definition of "operation"...
669
by: Xah Lee | last post by:
in March, i posted a essay “What is Expressiveness in a Computer Language”, archived at: http://xahlee.org/perl-python/what_is_expresiveness.html I was informed then that there is a academic...
84
by: aarklon | last post by:
Hi all, I found an interesting article here:- http://en.wikipedia.org/wiki/Criticism_of_the_C_programming_language well what do you guys think of this article....??? Is it constructive...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
1
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
0
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
0
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development projectplanning, coding, testing,...
0
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
0
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
0
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.