Bug #43056 for Hash-Merge: Ability to use from different places with different behaviours

Thu Feb 05 09:20:06 2009 MONS [...] cpan.org - Ticket created

Subject:

Ability to use from different places with different behaviours

There is such a problem In one place we do specify_behavior({...}, 'Behaviour1') in another place we do specify_behavior({...}, 'Behaviour2') Later we call merge() many times from both places. As could be seen, Behaviour1 would be ignored, and all merges would be done using Behaviour2. The fix could be done in at least 2 ways: 1. add OO interface, and keep merge matrix inside object 2. make $behaviors, $merge_behavior, $merge_matrix global, and store the value of additionally specified behaviors into them (later we could use: restore = get_behavior; set_behavior(own); merge; set_behavior(restore); or { local $Hash::Merge::behavior = 'own'; merge() }) Will you accept from me a version 0.11 with fix of this issue?

Thu Feb 05 10:30:00 2009 webmaster [...] simplemood.com - Correspondence added

Subject:	Re: [rt.cpan.org #43056] Ability to use from different places with different behaviours
Date:	Thu, 5 Feb 2009 09:19:56 -0600
To:	bug-Hash-Merge [...] rt.cpan.org
From:	Dan Muey <webmaster [...] simplemood.com>

yeah, globals are bad (which is what the set-by-function is really). Unfortunately that's the way they were done before I inherited it. I'm thinking an alternate object interface would be nice On Feb 5, 2009, at 8:20 AM, Mons Anderson via RT wrote: Show quoted text

> Thu Feb 05 09:20:06 2009: Request 43056 was acted upon. > Transaction: Ticket created by MONS > Queue: Hash-Merge > Subject: Ability to use from different places with different > behaviours > Broken in: (no value) > Severity: Important > Owner: Nobody > Requestors: MONS@cpan.org > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=43056 > > > > There is such a problem > > In one place we do specify_behavior({...}, 'Behaviour1') > in another place we do specify_behavior({...}, 'Behaviour2') > > Later we call merge() many times from both places. > As could be seen, Behaviour1 would be ignored, and all merges would be > done using Behaviour2. > > The fix could be done in at least 2 ways: > 1. add OO interface, and keep merge matrix inside object > 2. make $behaviors, $merge_behavior, $merge_matrix global, and store > the > value of additionally specified behaviors into them (later we could > use: > restore = get_behavior; set_behavior(own); merge; > set_behavior(restore); > or { local $Hash::Merge::behavior = 'own'; merge() }) > > Will you accept from me a version 0.11 with fix of this issue?

Thu Feb 05 10:30:04 2009 The RT System itself - Status changed from 'new' to 'open'

Thu Feb 05 10:57:46 2009 webmaster [...] simplemood.com - Correspondence added

Subject:	Re: [rt.cpan.org #43056] Ability to use from different places with different behaviours
Date:	Thu, 5 Feb 2009 09:19:56 -0600
To:	bug-Hash-Merge [...] rt.cpan.org
From:	Dan Muey <webmaster [...] simplemood.com>

yeah, globals are bad (which is what the set-by-function is really). Unfortunately that's the way they were done before I inherited it. I'm thinking an alternate object interface would be nice On Feb 5, 2009, at 8:20 AM, Mons Anderson via RT wrote: Show quoted text

> Thu Feb 05 09:20:06 2009: Request 43056 was acted upon. > Transaction: Ticket created by MONS > Queue: Hash-Merge > Subject: Ability to use from different places with different > behaviours > Broken in: (no value) > Severity: Important > Owner: Nobody > Requestors: MONS@cpan.org > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=43056 > > > > There is such a problem > > In one place we do specify_behavior({...}, 'Behaviour1') > in another place we do specify_behavior({...}, 'Behaviour2') > > Later we call merge() many times from both places. > As could be seen, Behaviour1 would be ignored, and all merges would be > done using Behaviour2. > > The fix could be done in at least 2 ways: > 1. add OO interface, and keep merge matrix inside object > 2. make $behaviors, $merge_behavior, $merge_matrix global, and store > the > value of additionally specified behaviors into them (later we could > use: > restore = get_behavior; set_behavior(own); merge; > set_behavior(restore); > or { local $Hash::Merge::behavior = 'own'; merge() }) > > Will you accept from me a version 0.11 with fix of this issue?

Thu Feb 05 11:44:24 2009 webmaster [...] simplemood.com - Correspondence added

Subject:	Re: [rt.cpan.org #43056] Ability to use from different places with different behaviours
Date:	Thu, 5 Feb 2009 09:19:56 -0600
To:	bug-Hash-Merge [...] rt.cpan.org
From:	Dan Muey <webmaster [...] simplemood.com>

yeah, globals are bad (which is what the set-by-function is really). Unfortunately that's the way they were done before I inherited it. I'm thinking an alternate object interface would be nice On Feb 5, 2009, at 8:20 AM, Mons Anderson via RT wrote: Show quoted text

> Thu Feb 05 09:20:06 2009: Request 43056 was acted upon. > Transaction: Ticket created by MONS > Queue: Hash-Merge > Subject: Ability to use from different places with different > behaviours > Broken in: (no value) > Severity: Important > Owner: Nobody > Requestors: MONS@cpan.org > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=43056 > > > > There is such a problem > > In one place we do specify_behavior({...}, 'Behaviour1') > in another place we do specify_behavior({...}, 'Behaviour2') > > Later we call merge() many times from both places. > As could be seen, Behaviour1 would be ignored, and all merges would be > done using Behaviour2. > > The fix could be done in at least 2 ways: > 1. add OO interface, and keep merge matrix inside object > 2. make $behaviors, $merge_behavior, $merge_matrix global, and store > the > value of additionally specified behaviors into them (later we could > use: > restore = get_behavior; set_behavior(own); merge; > set_behavior(restore); > or { local $Hash::Merge::behavior = 'own'; merge() }) > > Will you accept from me a version 0.11 with fix of this issue?

Fri Feb 06 11:54:24 2009 MONS [...] cpan.org - Correspondence added

Чтв. Фев. 05 10:30:00 2009, webmaster@simplemood.com писал: Show quoted text

> yeah, globals are bad (which is what the set-by-function is really). > Unfortunately that's the way they were done before I inherited it. > > I'm thinking an alternate object interface would be nice

I've attached the archive and the diff. The changes are: 1. Added OO interface. By default all calls are done (implicitly) on default, $GLOBAL object 2. Cloning were extended to use also Clone::PP or Storable::dclone (Storable is present more often, than Clone or Clone::PP, and it is very fast) 3. User specified matrix saved into $behaviors list, so it can be restored by get_behavior/set_behavior 4. Added tests for nested calls with different behaviors.

Download Hash-Merge-0.11.tar.gz
application/gzip 7.8k

Message body not shown because it is not plain text.

Message body is not shown because it is too large.

Sun Feb 14 05:56:06 2010 ribasushi [...] leporine.io - Correspondence added

RT-Send-CC:

webmaster [...] simplemood.com

On Thu Feb 05 11:44:24 2009, webmaster@simplemood.com wrote: Show quoted text

> yeah, globals are bad (which is what the set-by-function is really). > Unfortunately that's the way they were done before I inherited it.

A patch has been sitting in this queue for over a year, any plans of releasing a new H::M ?

Mon Feb 15 06:02:13 2010 MONS [...] cpan.org - Correspondence added

Peter, I can upload my version as unauthorized release. If you need it, I'll do it and will support future changes

Mon Feb 15 06:14:32 2010 MONS [...] cpan.org - Correspondence added

Пнд Фев 15 06:02:13 2010, MONS писал: Show quoted text

> Peter, I can upload my version as unauthorized release. > If you need it, I'll do it and will support future changes

Hm, sorry, I think this module was forgotten at all by an author. It's not so. I may propose you to look at Hash::Union as an alternative

Mon Feb 15 07:56:56 2010 dmuey [...] cpan.org - Correspondence added

Hello all, No I havn't forgotten about this, I've just been busy :) These emails yesterday and today are the first interest I've seen regarding this addition, not sure if rt was sending them out or not, regardless I'll look it over ASAP. thanks!

Mon Feb 15 11:16:03 2010 dmuey [...] cpan.org - Correspondence added

On Mon Feb 15 06:02:13 2010, MONS wrote: Show quoted text

> Peter, I can upload my version as unauthorized release. > If you need it, I'll do it and will support future changes

I've just uploaded 0.12 to CPAN. Thanks for the patch, I modified it quite a bit and added tests for the OO interface. Side note: It's never a good idea to upload unauthorized releases. This one especially, adding tests for the new OO revealed problems with it and it needed adjusted. If an author seems unresponsive then there is a process you should follow to get the issue resolved. You'll often find the author is responsive they are just busy and havn't gotten around to it since there was no demand for it. HTH

Mon Feb 15 11:16:08 2010 dmuey [...] cpan.org - Status changed from 'open' to 'resolved'