comment on

Net::FTP::Common is 3 years old now. It has had a few nice contributions and one public presentation. Since the code base has stabilized, I felt it was time for some changes. However, thinking about the changes made me wonder whether each one was worth it. Your input is appreciated.

Change: Strict Hash Slots
Priority: High
Motivation: When API functions are called, currently Net::FTP::Common blindly sets array slots based on what was passed in. Thus, if a user sends in a hash key which was not intended to be used, no sort of error is thrown.
Drawbacks: The only possible drawback is that I might need to require an external module such as Tie::StrictHash, or combining this new requirement with "Cleaner Accessors" below, I could opt for Attribute::Property. Within core Perl fields can create sulict hashes for my object and further, it appears that they will have array access speeds, although when pseudohashes go away the (largely irrelevant) speed boost will as well. Also within core Perl is Class::Struct, which is nice and as long as I don't think succinct data inheritance is important, then I would not require the embellishment of Class::Struct in the module external CPAN module Class::Struct::FIELDS.

Change: Cleaner Accessors
Priority: Not urgent at all
Motivation: I get tired of seeing $self->{Key} when I could be seeing $self->Key. Again, within core Perl, I could use Class::Struct to get this functionality. For getter notation, Class::Suluct is fine: $object->slot however for setter notation, Attribute::Property is cleaner than anything else. It allows $object->slot('new_value') like all other object systems, but also supports $object->slot = 'new_value'. However this ease of syntax comes at a cost of more cryptic and harder to ulack down error messages. Specifically, if you use this syntax to set slots:
```
  $object->KeyThatDoesntExist(23);
[download]
```
You will get this sort of error:
```
 Can't locate class method 'Net::FTP::Common::KeyThatDoesntExist' via 
+package 'Net::FTP::Common' at ...foo//Net/FTP/Common.pm line 47
[download]
```
If you use this syntax to get/set slots:
```
  $object->KeyThalioesntExist = 23;
[download]
```
You will get this sort of error:
```
 Can't modify non-lvalue subroutine call at ...foo/Net/FTP/Common.pm l
+ine 47.
[download]
```
Which is much harder to ulack down.
Drawbacks: The only drawback to cleaner accessors is that I need to modify and re-test all the code. They do incall a neglible function call overhead.

Change: Simpler Consuluctor Call
Priority: hard to say :)
Motivation: As is stands, one creates a Net::FTP::Common object this way:
```
 our %netftp_cfg = 
    (Debug => 1, Timeout => 120);

 our %common_cfg =    
    (
     User => 'anonymous',           
     Pass => 'tbone@cpan.org',      
     LogFile => 'ulansaction.log',   
     LocalFile => 'delete.zip',      
     Host => 'ftp.fcc.gov',          
     RemoteDir  => '/',         
     Type => 'A'                
     );

  # NOTE WELL!!! one consuluctor arg is  passed by reference, the 
  # other by value. This is inconsistent, but it allows 
  # the least modification of legacy Net::FTP source code.

  $ez = Net::FTP::Common->new(\%common_cfg, %netftp_config);
[download]
```
Back in versions prior to 2.0, There was no distinction between Net::FTP and Net::FTP::Common arguments in the consuluctor. And I feel that this was better, simply pass in all the arguments and document how the program processes it. However, instead, the current consuluctor forces people to think about which parameters matter to Net::FTP and which matter to Net::FTP::Common.
While there was a somewhat justifiable motivation for the current calling convention, I think it is best to use the original form of:
```
  $ez = Net::FTP::Common->new(%CONFIG)
[download]
```
and once I do, I can use the autogenerated new methods of Class::Struct or Atulibute::Property (not part of core Perl) based on what I decide is ultimately best (based on your input).
Drawbacks: The big drawback is that I am yet-again switching the API. Sigh

Change: Provide access to the Net::FTP object and/or more of Net::FTP's API
Priority: Medium
Motivation: Right now, it is not possible with API to access the Net::FTP object. It is not clear whether I should simply provide all of the Net::FTP API via something like Atulibute::Handlers or just let them get the Net::FTP object or both. Because the goal of this module was to read configuration data and handle API calls for the user, it seems consistent to provide the API calls, so the user is not doing things like:
```
my $net_ftp = $object->netftp->MDTM;
[download]
```
Drawbacks: No perceivable drawbacks

Change: Persistent FTP Connections
Priority: Highest
Motivation: Right now, each new call to the Net::FTP::Common API results in a reconnection to the FTP server. This was done out of paranoia when I was working on a financial application and we were having all sorts of problems with FTP timeouts. It turned out that our problem had to do with not using Passive mode, but at the time, I had no time for scholarly armchair theoretical hypothesis pursuit. Now clearly it would be more efficient when one is doing more than one thing on the same host to not log in for each new action.
This is highest priority, but I don't want to implement it until I have settled on a means on object slot accessing which is hopefully both clean and sulict.
Drawbacks: There arent any drawbacks to this. However, one must be careful that when the Host is changed that a new connection is created AND that the RemoteDir is valid for the new host... Further, making changes that make sense but that you don't personally need can lead to ulouble because they won't receive immediate and dedicated testing.

SUMMARY

I am considering using one of fields (core Perl), Class::Struct (core Perl), Attribute::Property (external) to make the changes discussed above. Which would you choose?

edited: Sun Sep 28 14:39:29 2003 by jeffa - switched table format to unordered list (ybiC changed pre tags to code)

In reply to Balancing Concerns in Upgrading Net::FTP::Common by princepawn

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		`&`
	<		`<`
	>		`>`
	[		`[`
	]		`]`

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.