Hi I don't know if I'll be clearly but I'll try to explain my doubt with this .NET Framework sample:
public class myDerivedClass : IComparer { // Calls CaseInsensitiveComparer.Compare with the parameters reversed. int Compare( object x, object y ) { return( new CaseInsensitiveComparer().Compare( y,x ) ); } } Here, 'new' modifier in myDerivedClass
will hide the described member above from IComparer Interface. If the IComparer interface had been created by myself I'll know their members etc Question: i have supposed that .NET Interfaces only have default constructors right? that's why is necessary re-write
method with another signature? thanks in advance lof
The "new" keyword as you are using it creates a new object of type CaseInsensitiveComparer() and then calls the method Compare(y,x) and then returns the int value. When you call "new" keyword as a modifier that hides a method below it you have to use it in
the method line along with the other describes such as what it returns, if it is "public" or not, and many others. I think you may be confused on what the "new" keyword does. Interfaces do not have constructors because they are not objects they are just a
set of predefined methods that can be called. Interfaces are most useful for objects that might not always be of the same type but if they have the same interface than a method can access any object of any type as long as it supports the interface. In addition
interface methods always have to have public methods and must have all methods displayed publicly by the class that is using them. I don't know if I told understood the second part of you questions.
thank you so much nberardi for reply! As you can see I'm a newbie on this - I really appreciated all your comments I always listen developers talking about 'objects'and I already can not understand it at all. I only see objects how an instance of a class like:
Class MyClass = new Class(); where MyClass would be the object. I really could not see 'new' keyword as an operator, i'm confused about that. (i thought CaseInsensitiveComparer e Compare both were methods) About interfaces you're right - we don't
have objects inside interfaces therefore not constructors either. what i'm doing is trying VS samples e reading some C# books - and it's being a hard way to knowlegde. - thanks again lof
Think of it like this then:CaseInsensitiveComparer MyClass = new CaseInsensitiveComparer(); return MyClass.Compare(y,x);It's the same thing, but more work to get it done (personally, I prefer the other way).
This is the true way to do it... you alway have to assign a data type to your variable and that's usually the name of the object that you are instantiating... assigning the data type would be CaseInsensitiveComparer MyClass; then you create a reference to the
CaseInsensitiveComparer class MyClass = new CaseInsensitiveComparer(); or you can also create references to different classes (if you need to) as long as is the new class is part of the inheritance tree.... Tree myTree; myTree = new OrangeTree(); or myTree
= new ApplesTree(); this is known as polimorphism...which is the ability of a single variable of a given type to be used to refrence objects of diffrent types. anyway this is good stuff... :)
You don't have to put them on a different line. And that is not the true way to do it. That is the true way to do stuff in Visual Basic 6 and less. For C langagues (i.e. C++, Java, C#). The true way to delcare a variable is on the same line. That is a given
unspoken standard that most programmers use. Putting them on different lines shows that you get your heritage in programming from VB which didn't support full line declarations until VB.Net. Tree myTree = new OrangeTree(); // or Tree myTree = new ApplesTree();
That is much cleaner.
I agree, but whichever way you want to do it is up to you, that is just a programming preference (creating object references that is). My point was to explain 2 things: 1) how data typing and object references worked and 2) explain how to do dynamic binding
OR object reference at run-time (polymorphism). Java is my core language, and I've done very little VB6... This is what polymorphism allows us to do: Tree myTree; if(some runtime condition) myTree = new OrangeTree() //Orange tree extends Tree else myTree =
new ApplesTree() //Apples tree extends Tree //is myTree an orange tree? //is myTree an apples tree? //we cannot tell at compile //time! myTree.grow() //override method by the time this program is run, we will know what type of object myTree is referring to...
meaning which tree is actually going to grow(). polymorphism can be used in more complex ways, but this is just nice clean way to explain it.... if your read up to this point you are soo geeky :-)
Yeah that is what confused me. Most VB people stick with VB and dont' transfer over. However you method of programming speaks of a VB programer. Such as this next instance also speaks of a VB guy, if they always use this style: int i; for(i =0; i < Count;
i++) instead of the more popular for (int i = 0; i < Count; i++)
I was just curious about your heritage. There are some instances where granted you have to break up the object and the construtor.
I'm not sure about the major differences between a VB6 guy or C# guy or any other combination.... Is great to know thought, but you missed my point. "int" is a primitive type... these are types that have no classes. Classes define an object type. Defining a
class can be consider the same as defining a data type, but primitive types are most of the time treated differntly. when you create an object of a class the contructor instance method is always invoked (with the keyword "new" - Note:Either way If you don't
define any constructors for your class, the compiler will supply a default constructor that does nothing.), so the object of a class is not created until the constructor is invoked. anyway.. what do you mean by heritage? did you mean background? I work for
the mouse... (mikey mouse) :-)
Well what you were talking about with the default constructor for "primitive types". That is a function of a struct not a primitive type. Granted that might be how it was in other languages. But test it out if you create a struct and then just initialize it
and don't give it a constructor. It will be the same as doing the MyStruct m = new MyStruct. See I am not totally convinced of the primitive types in .Net yet. Because all languages have to compile to the same primitive types. So when C# is working with uint
VB is working with System.UInt32 and so on. by the way "int" does have a class it is System.Int32 and what looks like a primitive type to C# is actually something totally different to VB such as the uint I mentioned up above because VB doesn't have support
for uint. And if they were not in class form VB would not be able to access them.
Ok you are totally loosing me now... In C# there is a list of built-in value types (or primitive types): http://www.devasp.net/Net/SampleChapters/6306/6306_2.asp whether you are convinced or not these are still consider primitive types... Yes I agree that System.Int32
is identical to "int" and the only difference is that "int" is an alias to the predefined type "System.Int32" in the System namespace... BUT, still consider a primitive type... what are you talking about when you say: "that is a function of a struct not a
primitive type"? You lost me there... Again: "int" does NOT have a class... "int" is just an alias "keyword" to System.Int32. You keep bringing references to VB...
No I was bring up VB as a reference for uint since it doesn't have a uint keyword. See I guess the word 'primitive' is where I am getting lost. Because as I understood them from the C++ days these were types that the compiler handled and there was no object
associated with them. That is why they were called primitives, because they were the building blocks for all other classes. In the .Net framework it doesn't seem that way any more because if int wasn't a class you wouldn't be able to typeint.MaxValue,
having this happen and work means it is more of an alias like you said than a primitive type. I understand what primitive types were back in C++ and even in Java, but the types we call primitive just seem to have that word associated for legacy terminology
reasons. Also with primitive types as defined in previous langueges you couldn't do the following:int i = new Int32("1");. This is what leads me to beleive the above. If you look at the framwork Int32, Int64, etc. All are of the type of struct.
Now if you create a struct without initializing it, it still calls the constructor. You can test this out and verify it for your self, because a struct that isn't initialized is an empty struct or the same as callingnew MyStruct(), unless it is
overridden to put some values in when a struct is created. That is why things such as DateTime and Int32 get a default value of min when they are not initilized. You can try this out for your self by creating a struct and using it in various ways. Struct was
defined this way because it can't take null values and if it can't take null values it needs to have some kind of value in memory. I could be wrong but this is how one of the guys on the Framework team described it to me. But that was when it first came out
in Febuary 2002.
I undestood that most C# programmers declare a variable(object) on the same line but how I'm in learning process I can not figure out about object that I'm instantiating. This simple delegate sample eg as follows:
// keyword_delegate.cs // delegate declaration delegate void MyDelegate(int i); class Program { public static void Main() { TakesADelegate(new MyDelegate(DelegateFunction)); } public static void TakesADelegate(MyDelegate SomeFunction) { SomeFunction(21);
} public static void DelegateFunction(int i) { System.Console.WriteLine("Called by delegate with number: {0}.", i); } }
How to put it in two lines? I'm really confused by working without seeing object. Thanks in advance -lof
You did not hijack our thread nberardi - by the contrary - I'm so grateful for all comments exposed here and certainly all your explanations always help us to increase our knowledge :) best regards
There are more reasons than just preference to sometimes useint i; for ( i = 0; i < Count; ++i );Scope. Normally I use the "more popular" way, but I do it pretty much on a case-by-case basis.
None
0 Points
200 Posts
working with interfaces
Jan 06, 2004 08:21 AM|lofquest|LINK
public class myDerivedClass : IComparer { // Calls CaseInsensitiveComparer.Compare with the parameters reversed. int Compare( object x, object y ) { return( new CaseInsensitiveComparer().Compare( y,x ) ); } }
Here, 'new' modifier in myDerivedClass will hide the described member above from IComparer Interface. If the IComparer interface had been created by myself I'll know their members etc Question: i have supposed that .NET Interfaces only have default constructors right? that's why is necessary re-write method with another signature? thanks in advance lofParticipant
792 Points
2233 Posts
Re: working with interfaces
Jan 06, 2004 08:43 AM|nberardi|LINK
None
0 Points
200 Posts
Re: working with interfaces
Jan 06, 2004 09:47 AM|lofquest|LINK
Class MyClass = new Class();
where MyClass would be the object. I really could not see 'new' keyword as an operator, i'm confused about that. (i thought CaseInsensitiveComparer e Compare both were methods) About interfaces you're right - we don't have objects inside interfaces therefore not constructors either. what i'm doing is trying VS samples e reading some C# books - and it's being a hard way to knowlegde. - thanks again lofParticipant
1203 Points
1896 Posts
Re: working with interfaces
Jan 07, 2004 04:39 AM|pickyh3d|LINK
CaseInsensitiveComparer MyClass = new CaseInsensitiveComparer(); return MyClass.Compare(y,x);
It's the same thing, but more work to get it done (personally, I prefer the other way).None
0 Points
200 Posts
Re: working with interfaces
Jan 07, 2004 09:06 AM|lofquest|LINK
None
0 Points
25 Posts
Re: working with interfaces
Jan 07, 2004 07:41 PM|geekman|LINK
Participant
792 Points
2233 Posts
Re: working with interfaces
Jan 08, 2004 08:39 AM|nberardi|LINK
Tree myTree = new OrangeTree(); // or Tree myTree = new ApplesTree();
That is much cleaner.None
0 Points
25 Posts
Re: working with interfaces
Jan 08, 2004 11:30 AM|geekman|LINK
Participant
792 Points
2233 Posts
Re: working with interfaces
Jan 08, 2004 12:22 PM|nberardi|LINK
int i; for(i =0; i < Count; i++)
instead of the more popularfor (int i = 0; i < Count; i++)
I was just curious about your heritage. There are some instances where granted you have to break up the object and the construtor.None
0 Points
25 Posts
Re: working with interfaces
Jan 08, 2004 01:48 PM|geekman|LINK
Participant
792 Points
2233 Posts
Re: working with interfaces
Jan 10, 2004 12:10 PM|nberardi|LINK
None
0 Points
25 Posts
Re: working with interfaces
Jan 10, 2004 06:40 PM|geekman|LINK
Participant
792 Points
2233 Posts
Re: working with interfaces
Jan 11, 2004 12:17 PM|nberardi|LINK
int.MaxValue
, having this happen and work means it is more of an alias like you said than a primitive type. I understand what primitive types were back in C++ and even in Java, but the types we call primitive just seem to have that word associated for legacy terminology reasons. Also with primitive types as defined in previous langueges you couldn't do the following:int i = new Int32("1");
. This is what leads me to beleive the above. If you look at the framwork Int32, Int64, etc. All are of the type of struct. Now if you create a struct without initializing it, it still calls the constructor. You can test this out and verify it for your self, because a struct that isn't initialized is an empty struct or the same as callingnew MyStruct()
, unless it is overridden to put some values in when a struct is created. That is why things such as DateTime and Int32 get a default value of min when they are not initilized. You can try this out for your self by creating a struct and using it in various ways. Struct was defined this way because it can't take null values and if it can't take null values it needs to have some kind of value in memory. I could be wrong but this is how one of the guys on the Framework team described it to me. But that was when it first came out in Febuary 2002.None
0 Points
200 Posts
Re: working with interfaces
Jan 12, 2004 06:26 AM|lofquest|LINK
// keyword_delegate.cs // delegate declaration delegate void MyDelegate(int i); class Program { public static void Main() { TakesADelegate(new MyDelegate(DelegateFunction)); } public static void TakesADelegate(MyDelegate SomeFunction) { SomeFunction(21); } public static void DelegateFunction(int i) { System.Console.WriteLine("Called by delegate with number: {0}.", i); } }
How to put it in two lines? I'm really confused by working without seeing object. Thanks in advance -lofNone
0 Points
200 Posts
Re: working with interfaces
Jan 12, 2004 07:05 AM|lofquest|LINK
MyDelegate MyClass = new MyDelegate(DelegateFunction); TakesADelegate(MyClass);
Participant
792 Points
2233 Posts
Re: working with interfaces
Jan 12, 2004 08:47 AM|nberardi|LINK
None
0 Points
200 Posts
Re: working with interfaces
Jan 12, 2004 10:37 AM|lofquest|LINK
Participant
1203 Points
1896 Posts
Re: working with interfaces
Jan 19, 2004 01:07 PM|pickyh3d|LINK
int i; for ( i = 0; i < Count; ++i );
Scope. Normally I use the "more popular" way, but I do it pretty much on a case-by-case basis.