Module submission Data::PathSimple

[Perl Authors Upload Server]

The following module was proposed for inclusion in the Module List:

modid: Data::PathSimple
DSLIP: Rdpfp
description: Manipulate data structures using paths
userid: ALFIE (Alfie John)
chapterid: 6 (Data_Type_Utilities)
communities:
Just at work with colleagues

similar:
Data::SPath, Data:

rationale:

Data::SPath only does get() operations.

Data::SPath also needs functions passed in which is a lot more
complicated for most situations.

My module (Data::PathSimple) picks sane defaults that are useful
99% of the time.

I was going to ask for Data::Path but it was already in use (even
though it's not a registered module).

Alfie

enteredby: ALFIE (Alfie John)
enteredon: Sat Oct 13 12:34:24 2012 GMT

The resulting entry would be:

Data::
::PathSimple Rdpfp Manipulate data structures using paths ALFIE


Thanks for registering,
--
The PAUSE

PS: The following links are only valid for module list maintainers:

Registration form with editing capabilities:
https://pause.perl.org/pause/authenquery?ACTION=add_mod&USERID=12a00000_aa8f2865cad6ab42&SUBMIT_pause99_add_mod_preview=1
Immediate (one click) registration:
https://pause.perl.org/pause/authenquery?ACTION=add_mod&USERID=12a00000_aa8f2865cad6ab42&SUBMIT_pause99_add_mod_insertit=1
Peek at the current permissions:
https://pause.perl.org/pause/authenquery?pause99_peek_perms_by=me&pause99_peek_perms_query=Data%3A%3APathSimple

[brian d foy]

[[ This message was both posted and mailed: see
the "To," "Cc," and "Newsgroups" headers for details. ]]

In article <201210131234....@pause.fiz-chemie.de>, "Perl

Authors Upload Server" <upl...@pause.perl.org> wrote:

> The following module was proposed for inclusion in the Module List:
>
> modid: Data::PathSimple
> DSLIP: Rdpfp
> description: Manipulate data structures using paths
> userid: ALFIE (Alfie John)

I thought I'd responded to this earlier, but maybe not. Generally, I
don't like "Simple" anywhere in a name because it doesn't say what's
simple about it (and everyone thinks their own module is simple). We
say some things in the naming guidelines.

https://pause.perl.org/pause/query?ACTION=pause_namingmodules

--
brian d foy (one of many PAUSE admins), http://pause.perl.org
PAUSE instructions: http://pause.perl.org/pause/query?ACTION=pause_04about
Archives: http://www.xray.mpe.mpg.de/mailing-lists/modules
Please send all messages back to mod...@perl.org with no CC to me.

[Alfie John]

Hey Brian,

On Mon, Oct 22, 2012 at 11:22:24PM -0500, brian d foy wrote:
> > The following module was proposed for inclusion in the Module List:
> >
> > modid: Data::PathSimple
> > DSLIP: Rdpfp
> > description: Manipulate data structures using paths
> > userid: ALFIE (Alfie John)
>
> I thought I'd responded to this earlier, but maybe not.

Weird. I checked my mail logs and can't find anything.

> Generally, I
> don't like "Simple" anywhere in a name because it doesn't say what's
> simple about it (and everyone thinks their own module is simple). We
> say some things in the naming guidelines.
>
> https://pause.perl.org/pause/query?ACTION=pause_namingmodules

Yeah, I read that when I was trying to come up with a name. I didn't
think it was a strict rule seeing as there already many *Simple modules
on CPAN that I use regularly.

I'd like if we could agree on a name for this module before moving
further rather than me changing the namespace, uploading to CPAN and
then getting another rejection days later.

Any objection to Data::Tree? I could then rename the description to:

Data::Tree - Navigate and manipulate data structures like a tree

Otherwise, I'd be willing to hear some suggestions.

Alfie

--
Alfie John
http://h4c.kr

[Matt S Trout]

On Tue, Oct 23, 2012 at 08:29:47PM +1100, Alfie John wrote:
> Any objection to Data::Tree? I could then rename the description to:
>
> Data::Tree - Navigate and manipulate data structures like a tree
>
> Otherwise, I'd be willing to hear some suggestions.

I can't really make a suggestion if you don't show any examples of usage.

What distinguishes it from Data::SPath? From Data::DPath? From straight up
XPath matching using an adaptor like Class::XPath?

"It picks the right thing 80% of the time" is true of all of those from the
point of view of the people -currently- using each one. I'm not using any yet
- what's special about your module apart from "it's a different set of
defaults" ? What made it worth being a separate module rather than a wrapper
around SPath or DPath ?

These are the questions you need answers to in order to pick a -good- name
rather than a merely adequate one - you try and answer them and we'll try
and help you come up with it :)

--
Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue

http://shadowcat.co.uk/blog/matt-s-trout/ http://twitter.com/shadowcat_mst/

Email me now on mst (at) shadowcat.co.uk and let's chat about how our Catalyst
commercial support, training and consultancy packages could help your team.

[Alfie John]

On Tue, Oct 23, 2012 at 04:37:31PM +0100, Matt S Trout wrote:
> On Tue, Oct 23, 2012 at 08:29:47PM +1100, Alfie John wrote:
> > Any objection to Data::Tree? I could then rename the description to:
> >
> > Data::Tree - Navigate and manipulate data structures like a tree
> >
> > Otherwise, I'd be willing to hear some suggestions.
>
> I can't really make a suggestion if you don't show any examples of usage.

Here's the SYNOPSIS:

use Data::PathSimple qw{
get
set
};

my $data = {
Languages => {
Perl => {
CurrentVersion => '5.16.1',
URLs => [
'http://www.perl.org',
'http://www.cpan.org',
],
},
PHP => {
CurrentVersion => '5.4.7',
URLs => [
'http://www.php.net',
'http://pear.php.net',
],
},
Python => {
CurrentVersion => '2.7.3',
URLs => [
'http://www.python.org',
],
},
},
};

my $current_perl = get( $data, '/Languages/Perl/CurrentVersion' );
my @perl_urls = @{ get( $data, '/Languages/Perl/URLs' ) || [] };

set( $data, '/Languages/Perl/CurrentVersion', '5.16.2' );
set( $data, '/Languages/Python/URLs/1/', 'http://pypi.python.org' );

> What distinguishes it from Data::SPath? From Data::DPath? From straight up
> XPath matching using an adaptor like Class::XPath?

First off, Data::SPath, Data::Dpan and Class::XPath only allow getting. My
module does setting too.

As you can see from the code above, the way you access the data that you want
is by *simple* paths. If you have a look at Data::DPath and Class::XPath, they
take complex paths and are used to match across the entire data structure.
That's not what my module is about. Mine is about access the specific part of
the data structure that you're after.

Comparing Data::SPath and my module, by default Data::SPath will croak when
accessing a path that doesn't exist. Since I'm using my module on the command
line and the path is coming from user input, I just want an undef if there is a
key miss.

Data::SPath provides a way to override the croak on key misses and other errors
by taking in error handling subroutines on the import:

use Data::SPath
spath => {
method_miss => \&_method_miss,
key_miss => \&_key_miss,
index_miss => \&_index_miss,
key_on_non_hash => \&_key_on_non_hash,
args_on_non_method => \&_args_on_non_method
};

To me, this seems a bit too much for what I want and feels inelegant. After
listening to Damian's Sufficiently Advanced Technology talk, I think my module
DWEM (where E is everyone)... unless I'm mistaken?

> "It picks the right thing 80% of the time" is true of all of those from the
> point of view of the people -currently- using each one. I'm not using any yet
> - what's special about your module apart from "it's a different set of
> defaults" ? What made it worth being a separate module rather than a wrapper
> around SPath or DPath ?

As for integrating set() into Data::SPath. I guess I could have created a
wrapper around it as my get() would just fill in the import subroutines with my
preferences and just copy/paste my set() in. The biggest drawback here (which
is a killer IMHO) is having a dependency. My get() subroutine is 32 lines and
set() 56 lines. Do I really want to rely on another peice of code for the sake
of 56 lines? No I don't. The less dependencies the better IMHO and I think the
majority would agree too.

[Matt S Trout]

On Wed, Oct 24, 2012 at 07:49:37AM +1100, Alfie John wrote:
> As for integrating set() into Data::SPath. I guess I could have created a
> wrapper around it as my get() would just fill in the import subroutines with my
> preferences and just copy/paste my set() in. The biggest drawback here (which
> is a killer IMHO) is having a dependency. My get() subroutine is 32 lines and
> set() 56 lines. Do I really want to rely on another peice of code for the sake
> of 56 lines? No I don't. The less dependencies the better IMHO and I think the
> majority would agree too.

Audrey Tang once said:

"perl5 is just syntax. CPAN is the language."

After I wrote Devel::Declare we amended it to:

"perl5 is just a VM. CPAN is the language."

C-level dependencies can be annoying. App::FatPacker et. al. make small, pure
perl dependencies as close to free as they're going to get.

You're entirely welcome to disagree, but "I think the majority would agree"
comes into the unfounded assertion category - and leads people to avoid
dependencies "just becase", thereby resulting in CPAN soup where you have
three modules doing very similar things in a particular piece of code that
all behave -slightly- differently, at which point DW(anybody)M goes out the
window because the 'what' that it does changes between sections of the same
codebase.

Damian made a substantial effort to try and provide a 'one common way' for
a lot of things with Perl Best Practices and other works; quoting him while
working towards undoing some if this work seems a trifle unfair.

But ... it's still your module, hence my naming suggestions went in a
separate email to the 'grumpy old man' stuff above :)

[Matt S Trout]

Data::Selector ?

You probably also want to provide alternative names to get() and set() - those
are way way too commonly already in use in existing code.

[Alfie John]

On Tue, Oct 23, 2012 at 10:02:40PM +0100, Matt S Trout wrote:
> Data::Selector ?

The problem with 'Selector' is that it doesn't tell you what the module
does. That's why Path was the most obvious choice. The only thing close
to that would be Tree, but then again I don't think people think of
trees as they do paths.

So I think 'Path' is the most obvious choice. Since Simple isn't liked,
what about the following?

- Data::Path::Manip
- Data::Path::Access
- Data::ByPath

If we do go down the "tree" path, how about:

- Data::Tree
- Data::Hierarchy
- Data::Directory

To be honest, after all these examples nothing is jumping at me and so I
still prefer Data::PathSimple.

[Alfie John]

On Tue, Oct 23, 2012 at 10:10:44PM +0100, Matt S Trout wrote:
> Audrey Tang once said:
>
> "perl5 is just syntax. CPAN is the language."

Nice. I'm going to steal that.

> You're entirely welcome to disagree, but "I think the majority would agree"
> comes into the unfounded assertion category - and leads people to avoid
> dependencies "just becase", thereby resulting in CPAN soup where you have
> three modules doing very similar things in a particular piece of code that
> all behave -slightly- differently, at which point DW(anybody)M goes out the
> window because the 'what' that it does changes between sections of the same
> codebase.

Have you ever tried to install a single Perl module in a production
environment and it asks you to upgrade 20+ other modules? Saying Y is
not for the faint hearted. In fact, it's probably more likely to make
you think "do we really need to install this module, let's try looking
at something else".

> Damian made a substantial effort to try and provide a 'one common way' for
> a lot of things with Perl Best Practices and other works; quoting him while
> working towards undoing some if this work seems a trifle unfair.

I'd have to disagree with you here. What I meant by refering to his
Sufficiently Advanced Technologies talk is preciesly picking the best
defaults, providing a clean interface, and get out of the way of the
programmer. In other words, trying to keep it "Simple" :)

> But ... it's still your module, hence my naming suggestions went in a
> separate email to the 'grumpy old man' stuff above :)

All good :)

Hopefully you've all now got a better understanding of what I'm shooting for.

[Matt S Trout]

On Wed, Oct 24, 2012 at 08:12:58AM +1100, Alfie John wrote:
> On Tue, Oct 23, 2012 at 10:02:40PM +0100, Matt S Trout wrote:
> > Data::Selector ?
>
> The problem with 'Selector' is that it doesn't tell you what the module
> does. That's why Path was the most obvious choice. The only thing close
> to that would be Tree, but then again I don't think people think of
> trees as they do paths.
>
> So I think 'Path' is the most obvious choice. Since Simple isn't liked,
> what about the following?
>
> - Data::Path::Manip
> - Data::Path::Access
> - Data::ByPath

Maybe Data::ByPath::RW or something? The read/write-ness is something people
are going to care about.

> To be honest, after all these examples nothing is jumping at me and so I
> still prefer Data::PathSimple.

You're welcome to upload it under that name without registration, you know.

I don't tend to register my own modules these days; I regard the registration
process more as a useful feedback cycle on naming than anything else.

I'm also starting to think that the reasons why many ::Simple modules are
actively hated by experienced perl programmers may not apply from your
point of view - or more accurately, that I'll probably hate your module for
the same reasons ... but that the people who won't will search for ::Simple
modules for a different set of reasons.

So the name might be ok after all.

[Alfie John]

On Wed, Oct 24, 2012 at 03:05:55PM +0100, Matt S Trout wrote:
> I don't tend to register my own modules these days; I regard the registration
> process more as a useful feedback cycle on naming than anything else.

I thought the main difference was that registered modules are more
discoverable on CPAN i.e. end up in
http://search.cpan.org/modlist/Data_and_Data_Types/Data rather than just
the search results. Maybe I missed the point?

> Maybe Data::ByPath::RW or something? The read/write-ness is something people
> are going to care about.
>
> > To be honest, after all these examples nothing is jumping at me and so I
> > still prefer Data::PathSimple.
>
> You're welcome to upload it under that name without registration, you know.
>

> I'm also starting to think that the reasons why many ::Simple modules are
> actively hated by experienced perl programmers may not apply from your
> point of view - or more accurately, that I'll probably hate your module for
> the same reasons ... but that the people who won't will search for ::Simple
> modules for a different set of reasons.

Data::ByPath::RW just doesn't have the same ring to me. I think I'm
going to settle with Data::PathSimple because it works with my brain.

Ofcourse it depends on what you're doing, but I don't get the hate for
::Simple modules. I would rather be using XML::Simple rather than
XML::Parser and XML::SAX. I would rather use Filter::Simple rather than
Filter::Util::Call.

> So the name might be ok after all.

I guess in the end the name really doesn't matter, it's what the code
does that's priority. I just thought that by using Data::PathSimple,
people would actually find it and use it.

[Matt S Trout]

On Thu, Oct 25, 2012 at 07:30:35AM +1100, Alfie John wrote:
> On Wed, Oct 24, 2012 at 03:05:55PM +0100, Matt S Trout wrote:
> > I don't tend to register my own modules these days; I regard the registration
> > process more as a useful feedback cycle on naming than anything else.
>
> I thought the main difference was that registered modules are more
> discoverable on CPAN i.e. end up in
> http://search.cpan.org/modlist/Data_and_Data_Types/Data rather than just
> the search results. Maybe I missed the point?

I've not used the modulelist to find modules in half a decade, and I don't
think most of the people I know do either.

In fact, I'm not even sure http://metacpan.org/ provides it (which is the
new open source "better cpan search") - it simply didn't occur to me to care
enough to look :)