Bug #63017 for Net-MAC: Net::MAC - un-obfuscate the class data?

Mon Nov 15 23:23:50 2010 grail [...] goldweb.com.au - Ticket created

Subject:	Net::MAC - un-obfuscate the class data?
Date:	Tue, 16 Nov 2010 15:23:35 +1100
To:	bug-Net-MAC [...] rt.cpan.org
From:	Alex Satrapa <grail [...] goldweb.com.au>

I've been trying to extend the Net::MAC class to cater for some different formats (SNMP and weird vendor-specific strings). This has proven to be harder than I'd like, due to the use of a closure to hide the "class data and methods" outside of any namespace. For my purposes, I'd have been able to achieve my desired result by simply adding a new format spec to the "%_format_for" hash. As it stands, I've had to define my own "as_X" methods, and override the _discover method to handle the parsing of my specific formats, then pass everything on to the Net::MAC version of _discover - this makes my code longer than necessary, introduces more avenues for bugs (since I'm basically duplicating code), and makes my code look messy. Is there any possibility of removing that closure and just leave the Net::MAC class variables in the Net::MAC namespace where they can be modified by programmers who understand the risks?

Sun Dec 12 16:15:33 2010 OLIVER [...] cpan.org - Taken

Sun Dec 12 16:16:48 2010 OLIVER [...] cpan.org - Correspondence added

On Mon Nov 15 23:23:50 2010, grail@goldweb.com.au wrote: Show quoted text

> I've been trying to extend the Net::MAC class to cater for some > different formats (SNMP and weird vendor-specific strings). This > has proven to be harder than I'd like, due to the use of a closure > to hide the "class data and methods" outside of any namespace. > > Is there any possibility of removing that closure and just leave the > Net::MAC class variables in the Net::MAC namespace where they can > be modified by programmers who understand the risks?

Yes this seems a reasonable request. I'll do the necessary development and if our tests pass then release to CPAN. Many thanks for reporting this issue! -- regards, oliver.

Sun Dec 12 16:16:48 2010 The RT System itself - Status changed from 'new' to 'open'

Tue Dec 28 10:07:42 2010 OLIVER [...] cpan.org - Correspondence added

Hello, On Mon Nov 15 23:23:50 2010, grail@goldweb.com.au wrote: Show quoted text

> I've been trying to extend the Net::MAC class to cater for some > different formats (SNMP and weird vendor-specific strings).

I've uploaded a new version of the module to CPAN which includes support for custom MAC address formats. There is a new ->set_format_for() class method to install them, and a format option to new() as well. See the documentation for further details. Please let me know how you get on. regards, oliver. -- regards, oliver.

Tue Dec 28 10:07:43 2010 OLIVER [...] cpan.org - Status changed from 'open' to 'resolved'

Tue Dec 28 17:34:28 2010 grail [...] goldweb.com.au - Correspondence added

Subject:	Re: [rt.cpan.org #63017] Net::MAC - un-obfuscate the class data?
Date:	Wed, 29 Dec 2010 09:34:11 +1100
To:	bug-Net-MAC [...] rt.cpan.org
From:	Alex Satrapa <grail [...] goldweb.com.au>

On 29/12/2010, at 02:07 , Oliver Gorwits via RT wrote: Show quoted text

> I've uploaded a new version of the module to CPAN which includes support for custom MAC > address formats. There is a new ->set_format_for() class method to install them, and a > format option to new() as well. See the documentation for further details.

Thanks, I'll have a play with it promptly! Alex

Tue Dec 28 17:34:29 2010 The RT System itself - Status changed from 'resolved' to 'open'

Wed Dec 29 17:26:24 2010 OLIVER [...] cpan.org - Status changed from 'open' to 'resolved'