RE: [Sharpcvslib-developers] RE: Class visibility question

[Clayton Harbour <claytonharbour@sp...>]

Gerald,

I ran the entire test suite (before I just ran the internal class tests)
against this solution and ran into a problem with the configuration
loader test (class cast exception).  I have not had a chance to track it
down yet and I don't think it would be a deterrent, just thought I would
flag it.


Clayton

-----Original Message-----
From: Clayton Harbour=20
Sent: September 22, 2003 6:17 AM
To: Gerald Evans
Cc: sharpcvslib-developers@...
Subject: [Sharpcvslib-developers] RE: Class visibility question

Gerald,

I have cc'd the #cvslib list. =20

Some very good questions and something I have thought about a (tiny)
bit.  Responses below.


-----Original Message-----
From: Gerald Evans [mailto:gne@...]=20
Sent: September 22, 2003 4:51 AM
To: Clayton Harbour
Subject: Class visibility question

Clayton,

>1) Is there any documentation on the interface that sharpcvslib
provides=20
>(or will provide) for developers wishing to make use of it in their
>projects?

C: Yes, there is some documentation (the API docs).  There is not a lot
there and it is a little mixed with the methods that we might want to be
internal but it is a start. =20

>2) Is the intention to expose the minimum necessary to provide cvs
support=20
>for other projects, or do we want to provide access to some/all of the=20
>internal 'helper' classes as well?

C: The minimum necessary definitely.  I see the Command, Misc (probably
only pieces...and maybe with a better name) and Client namespace being
the ones requiring he

>3) As far as I can see, at the moment all classes are public so any
user of=20
>the DLL has access to all of these classes.  It users do start using
the=20
>'helper' classes then this would make it more difficult for us to
change=20
>them later on if we needed to, or would make it more difficult for
users to=20
>upgrade to a later DLL.

C: I agree, we should lock it down.

>4) As the unit tests are in a separate DLL, does this mean that they
would=20
>not be able to test the 'helper' classes if they were marked
'internal', or=20
>is there some way around it with multi-file assemblies?

C: That is true, if the helpers are compiled separately from the main
assembly then it would be impossible to test the internal helper
methods.  I have been thinking of a workaround for this which would be
to build the test and source all into one assembly (the test assembly).
I have attached the files to make this change and commented them with:
	// TODO: Change to internalize helpers
with the type of change.  If you like this I can commit what I have and
then we can hash over the details of what needs to be internal and what
we need to expose.  Let me know what you think.


Perhaps it is still a bit early to start worrying about the above, but
was=20
just wondering if you had any specific intensions towards class
visibility.

Gerald.

RE: [Sharpcvslib-developers] RE: Class visibility question

[Clayton Harbour <claytonharbour@sp...>]

Gerald,

I ran the entire test suite (before I just ran the internal class tests)
against this solution and ran into a problem with the configuration
loader test (class cast exception).  I have not had a chance to track it
down yet and I don't think it would be a deterrent, just thought I would
flag it.


Clayton

-----Original Message-----
From: Clayton Harbour=20
Sent: September 22, 2003 6:17 AM
To: Gerald Evans
Cc: sharpcvslib-developers@...
Subject: [Sharpcvslib-developers] RE: Class visibility question

Gerald,

I have cc'd the #cvslib list. =20

Some very good questions and something I have thought about a (tiny)
bit.  Responses below.


-----Original Message-----
From: Gerald Evans [mailto:gne@...]=20
Sent: September 22, 2003 4:51 AM
To: Clayton Harbour
Subject: Class visibility question

Clayton,

>1) Is there any documentation on the interface that sharpcvslib
provides=20
>(or will provide) for developers wishing to make use of it in their
>projects?

C: Yes, there is some documentation (the API docs).  There is not a lot
there and it is a little mixed with the methods that we might want to be
internal but it is a start. =20

>2) Is the intention to expose the minimum necessary to provide cvs
support=20
>for other projects, or do we want to provide access to some/all of the=20
>internal 'helper' classes as well?

C: The minimum necessary definitely.  I see the Command, Misc (probably
only pieces...and maybe with a better name) and Client namespace being
the ones requiring he

>3) As far as I can see, at the moment all classes are public so any
user of=20
>the DLL has access to all of these classes.  It users do start using
the=20
>'helper' classes then this would make it more difficult for us to
change=20
>them later on if we needed to, or would make it more difficult for
users to=20
>upgrade to a later DLL.

C: I agree, we should lock it down.

>4) As the unit tests are in a separate DLL, does this mean that they
would=20
>not be able to test the 'helper' classes if they were marked
'internal', or=20
>is there some way around it with multi-file assemblies?

C: That is true, if the helpers are compiled separately from the main
assembly then it would be impossible to test the internal helper
methods.  I have been thinking of a workaround for this which would be
to build the test and source all into one assembly (the test assembly).
I have attached the files to make this change and commented them with:
	// TODO: Change to internalize helpers
with the type of change.  If you like this I can commit what I have and
then we can hash over the details of what needs to be internal and what
we need to expose.  Let me know what you think.


Perhaps it is still a bit early to start worrying about the above, but
was=20
just wondering if you had any specific intensions towards class
visibility.

Gerald.