On Tue, Apr 06, 2010 at 01:07:33AM +0300, Sawyer X wrote:
>    On Mon, Apr 5, 2010 at 11:29 PM, Tim Bunce <[1]tim.bu...@pobox.com> wrote:
> 
>      "Data" is fairly meaningless as a name. The Data:: is intended to be
>      used for modules that work with abstract data values: Data::Bind,
>      Data::Bucket, Data::BitMask, Data::COW etc.
> 
>    Thank you for taking the time to comment!
> 
>    Meanwhile, while writing all the docs in order to be able to release 
> properly to CPAN, I've also renamed
>    it to Data::Collector. I think it's a more accurate term than 
> Data::Scanner, since it doesn't really
>    "scan" anything. It provides a small framework for collecting information.
> 
>      There's a Sys:: namespace that has things like Sys::Info. (Perhaps you
>      could integrate with that.)
> 
>    Even though I will be using this in a system environment (trying to get 
> information on the system -
>    where Sys::Info might be useful), Data::Collector was built with 
> flexibility in mind, and can be used
>    for things not related to a system at all.
> 
>    You could write Data::Collector::Info::Dilbert to have a piece of info 
> that fetches Dilbert comics, for
>    example. You could have a Data::Collector::Info::MyCorpIncCustomerInfo and 
> so on. Pretty much like
>    plugins so anything homegrown can be used with it without altering 
> anything. I reckon that's why
>    settling down to a specific type of data will not be right.
> 
>      Generally speaking the more specialized the module the more
>      words-per-level the name should have.
> 
>    I reckon that is why Sys::Collector is probably not a good bet, since it's 
> not necessarily system
>    information.
>    It gets even trickier since the data can be returned in various forms 
> (XML, JSON, Data::Dumper. YAML,
>    Perl objects - these I had already implemented as Data::Collector core 
> serializing engines along the
>    way).
> 
>    Thanks again, I appreciate the response, it helped me understand it more.
> 
>    "Abstract data values" seems like what I'm going for, so it looks like a 
> good match.

"You could write Data::Collector::Info::Dilbert to have a piece of info
that fetches Dilbert comics". That's far from abstract in the sense that
Data:: was indended for.

I believe you're thinking of what I'd call "generic", and you called it
a "framework" yourself.

On CPAN frameworks, especially generic ones with plugins etc., are
encouraged to have "brand names". Think Catalyst, Mojo, Smolder, Plack,
Dist::Zilla to name a few off the top of my head.

Posting the docs may help.

Tim.

Reply via email to