EldoS | Feel safer!

Software components for data protection, secure storage and transfer

On the interface

Posted: 04/21/2011 16:08:49
by Stephen Richards (Standard support level)
Joined: 04/21/2011
Posts: 2

I've just licensed SecureBlackbox for the purpose of doing SFTP transfers. I have to admit that I'm somewhat mystified by the interface of this product. Take for instance:

void TElSimpleSftpClient.ListDirectory(string Path, ArrayList listing, string filemask, bool caseSensitive, bool includeFiles, bool includeDirectories);

I can't help wondering:

(1) why this function doesn't return the ArrayList, rather than returning void and having the actual return value be the second parameter of the call.

(2) why this function doesn't return a List<TElSftpFileInfo>, or failing that, why there isn't an overload that does. ArrayLists were old school when I started learning C#. I'd rather have the clunky casts inside of your code than mine . . .

(3) why the field called "LongName" in TElsftpFileInfo is actually a directory listing line.

(4) why the SFTP example program has the initialization of the SftpClient object inside of Form1.InitializeComponent(). While I am hardly an expert, that seems like the wrong place to put it, since that is "designer generated" code, and since the SftpClient is not a graphical object.

(5) why the code uses booleans instead of enums. In this call:

sftp.ListDirectory(directory, listing, mask, false, true, true);

it is not intuitively obvious to the casual reader what those booleans are doing. Enums would fix that:

sftp.ListDirectory(directory, listing, mask, ElSftpDirSearch.CaseSensitive, ElSftpDirSearch.IncludeFiles, ElSftpDirSearch.IncludeDirectories);

(or preferably:

listing = sftp.ListDirectory(directory, mask, ElSftpDirSearch.CaseSensitive, ElSftpDirSearch.IncludeFiles, ElSftpDirSearch.IncludeDirectories);


I'm guessing that some of these things have to do with continuing support for VB6, but maybe it's time to let the design move on from that? I also understand that you have an installed base that would probably holler if you changed everything. But then, that's what overloads are for.

On the plus side, let me say that I had immediate success uploading files with C# under both VS 2008 and Mono, which is my main objective.
Posted: 04/21/2011 23:16:14
by Eugene Mayevski (Team)

Thank you for your letter. The same code is used to build all editions (including upcoming ones) and initially it was not .NET code, so coding conventions etc were different. Now the code has plenty of ifdefs for conditional compilation for all supported platforms (and we already support more than a dozen of targets and we have more to come). So if we start rewriting code for every platform, we will waste time on rewriting rather than on investing this time in product development or customer support.

About some of your questions:

(2) the code is the same for .NET 1.1 and .NET 4.0 and templates appeared later than .NET 1.1.

Also, there can be problems with some more sophisticated language features - .NET is language-agnostic yet there are languages that don't understand some of newest features. We can't limit components to C# only or even to C# and VB.NET.

(3) the field is called so in SFTP specification. It contains *human-readable* entry, whose exact format is not specified. The field itself is optional and has been deprecated in SFTP 4. It's not recommended for use at all.

(4) It doesn't really matter where to place this code. You can do this in class declaration, in constructor, in InitializeComponent() or even in Open(), if you need.

(5) It's a bad idea to introduce unnecessary entities. If the entity is used in only one place, - it's a good candidate for removal. While I agree that readability is increased, actual work is hardened, cause when writing code you need to go to docs all the time to see where this or that constant is defined. And again see above remark on platform support.

Sincerely yours
Eugene Mayevski
Posted: 04/22/2011 17:55:41
by Stephen Richards (Standard support level)
Joined: 04/21/2011
Posts: 2

Thanks for your response.

As to point 5, I actually got the notion that enums are better than bools in situations like this from Cwalina & Abrams "Framework Design Guidelines" (ISBN 0321545613), which I think is a great book and well worth a read, for both library developers and others. It made me look at some of my own code, which had things like Foo(filename, mask, false, true, false), and realize that those bools just weren't that readable. They also aren't extensible, if in the future other possibilities besides true and false arise. (Hard to see that happening in this instance, but you see my point.)

Regarding having to "go to the docs", in an intellisense world that becomes less necessary. The function prototype will show that an (in my example) ElSftpDirSearch is called for, you type that in and hit "." and the easily read and understood values of the enum pop up. So it's a readability win and a code-ability, if that's a word, tie, in my opinion.

Thanks again for your response.
Posted: 04/25/2011 07:41:34
by Eugene Mayevski (Team)

Stephen Richards wrote:
They also aren't extensible, if in the future other possibilities besides true and false arise. (Hard to see that happening in this instance, but you see my point.)

They aren't with enums as well (only with int flag combinations).

In any case, nobody will rewrite hundreds of methods now.

Sincerely yours
Eugene Mayevski



Topic viewed 1335 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS business operates as a division of /n software, inc. For more information, please read the announcement.

Got it!