Re: Help on module name (working name 'Regexp::Query' - UPDATE: now 'Grep::Query')

[kenneth]

In case anyone is interested a working module is now available at 
https://github.com/kenneth-olwing/grep-query.git, also see an entry for 
it on PrePAN.


ken1

On 2016-07-26 10:39, kenn...@olwing.se wrote:

Hi David,

Many thanks for taking the time!


...
So, first of all, please do not take Scrooge. I am rather fond of that
name, and plan to publish my module with that name some day.


Noted :-) !


As to your idea, it looks like you're working with something like
grep. The key difference is that you provide some sort string parsing
for queries, along with a way to add keywords to those queries. In
that case, I think that GREP::QUERY might be the best name.


Yes - this is clearly better as it captures the essence. Basically:
'using this criteria, whittle down this list for me', which in normal
grep-speak means 'criteria' is either a BLOCK or EXPR, whereas I sort
of give the ability to have criteria be 'ARBITRARY QUERY'.

So yes, there's a small parser involved to parse the query language
(uses Parse::RecDescent for grammar).

Actually, I've already called the main method 'qgrep(...)' (i.e.
'query grep'), and also supply a tiny 'qgrep' script as a way to write
"qgrep 'some_query' ..." on the command line. So I should have seen it
coming :-).


Another
possibility, if you want to some day add map-like capabilities as
well, would be a top-level namespace. The name Matchbox comes to mind,
for some odd reason, with Matchbox::Grep and Matchbox::Map being your
two major namespaces.


I can't quite see what to do with that at the moment so I think
'Grep::Query' is a favourite right now. Given the fact that the actual
querying can be inside a block and on 'lists' with a single item, it
can be used in a map situation also. But any suggestions to do
something easier/better for map may be worth considering.

ken1

Re: Help on module name (working name 'Regexp::Query' - UPDATE: now 'Grep::Query')

[kenneth]

Hi David,

Many thanks for taking the time!


...
So, first of all, please do not take Scrooge. I am rather fond of that
name, and plan to publish my module with that name some day.


Noted :-) !


As to your idea, it looks like you're working with something like
grep. The key difference is that you provide some sort string parsing
for queries, along with a way to add keywords to those queries. In
that case, I think that GREP::QUERY might be the best name.


Yes - this is clearly better as it captures the essence. Basically: 
'using this criteria, whittle down this list for me', which in normal 
grep-speak means 'criteria' is either a BLOCK or EXPR, whereas I sort of 
give the ability to have criteria be 'ARBITRARY QUERY'.


So yes, there's a small parser involved to parse the query language 
(uses Parse::RecDescent for grammar).


Actually, I've already called the main method 'qgrep(...)' (i.e. 'query 
grep'), and also supply a tiny 'qgrep' script as a way to write "qgrep 
'some_query' ..." on the command line. So I should have seen it coming 
:-).



Another
possibility, if you want to some day add map-like capabilities as
well, would be a top-level namespace. The name Matchbox comes to mind,
for some odd reason, with Matchbox::Grep and Matchbox::Map being your
two major namespaces.


I can't quite see what to do with that at the moment so I think 
'Grep::Query' is a favourite right now. Given the fact that the actual 
querying can be inside a block and on 'lists' with a single item, it can 
be used in a map situation also. But any suggestions to do something 
easier/better for map may be worth considering.


ken1

Re: Help on module name (working name 'Regexp::Query')

[David Mertens]

Hello Kenneth,

My background: I have been working on a generic greedy pattern matching
engine for my years. It is called Scrooge. The original itch was to be able
to write "regexes" for numerical data (i.e. PDL). It took a long time
before that idea grew into an implementation (starting around 2012), which
then morphed into a generic sequential greedy pattern matching engine for
arrays of any type. I don't know if it handles hashes yet, but they will be
easy to weave in as arrays of zero length that are tested with zero-width
assertions. (If anybody is interested, my current development is at
https://github.com/run4flat/perl-Scrooge.)

So, first of all, please do not take Scrooge. I am rather fond of that
name, and plan to publish my module with that name some day.

As to your idea, it looks like you're working with something like grep. The
key difference is that you provide some sort string parsing for queries,
along with a way to add keywords to those queries. In that case, I think
that *Grep::Query* might be the best name. Another possibility, if you want
to some day add map-like capabilities as well, would be a top-level
namespace. The name Matchbox comes to mind, for some odd reason, with
Matchbox::Grep and Matchbox::Map being your two major namespaces.

That's just my two cents. I hope that helps.
David

On Mon, Jul 25, 2016 at 6:20 AM,  wrote:

> Hello all,
>
> I'd like to request some advice/thoughs/help on selecting a name for a
> module.
> The working name is 'Regexp::Query', but as it happens the realization of
> the
> original idea has moved slightly ahead of that so I'm no longer confident
> on the
> suitability...
>
> The Scratched Itch:
>
> I have a large number of commandline tools, and quite frequently I want
> the user
> to be able to express, with some flag(s), a selection among something.
>
> Example: the user gives the command
>
>   SomeCommand /some/path
>
> and it will scan the path and for all files it finds it will do something
> useful. Now, I also want to provide flags for the command such that they
> can say
>
>   SomeCommand -exclude 'some_regexp' /some/path
>
> Obviously not a problem, and I also provide the reverse if that is more
> convenient:
>
>   SomeCommand -include 'another_regexp' /some/path
>
> and this can be extended so flags can be given multiple times and
> interweaved:
>
>   SomeCommand -include 'rx1' -exclude 'rx2' -include 'rx3' /some/path
>
> coupled with rules that then shrinks the target set based on rx1, shrinks
> that
> set using rx2 etc etc. I think you get the idea.
>
> What I found however is that it becomes hard to string together regexps to
> find
> the exact subset you want. In fact, while regexps are powerful, they're
> not that
> suited to easily mix multiple of them, and some expressions are basically
> impossible, especially to provide a commandline interface to them...
>
> Thus, instead I'd like to provide a more capable way for a user to provide
> a
> more complex query, i.e. where it'd be possible to use AND/OR/NOT,
> including
> parenthesized, e.g. something very contrived:
>
>   (
> REGEXP/some_rx_1/ AND REGEXP/some_rx_2/
>   ) OR
>   (
> REGEXP/some_rx_3/ AND NOT REGEXP/some_rx_4/
>   ) OR
>   NOT (
> REGEXP/some_rx_5/ OR NOT REGEXP/some_rx_6/
>   )
>
> Basically, feed 'something' the query and a list of scalars and get back a
> list
> of the subset of scalars that fulfills the query. In short, behaving like a
> grep, you might say.
>
> This was my original goal, and stopping there, arguably calling such a
> module
> "Regexp::Query" could make sense IMHO.
>
> ===
>
> However, moving beyond this I realized two things:
>
> 1) It would be generically useful to allow simple numerical comparisons on
> the
> scalars, i.e. the usual suspects ==, !=, >, >=, <, <=
> 2) Why only scalars? With some additions it can handle lists of raw
> hashes, or
> even arbitrary objects
>
> The first now provides the opportunity to write a queries like this:
>
>   EQ(42) OR GTE(99) OR REGEXP(1\d\d\d2)
>
> This is not so interesting with a list of plain scalars, but adding the
> second
> capability, I introduce the notion of 'fields'. With plain hashes, this
> equates
> to plainly looking up the keys, but with objects we can provide a special
> hash
> which has keys corresponding to small anonymous subs that knowns how to
> dig out
> the data we want. Given a query like this:
>
>   name.REGEXP(^A) and age.GT(30)
>
> and having any kind of Perl objects that has these 'fields', we can do
> this:
>
>   my $fa = FieldAccessor(
>  {
>name => sub { $_[0]->getName() },
>age => sub { $_[0]->calculateAge() },
>  });
>
> which, passed along with the list of objects, will perform the query.
>
> Given the last features, I feel I'm slightly beyond just something in the
> Regexp:: namespace, but I have no good feel for what it could be instead.
> Pretty
> generic in a way, so just 

Help on module name (working name 'Regexp::Query')

[kenneth]

Hello all,

I'd like to request some advice/thoughs/help on selecting a name for a 
module.
The working name is 'Regexp::Query', but as it happens the realization 
of the
original idea has moved slightly ahead of that so I'm no longer 
confident on the

suitability...

The Scratched Itch:

I have a large number of commandline tools, and quite frequently I want 
the user

to be able to express, with some flag(s), a selection among something.

Example: the user gives the command

  SomeCommand /some/path

and it will scan the path and for all files it finds it will do 
something
useful. Now, I also want to provide flags for the command such that they 
can say


  SomeCommand -exclude 'some_regexp' /some/path

Obviously not a problem, and I also provide the reverse if that is more
convenient:

  SomeCommand -include 'another_regexp' /some/path

and this can be extended so flags can be given multiple times and 
interweaved:


  SomeCommand -include 'rx1' -exclude 'rx2' -include 'rx3' /some/path

coupled with rules that then shrinks the target set based on rx1, 
shrinks that

set using rx2 etc etc. I think you get the idea.

What I found however is that it becomes hard to string together regexps 
to find
the exact subset you want. In fact, while regexps are powerful, they're 
not that
suited to easily mix multiple of them, and some expressions are 
basically

impossible, especially to provide a commandline interface to them...

Thus, instead I'd like to provide a more capable way for a user to 
provide a
more complex query, i.e. where it'd be possible to use AND/OR/NOT, 
including

parenthesized, e.g. something very contrived:

  (
REGEXP/some_rx_1/ AND REGEXP/some_rx_2/
  ) OR
  (
REGEXP/some_rx_3/ AND NOT REGEXP/some_rx_4/
  ) OR
  NOT (
REGEXP/some_rx_5/ OR NOT REGEXP/some_rx_6/
  )

Basically, feed 'something' the query and a list of scalars and get back 
a list
of the subset of scalars that fulfills the query. In short, behaving 
like a

grep, you might say.

This was my original goal, and stopping there, arguably calling such a 
module

"Regexp::Query" could make sense IMHO.

===

However, moving beyond this I realized two things:

1) It would be generically useful to allow simple numerical comparisons 
on the

scalars, i.e. the usual suspects ==, !=, >, >=, <, <=
2) Why only scalars? With some additions it can handle lists of raw 
hashes, or

even arbitrary objects

The first now provides the opportunity to write a queries like this:

  EQ(42) OR GTE(99) OR REGEXP(1\d\d\d2)

This is not so interesting with a list of plain scalars, but adding the 
second
capability, I introduce the notion of 'fields'. With plain hashes, this 
equates
to plainly looking up the keys, but with objects we can provide a 
special hash
which has keys corresponding to small anonymous subs that knowns how to 
dig out

the data we want. Given a query like this:

  name.REGEXP(^A) and age.GT(30)

and having any kind of Perl objects that has these 'fields', we can do 
this:


  my $fa = FieldAccessor(
 {
   name => sub { $_[0]->getName() },
   age => sub { $_[0]->calculateAge() },
 });

which, passed along with the list of objects, will perform the query.

Given the last features, I feel I'm slightly beyond just something in 
the
Regexp:: namespace, but I have no good feel for what it could be 
instead. Pretty
generic in a way, so just plain 'Data::Query' perhaps (ignoring for a 
second
that that name appears to be taken for some module I at present don't 
quite

understand what it's for...perhaps there's a fit...?)

Maybe I should just stick with the R::Q naming...:-)

Any feedback helpful.

TIA,

ken1 (CPAN id: KNTH)

help with module name, module of abstracted regex via data objects.

[benh]

Currently I've been running with this named as String::Clean but I
think that it could be more descriptive. The end goal is to have a
collection of things that you would need to be replaced or striped
from a string. This all started because each of the developers at work
had seperate lists of things that would be pulled from input forms and
other common input streams. So I started building a toolkit where we
could not only consolidate but also quickly show what gets modified to
management. Most of this is done via YAML, arrays are striped, hashes
are replaces, it allows for things like:

is (
   $obj-clean_by_yaml(q{
---
this : that
is   : was
a: an
---
- still
---
for : to explain
'  ': ' '
},
   q{this is still just a example for the yaml stuff},
   { replace = 'word' } ),

   q{that was just an example to explain the yaml stuff},

   q{clean by yaml example from the docs}
);


Any better suggestions on a name?

-- 
benh~

Re: help for module name?

[Jerome Quelin]

On 07/05/27 21:27 +0200, A. Pagaltzis wrote:
  well, i don't like the way to prereq sthg in pococm that i
  won't really use - that is, the whole non-poe logic of
  audio::mpd.
 
 What whole non-POE logic? All the logic I can find is the
 as_string method. Are we talking about the same modules?

i was talking of adding in this helper dist the modules stats, status
and time (always in audio::mpd::) which are also just structs and are
shared between the poe and non-poe implementation.

thus, the dist audio::mpd::items would not be enough - unless i also
release separately audio::mpd::stats and... which is a bit silly imo.

therefore:
- audio::mpdhelper?
- audio::mpdcommon?


regards,
jérôme 
-- 
[EMAIL PROTECTED]

Re: help for module name?

[Philippe Bruhat (BooK)]

Le lundi 28 mai 2007 à 08:47, Jerome Quelin écrivait:
 
 thus, the dist audio::mpd::items would not be enough - unless i also
 release separately audio::mpd::stats and... which is a bit silly imo.
 
 therefore:
 - audio::mpdhelper?
 - audio::mpdcommon?
 

Maybe Audio::MPD::Common, so that everythings stays in the namespace 
you're using?

-- 
 Philippe BooK Bruhat

 In war, the only winners are those who sell the weapons.
 (Moral from Groo #3 (Image))

Re: help for module name?

[Philippe Bruhat (BooK)]

Le lundi 28 mai 2007 à 13:11, Jerome Quelin écrivait:
 On 07/05/28 12:31 +0200, Philippe 'Book' Bruhat wrote:
   thus, the dist audio::mpd::items would not be enough - unless i also
   release separately audio::mpd::stats and... which is a bit silly imo.
   
   therefore:
   - audio::mpdhelper?
   - audio::mpdcommon?
  
  Maybe Audio::MPD::Common, so that everythings stays in the namespace 
  you're using?
 
 but it's to be used also in the namespace poe::component::client::mpd
 == therefore, why take one rather than the other?
 

Because it's not POE specific, so it should live in the POE namespace.

-- 
 Philippe BooK Bruhat

 For every winner, there must be one or more losers.
(Moral to the Sage story in Groo #111 (Epic))

help for module name?

[Jerome Quelin]

hi there,

i'm working on a module to interface with music player daemon (mpd).
i've released:
 - audio::mpd, a traditional oo interface
 - poe::component::client::mpd, a poe-aware interface

they're both under development.

for each of them, i've defined an item class to map the items
manipulated by mpd. there are 3 subclasses item::song,
item::directory and item::playlist.

note that:
 - those items are just a bunch of accessors,
 - those items do not retrieve their information themselves from a file
   or whatever

my problem is that those classes are defined both:
 - in audio::mpd::item (with audio::mpd::item::* subclasses)
 - and poe::component::client::mpd::item (with pococm::item::*
   subclasses)

and the code is the same, with only the package name differing.

since code duplication is bad, and since i don't want to put a prereq
relationship between the 2 modules (in either direction), i'm going to
extract the item::* classes in their own module that's going to be
prereq by the others.

i haven't seen any such thing on cpan, it's always tied to a format
(mp3, or ogg vorbis, or...) and meant to extract meta-information from a
file.

so here's my question: how should i name this new module?
 - audio::item= isn't it too vague?
 - audio::mpditem = isn't it too specific? (would it be used by others?)
 - other?


thanks for your help,
jérôme 
-- 
[EMAIL PROTECTED]

Re: help for module name?

[A. Pagaltzis]

* Jerome Quelin [EMAIL PROTECTED] [2007-05-27 09:50]:
 so here's my question: how should i name this new module?
  - audio::item= isn't it too vague?
  - audio::mpditem = isn't it too specific? (would it be used by others?)
  - other?

The modules I see are just structs, and the only code in there is
the formatter method in Audio::MPD::Item::Song. I does not seem
to me that these things are very generically useful; you’d have
to do a lot of work to make them interesting for other purposes.

I’d suggest Audio::MPD::Item as the distro name, since you’ve
already organised them as a hierarchy in there. As a bonus you
won’t even need to change any of the Audio::MPD code, just add
the dependency and you’re done.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: help for module name?

[Jerome Quelin]

On 07/05/27 17:31 +0200, A. Pagaltzis wrote:
 * Jerome Quelin [EMAIL PROTECTED] [2007-05-27 09:50]:
  so here's my question: how should i name this new module?
   - audio::item= isn't it too vague?
   - audio::mpditem = isn't it too specific? (would it be used by others?)
   - other?
 
 The modules I see are just structs, and the only code in there is
 the formatter method in Audio::MPD::Item::Song. I does not seem
 to me that these things are very generically useful; you’d have
 to do a lot of work to make them interesting for other purposes.

they are indeed just structs, as i said.

 I’d suggest Audio::MPD::Item as the distro name, since you’ve
 already organised them as a hierarchy in there. As a bonus you
 won’t even need to change any of the Audio::MPD code, just add
 the dependency and you’re done.

well, i don't like the way to prereq sthg in pococm that i won't really
use - that is, the whole non-poe logic of audio::mpd. i'd really like to
have a small dist that could be used by the two. it would be way
cleaner imho.

after having sent this mail, i thought that i could as well add other
helper classes used by both audio::mpd and pococ::mpd...

== maybe Audio::MPDHelper could do the trick?


jérôme 
-- 
[EMAIL PROTECTED]

Re: help for module name?

[A. Pagaltzis]

* Jerome Quelin [EMAIL PROTECTED] [2007-05-27 18:05]:
 On 07/05/27 17:31 +0200, A. Pagaltzis wrote:
  I’d suggest Audio::MPD::Item as the distro name, since you’ve
  already organised them as a hierarchy in there. As a bonus
  you won’t even need to change any of the Audio::MPD code,
  just add the dependency and you’re done.
 
 well, i don't like the way to prereq sthg in pococm that i
 won't really use - that is, the whole non-poe logic of
 audio::mpd.

What whole non-POE logic? All the logic I can find is the
as_string method. Are we talking about the same modules?

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/