Re: [Libphidget-devel] serial numbers

[Vadim T. <vt...@fr...>]

According to fit...@ph...:

> > Then, the string serves as good as the number, though you can a) add more
> > significant information to it (like, the release variations, or specific
> > options included into an instance of a phidget), b) extend the address space
> > (though this is rather theoretical at this moment).
> >
> > How much of the existing code will break if the serial happens to be a
> > malformed number?
> 
> Well, it doesn't bother me very much, because I just release a new Windows
> version and tell everyone to go use it.  It's nice owning your own
> sandbox.  I just try not to change it all the time..  As long as my
> library is smart enough to figure out all the old phidgets, I don't worry
> about broken code.
> 
> I don't think it's really worth mucking with, because USB provides other
> mechanisms for device versioning, and so forth.  Particularly with the HID
> devices.
> 
> With the soft phidgets, all that data, including the serial number,
> version, .... extraneous information like programmable logic
> device firmware versions, get stored into a fat EEPROM.  And it makes no
> sense to cram everything into the serial number when it can stay
> structured?

True. My rationale, though, was: Occam's Razor. Why should I parse the
serial to number when it is *enough* to treat it as a string?

One reason I might think of: memory. But is this reason good enough? Not to
me - how many phidgets will I have on the adapter, and how many bytes will I
lose if I store serials as numbers? Definitely less than amount of code
necessary to parse it...

Performance - how often do I have to compare the serial with something?
Don't think more than once - at initialization.

Just thinking aloud...
 
> Chester

--vt