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)

when XPers start ranting and raving, frothing at the mouth and just
generally droning on about how comments are evil and code should be
readable, this is the kind of thing they are talking about. In this case
the SerialPort code didn't communicate the fact that you have to assign
baud rate, data bits, parity type and stop bits before it can be opened and
used. Solution: put these parameters in a constructor (and enforce the use
of that constuctor).

The first thing you always want to know about a Class is What do I have to
do to get a usable instance? Constructors answer that question quickly and
easily.

see also Smalltalk Best Practice Patterns by Kent Beck, pgs 23-27.

i was going to attach a change set, but it looks like Steve Gilbert beat me
to it. :)

david


At 08:33 AM 2/11/02 -0800, you wrote:
>On Monday 11 February 2002 03:19 am, Bergel Alexandre wrote:
>
>> These feature seems a good candidate for a fix. Also, I have lost more than
>> one week for how to open a serial port connection.
>
>You should have checked the list archives. I've said a number of times that 
>you have to set up the parameters _before_ a serial port open (no, that's
not 
>my fault; it was that way already in the Mac interface).
>
>Sorry you lost a week.
>
>> Of course, parameters are given to SerialPort plugin only when it is
>> opened. Anyway, 1 week lost only for that. I think it should be interesting
>> to throw at least an exception when parameters try to be changed after to
>> open it.
>
>Easy to do.
>
>> Also I am working on integration of RCX management for Squeak. Actually, I
>> have a prototype which work, BUT, with some serialplugin fixes (I have
>> remove O_NONBLOCK|O_NOCTTY option for system open function call).
>
>Why should you need this? Especially the O_NOCTTY bit?
>
>And the O_NONBLOCK is only going to keep you from being able to open the
port 
>if you have handshaking enabled but the state is inactive.
>
>You shouldn't need to modify this.
>
>Instead, use polling (in a separate Process) and a SharedQueue to
communicate 
>any characters received. Then assemble them using a Stream until you have 
>enough response to deal with.
>
>I realize this isn't the best way to do things in the Serial world.
>
>Have you looked at Craig's Flow? I understand he has also tackled the 
>SerialPort stuff...
>
>-- 
>Ned Konz
>currently: Stanwood, WA
>email:     ned at bike-nomad.com
>homepage:  http://bike-nomad.com
>
>
--
David Farber
dfarber at numenor.com