Private, Shared, Public etc.

[whitezombie]

Can someone please give me a good resource that explains the difference between a Private, Public, Shared Functions/Sub/Variables? I normally use Public for Subs/Functions inside of Modules I call from other parts of the program. But I'd like to get more of an understanding of how and when to use them. I want as little as impact to a system that is running my programs as possible, so i guess the key here is I'm trying to just get more proficient in my coding.

Thanks in advance for any help!

 

[jmcilhinney]

MSDN should always be your first resource for anything related to .NET development. It has an explanation of all access modifiers.

access modifiers - MSDN Search

 

[whitezombie]

Thank you!

 

[Element6]

Shesh? How do you .NET development without knowing that? Are you migrating from VB?

In .NET the basic thing you need to know is that everything is modifiable for security; so new accessors references are created to handle "on the fly" or ease of access for the developers

PUBLIC and PRIVATE is self explanitory; if it's PUBLIC it's Visible, if it's PRIVATE it's NOT

SHARED is specific to the Class or Module, and allows the reference to be cascaded to other Classes or Modules without declaring an instance (As long as you don't have specific enumeration passing or object/class information)

OVERLOADS means that there is more then one Function with the same name, and it has different "parameters" this is so you can do the 16 different types of function/sub calls (which even though it's cool it's a little rediculous IMO)

SHADOWS is where the world gets fuzzy to learn; it basically Acts like OVERLOADS but it hides the function it's overloading and replace it with itself. So that it becomes the primary Function reference.

Really, .NET is best described in the way it handles EVENTS and Delegates; If you read on anything that's what you want to read on, and the copied some really cool features from old PASCAL like inline Sub routines within routines so you can make more readable code (even though I still think if your code is that long your doing something wrong and need to break it apart)

I do a lot of Delegates calling because I am C/VB/ASM guy and I view the universe a little different then IF THEN ELSE I like addressing and it's easier for me to calculate. So, VB.NET did EXTREAMLY well, there. I am very pleased with it. However, I of course found the one error which crashes the VB.NET framework; and the only other guy in the world that recreated it is in China and I can't read his messages (Thats right exactly 1 hit for my question from google) So, VB.NET still has some issues but overall good job.

Hope that helps.

 

[jmcilhinney]

SHARED is specific to the Class or Module, and allows the reference to be cascaded to other Classes or Modules without declaring an instance (As long as you don't have specific enumeration passing or object/class information)

I know what Shared means and that confused me. Shared means that the member is accessed vis the type itself rather than a specific instance of the type. For fields and properties, that means that there's one copy of the data for the whole type, no matter how many instances you create. Modules don't, and can't, have Shared members. All module members inherently act as Shared because you can't create an instance of a module anyway, but you cannot declare them as Shared. When compiled, VB modules are treated the same as C# static classes. In C# a static class is a class that is declared static and, as required, all members are also declared static. 'static' is the C# equivalent of Shared in VB.

SHADOWS is where the world gets fuzzy to learn; it basically Acts like OVERLOADS but it hides the function it's overloading and replace it with itself. So that it becomes the primary Function reference.

Shadows and Overloads have no relationship at all. I assume you mean Overrides. Overriding is always preferable to Shadowing but the base member must be declared Overridable for it to be done. The difference is that overriding follows the type of the object while shadowing follows the type of the reference. Try running the following code to see the difference:

Public Class BaseClass

    Public Overridable Sub Method1()
        MessageBox.Show("BaseClass.Method1")
    End Sub

    Public Sub Method2()
        MessageBox.Show("BaseClass.Method2")
    End Sub

End Class


Public Class DerivedClass
    Inherits BaseClass

    Public Overrides Sub Method1()
        MessageBox.Show("DerivedClass.Method1")
    End Sub

    Public Shadows Sub Method2()
        MessageBox.Show("DerivedClass.Method2")
    End Sub

End Class

Dim dc As New DerivedClass

dc.Method1()
dc.Method2()

Dim bc As BaseClass = DirectCast(dc, BaseClass)

bc.Method1()
bc.Method2()

As you can see from that, calling a method of a DerivedClass object through a BaseClass reference differs between an overridden member and a shadowed member. Overriding follows the type of the object, so it's the Method1 implementation from the DerivedClass that is executed. Shadowing follows the type of the reference, so it's the Method2 implementation from the BaseClass that is executed.

 

[Element6]

Yes I agree for SHARED - Better explaination, I explained as if a person has recursive foreknowledge of how .NET works. Your explaination is better, in the sense that it is from the accessability level.

As for SHADOWS I think your over complicating the concept. The actual in development reference says

Specifies that a declared programming element redeclares and hides an identically named element in a base class

It is most useful in inheritance; when you are using identical function references; but want one to act as the default rather then allowing them to be Overload which is defaulted (I think or at least I have set to default).

 

[JuggaloBrotha]

Shesh? How do you .NET development without knowing that? Are you migrating from VB?

In .NET the basic thing you need to know is that everything is modifiable for security; so new accessors references are created to handle "on the fly" or ease of access for the developers

PUBLIC and PRIVATE is self explanitory; if it's PUBLIC it's Visible, if it's PRIVATE it's NOT

SHARED is specific to the Class or Module, and allows the reference to be cascaded to other Classes or Modules without declaring an instance (As long as you don't have specific enumeration passing or object/class information)

OVERLOADS means that there is more then one Function with the same name, and it has different "parameters" this is so you can do the 16 different types of function/sub calls (which even though it's cool it's a little rediculous IMO)

SHADOWS is where the world gets fuzzy to learn; it basically Acts like OVERLOADS but it hides the function it's overloading and replace it with itself. So that it becomes the primary Function reference.

Really, .NET is best described in the way it handles EVENTS and Delegates; If you read on anything that's what you want to read on, and the copied some really cool features from old PASCAL like inline Sub routines within routines so you can make more readable code (even though I still think if your code is that long your doing something wrong and need to break it apart)

I do a lot of Delegates calling because I am C/VB/ASM guy and I view the universe a little different then IF THEN ELSE I like addressing and it's easier for me to calculate. So, VB.NET did EXTREAMLY well, there. I am very pleased with it. However, I of course found the one error which crashes the VB.NET framework; and the only other guy in the world that recreated it is in China and I can't read his messages (Thats right exactly 1 hit for my question from google) So, VB.NET still has some issues but overall good job.

Hope that helps.

You're forgetting: Protected, Friend, Private Protected, MustInherit, NotInheritable, etc..

Also you're bringing up a 7 month old thread...

 

[Element6]

For your Information I know C#, VB.NET, C++, ASM x86 (learning 64bit) and VB, JavaScript, Java IEEE, Pascal (Delphi) , PHP.

So for the record; syntax to me is irrelevant for the most part because it all complies the same I look for root level problems like how addressing is handled and stuff like that, code optimization and efficentcies.

My view of the universe is Biased in the sense that when I code; I code as a Frame developer and not an IT developer; which basically means that I'm lazy and hate reinventing the wheel a hundred times because my boss is trying to smooth something over with his boss. So no need to describe the C# references or anything else that is trivial especially in .NET because all the languages use the exact same interruptor and create the same assembly types.

Syntax is a matter of comfortability. Personally I think they should have just reinvented a whole new language and forced people to do Mathematics and Calculus so that we can get out of IF logic world; I'm getting rusty in Math now because I have been stuck in IF logic world.

Oh and BTW for the record Mircosoft people because I know you read these things, WHY HAVEN'T YOU DEVELOPED InterruptableFOR loops? I have been coding them since the 80's but apparently I am the only one that uses that logic which makes no sense to me; because for true event processing you need interruptableFor Loops. I call them iFor and it is a basic For loop with 2 additional parameter passing 1 that passes an interrupt function reference check, and the other is the result function reference (what to do if interrupted) So, if you use the idea pay me a million dollars and you can have it I want credit for the idea though otherwise (C)opyright 1985-present and if I see it on the market now I know you stole the idea from me becuase noone ELSE DOES THEM!

 

[jmcilhinney]

Oh and BTW for the record Mircosoft people because I know you read these things, WHY HAVEN'T YOU DEVELOPED InterruptableFOR loops? I have been coding them since the 80's but apparently I am the only one that uses that logic which makes no sense to me; because for true event processing you need interruptableFor Loops. I call them iFor and it is a basic For loop with 2 additional parameter passing 1 that passes an interrupt function reference check, and the other is the result function reference (what to do if interrupted) So, if you use the idea pay me a million dollars and you can have it I want credit for the idea though otherwise (C)opyright 1985-present and if I see it on the market now I know you stole the idea from me becuase noone ELSE DOES THEM!

Please keep your comments relevant. If you want a dialogue with Microsoft designers then please contact them directly or use a forum dedicated to that purpose.