Lex Spoon wrote:
> 
> > If a SerialPort is not useable until its parameters have been set, then the
> > SerialPort code needs to be factored thusly:
> >
> > add
> >   SerialPort class>>baudRate:dataBits:parityType:stopBitsType:
> > and maybe even
> >   SerialPort class>>openOnBaudRate:dataBits:parityType:stopBitsType:
> > and (if you are a real purist) remove
> >   SerialPort class>>new
> > (ie. throw an exception or do self shouldNotImplement)
> >
> 
> The downside is that you no longer get default parameters.  Thus you
> either add lots of combinations of the instance creation method, or you
> force everyone to use the long version even  when they only care about
> one or two options.  Thus the opposite refactoring can make sense as
> well: take an instance creation method with bunches of parameters, and
> turn them into individual initialization methods.  A more extreme
> example of this is HTTPSocket.

Actually the defaults are still available. Just do

SerialPort new

Which implicitly calls SerialPort>>initialize

The real problem, which I missed on the first pass, was the changing of
parameters after the opening of the port. Having worked with serial
ports often in the past I would never do that, but I can understand how
someone might to try to do so.

So... a fix that would satisfy both camps would be to add something like
this to all of the parameter setting methods.  I'll pick on baudRate:

baudRate: anInteger
     baudRate := anInteger.
     self resetOnOpenPort.

resetOnOpenPort
     port ifNotNil: [openPort: port].

Note that openPort: closes the port before it opens it.

If you wanted to prevent the user from changing the parameters to an
open port, it would take same amount of code, but with the reopen
approach Alexandre's code works the first time. And I can change baud
rate or other configuration parameters on the fly.

If I get any positive comments on this approach, I'll send in a
changeset.

Steve