Re: please help me name a module
On Fri, Sep 13, 2013 at 01:24:59PM -0700, Greg Lindahl wrote: Exercise gear is another source of naming inspiration: existing modules are WWW::Nike::NikePlus, WWW::Jawbone::Up, a top level of GPS:: for gps eqipment. And nothing for FitBit. Not so organized. People search to find modules, they don't navigate hierarchies, so having a rigourous hierarchy doesn't matter much. However, having a sensible name does a few things: * the 'Tesla' in there makes it searchable; * 'Device::Car' there serves to disambiguate from some hypothetical future module like WWW::Museum::Tesla (for searching the Nikola Tesla museum's archives, perhaps) or Net::TESLA (Timed Efficient Stream Loss-tolerant Authentication protocol) or Device::Earthquake::Tesla; * a sensible name also helps someone maintaining code that uses your code to make a sensible guess about what your module does, and hence whether the bit of the application that uses your code is relevant to whatever he's trying to fix. -- David Cantrell | A machine for turning tea into grumpiness Vegetarian: n: a person who, due to malnutrition caused by poor lifestyle choices, is eight times more likely to catch TB than a normal person
Re: please help me name a module
On 13 September 2013 21:24, Greg Lindahl lind...@pbm.com wrote: On Fri, Sep 13, 2013 at 09:28:30AM +0100, Pearce, Martyn wrote: I think Car::Tesla:: ... is TRT here. Vehicle is nice and general, but I wouldn't expect to share a namespace with stuff for working with my pushbike speedo. Car:: is pretty clear and universal. +1 Internet-of-Things is an amusing byline for journos, but doesn't actually mean anything (or at least, I've never seen a definition that's actually useful). +1 again The very nature of ubiquitous computing is that it becomes invisible, normal and taken for granted - much as the internet is now. There's not an internet namespace on CPAN. It's interesting that all of you guys don't think much of the Internet of Things name. Here in the Silicon Valley we have talks, meetup groups, conferences, and startups focused on the phrase -- it's not driven by journalists. Silicon Valley right, because that's a community and industry that's the epitome of calm, stoical and rational and not at all chasing the latest fad and like, totally, reflects whats happening in the rest of the world. ;p I have no idea if it's going to stay popular by that name. Only in media and nerd circles, it'll be normalised and then have no name at all. As exciting as it seems now, consumers will take it for granted in no time. Cheers, A -- Aaron J Trevena, BSc Hons http://www.aarontrevena.co.uk LAMP System Integration, Development and Consulting On 13 September 2013 21:24, Greg Lindahl lind...@pbm.com wrote: On Fri, Sep 13, 2013 at 09:28:30AM +0100, Pearce, Martyn wrote: I think Car::Tesla:: ... is TRT here. Vehicle is nice and general, but I wouldn't expect to share a namespace with stuff for working with my pushbike speedo. Car:: is pretty clear and universal. Internet-of-Things is an amusing byline for journos, but doesn't actually mean anything (or at least, I've never seen a definition that's actually useful). It's interesting that all of you guys don't think much of the Internet of Things name. Here in the Silicon Valley we have talks, meetup groups, conferences, and startups focused on the phrase -- it's not driven by journalists. I have no idea if it's going to stay popular by that name. My use of the car sensors is very much in the Internet of Things style: I do the same kinds of maps and charts and statistics you'd do for your bike rides or hikes, and there's also stuff related to the fact that it's got a battery and charges and discharges. Exercise gear is another source of naming inspiration: existing modules are WWW::Nike::NikePlus, WWW::Jawbone::Up, a top level of GPS:: for gps eqipment. And nothing for FitBit. Not so organized. -- greg -- Aaron J Trevena, BSc Hons http://www.aarontrevena.co.uk LAMP System Integration, Development and Consulting
Re: please help me name a module
Greg Lindahl writes: On Thu, Sep 12, 2013 at 05:38:00PM +0100, Smylers wrote: How about Vehicle::Tesla::ModelS then? Does putting Device:: in front of that lot actually add anything, other than to the unwieldiness of the name? Vehicle:: doesn't generalize very well to toasters, refrigerators, etc. Does it have to? If modules for such household goods come along, how much does it help users for those modules to share a namespace with modules for vehicles? (Note they can share implementation, or not, independently of whether they share a namespace.) If a new top-level name is a good idea, It isn't a good idea _per se_; it's only a good idea if none of the existing ones seem to fit. I'd suggest an Internet-of-Things top-level, Thing:: or IoT:: or IOT:: Would somebody who has a Tesla car (or indeed a toaster) think of searching for IOT? Would somebody seeing IOT in a module name realize what it means? (I don't think I would.) “Thing” is such a generic word that I don't think prepending Thing:: adds any meaning at all. While you're using “thing” in quite a specific way, almost anything could be thought of as a thing. I'd say Device:: is more meaningful than Thing::. This particular module, btw, will probably be good for future Tesla vehicles; it's anyone's guess how the API will evolve. In that case go with your instinct and name it ::Tesla. If other Tesla APIs come into being (either for different cars or later versions for the Model S) your module can always be extended to cope with those somehow. Smylers -- Stop drug companies hiding negative research results. Sign the AllTrials petition to get all clinical research results published. Read more: http://www.alltrials.net/blog/the-alltrials-campaign/
Re: please help me name a module
# from Bill Ward on Thursday 12 September 2013: On Thu, Sep 12, 2013 at 8:56 PM, Greg Lindahl lind...@pbm.com wrote: Vehicle:: doesn't generalize very well to toasters, refrigerators, etc. If a new top-level name is a good idea, I'd suggest an Internet-of-Things top-level, Thing:: or IoT:: or IOT:: ... Thing::Vehicle::Tesla::ModelS? A::Vehicle::Tesla::ModelS I don't think it's strictly necessary to generalize the top-level namespace. Would one be unable to locate the refrigerator interface module without it being filed under things? It might be better as Car::Tesla::ModelS or Tesla::ModelS. --Eric -- --- http://scratchcomputing.com ---
RE: please help me name a module
I think Car::Tesla:: ... is TRT here. Vehicle is nice and general, but I wouldn't expect to share a namespace with stuff for working with my pushbike speedo. Car:: is pretty clear and universal. Internet-of-Things is an amusing byline for journos, but doesn't actually mean anything (or at least, I've never seen a definition that's actually useful). -Original Message- From: Eric Wilhelm [mailto:enoba...@gmail.com] Sent: Friday, September 13, 2013 9:18 AM To: module-authors@perl.org Subject: Re: please help me name a module # from Bill Ward on Thursday 12 September 2013: On Thu, Sep 12, 2013 at 8:56 PM, Greg Lindahl lind...@pbm.com wrote: Vehicle:: doesn't generalize very well to toasters, refrigerators, etc. If a new top-level name is a good idea, I'd suggest an Internet-of-Things top-level, Thing:: or IoT:: or IOT:: ... Thing::Vehicle::Tesla::ModelS? A::Vehicle::Tesla::ModelS I don't think it's strictly necessary to generalize the top-level namespace. Would one be unable to locate the refrigerator interface module without it being filed under things? It might be better as Car::Tesla::ModelS or Tesla::ModelS. --Eric -- --- http://scratchcomputing.com ---
Re: please help me name a module
On Fri, Sep 13, 2013 at 09:28:30AM +0100, Pearce, Martyn wrote: I think Car::Tesla:: ... is TRT here. Vehicle is nice and general, but I wouldn't expect to share a namespace with stuff for working with my pushbike speedo. Car:: is pretty clear and universal. Internet-of-Things is an amusing byline for journos, but doesn't actually mean anything (or at least, I've never seen a definition that's actually useful). It's interesting that all of you guys don't think much of the Internet of Things name. Here in the Silicon Valley we have talks, meetup groups, conferences, and startups focused on the phrase -- it's not driven by journalists. I have no idea if it's going to stay popular by that name. My use of the car sensors is very much in the Internet of Things style: I do the same kinds of maps and charts and statistics you'd do for your bike rides or hikes, and there's also stuff related to the fact that it's got a battery and charges and discharges. Exercise gear is another source of naming inspiration: existing modules are WWW::Nike::NikePlus, WWW::Jawbone::Up, a top level of GPS:: for gps eqipment. And nothing for FitBit. Not so organized. -- greg
Re: please help me name a module
I'd go for Device::Car::Tesla(::ModelS)?. Car, not Auto, because in most of the English-speaking world auto means automatic, not automobile. -- David Cantrell This electrogram was despatched by wireless field telegraph. I would therefore ask that the recipient be so kind as to excuse any failures of courtesy or linguistic inelegance as an unfortunate side-effect of the technology. On 11 Sep 2013, at 18:49, Greg Lindahl lind...@pbm.com wrote: I have a module that talks to my car, a Tesla Model S. You can get speed and position, remotely turn on the AC, all that good stuff. These sorts of things are sometimes called the Internet of Things, or IOT. Looking in CPAN I don't see any existing modules for cars or mentioning the Internet of Things. There is a top-level group named Device that might be useful ... Device::Tesla? Device::Auto::Tesla ? Thanks in advance! -- greg
Re: please help me name a module
On Thu, 12 Sep 2013 12:15:22 +0100 David Cantrell da...@cantrell.org.uk wrote: I'd go for Device::Car::Tesla(::ModelS)?. Car, not Auto, because in most of the English-speaking world auto means automatic, not automobile. This ^. Also, I would suggest including the ::ModelS, as it's entirely possible that Tesla will release budget modules in future which won't support all the cool stuff. (Also, it might be a case of a Device::Car::Tesla base class providing functionality which is common to most Tesla models, and model-specific subclasses which implement extra features only that model has, for instance.) I think it's pretty cool that we're to the point of what do I name a module that interfaces with my car :)
Re: please help me name a module
I'd suggest Vehicle instead of Car since future instances might be trucks, vans, motorcycles, etc. Sent from my phone (sorry if my reply is brief, ask me again when I'm at a real keyboard) On Sep 12, 2013 1:47 AM, Aaron Trevena aaron.trev...@gmail.com wrote: On 12 September 2013 07:58, Aristotle Pagaltzis pagalt...@gmx.de wrote: * Greg Lindahl lind...@pbm.com [2013-09-11 22:45]: I have a module that talks to my car, a Tesla Model S. You can get speed and position, remotely turn on the AC, all that good stuff. Cool!! +1 serious envy! These sorts of things are sometimes called the Internet of Things, or IOT. Looking in CPAN I don't see any existing modules for cars or mentioning the Internet of Things. There is a top-level group named Device that might be useful ... Device::Tesla? Device::Auto::Tesla ? That was the TLNS I immediately thought of. Device::Car::Tesla? Yes, much better. Auto is ambiguous and rarely used to refer to cars except by merkins. A.
Re: please help me name a module
On Thu, Sep 12, 2013 at 9:38 AM, Smylers smyl...@stripey.com wrote: David Precious writes: On Thu, 12 Sep 2013 12:15:22 +0100 David Cantrell da...@cantrell.org.uk wrote: I'd go for Device::Car::Tesla(::ModelS)?. Car, not Auto, because in most of the English-speaking world auto means automatic, not automobile. Also, I would suggest including the ::ModelS, as it's entirely possible that Tesla will release budget modules in future which won't support all the cool stuff. Bill Ward writes: I'd suggest Vehicle instead of Car since future instances might be trucks, vans, motorcycles, etc. How about Vehicle::Tesla::ModelS then? Does putting Device:: in front of that lot actually add anything, other than to the unwieldiness of the name? I like that -- Check out my LEGO blog at brickpile.com http://www.brickpile.com/ Follow/friend me: Facebook http://facebook.com/billward • Flickrhttp://flickr.com/photos/billward/• Twitter http://twitter.com/williamward • LinkedInhttp://www.linkedin.com/pub/william-ward/63/393/985/
Re: please help me name a module
David Precious writes: On Thu, 12 Sep 2013 12:15:22 +0100 David Cantrell da...@cantrell.org.uk wrote: I'd go for Device::Car::Tesla(::ModelS)?. Car, not Auto, because in most of the English-speaking world auto means automatic, not automobile. Also, I would suggest including the ::ModelS, as it's entirely possible that Tesla will release budget modules in future which won't support all the cool stuff. Bill Ward writes: I'd suggest Vehicle instead of Car since future instances might be trucks, vans, motorcycles, etc. How about Vehicle::Tesla::ModelS then? Does putting Device:: in front of that lot actually add anything, other than to the unwieldiness of the name? Smylers -- Stop drug companies hiding negative research results. Sign the AllTrials petition to get all clinical research results published. Read more: http://www.alltrials.net/blog/the-alltrials-campaign/
Re: please help me name a module
On Thu, Sep 12, 2013 at 05:38:00PM +0100, Smylers wrote: How about Vehicle::Tesla::ModelS then? Does putting Device:: in front of that lot actually add anything, other than to the unwieldiness of the name? Vehicle:: doesn't generalize very well to toasters, refrigerators, etc. If a new top-level name is a good idea, I'd suggest an Internet-of-Things top-level, Thing:: or IoT:: or IOT:: This particular module, btw, will probably be good for future Tesla vehicles; it's anyone's guess how the API will evolve. In fact, at the moment it's just the reverse-engineered API used by the Tesla iOS and Android apps; nothing officially supported. I'll have to have a big fat dislciamer at the top of the POD... -- greg
Re: please help me name a module
On Thu, Sep 12, 2013 at 8:56 PM, Greg Lindahl lind...@pbm.com wrote: On Thu, Sep 12, 2013 at 05:38:00PM +0100, Smylers wrote: How about Vehicle::Tesla::ModelS then? Does putting Device:: in front of that lot actually add anything, other than to the unwieldiness of the name? Vehicle:: doesn't generalize very well to toasters, refrigerators, etc. If a new top-level name is a good idea, I'd suggest an Internet-of-Things top-level, Thing:: or IoT:: or IOT:: This particular module, btw, will probably be good for future Tesla vehicles; it's anyone's guess how the API will evolve. In fact, at the moment it's just the reverse-engineered API used by the Tesla iOS and Android apps; nothing officially supported. I'll have to have a big fat dislciamer at the top of the POD... Thing::Vehicle::Tesla::ModelS? -- Check out my LEGO blog at brickpile.com http://www.brickpile.com/ Follow/friend me: Facebook http://facebook.com/billward • Flickrhttp://flickr.com/photos/billward/• Twitter http://twitter.com/williamward • LinkedInhttp://www.linkedin.com/pub/william-ward/63/393/985/
please help me name a module
I have a module that talks to my car, a Tesla Model S. You can get speed and position, remotely turn on the AC, all that good stuff. These sorts of things are sometimes called the Internet of Things, or IOT. Looking in CPAN I don't see any existing modules for cars or mentioning the Internet of Things. There is a top-level group named Device that might be useful ... Device::Tesla? Device::Auto::Tesla ? Thanks in advance! -- greg
Re: Please help me name a module for lossy text compression
I have a similar conundrum. I'm writing a suite of preprocessors for Rozenshtein delta functions (aka Encoded Characteristic functions). The basic idea is really simple, and I imagine embedded quite deeply in the Perl psyche. The idea is that the delta function δ[x⊜y], where ⊜ is any comparison operator and the expression x⊜y returns boolean true or false, evaluates the comparison and returns 1 if true, or 0 if false. The great thing (for me) is that there are rewrites from delta functions to plain ol' math for all the common comparisons -- rewrites that can be expressed in languages without a built-in IF or CASE statement. For example, δ[x=y] can be expanded to 1 - abs(sign(x - y)). The Perl expansion of any delta function δ[x⊜y] is simply !!(x⊜y), but not all languages are as forgiving. Anyway. Enough exposition. The problem I'm solving is to provide a suite of rewrite engines for various programming languages that detect embedded δ functions and rewrite them using the appropriate syntax for the containing language. Right now, I'm considering the Text::Rewrite::DeltaExpression::(.*) namespace where $1 is the target language. Any suggestions from y'all about better places to put it? Does Text::Filter::DeltaExpression::(.*) more closely fit what the community would be expecting? Thanks, -- Paul Bennett (aka PWBENNETT) On Wed, Dec 19, 2012 at 10:26 PM, Brian Katzung bri...@kappacs.com wrote: Ben, How about creating Text::Filter::LowerCase and Text::Filter::Unpunctuate as derived classes of Text::Filter? - Brian On 2012-12-19 13:56, Ben Deutsch wrote: Hello, I'm writing a small module to apply lossy filters to text, to enable better subsequent lossless compression. For example, Hello, World! would become hello, world! with the lowercase filter, or Hello World with the punctuation removal filter. This does not apply the actual compression, it just reduces the entropy of the text in question. As a working title, I'm using Text::Lossy as the module name. But Text is quite a large and well-known top-level namespace, so I'm asking if this is a good fit, and if not, what I might call the module instead. One thing I do *not* want to do is place it in the Acme namespace – the module may sound a bit silly, but it strives to do exactly what it says on the tin: every filter reduces the entropy while still retaining most of the meaning. For example, reducing the entire text to the empty string (while great for compression) is straight out. Thanks for your time, Ben Deutsch -- Brian Katzung, Kappa Computer Solutions, LLC Offering web, client/server, open source, and traditional software development and mixed operating system support for business, education, and science Phone: 847.412.0713 http://www.kappacs.com
Re: Please help me name a module for lossy text compression
On second thought... Text::Filter::NoPunctuation is probably better than ::Unpunctuate. However, a more general solution might be Text::Filter::Transliterate (using tr with from and to mappings passed to the filter) and Text::Filter::Delete (deleting characters specified according to a string or regex). - Brian On 2012-12-19 21:26, Brian Katzung wrote: Ben, How about creating Text::Filter::LowerCase and Text::Filter::Unpunctuate as derived classes of Text::Filter? - Brian On 2012-12-19 13:56, Ben Deutsch wrote: Hello, I'm writing a small module to apply lossy filters to text, to enable better subsequent lossless compression. For example, Hello, World! would become hello, world! with the lowercase filter, or Hello World with the punctuation removal filter. This does not apply the actual compression, it just reduces the entropy of the text in question. As a working title, I'm using Text::Lossy as the module name. But Text is quite a large and well-known top-level namespace, so I'm asking if this is a good fit, and if not, what I might call the module instead. One thing I do *not* want to do is place it in the Acme namespace – the module may sound a bit silly, but it strives to do exactly what it says on the tin: every filter reduces the entropy while still retaining most of the meaning. For example, reducing the entire text to the empty string (while great for compression) is straight out. Thanks for your time, Ben Deutsch -- Brian Katzung, Kappa Computer Solutions, LLC Offering web, client/server, open source, and traditional software development and mixed operating system support for business, education, and science Phone: 847.412.0713 http://www.kappacs.com
Re: Please help me name a module for lossy text compression
On Thu, Dec 20, 2012 at 11:09 AM, Brian Katzung bri...@kappacs.com wrote: On second thought... Text::Filter::NoPunctuation is probably better than ::Unpunctuate. ::StripPunctuation would be even more descriptive. -- Darren Chamberlain d...@sevenroot.org
Re: Please help me name a module for lossy text compression
Hello everyone, How about creating Text::Filter::LowerCase and Text::Filter::Unpunctuate as derived classes of Text::Filter? I had peeked at Text::Filter before, and had deemed it great as a transport mechanism (handling various in- and outputs, which my module deliberately would *not* cover), but I had left with the impression that this was strictly line-based, which is not enough for some of the filters I'm planning, and couldn't handle filter parameters. However, I've had another look, and discovered the peek-and-pushback mechanisms. So I'll subclass Text::Filter. I'm now going with Text::Filter::Lossy, since I want to keep (most of the) filters in one place, and also to enable easy programmatic sub-filter selection, for example from command line arguments. Thanks for the pointers, everyone! Ben Deutsch
Re: Please help me name a module for lossy text compression
Hello Paul, I have a similar conundrum. I'm writing a suite of preprocessors for Rozenshtein delta functions (aka Encoded Characteristic functions). The basic idea is really simple […] Right now, I'm considering the Text::Rewrite::DeltaExpression::(.*) namespace where $1 is the target language. Any suggestions from y'all about better places to put it? Does Text::Filter::DeltaExpression::(.*) more closely fit what the community would be expecting? As Brian pointed out in a reply to my question, there's a Text::Filter module, which is meant for subclassing. Text::Filter::DeltaExpression:: would sound like a subclass of this to me. Have you had a look at Text::Filter? If your filters work primarily line-based, it's probably a good fit. Regards, Ben Deutsch
Please help me name a module for lossy text compression
Hello, I'm writing a small module to apply lossy filters to text, to enable better subsequent lossless compression. For example, Hello, World! would become hello, world! with the lowercase filter, or Hello World with the punctuation removal filter. This does not apply the actual compression, it just reduces the entropy of the text in question. As a working title, I'm using Text::Lossy as the module name. But Text is quite a large and well-known top-level namespace, so I'm asking if this is a good fit, and if not, what I might call the module instead. One thing I do *not* want to do is place it in the Acme namespace – the module may sound a bit silly, but it strives to do exactly what it says on the tin: every filter reduces the entropy while still retaining most of the meaning. For example, reducing the entire text to the empty string (while great for compression) is straight out. Thanks for your time, Ben Deutsch
Re: Please help me name a module for lossy text compression
Ben, How about creating Text::Filter::LowerCase and Text::Filter::Unpunctuate as derived classes of Text::Filter? - Brian On 2012-12-19 13:56, Ben Deutsch wrote: Hello, I'm writing a small module to apply lossy filters to text, to enable better subsequent lossless compression. For example, Hello, World! would become hello, world! with the lowercase filter, or Hello World with the punctuation removal filter. This does not apply the actual compression, it just reduces the entropy of the text in question. As a working title, I'm using Text::Lossy as the module name. But Text is quite a large and well-known top-level namespace, so I'm asking if this is a good fit, and if not, what I might call the module instead. One thing I do *not* want to do is place it in the Acme namespace – the module may sound a bit silly, but it strives to do exactly what it says on the tin: every filter reduces the entropy while still retaining most of the meaning. For example, reducing the entire text to the empty string (while great for compression) is straight out. Thanks for your time, Ben Deutsch -- Brian Katzung, Kappa Computer Solutions, LLC Offering web, client/server, open source, and traditional software development and mixed operating system support for business, education, and science Phone: 847.412.0713 http://www.kappacs.com
