On Thu, 22 Oct 2015 11:39:00 +0100 Matthew Astley <m...@sanger.ac.uk> wrote:
> The Bus::I2C:: namespace seems safe. Short, unambiguous, unlikely to > have a legitimate claim from software. > > Under that you could put chip names like Bus::I2C::DS1307 [1] but I > suspect software will fit better by function like Bus::I2C::EEPROM [2] > since families of chips will naturally share code. Hmm. I'm not sure I like "Bus" - the driver talks to just one device, one chip. If it sits on a bus like I2C that's a different concern. I wonder if simply Device::Chip::* > The CPAN search for just I2C shows a few things, > > https://metacpan.org/release/i2c (i2c_{ser,lpt}) > https://metacpan.org/pod/HiPi (various under HiPi::*) > https://metacpan.org/pod/Device::LPS331AP > https://metacpan.org/pod/Device::Gyroscope::L3GD20 > https://metacpan.org/pod/Device::SMBus > https://metacpan.org/pod/Device::WebIO::Device::I2CUser > > so it's probably too late to converge on one perfect naming scheme > anyway. Well there's at least some precedent for putting it under Device::, so that's a start :) > I don't see a way to avoid the usual problem with someone releasing > Bus::I2C::EEPROM::Lite and Bus::I2C::EEPROM::Tiny after the first come > module gets bloated out with obsolete parts. Eh... That's a standard problem across the whole of CPAN. We usually cope fairly well... :) -- Paul "LeoNerd" Evans leon...@leonerd.org.uk http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS
pgpNytw7D0Z3W.pgp
Description: OpenPGP digital signature
