From jarich at perltraining.com.au Sun Nov 14 21:11:10 2010 From: jarich at perltraining.com.au (jarich at perltraining.com.au) Date: Mon, 15 Nov 2010 16:11:10 +1100 (EST) Subject: [Canberra-pm] OSDC Call for volunteers (free conference entry) Message-ID: <20101115051111.038D3A8D39@teddybear.perltraining.com.au> Still hankering to go to OSDC this year? Here's an opportunity for some of you to get in for no charge! We're looking for volunteers to cover the registration desk, provide room monitor duties, operate the audio and video equipment and generally help with the smooth running of the event. If you're interested, please contact conference at osdc.com.au or fill out the form at http://2010.osdc.com.au/contact. Those interested in the audio/video side of things must be available Tuesday afternoon (23rd Nov) for training and then Wednesday 24th to Friday 26th from 8.30am to 5.30pm. While no experience is required for any volunteer tasks, including audio/video, you must be keen. We will try and schedule you all so you get to see what you want to, but cannot make any promises. In exchange for your help, you will get free access to the conference (no dinner unfortunately, but you can upgrade for $80 if you want to attend that too). We look forward to hearing from you, From grail at goldweb.com.au Mon Nov 15 16:36:14 2010 From: grail at goldweb.com.au (Alex Satrapa) Date: Tue, 16 Nov 2010 11:36:14 +1100 Subject: [Canberra-pm] Q: Subclassing an object with closures Message-ID: Hello Mongers! I think I'm going to have to hand in my Perl license, I've encountered a structure I don't understand and now I have no idea how to extend the class. Observe the contents of the Net::MAC module. There is a closure containing "class data and class methods", so the module basically looks like this: > package Net::MAC; > > sub new { > # Usual blessing a hashref as the class > $self->_init(%arg); > return $self > } > > { # Closure for class data and class methods > my %_format_for = ( > # Hash mapping format name to format options > IEEE => { > base => 16, > bit_group => 8, > delimiter => ':', > zero_padded => 1, > case => 'lower' > }, > ) > } > > sub _discover { > # Stuff which handles parsing the MAC string. > } Now what I'd like to do is define a new format or three due to various equipment in my network which produces MAC addresses in formats such as '0xDEADBEEF' which is common in SNMP from what I've seen. I'd like to take advantage of the existing autoloading, rather than overriding _discover (to take out the 0x where required, then simply invoking the superclass _discover method) and providing an explicitly defined "as_SNMP" method (which simply sticks a 0x on the front). The first thing I'd like to understand is whether I can add a new entry into that %_format_for hash without touching the Net::MAC module (since I doubt many sysadmins would like my module interfering with read-only modules already installed). Then I'd like to be able to add a new sub into the closure to handle special formatting, such as stripping the 0x off when parsing and adding it on when the user requests as_SNMP. Of course the simple approach is to create the as_SNMP and override _discover myself, but I can't help feeling that's too easy. And remember the sage words of H. L. Mencken, "for every complex problem there is a solution which is simple, elegant, and completely wrong." Alex Satrapa | web.mac.com/alexsatrapa | Ph: +61 4 0770 5332 From daniel at rimspace.net Mon Nov 15 17:54:50 2010 From: daniel at rimspace.net (Daniel Pittman) Date: Tue, 16 Nov 2010 12:54:50 +1100 Subject: [Canberra-pm] Q: Subclassing an object with closures In-Reply-To: (Alex Satrapa's message of "Tue, 16 Nov 2010 11:36:14 +1100") References: Message-ID: Alex Satrapa writes: > I think I'm going to have to hand in my Perl license, I've encountered a > structure I don't understand and now I have no idea how to extend the class. The goal of a bunch of that code is to make it "private", so that you can't fiddle with it, so it isn't a great shock that extending it is hard. > Observe the contents of the Net::MAC module. There is a closure containing > "class data and class methods", so the module basically looks like this: > >> package Net::MAC; >> >> sub new { >> # Usual blessing a hashref as the class >> $self->_init(%arg); >> return $self >> } >> >> { # Closure for class data and class methods >> my %_format_for = ( >> # Hash mapping format name to format options >> IEEE => { >> base => 16, >> bit_group => 8, >> delimiter => ':', >> zero_padded => 1, >> case => 'lower' >> }, >> ) >> } >> >> sub _discover { >> # Stuff which handles parsing the MAC string. >> } > > Now what I'd like to do is define a new format or three due to various > equipment in my network which produces MAC addresses in formats such as > '0xDEADBEEF' which is common in SNMP from what I've seen. > > I'd like to take advantage of the existing autoloading, rather than > overriding _discover (to take out the 0x where required, then simply > invoking the superclass _discover method) and providing an explicitly > defined "as_SNMP" method (which simply sticks a 0x on the front). > > The first thing I'd like to understand is whether I can add a new entry into > that %_format_for hash without touching the Net::MAC module (since I doubt > many sysadmins would like my module interfering with read-only modules > already installed). Absolutely not. It is by design entirely private, and no longer has a name-binding by design. > Then I'd like to be able to add a new sub into the closure to handle special > formatting, such as stripping the 0x off when parsing and adding it on when > the user requests as_SNMP. > > Of course the simple approach is to create the as_SNMP and override > _discover myself, but I can't help feeling that's too easy. You probably need to override _format and _discover to do your mangling, because the upstream author has deliberately locked you out of being able to touch the existing method. > And remember the sage words of H. L. Mencken, "for every complex problem > there is a solution which is simple, elegant, and completely wrong." ...is the right solution to fix the module, then submit it to the author, and just depend on the latest CPAN release? Daniel -- ? Daniel Pittman ? daniel at rimspace.net ? +61 401 155 707 ? made with 100 percent post-consumer electrons From grail at goldweb.com.au Mon Nov 15 18:20:37 2010 From: grail at goldweb.com.au (Alex Satrapa) Date: Tue, 16 Nov 2010 13:20:37 +1100 Subject: [Canberra-pm] Q: Subclassing an object with closures In-Reply-To: References: Message-ID: <14C6A3E0-EA6F-47C0-9287-7A2542D0EF9F@goldweb.com.au> On 16/11/2010, at 12:54 , Daniel Pittman wrote: > Alex Satrapa writes: > >> I think I'm going to have to hand in my Perl license, I've encountered a >> structure I don't understand and now I have no idea how to extend the class. > > The goal of a bunch of that code is to make it "private", so that you can't > fiddle with it, so it isn't a great shock that extending it is hard. Why would someone do something so selfish in a module contributed to CPAN? > ...is the right solution to fix the module, then submit it to the author, and > just depend on the latest CPAN release? Well, in an ideal world* yes. In the real world, no. I will fix the module, rendering the "class variables and methods" as actually belonging to the namespace, and suggest to the author that he shouldn't be pulling silly stunts like this. For my immediate purposes, I'll simply override the methods as required in my subclass. I have a deadline to meet, since I write code for money rather than intellectual stimulation :) Alex * The "ideal world" being defined as one where time and money are not a constraint on any activity. Alex Satrapa | web.mac.com/alexsatrapa | Ph: +61 4 0770 5332 From daniel at rimspace.net Mon Nov 15 18:32:37 2010 From: daniel at rimspace.net (Daniel Pittman) Date: Tue, 16 Nov 2010 13:32:37 +1100 Subject: [Canberra-pm] Q: Subclassing an object with closures In-Reply-To: <14C6A3E0-EA6F-47C0-9287-7A2542D0EF9F@goldweb.com.au> (Alex Satrapa's message of "Tue, 16 Nov 2010 13:20:37 +1100") References: <14C6A3E0-EA6F-47C0-9287-7A2542D0EF9F@goldweb.com.au> Message-ID: Alex Satrapa writes: > On 16/11/2010, at 12:54 , Daniel Pittman wrote: >> Alex Satrapa writes: >> >>> I think I'm going to have to hand in my Perl license, I've encountered a >>> structure I don't understand and now I have no idea how to extend the >>> class. >> >> The goal of a bunch of that code is to make it "private", so that you can't >> fiddle with it, so it isn't a great shock that extending it is hard. > > Why would someone do something so selfish in a module contributed to CPAN? The same reason C++ and other languages have baked-in private/protected/public protection for members: because there are design and style reasons you might want to protect those. Is it overall better? Maybe. Is it Perl style? Not really; it trusts people not to be stupid, generally, but some people don't agree. :) (Theoretically those protections are used in a sensible way so that subclasses can easily extend behaviour. In this case ... not so much.) >> ...is the right solution to fix the module, then submit it to the author, >> and just depend on the latest CPAN release? > > Well, in an ideal world* yes. In the real world, no. I will fix the module, > rendering the "class variables and methods" as actually belonging to the > namespace, and suggest to the author that he shouldn't be pulling silly > stunts like this. > > For my immediate purposes, I'll simply override the methods as required in > my subclass. I have a deadline to meet, since I write code for money rather > than intellectual stimulation :) Uh-huh. That sounds like the right decision to me. > > Alex > > * The "ideal world" being defined as one where time and money are not a constraint on any activity. > > Alex Satrapa | web.mac.com/alexsatrapa | Ph: +61 4 0770 5332 > > > _______________________________________________ > Canberra-pm mailing list > Canberra-pm at pm.org > http://mail.pm.org/mailman/listinfo/canberra-pm -- ? Daniel Pittman ? daniel at rimspace.net ? +61 401 155 707 ? made with 100 percent post-consumer electrons