Hello!
I was wondering why we're allowed to define interfaces as internal, when all
the members of the interface, when implemented in a class, are made public?
I know that interfaces serve as contracts, but why wouldn't you be allowed
to have internal contracts also, not necessarily exposing the members
publicly? You're not allowed to cast an object to the internal interface,
but I'm unable to keep the members internal.
It's quite annoying as I'll have to introduce extra abstract classes to
achieve the hidden interface members.
internal interface IXml
{
string ToXml();
}
public class CmsObject : IXml
{
.. other members / constructors
public string ToXml() { return null; }
}
... and in another project (assembly):
CmsObject o = new CmsObject();
string s = o.ToXml();
--
venlig hilsen / with regards
anders borum
-- 12 12439
Just implement the interface explcitly, then its members are only accessible via an inerface based reference which is only possible if you have access to the interace itself
Regards
Richard Blewett - DevelopMentor http://www.dotnetconsult.co.uk/weblog http://www.dotnetconsult.co.uk
nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<eJ**************@TK2MSFTNGP14.phx.gbl>
Hello!
I was wondering why we're allowed to define interfaces as internal, when all
the members of the interface, when implemented in a class, are made public?
I know that interfaces serve as contracts, but why wouldn't you be allowed
to have internal contracts also, not necessarily exposing the members
publicly? You're not allowed to cast an object to the internal interface,
but I'm unable to keep the members internal.
It's quite annoying as I'll have to introduce extra abstract classes to
achieve the hidden interface members.
Hello!
I understand what you're saying, but could you give me a short example a'la
the one I presented?
Thanks Richard!
--
venlig hilsen / with regards
anders borum
--
I think he means this:
public class CmsObject : IXml
{
.. other members / constructors
// Change is here (added IXml and removed public)
string IXml.ToXml() { return null; }
}
"Anders Borum" <an****@sphereworks.dk> wrote in message
news:eR*************@TK2MSFTNGP12.phx.gbl... Hello!
I understand what you're saying, but could you give me a short example a'la the one I presented?
Thanks Richard!
-- venlig hilsen / with regards anders borum --
Hi Rene
Thanks for the example. I was probably thinking about something else, but it
makes sense.
--
venlig hilsen / with regards
anders borum
--
internal interface IFoo
{
void Spong();
}
public class Bar : IFoo
{
public void Quux()
{
}
void IFoo.Spong()
{
}
}
inside the assembly I can do this:
Bar b = new Bar();
b.Quux();
IFoo f = b;
f = Spong();
outside the assembly I can only do this:
Bar b = new Bar();
b.Quux();
IFoo f = b; // this won't compile as IFoo is marked as internal
Regards
Richard Blewett - DevelopMentor http://www.dotnetconsult.co.uk/weblog http://www.dotnetconsult.co.uk
Hello!
I understand what you're saying, but could you give me a short example a'la
the one I presented?
Thanks Richard!
Hello!
I follow your implementation, but this means I'll have to cast the reference
each time I'm looking to access the members of the internal interface. Why
this is necessary doesn't make sense to me.
--
venlig hilsen / with regards
anders borum
--
Well, you don't have to make the cast all the time, you can add Internal
methods that map to the hidden interfaces such as:
public class CmsObject : IXml
{
.. other members / constructors
// Change is here (added IXml and removed public)
string IXml.ToXml() { return null; }
// Add maping here.
internal string ToXml()
{
return ToXml();
}
}
"Anders Borum" <an****@sphereworks.dk> wrote in message
news:u6**************@TK2MSFTNGP15.phx.gbl... Hello!
I follow your implementation, but this means I'll have to cast the reference each time I'm looking to access the members of the internal interface. Why this is necessary doesn't make sense to me.
-- venlig hilsen / with regards anders borum --
Hello!
Thanks for the example. I think it kind of defeats the whole idea of having
internal interfaces, if you have to provide a duplicate (redundant) internal
method for each of the interface members. Ideally, one would expect the
members to be available internally only..
I don't know if I'm the only one who think this is odd?
I have a concrete situation where I was thinking about replacing a abstract
class (named CmsContext) with an ICmsContext interface. The abstract
CmsContext provides public as well as internal abstract members. I have been
looking a lot on the object model and it seems like I will have to introduce
extra abstract classes instead of the interface approach ..
--
venlig hilsen / with regards
anders borum
--
I see your point, unfortunately I think this is a necessary evil, for
example, if you ever have to inherit from multiple interfaces and say that a
method signature repeat on two of the interfaces. How would you tell them
apart? The only way will be to implement the interface explicitly (Fully
qualified: The interface name plus the method name). Not doing so will
create a compile error. This will also mean that you will have to cast the
object to the interface to get a hold of the method, there is no other way.
If the compilers allow you to do what you want to do, and if you ever
inherit two or more interfaces with members having the same name, there
would be no way to resolve the name conflict.
"Anders Borum" <an****@sphereworks.dk> wrote in message
news:eF**************@TK2MSFTNGP10.phx.gbl... Hello!
Thanks for the example. I think it kind of defeats the whole idea of having internal interfaces, if you have to provide a duplicate (redundant) internal method for each of the interface members. Ideally, one would expect the members to be available internally only..
I don't know if I'm the only one who think this is odd?
I have a concrete situation where I was thinking about replacing a abstract class (named CmsContext) with an ICmsContext interface. The abstract CmsContext provides public as well as internal abstract members. I have been looking a lot on the object model and it seems like I will have to introduce extra abstract classes instead of the interface approach ..
-- venlig hilsen / with regards anders borum --
Hello! I see your point, unfortunately I think this is a necessary evil, for example, if you ever have to inherit from multiple interfaces and say that
a method signature repeat on two of the interfaces. How would you tell them apart?
If you have a method signature repeat on two interfaces, you're only asked
to implement the method once (thus covering both interfaces).
interface a
{
string c();
}
interface b
{
string c();
}
public class d : a, b
{
string c() { return null; }
}
The above compiles perfectly. I see your point though, in the case where you
have different access modifiers on the two interfaces. In my case, however,
there are no conflicts as I am 100% in charge of the design.
Maybe I should have asked this to Anders Hejlsberg from the Microsoft C#
design team, when he guested Denmark a few weeks ago.
The only way will be to implement the interface explicitly (Fully qualified: The interface name plus the method name). Not doing so will create a compile error. This will also mean that you will have to cast the object to the interface to get a hold of the method, there is no other
way.
What would be wrong about the following:
interface a
{
internal string c();
}
public class d : a
{
internal string c() { return null; }
}
I have asked google the same question with little luck and am quite sure
there is an answer to this - I'd like to see it.
--
venlig hilsen / with regards
anders borum
--
Good question, other than the typical "Because that's the way it is" answer,
I have no idea. Maybe they didn't want to bother since it is possible to
archive the functionality that you require through other methods?
Personally, the thing that rally ticks me is not having different access
modifiers in a Property, there are times when having a public "get" and an
internal "set" would be kind of nice but did they add that functionality
Noooooooooooooooo.
Cheers
"Anders Borum" <an****@sphereworks.dk> wrote in message
news:uI**************@TK2MSFTNGP12.phx.gbl... Hello!
I see your point, unfortunately I think this is a necessary evil, for example, if you ever have to inherit from multiple interfaces and say that a method signature repeat on two of the interfaces. How would you tell them apart?
If you have a method signature repeat on two interfaces, you're only asked to implement the method once (thus covering both interfaces).
interface a { string c(); }
interface b { string c(); }
public class d : a, b { string c() { return null; } }
The above compiles perfectly. I see your point though, in the case where you have different access modifiers on the two interfaces. In my case, however, there are no conflicts as I am 100% in charge of the design.
Maybe I should have asked this to Anders Hejlsberg from the Microsoft C# design team, when he guested Denmark a few weeks ago.
The only way will be to implement the interface explicitly (Fully qualified: The interface name plus the method name). Not doing so will create a compile error. This will also mean that you will have to cast the object to the interface to get a hold of the method, there is no other way.
What would be wrong about the following:
interface a { internal string c(); }
public class d : a { internal string c() { return null; } }
I have asked google the same question with little luck and am quite sure there is an answer to this - I'd like to see it.
-- venlig hilsen / with regards anders borum --
Hello! Personally, the thing that rally ticks me is not having different access modifiers in a Property, there are times when having a public "get" and an internal "set" would be kind of nice but did they add that functionality Noooooooooooooooo.
You'll be pleased to work with C# 2.0. From what I know, there will be
different access modifiers on the get/set parts of a field. I'm looking
forward to that as well!
--
venlig hilsen / with regards
anders borum
-- This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Andrew R. Thomas-Cramer |
last post by:
Can I simply mark a class as internal, or should I change all its public
members to internal as well?
If I can mark the class only as internal, it makes modifications easy.
|
by: Chien Lau |
last post by:
I frequently define internal UserControl-derived classes in my WinForms
apps:
internal class MyUserControl:UserControl{
...
}
I'll often need to embed these controls in a Form, whose class...
|
by: Sgt. Sausage |
last post by:
I know it's not possible, but I need a protected internal interface:
protected internal interface ISomeInterface{
// yadda yadda yadda
}
Basically, I need an interface that is completely...
|
by: Ray Stevens |
last post by:
"Server encountered an internal error. For more information, turn off
customErrors in the server's .config file."
The above is not a particularly helpful error message. It is being thrown by
a...
|
by: john doe |
last post by:
The UnsafeNativeMethods seems to be the answer to most .NET developer's
prayers in terms of defining interfaces and functions from the Windows
API, without us having to constantly having to...
|
by: mmkhajah |
last post by:
Hi,
I am trying to have a set of base classes and interfaces of an
application framework in their own assembly. That way, concrete
implementations of the API will reference that assembly and...
|
by: dhruv19280 |
last post by:
Can someone confirm that DB2 UDB v8.1.2 does NOT support internal
procedures as supported by Oracle? For example, this would work in
Oracle, but not in DB2. Am I correct?
CREATE OR REPLACE...
|
by: tris0516 |
last post by:
Hi, would like to ask for help regarding the error we encountered on our database. We are currently using Oracle 8.0.5. Below is the error message got from the alert.log. Please advise. Thank you.
...
|
by: JT |
last post by:
Here is the overall structure I will be referring to:
End-program
ProvideWorkFlow.dll
Forms and methods that properly manipulate calls to methods in
AccessUtils
AccessUtils (a web service)...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
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,...
|
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...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
| |