Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: Clayton Harbour <claytonharbour@sp...> - 2003-09-22 14:18:17
|
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. |