I have two separate classes and would like the members of one class to have
access to the private members of another class. What is the idiomatic C#
solution to this?
I believe C++ would use "friends".
--
Dr Jon D Harrop, Flying Frog Consultancy
-
I have two separate classes and would like the members of one class to have
access to the private members of another class. What is the idiomatic C#
solution to this?
I believe C++ would use "friends".
--
Dr Jon D Harrop, Flying Frog Consultancy
-
Re: Encapsulation
On Fri, 23 May 2008 21:07:16 -0700, Jon Harrop <jon@ffconsulta ncy.com>
wrote:
It doesn't exist in C#.I have two separate classes and would like the members of one class to
have
access to the private members of another class. What is the idiomatic C#
solution to this?
>
I believe C++ would use "friends".
You can come close with the "internal" keyword. In that access modifier,
every class within the same assembly would be equivalent to being a
"friend", except that private and protected members would still be
hidden. You'd use "internal" on the members that you really want to share.
Alternatively, nested classes have access to private members of the
containing class(es). But IMHO that's only an appropriate solution if the
nested class really makes sense as a nested class. I wouldn't use it just
to address some accessibility issue.
Pete
-
Re: Encapsulation
Jon Harrop wrote:The typical C# solution would be to put the classes in sameI have two separate classes and would like the members of one class to have
access to the private members of another class. What is the idiomatic C#
solution to this?
>
I believe C++ would use "friends".
assembly and use "internal" accessibility.
The most similar to C++ friend would be if they use
"internal" accessibility and are in different assemblies, but
use the InternalsVisibl eTo attribute - see details at:
Arne
Comment
-
Re: Encapsulation
Arne Vajhøj wrote:That only restricts accessibility to the million lines of other code thatJon Harrop wrote:>>I have two separate classes and would like the members of one class to
>have access to the private members of another class. What is the
>idiomatic C# solution to this?
>>
>I believe C++ would use "friends".
The typical C# solution would be to put the classes in same
assembly and use "internal" accessibility.
happens to be in the same assembly, which is such a weak constraint as to
be of no practical use.
--
Dr Jon D Harrop, Flying Frog Consultancy
Comment
-
Re: Encapsulation
Jon Harrop wrote:I don't think millions of lines of C# code in one assemblyArne Vajhøj wrote:>>Jon Harrop wrote:>The typical C# solution would be to put the classes in same>>I have two separate classes and would like the members of one class to
>>have access to the private members of another class. What is the
>>idiomatic C# solution to this?
>>>
>>I believe C++ would use "friends".
>assembly and use "internal" accessibility.
That only restricts accessibility to the million lines of other code that
happens to be in the same assembly, which is such a weak constraint as to
be of no practical use.
is good at all.
Arne
Comment
-
Re: Encapsulation
Arne Vajhøj wrote:Whether I have one line or a million lines, the idea of restrictingJon Harrop wrote:>>Arne Vajhøj wrote:>>>>Jon Harrop wrote:
>>>I have two separate classes and would like the members of one class to
>>>have access to the private members of another class. What is the
>>>idiomatic C# solution to this?
>>>>
>>>I believe C++ would use "friends".
>>The typical C# solution would be to put the classes in same
>>assembly and use "internal" accessibility.
>That only restricts accessibility to the million lines of other code that
>happens to be in the same assembly, which is such a weak constraint as to
>be of no practical use.
I don't think millions of lines of C# code in one assembly
is good at all.
accessibility to a single-level (the assembly) does not scale. Moreover, if
I reduce the size of my assemblies then I increase the probability
that "internal" cannot work because access is required from another
assembly.
--
Dr Jon D Harrop, Flying Frog Consultancy
Comment
-
Re: Encapsulation
Jon Harrop wrote:Thank you for everyone's responses. The answer appears to be that C# isI have two separate classes and would like the members of one class to
have access to the private members of another class. What is the idiomatic
C# solution to this?
>
I believe C++ would use "friends".
unable to express this.
For anyone who is interested, here is a simple example of the kind of
encapsulation that I am referring to (written in OCaml):
module Counter : sig
module Incr : sig
val incr : unit -unit
val get_n : unit -int
end
module Adder : sig
val add : int -unit
end
end = struct
module Incr : sig
val incr : unit -unit
val get_n : unit -int
val set_n : int -unit
end = struct
let n = ref 0
let incr() = incr n
let get_n() = !n
let set_n m =
n := m
end
module Adder = struct
let add m =
Incr.set_n (Incr.get_n() + m)
end
end;;
Note how Counter.Incr.n is used in Counter.Adder.a dd but is not visible
outside Counter because the Incr module has two different signatures.
Perhaps a better way to explain that in C#-speak is: Counter.Incr.n is
private to Counter.Incr but Counter.Incr.se t_n is private to Counter.
--
Dr Jon D Harrop, Flying Frog Consultancy
Comment
-
Re: Encapsulation
Jon Harrop wrote:It scales fine.Arne Vajhøj wrote:>>Jon Harrop wrote:>I don't think millions of lines of C# code in one assembly>>Arne Vajhøj wrote:
>>>Jon Harrop wrote:
>>>>I have two separate classes and would like the members of one class to
>>>>have access to the private members of another class. What is the
>>>>idiomatic C# solution to this?
>>>>>
>>>>I believe C++ would use "friends".
>>>The typical C# solution would be to put the classes in same
>>>assembly and use "internal" accessibility.
>>That only restricts accessibility to the million lines of other code that
>>happens to be in the same assembly, which is such a weak constraint as to
>>be of no practical use.
>is good at all.
Whether I have one line or a million lines, the idea of restricting
accessibility to a single-level (the assembly) does not scale.
But it means that the source code and the assemblies are not
independent.
Well - we have give you the solution to that problem. If you chooseMoreover, if
I reduce the size of my assemblies then I increase the probability
that "internal" cannot work because access is required from another
assembly.
not to use that, then it is your problem not .NET's.
Arne
Comment
-
Re: Encapsulation
Arne Vajhøj wrote:If it scaled then I would be able to nest assemblies and mark dataJon Harrop wrote:>>Whether I have one line or a million lines, the idea of restricting
>accessibilit y to a single-level (the assembly) does not scale.
It scales fine.
as "internal" to the current or any parent assembly. But I cannot =it
does not scale.
Perhaps you mean that it is still possible to write monumental code bases in
the absence of decent encapsulation mechanisms. I cannot disagree with
that.
--
Dr Jon D Harrop, Flying Frog Consultancy
Comment
-
Re: Encapsulation
Jon Harrop wrote:I assume you mean "I cannot agree" or "I disagree".Arne Vajhøj wrote:>>Jon Harrop wrote:>It scales fine.>>Whether I have one line or a million lines, the idea of restricting
>>accessibili ty to a single-level (the assembly) does not scale.
If it scaled then I would be able to nest assemblies and mark data
as "internal" to the current or any parent assembly. But I cannot =it
does not scale.
>
Perhaps you mean that it is still possible to write monumental code bases in
the absence of decent encapsulation mechanisms. I cannot disagree with
that.
If you look out in the real world, then you will see that
somehow people are able to write software with lots
of assemblies without the ability to have a "nested
assembly" mechanism.
Arne
Comment
-
Re: Encapsulation
On Sat, 24 May 2008 15:34:23 -0700, Jon Harrop <jon@ffconsulta ncy.com>
wrote:
That word "scale". You seem to think it means something other than what>>I don't think millions of lines of C# code in one assembly
>is good at all.
Whether I have one line or a million lines, the idea of restricting
accessibility to a single-level (the assembly) does not scale.
it means.
Huh? If access is required from another assembly, you add the attributeMoreover, if
I reduce the size of my assemblies then I increase the probability
that "internal" cannot work because access is required from another
assembly.
Arne suggested, so that the other assembly has access.
I agree it's not a perfect solution, but IMHO "friend" is overused
anyway. Most of the time I see someone wanting to make their classes
"friends", they are heading down the wrong path in the first place.
In any case, as has been explained: this is what C# offers. If you think
it's completely unsuitable to your needs, you need to use a different
language. C++ still has "friend" and you can use that with .NET if you're
still trying to write a .NET program.
Pete
Comment
-
Re: Encapsulation
Arne Vajhøj wrote:No, I meant what I said. Consider it roughly equivalent to "I agree withJon Harrop wrote:>>Perhaps you mean that it is still possible to write monumental code bases
>in the absence of decent encapsulation mechanisms. I cannot disagree with
>that.
I assume you mean "I cannot agree" or "I disagree".
that".
Absolutely. Many of our competitors are bumbling around with enormousIf you look out in the real world, then you will see that
somehow people are able to write software with lots
of assemblies without the ability to have a "nested
assembly" mechanism.
Fortran 77 codebases that have no encapsulation or high-level structure at
all.
Tolerating the same deficiencies would mean commercial suicide for us.
--
Dr Jon D Harrop, Flying Frog Consultancy
Comment
-
Re: Encapsulation
Jon Harrop wrote:I just had an idea of how it might be possible to workaround this deficiencymodule Counter : sig
module Incr : sig
val incr : unit -unit
val get_n : unit -int
end
module Adder : sig
val add : int -unit
end
end = struct
module Incr : sig
val incr : unit -unit
val get_n : unit -int
val set_n : int -unit
end = struct
let n = ref 0
let incr() = incr n
let get_n() = !n
let set_n m =
n := m
end
module Adder = struct
let add m =
Incr.set_n (Incr.get_n() + m)
end
end;;
in C#. You can try to rewrite your code such that C#'s notion of "private
to this class only" is sufficient by pushing data up the class hierarchy.
Then you can pretend the data is actually in its logical place low in the
class hierarchy by implementing a property in that class.
I don't think that covers the general case but it might be sufficient for my
purposes. Our internal code will be hideous but at least it will present a
usable API for our customers.
--
Dr Jon D Harrop, Flying Frog Consultancy
Comment
-
Re: Encapsulation
Jon Harrop wrote:I was talking about .NET code even though I also know aboutArne Vajhøj wrote:>>If you look out in the real world, then you will see that
>somehow people are able to write software with lots
>of assemblies without the ability to have a "nested
>assembly" mechanism.
Absolutely. Many of our competitors are bumbling around with enormous
Fortran 77 codebases that have no encapsulation or high-level structure at
all.
>
Tolerating the same deficiencies would mean commercial suicide for us.
some Fortran code.
But one size does not fit all. Maybe C# and .NET is not
suitable for your apps.
Arne
Comment
-
Re: Encapsulation
Arne Vajhøj wrote:Fortunately there are other .NET languages. Unfortunately, the all shareJon Harrop wrote:>>Absolutely. Many of our competitors are bumbling around with enormous
>Fortran 77 codebases that have no encapsulation or high-level structure
>at all.
>>
>Tolerating the same deficiencies would mean commercial suicide for us.
I was talking about .NET code even though I also know about
some Fortran code.
>
But one size does not fit all. Maybe C# and .NET is not
suitable for your apps.
deficiency AFAIK...
--
Dr Jon D Harrop, Flying Frog Consultancy
Comment
Comment