Is VB.NET breaking leaking encapsulation ...

**=?ISO-8859-1?Q?G=F6ran_Andersson?=** · Aug 6 '07, 07:45 AM

Re: Is VB.NET breaking leaking encapsulation ...

AshokG wrote:

Hi,
>
Consider this code in VB.NET project ClassLibrary1.. .
>
Public Interface ITest
>
Function Name() As String
Function Age() As Integer
>
End Interface
>
Public Class Test
Implements ITest
>
Private Function Age() As Integer Implements ITest.Age
Return 10
End Function
>
Public Function Name() As String Implements ITest.Name
Return "Test"
End Function
>
End Class
>
And a new C# (VB.NET too) Console Project and referefer above ClassLibrary1
>
class Class1
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main(string[] args)
{
ClassLibrary1.I Test t = new ClassLibrary1.T est();
Console.WriteLi ne(t.Age());
}
}
>
Note that Age is private in VB is getting accessing from C#/VB.NET through
interface... -Huh
>
C# doen't allow this as it won't compile!
>
Regards
Ashok
>

You are confusing the Age method with the Age method. :)

There are actually two methods Age in the class. The method Age in the
Test class is private. The method Age in the ITest interface is public.
They just happen to be the same method and happen to have the same name.

When the method has a different name than the method that it implements,
it gets less confusing:

Private Function Answer() As Integer Implements IQuestion.Reply
Return 42
End Function

The method Answer is private, but the method Reply is public.

In C# it's a bit stricter, and thus less confusing. The methods that
implement the interface has to have the same names as in the interface,
and they have to be public.

--
Göran Andersson
_____

guffa.com

http://www.guffa.com

Göran Anderssons privata hemsida.

**AshokG** · Aug 6 '07, 09:55 AM

Re: Is VB.NET breaking leaking encapsulation ...

Göran Andersson,

Thanks for the reply. Even if you rename the method in the implementation it
get's called.

My point here is allowing to call a private method through the Interface. If
you delcare with class name then you can't call.

So, Private members should not be allowed to call from outside the class and
similarly it should not allow Interface implemented member to declared as
Private

Regards,
Ashok

"Göran Andersson" <guffa@guffa.co mwrote in message
news:OCKS50$1HH A.5616@TK2MSFTN GP04.phx.gbl...

AshokG wrote:

>Hi,
>>
>Consider this code in VB.NET project ClassLibrary1.. .
>>
>Public Interface ITest
>>
> Function Name() As String
> Function Age() As Integer
>>
>End Interface
>>
>Public Class Test
> Implements ITest
>>
> Private Function Age() As Integer Implements ITest.Age
> Return 10
> End Function
>>
> Public Function Name() As String Implements ITest.Name
> Return "Test"
> End Function
>>
>End Class
>>
>And a new C# (VB.NET too) Console Project and referefer above
>ClassLibrary 1
>>
>class Class1
>{
> /// <summary>
> /// The main entry point for the application.
> /// </summary>
> [STAThread]
> static void Main(string[] args)
> {
> ClassLibrary1.I Test t = new ClassLibrary1.T est();
> Console.WriteLi ne(t.Age());
> }
>}
>>
>Note that Age is private in VB is getting accessing from C#/VB.NET
>through interface... -Huh
>>
>C# doen't allow this as it won't compile!
>>
>Regards
>Ashok
>>

>
You are confusing the Age method with the Age method. :)
>
There are actually two methods Age in the class. The method Age in the
Test class is private. The method Age in the ITest interface is public.
They just happen to be the same method and happen to have the same name.
>
When the method has a different name than the method that it implements,
it gets less confusing:
>
Private Function Answer() As Integer Implements IQuestion.Reply
Return 42
End Function
>
The method Answer is private, but the method Reply is public.
>
>
In C# it's a bit stricter, and thus less confusing. The methods that
implement the interface has to have the same names as in the interface,
and they have to be public.
>
--
Göran Andersson
_____
http://www.guffa.com

**tommaso.gastaldi@uniroma1.it** · Aug 6 '07, 11:25 AM

Re: Is VB.NET breaking leaking encapsulation ...

On 6 Ago, 08:56, "AshokG" <gw2ks...@hotma il.comwrote:

Hi,
>
Consider this code in VB.NET project ClassLibrary1.. .
>
Public Interface ITest
>
Function Name() As String
Function Age() As Integer
>
End Interface
>
Public Class Test
Implements ITest
>
Private Function Age() As Integer Implements ITest.Age
Return 10
End Function
>
Public Function Name() As String Implements ITest.Name
Return "Test"
End Function
>
End Class
>
And a new C# (VB.NET too) Console Project and referefer above ClassLibrary1
>
class Class1
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main(string[] args)
{
ClassLibrary1.I Test t = new ClassLibrary1.T est();
Console.WriteLi ne(t.Age());
}
>
}
>
Note that Age is private in VB is getting accessing from C#/VB.NET through
interface... -Huh
>
C# doen't allow this as it won't compile!
>
Regards
Ashok

Nope. Within VB, if you try this, you will see you get a complaint
from the compiler:

Public Interface ITest
Function Name() As String
Function Age() As Integer
End Interface

Class ClassLibrary
Implements ITest

Public Class Test
Implements ITest

Private Function Age() As Integer Implements ITest.Age
Return 10
End Function

Public Function Name() As String Implements ITest.Name
Return "Test"
End Function

End Class

End Class

Public Class Form1

Private Sub Form1_Load(ByVa l sender As System.Object, ByVal e As
System.EventArg s) Handles MyBase.Load
Dim t As New ClassLibrary
MsgBox(t.Test)
End Sub

End Class

It wants:

Public Function Age() As Integer Implements ITest.Age

End Function

Public Function Name() As String Implements ITest.Name

End Function

The compiler autonatically provides them.

T

**Armin Zingler** · Aug 6 '07, 11:55 AM

Re: Is VB.NET breaking leaking encapsulation ...

"AshokG" <gw2ksoft@hotma il.comschrieb

Göran Andersson,
>
Thanks for the reply. Even if you rename the method in the
implementation it get's called.
>
My point here is allowing to call a private method through the
Interface. If you delcare with class name then you can't call.
>
So, Private members should not be allowed to call from outside the
class and similarly it should not allow Interface implemented member
to declared as Private

You must distinguish between the "Class interface" (or better: the entirety
of all publicly available members) and the implemented interface. As you see
here, the Private modifier does work:

Public Class Test2
Public Sub Test
dim o as new test
msgbox(o.Age) '<---- Does not work because it's private
end sub
End Class

Using the ITest interface, the member is accessible, of course, because
there are no private Interface members at all. That's the purpose of an
interface.

Without this behavior, it wouldn't be possible to define the set of publicly
accessible members independently from the implemented interfaces.

In other words, by implementing an Interface, I don't want to be forced to
make a member public through a class reference.

Armin

**Bill McCarthy** · Aug 6 '07, 02:55 PM

Re: Is VB.NET breaking leaking encapsulation ...

Hi Ashok,

An interface is a contract. IF you implement an interface you guarantee to
expose the methods that interface defines.. that is the contract. C# also
has private interface implementation via explicit interface implementation,
in which case you can't even call that method from inside the class, you
must first cast the "this" (Me in Vb) reference to the interface. That is,
in the strictest form of the contract, the members are always accessible but
you may need to cast to the interface first.

I wrote a little mroe aobut this here:

http://msmvps.com/blogs/bill/archive/2005/02/27/37105.aspx

Bill.

"AshokG" <gw2ksoft@hotma il.comwrote in message
news:eaug$6A2HH A.536@TK2MSFTNG P06.phx.gbl...

Göran Andersson,
>
Thanks for the reply. Even if you rename the method in the implementation
it get's called.
>
My point here is allowing to call a private method through the Interface.
If you delcare with class name then you can't call.
>
So, Private members should not be allowed to call from outside the class
and similarly it should not allow Interface implemented member to declared
as Private
>
Regards,
Ashok
>
"Göran Andersson" <guffa@guffa.co mwrote in message
news:OCKS50$1HH A.5616@TK2MSFTN GP04.phx.gbl...

>AshokG wrote:

>>Hi,
>>>
>>Consider this code in VB.NET project ClassLibrary1.. .
>>>
>>Public Interface ITest
>>>
>> Function Name() As String
>> Function Age() As Integer
>>>
>>End Interface
>>>
>>Public Class Test
>> Implements ITest
>>>
>> Private Function Age() As Integer Implements ITest.Age
>> Return 10
>> End Function
>>>
>> Public Function Name() As String Implements ITest.Name
>> Return "Test"
>> End Function
>>>
>>End Class
>>>
>>And a new C# (VB.NET too) Console Project and referefer above
>>ClassLibrar y1
>>>
>>class Class1
>>{
>> /// <summary>
>> /// The main entry point for the application.
>> /// </summary>
>> [STAThread]
>> static void Main(string[] args)
>> {
>> ClassLibrary1.I Test t = new ClassLibrary1.T est();
>> Console.WriteLi ne(t.Age());
>> }
>>}
>>>
>>Note that Age is private in VB is getting accessing from C#/VB.NET
>>through interface... -Huh
>>>
>>C# doen't allow this as it won't compile!
>>>
>>Regards
>>Ashok
>>>

>>
>You are confusing the Age method with the Age method. :)
>>
>There are actually two methods Age in the class. The method Age in the
>Test class is private. The method Age in the ITest interface is public.
>They just happen to be the same method and happen to have the same name.
>>
>When the method has a different name than the method that it implements,
>it gets less confusing:
>>
>Private Function Answer() As Integer Implements IQuestion.Reply
> Return 42
>End Function
>>
>The method Answer is private, but the method Reply is public.
>>
>>
>In C# it's a bit stricter, and thus less confusing. The methods that
>implement the interface has to have the same names as in the interface,
>and they have to be public.
>>
>--
>Göran Andersson
>_____
>http://www.guffa.com

>
>

**=?ISO-8859-1?Q?G=F6ran_Andersson?=** · Aug 6 '07, 05:25 PM

Re: Is VB.NET breaking leaking encapsulation ...

AshokG wrote:

Göran Andersson,
>
Thanks for the reply. Even if you rename the method in the implementation it
get's called.

Yes, of course. You have exposed the method publically through the
interface, that's why you can call it through the interface, but not
through the class.

My point here is allowing to call a private method through the Interface. If
you delcare with class name then you can't call.

But the method is not private. When you expose it throught the interface
it's public.

So, Private members should not be allowed to call from outside the class

You can't call private members, but you can always expose a private
member through another member that is public. For example:

Class Test

Private Function SecretAge() As Integer
Return 12
End Function

Public Function Age() As Integer
Return SecretAge()
End Function

End Class

Making the SecretAge private does not prevent a public method from using it.

and
similarly it should not allow Interface implemented member to declared as
Private

Then there would have to be a different way of telling the compiler if
the method should be reachable through the class or not. C# does this by
differentiating between implicit and explicit implementation of the
interface. That can't be used in VB, as there is only explicit
implementation.

--
Göran Andersson
_____

guffa.com

http://www.guffa.com

Göran Anderssons privata hemsida.

**AshokG** · Aug 7 '07, 07:35 AM

Re: Is VB.NET breaking leaking encapsulation ...

Göran Andersson,

Thanks for the reply,

Then there would have to be a different way of telling the compiler if the
method should be reachable through the class or not. C# does this by
differentiating between implicit and explicit implementation of the
interface. That can't be used in VB, as there is only explicit
implementation.

in C# even if it is implemented explicitly, it will not get compile. Means
C# enforces the implementing class to declare it as Public - VB doesn't!. So
VB should also do this.

Regards,
Ashok

"Göran Andersson" <guffa@guffa.co mwrote in message
news:uJDrZ1E2HH A.484@TK2MSFTNG P06.phx.gbl...

AshokG wrote:

>Göran Andersson,
>>
>Thanks for the reply. Even if you rename the method in the implementation
>it get's called.

>
Yes, of course. You have exposed the method publically through the
interface, that's why you can call it through the interface, but not
through the class.
>

>My point here is allowing to call a private method through the Interface.
>If you delcare with class name then you can't call.

>
But the method is not private. When you expose it throught the interface
it's public.
>

>So, Private members should not be allowed to call from outside the class

>
You can't call private members, but you can always expose a private member
through another member that is public. For example:
>
Class Test
>
Private Function SecretAge() As Integer
Return 12
End Function
>
Public Function Age() As Integer
Return SecretAge()
End Function
>
End Class
>
Making the SecretAge private does not prevent a public method from using
it.
>

>and similarly it should not allow Interface implemented member to
>declared as Private

>
Then there would have to be a different way of telling the compiler if the
method should be reachable through the class or not. C# does this by
differentiating between implicit and explicit implementation of the
interface. That can't be used in VB, as there is only explicit
implementation.
>
--
Göran Andersson
_____
http://www.guffa.com

**AshokG** · Aug 7 '07, 07:45 AM

Re: Is VB.NET breaking leaking encapsulation ...

oops!

I quickly checked the behaviour once again. C# simply doesn't allow to put
access modifiers on the explicitly impletemented interface members.

Anyway still C#'s behaviour is correct IMHO.

Regards,
Ashok

"Bill McCarthy" <Bill@NOSPAM.co mwrote in message
news:E749CA3B-5D21-4B4F-BF34-BAB79F117D7F@mi crosoft.com...

Hi Ashok,
>
An interface is a contract. IF you implement an interface you guarantee
to expose the methods that interface defines.. that is the contract. C#
also has private interface implementation via explicit interface
implementation, in which case you can't even call that method from inside
the class, you must first cast the "this" (Me in Vb) reference to the
interface. That is, in the strictest form of the contract, the members
are always accessible but you may need to cast to the interface first.
>
I wrote a little mroe aobut this here:

http://msmvps.com/blogs/bill/archive/2005/02/27/37105.aspx

>
Bill.
>
>
>
"AshokG" <gw2ksoft@hotma il.comwrote in message
news:eaug$6A2HH A.536@TK2MSFTNG P06.phx.gbl...

>Göran Andersson,
>>
>Thanks for the reply. Even if you rename the method in the implementation
>it get's called.
>>
>My point here is allowing to call a private method through the Interface.
>If you delcare with class name then you can't call.
>>
>So, Private members should not be allowed to call from outside the class
>and similarly it should not allow Interface implemented member to
>declared as Private
>>
>Regards,
>Ashok
>>
>"Göran Andersson" <guffa@guffa.co mwrote in message
>news:OCKS50$1H HA.5616@TK2MSFT NGP04.phx.gbl.. .

>>AshokG wrote:
>>>Hi,
>>>>
>>>Consider this code in VB.NET project ClassLibrary1.. .
>>>>
>>>Public Interface ITest
>>>>
>>> Function Name() As String
>>> Function Age() As Integer
>>>>
>>>End Interface
>>>>
>>>Public Class Test
>>> Implements ITest
>>>>
>>> Private Function Age() As Integer Implements ITest.Age
>>> Return 10
>>> End Function
>>>>
>>> Public Function Name() As String Implements ITest.Name
>>> Return "Test"
>>> End Function
>>>>
>>>End Class
>>>>
>>>And a new C# (VB.NET too) Console Project and referefer above
>>>ClassLibrary 1
>>>>
>>>class Class1
>>>{
>>> /// <summary>
>>> /// The main entry point for the application.
>>> /// </summary>
>>> [STAThread]
>>> static void Main(string[] args)
>>> {
>>> ClassLibrary1.I Test t = new ClassLibrary1.T est();
>>> Console.WriteLi ne(t.Age());
>>> }
>>>}
>>>>
>>>Note that Age is private in VB is getting accessing from C#/VB.NET
>>>through interface... -Huh
>>>>
>>>C# doen't allow this as it won't compile!
>>>>
>>>Regards
>>>Ashok
>>>>
>>>
>>You are confusing the Age method with the Age method. :)
>>>
>>There are actually two methods Age in the class. The method Age in the
>>Test class is private. The method Age in the ITest interface is public.
>>They just happen to be the same method and happen to have the same name.
>>>
>>When the method has a different name than the method that it implements,
>>it gets less confusing:
>>>
>>Private Function Answer() As Integer Implements IQuestion.Reply
>> Return 42
>>End Function
>>>
>>The method Answer is private, but the method Reply is public.
>>>
>>>
>>In C# it's a bit stricter, and thus less confusing. The methods that
>>implement the interface has to have the same names as in the interface,
>>and they have to be public.
>>>
>>--
>>Göran Andersson
>>_____
>>http://www.guffa.com

>>
>>

>

**AshokG** · Aug 7 '07, 07:45 AM

Re: Is VB.NET breaking leaking encapsulation ...

oops!

I quickly checked the behaviour once again. C# simply doesn't allow to put
access modifiers on the explicitly impletemented interface members.

Anyway still C#'s behaviour is correct IMHO.

Regards,
Ashok

"Göran Andersson" <guffa@guffa.co mwrote in message
news:uJDrZ1E2HH A.484@TK2MSFTNG P06.phx.gbl...