From tmcd at panix.com Thu Sep 13 07:53:41 2007 From: tmcd at panix.com (Tim McDaniel) Date: Thu, 13 Sep 2007 09:53:41 -0500 (CDT) Subject: APM: Just need structs Message-ID: In C terms, all I need is three structs, each one with two fields now, but I may need more later. There's no class inheritance. I don't *need* getter/setter functions (it's all one program, so the caller is as trusted as the library), though I might implement them for implementation convenience. Any neato-keeno CPAN modules that you've used and that have been stable enough, or should I just type "man perlobj" and read? -- Tim McDaniel, tmcd at panix.com From taylor at codecafe.com Thu Sep 13 09:02:35 2007 From: taylor at codecafe.com (Taylor Carpenter) Date: Thu, 13 Sep 2007 11:02:35 -0500 Subject: APM: Just need structs In-Reply-To: References: Message-ID: <761AFC9D-BDFA-4AF0-ADA2-EA49484B4D3B@codecafe.com> Not sure if this is what you want... but it looks like a C struct other than the {}. Unless you are tricky then direct access is always there even with subs for access each variable. If you do not care to have them (eg. name() for setting and getting the name var below) then just hit it directly. If the 3 structs you need all have the same 2 fields then just do "new" on that object... Other-wise create 3 "packages". BTW you can also make it so new() will take arguments and set the values of the variables at initialization... $p = new Person; $p->{name} = "Henry"; print "$p->{name}\n"; package Person; sub new { my $self = {}; $self->{name} = undef; $self->{age} = 0; $self->{favorite_foods} = []; bless($self); return $self; } On Sep 13, 2007, at 9:53 AM, Tim McDaniel wrote: > In C terms, all I need is three structs, each one with two fields now, > but I may need more later. There's no class inheritance. I don't > *need* getter/setter functions (it's all one program, so the caller is > as trusted as the library), though I might implement them for > implementation convenience. > > Any neato-keeno CPAN modules that you've used and that have been > stable enough, or should I just type "man perlobj" and read? > > -- > Tim McDaniel, tmcd at panix.com > _______________________________________________ > Austin mailing list > Austin at pm.org > http://mail.pm.org/mailman/listinfo/austin From tmcd at panix.com Thu Sep 13 09:42:36 2007 From: tmcd at panix.com (Tim McDaniel) Date: Thu, 13 Sep 2007 11:42:36 -0500 (CDT) Subject: APM: Just need structs In-Reply-To: <761AFC9D-BDFA-4AF0-ADA2-EA49484B4D3B@codecafe.com> References: <761AFC9D-BDFA-4AF0-ADA2-EA49484B4D3B@codecafe.com> Message-ID: On Thu, 13 Sep 2007, Taylor Carpenter wrote: > If the 3 structs you need all have the same 2 fields No, no -- three different types with many instances each, not one type with three instances. > package Person; > > sub new { > my $self = {}; > $self->{name} = undef; > $self->{age} = 0; > $self->{favorite_foods} = []; > bless($self); > return $self; > } Thanks. Looks like "man perlobj", without inheritance and "$obj->new()". -- Tim McDaniel, tmcd at panix.com From jason at shakabuku.org Thu Sep 13 10:42:40 2007 From: jason at shakabuku.org (Jason Bodnar) Date: Thu, 13 Sep 2007 12:42:40 -0500 Subject: APM: Just need structs In-Reply-To: References: <761AFC9D-BDFA-4AF0-ADA2-EA49484B4D3B@codecafe.com> Message-ID: <20070913174043.M39544@shakabuku.org> http://search.cpan.org/~nwclark/perl-5.8.8/lib/Class/Struct.pm I've never used it but it looks like it's part of the perl dist. On Thu, 13 Sep 2007 11:42:36 -0500 (CDT), Tim McDaniel wrote > On Thu, 13 Sep 2007, Taylor Carpenter wrote: > > If the 3 structs you need all have the same 2 fields > > No, no -- three different types with many instances each, not one > type with three instances. > > > package Person; > > > > sub new { > > my $self = {}; > > $self->{name} = undef; > > $self->{age} = 0; > > $self->{favorite_foods} = []; > > bless($self); > > return $self; > > } > > Thanks. Looks like "man perlobj", without inheritance and > "$obj->new()". > > -- > Tim McDaniel, tmcd at panix.com > _______________________________________________ > Austin mailing list > Austin at pm.org > http://mail.pm.org/mailman/listinfo/austin -- Jason Bodnar jason at shakabuku.org http://www.shakabuku.org From tmcd at panix.com Thu Sep 13 11:41:32 2007 From: tmcd at panix.com (Tim McDaniel) Date: Thu, 13 Sep 2007 13:41:32 -0500 (CDT) Subject: APM: Just need structs In-Reply-To: <20070913174043.M39544@shakabuku.org> References: <761AFC9D-BDFA-4AF0-ADA2-EA49484B4D3B@codecafe.com> <20070913174043.M39544@shakabuku.org> Message-ID: On Thu, 13 Sep 2007, Jason Bodnar wrote: > http://search.cpan.org/~nwclark/perl-5.8.8/lib/Class/Struct.pm > > I've never used it but it looks like it's part of the perl dist. And it's even on the ancient RedHat Linux 9 box. Thanks -- I'm checking it out now. -- Tim McDaniel, tmcd at panix.com From montgomery.conner at gmail.com Thu Sep 13 20:55:10 2007 From: montgomery.conner at gmail.com (Montgomery Conner) Date: Thu, 13 Sep 2007 22:55:10 -0500 Subject: APM: Just need structs In-Reply-To: References: <761AFC9D-BDFA-4AF0-ADA2-EA49484B4D3B@codecafe.com> <20070913174043.M39544@shakabuku.org> Message-ID: If you don't require encapsulation the easiest (and most efficient) solution would be to forgo building an object to hold this data: there would be no point and there is a semi-trivial amount of overhead in doing so. You could use an array instead. Perl arrays are optimized and fast (internally implemented as a C struct by the compiler), but because the implementation of Perl variables is not strongly typed (like C) they will dynamically accommodate a variety of data-types... so you'd likely only need one type of container in Perl not three. If you need to have a ternary grouping of similar data ( and if you understand the use of anonymous data in Perl) you could use three arrays of arrays, or an array of hashes (if you'd like named access to the data). Or maybe I don't understand your intended use of this data... Montgomery Conner On 9/13/07, Tim McDaniel wrote: > > On Thu, 13 Sep 2007, Jason Bodnar wrote: > > http://search.cpan.org/~nwclark/perl-5.8.8/lib/Class/Struct.pm > > > > I've never used it but it looks like it's part of the perl dist. > > And it's even on the ancient RedHat Linux 9 box. Thanks -- I'm > checking it out now. > > -- > Tim McDaniel, tmcd at panix.com > _______________________________________________ > Austin mailing list > Austin at pm.org > http://mail.pm.org/mailman/listinfo/austin > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/austin/attachments/20070913/2c23e572/attachment.html From tmcd at panix.com Thu Sep 13 22:53:35 2007 From: tmcd at panix.com (tmcd at panix.com) Date: Fri, 14 Sep 2007 00:53:35 -0500 (CDT) Subject: APM: Just need structs In-Reply-To: References: <761AFC9D-BDFA-4AF0-ADA2-EA49484B4D3B@codecafe.com> <20070913174043.M39544@shakabuku.org> Message-ID: On Thu, 13 Sep 2007, Montgomery Conner wrote: > If you don't require encapsulation the easiest (and most efficient) > solution would be to forgo building an object to hold this data: > there would be no point and there is a semi-trivial amount of > overhead in doing so. Micro-optimization leads to micro-results. What's going to dominate the runtime of this program is the many many `...` and open(IN, "...|") calls to external programs. > You could use an array instead. The three types of objects: - Filespecs like //depot/dev/foo/bar.java#3 That's a dead giveaway that it's Perforce. - Changelist numbers like 67890 - Bug numbers like 12345 A filespec is associated with a changelist. A changelist may be associated with a bug. I have to do system("p4 ...") to find out what objects exist and their associations. I need to be able to query whether I've dealt with an object before, so lookup must be efficient. There's different data that I want to store with each object type. Filespecs obviously wouldn't work as array indices, and searching array values would be ugly to work with. The changelist numbers and bug numbers could work as arrays, but I was thinking of hashes anyway. -- Tim McDaniel; Reply-To: tmcd at panix.com From tmcd at panix.com Fri Sep 14 15:39:32 2007 From: tmcd at panix.com (Tim McDaniel) Date: Fri, 14 Sep 2007 17:39:32 -0500 (CDT) Subject: APM: Inverted objects? Message-ID: I dimly recall a presentation about "inverted objects" or some phrase like that. The standard Perl procedure boils down to my $obj = {}; $obj->{foo} = 123; $obj->{bar} = 456; The technique was something like my $obj = \0; # some way of generating a unique reference $foo{$obj} = 123; $bar{$obj} = 456; This allows compile-time "member" checking and perhaps other advantages that I don't recall right now. Who thought of this pattern (was it Schwartz?) and where can I read up on it again? -- Tim McDaniel, tmcd at panix.com From montgomery.conner at gmail.com Fri Sep 14 16:38:35 2007 From: montgomery.conner at gmail.com (Montgomery Conner) Date: Fri, 14 Sep 2007 18:38:35 -0500 Subject: APM: Just need structs In-Reply-To: References: <761AFC9D-BDFA-4AF0-ADA2-EA49484B4D3B@codecafe.com> <20070913174043.M39544@shakabuku.org> Message-ID: Ech, shelling-out is so 20th century! :^) Yeah, if you're going to be shelling-out a lot an an array wouldn't buy you much efficiency. If you need random access to the data you can do it most easily with a hash of (anonymous) hashes like this: %object_type1 = ( id1 => { fs => $filespec, cl => $changelist, bg => $bug_no }, id2 => { fs => $filespec, cl => $changelist, bg => $bug_no }, id3 => { fs => $filespec, cl => $changelist, bg => $bug_no }, id4 => { fs => $filespec, cl => $changelist, bg => $bug_no }, id5 => { fs => $filespec, cl => $changelist, bg => $bug_no }, id6 => { fs => $filespec, cl => $changelist, bg => $bug_no }, ... ); The 'id' can be any unique value you'd like of course... then you can access (get or set) it like this: # retrieve a value my $changelist = $object_type1{id2}->{cl}; # set a value $object_type1{id5}->{bg} = $new_bug; # create a new record $object_type1{id213} = { fs => $filespec, cl => $changelist, bg => $bug_no }; ...which is pretty efficient, and, I think, straightforward to use. Alternatively you could opt to use anonymous arrays and access them by index. BUT if you want (or need) to optimize this process (i.e. avoid shelling-out) you might either try the Inline distribution from CPAN (which would allow you to tie your code into the native language of the objects your dealing with via an XSub wrapper), or if this only interacts with Perforce you could avoid reinventing the wheel and just use something in the P4 namespace from CPAN. Like this guy: http://search.cpan.org/~smee/P4-3.5313/P4.pm . Hope that helps, Montgomery On 9/14/07, tmcd at panix.com wrote: > > On Thu, 13 Sep 2007, Montgomery Conner > wrote: > > If you don't require encapsulation the easiest (and most efficient) > > solution would be to forgo building an object to hold this data: > > there would be no point and there is a semi-trivial amount of > > overhead in doing so. > > Micro-optimization leads to micro-results. What's going to dominate > the runtime of this program is the many many `...` and > open(IN, "...|") calls to external programs. > > > You could use an array instead. > > The three types of objects: > - Filespecs like //depot/dev/foo/bar.java#3 > That's a dead giveaway that it's Perforce. > - Changelist numbers like 67890 > - Bug numbers like 12345 > > A filespec is associated with a changelist. A changelist may be > associated with a bug. I have to do system("p4 ...") to find out what > objects exist and their associations. I need to be able to query > whether I've dealt with an object before, so lookup must be efficient. > There's different data that I want to store with each object type. > > Filespecs obviously wouldn't work as array indices, and searching > array values would be ugly to work with. The changelist numbers and > bug numbers could work as arrays, but I was thinking of hashes anyway. > > -- > Tim McDaniel; Reply-To: tmcd at panix.com > _______________________________________________ > Austin mailing list > Austin at pm.org > http://mail.pm.org/mailman/listinfo/austin > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/austin/attachments/20070914/fa6e8558/attachment.html From montgomery.conner at gmail.com Fri Sep 14 16:38:35 2007 From: montgomery.conner at gmail.com (Montgomery Conner) Date: Fri, 14 Sep 2007 18:38:35 -0500 Subject: APM: Just need structs In-Reply-To: References: <761AFC9D-BDFA-4AF0-ADA2-EA49484B4D3B@codecafe.com> <20070913174043.M39544@shakabuku.org> Message-ID: Ech, shelling-out is so 20th century! :^) Yeah, if you're going to be shelling-out a lot an an array wouldn't buy you much efficiency. If you need random access to the data you can do it most easily with a hash of (anonymous) hashes like this: %object_type1 = ( id1 => { fs => $filespec, cl => $changelist, bg => $bug_no }, id2 => { fs => $filespec, cl => $changelist, bg => $bug_no }, id3 => { fs => $filespec, cl => $changelist, bg => $bug_no }, id4 => { fs => $filespec, cl => $changelist, bg => $bug_no }, id5 => { fs => $filespec, cl => $changelist, bg => $bug_no }, id6 => { fs => $filespec, cl => $changelist, bg => $bug_no }, ... ); The 'id' can be any unique value you'd like of course... then you can access (get or set) it like this: # retrieve a value my $changelist = $object_type1{id2}->{cl}; # set a value $object_type1{id5}->{bg} = $new_bug; # create a new record $object_type1{id213} = { fs => $filespec, cl => $changelist, bg => $bug_no }; ...which is pretty efficient, and, I think, straightforward to use. Alternatively you could opt to use anonymous arrays and access them by index. BUT if you want (or need) to optimize this process (i.e. avoid shelling-out) you might either try the Inline distribution from CPAN (which would allow you to tie your code into the native language of the objects your dealing with via an XSub wrapper), or if this only interacts with Perforce you could avoid reinventing the wheel and just use something in the P4 namespace from CPAN. Like this guy: http://search.cpan.org/~smee/P4-3.5313/P4.pm . Hope that helps, Montgomery On 9/14/07, tmcd at panix.com wrote: > > On Thu, 13 Sep 2007, Montgomery Conner > wrote: > > If you don't require encapsulation the easiest (and most efficient) > > solution would be to forgo building an object to hold this data: > > there would be no point and there is a semi-trivial amount of > > overhead in doing so. > > Micro-optimization leads to micro-results. What's going to dominate > the runtime of this program is the many many `...` and > open(IN, "...|") calls to external programs. > > > You could use an array instead. > > The three types of objects: > - Filespecs like //depot/dev/foo/bar.java#3 > That's a dead giveaway that it's Perforce. > - Changelist numbers like 67890 > - Bug numbers like 12345 > > A filespec is associated with a changelist. A changelist may be > associated with a bug. I have to do system("p4 ...") to find out what > objects exist and their associations. I need to be able to query > whether I've dealt with an object before, so lookup must be efficient. > There's different data that I want to store with each object type. > > Filespecs obviously wouldn't work as array indices, and searching > array values would be ugly to work with. The changelist numbers and > bug numbers could work as arrays, but I was thinking of hashes anyway. > > -- > Tim McDaniel; Reply-To: tmcd at panix.com > _______________________________________________ > Austin mailing list > Austin at pm.org > http://mail.pm.org/mailman/listinfo/austin > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/austin/attachments/20070914/fa6e8558/attachment-0001.html From montgomery.conner at gmail.com Fri Sep 14 17:02:01 2007 From: montgomery.conner at gmail.com (Montgomery Conner) Date: Fri, 14 Sep 2007 19:02:01 -0500 Subject: APM: Inverted objects? In-Reply-To: References: Message-ID: AFAIN this tactic was originally proposed by Damian Conway in his 2000 book 'Object Oriented Perl'... the implementation is typically called 'inside-out objects'. These have been implemented in dozens of ways over the last few years, but perhaps the best explanation and description is the documentation that comes with Damian's own Class::Std... here: http://search.cpan.org/~dconway/Class-Std-v0.0.8/lib/Class/Std.pm good luck, Montgomery On 9/14/07, Tim McDaniel wrote: > > I dimly recall a presentation about "inverted objects" or some phrase > like that. The standard Perl procedure boils down to > my $obj = {}; > $obj->{foo} = 123; > $obj->{bar} = 456; > > The technique was something like > my $obj = \0; # some way of generating a unique reference > $foo{$obj} = 123; > $bar{$obj} = 456; > This allows compile-time "member" checking and perhaps other > advantages that I don't recall right now. > > Who thought of this pattern (was it Schwartz?) and where can I read up > on it again? > > -- > Tim McDaniel, tmcd at panix.com > _______________________________________________ > Austin mailing list > Austin at pm.org > http://mail.pm.org/mailman/listinfo/austin > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/austin/attachments/20070914/5eb6841b/attachment.html From montgomery.conner at gmail.com Fri Sep 14 16:38:35 2007 From: montgomery.conner at gmail.com (Montgomery Conner) Date: Fri, 14 Sep 2007 18:38:35 -0500 Subject: APM: Just need structs In-Reply-To: References: <761AFC9D-BDFA-4AF0-ADA2-EA49484B4D3B@codecafe.com> <20070913174043.M39544@shakabuku.org> Message-ID: Ech, shelling-out is so 20th century! :^) Yeah, if you're going to be shelling-out a lot an an array wouldn't buy you much efficiency. If you need random access to the data you can do it most easily with a hash of (anonymous) hashes like this: %object_type1 = ( id1 => { fs => $filespec, cl => $changelist, bg => $bug_no }, id2 => { fs => $filespec, cl => $changelist, bg => $bug_no }, id3 => { fs => $filespec, cl => $changelist, bg => $bug_no }, id4 => { fs => $filespec, cl => $changelist, bg => $bug_no }, id5 => { fs => $filespec, cl => $changelist, bg => $bug_no }, id6 => { fs => $filespec, cl => $changelist, bg => $bug_no }, ... ); The 'id' can be any unique value you'd like of course... then you can access (get or set) it like this: # retrieve a value my $changelist = $object_type1{id2}->{cl}; # set a value $object_type1{id5}->{bg} = $new_bug; # create a new record $object_type1{id213} = { fs => $filespec, cl => $changelist, bg => $bug_no }; ...which is pretty efficient, and, I think, straightforward to use. Alternatively you could opt to use anonymous arrays and access them by index. BUT if you want (or need) to optimize this process (i.e. avoid shelling-out) you might either try the Inline distribution from CPAN (which would allow you to tie your code into the native language of the objects your dealing with via an XSub wrapper), or if this only interacts with Perforce you could avoid reinventing the wheel and just use something in the P4 namespace from CPAN. Like this guy: http://search.cpan.org/~smee/P4-3.5313/P4.pm . Hope that helps, Montgomery On 9/14/07, tmcd at panix.com wrote: > > On Thu, 13 Sep 2007, Montgomery Conner > wrote: > > If you don't require encapsulation the easiest (and most efficient) > > solution would be to forgo building an object to hold this data: > > there would be no point and there is a semi-trivial amount of > > overhead in doing so. > > Micro-optimization leads to micro-results. What's going to dominate > the runtime of this program is the many many `...` and > open(IN, "...|") calls to external programs. > > > You could use an array instead. > > The three types of objects: > - Filespecs like //depot/dev/foo/bar.java#3 > That's a dead giveaway that it's Perforce. > - Changelist numbers like 67890 > - Bug numbers like 12345 > > A filespec is associated with a changelist. A changelist may be > associated with a bug. I have to do system("p4 ...") to find out what > objects exist and their associations. I need to be able to query > whether I've dealt with an object before, so lookup must be efficient. > There's different data that I want to store with each object type. > > Filespecs obviously wouldn't work as array indices, and searching > array values would be ugly to work with. The changelist numbers and > bug numbers could work as arrays, but I was thinking of hashes anyway. > > -- > Tim McDaniel; Reply-To: tmcd at panix.com > _______________________________________________ > Austin mailing list > Austin at pm.org > http://mail.pm.org/mailman/listinfo/austin > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/austin/attachments/20070914/fa6e8558/attachment-0005.html From montgomery.conner at gmail.com Fri Sep 14 17:02:01 2007 From: montgomery.conner at gmail.com (Montgomery Conner) Date: Fri, 14 Sep 2007 19:02:01 -0500 Subject: APM: Inverted objects? In-Reply-To: References: Message-ID: AFAIN this tactic was originally proposed by Damian Conway in his 2000 book 'Object Oriented Perl'... the implementation is typically called 'inside-out objects'. These have been implemented in dozens of ways over the last few years, but perhaps the best explanation and description is the documentation that comes with Damian's own Class::Std... here: http://search.cpan.org/~dconway/Class-Std-v0.0.8/lib/Class/Std.pm good luck, Montgomery On 9/14/07, Tim McDaniel wrote: > > I dimly recall a presentation about "inverted objects" or some phrase > like that. The standard Perl procedure boils down to > my $obj = {}; > $obj->{foo} = 123; > $obj->{bar} = 456; > > The technique was something like > my $obj = \0; # some way of generating a unique reference > $foo{$obj} = 123; > $bar{$obj} = 456; > This allows compile-time "member" checking and perhaps other > advantages that I don't recall right now. > > Who thought of this pattern (was it Schwartz?) and where can I read up > on it again? > > -- > Tim McDaniel, tmcd at panix.com > _______________________________________________ > Austin mailing list > Austin at pm.org > http://mail.pm.org/mailman/listinfo/austin > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/austin/attachments/20070914/5eb6841b/attachment-0002.html From tmcd at panix.com Fri Sep 14 17:23:48 2007 From: tmcd at panix.com (Tim McDaniel) Date: Fri, 14 Sep 2007 19:23:48 -0500 (CDT) Subject: APM: Just need structs In-Reply-To: References: <761AFC9D-BDFA-4AF0-ADA2-EA49484B4D3B@codecafe.com> <20070913174043.M39544@shakabuku.org> Message-ID: On Fri, 14 Sep 2007, Montgomery Conner wrote: > If you need random access to the data you can do it most easily with > a hash of (anonymous) hashes That's what I'm doing, via Class::Struct for the instances. I'm not sure Class::Struct buys me much more than documentation. > or if this only interacts with Perforce you could avoid reinventing > the wheel and just use something in the P4 namespace from CPAN. Like > this guy: > http://search.cpan.org/~smee/P4-3.5313/P4.pm *blink* *blink* *blink* I shoulda figured that there would be a Perl module for it. It's a valuable lesson. Thank you. On the other hand, the two reviews are P4 (3.5313) This is the best module to use if you are one of those who do not like system calls. It is also very fast compared to calling perforce through system calls. p4 tagged mode( p4 -ztag) will return the results in a hash which saves you the trouble of parsing the output. The support is also excellent and requests for support on different platforms has been very prompt. Also has a very simple and intuitive interface provided you already know perforce. P4 (3.5313) Wished there weren't soooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo many hoops through which I jumped. and still nothing. Forget this. Use system calls. This is a waste of your time. Turn back now. And I've already coded the p4 system() calls. -- Tim McDaniel, tmcd at panix.com From montgomery.conner at gmail.com Fri Sep 14 17:02:01 2007 From: montgomery.conner at gmail.com (Montgomery Conner) Date: Fri, 14 Sep 2007 19:02:01 -0500 Subject: APM: Inverted objects? In-Reply-To: References: Message-ID: AFAIN this tactic was originally proposed by Damian Conway in his 2000 book 'Object Oriented Perl'... the implementation is typically called 'inside-out objects'. These have been implemented in dozens of ways over the last few years, but perhaps the best explanation and description is the documentation that comes with Damian's own Class::Std... here: http://search.cpan.org/~dconway/Class-Std-v0.0.8/lib/Class/Std.pm good luck, Montgomery On 9/14/07, Tim McDaniel wrote: > > I dimly recall a presentation about "inverted objects" or some phrase > like that. The standard Perl procedure boils down to > my $obj = {}; > $obj->{foo} = 123; > $obj->{bar} = 456; > > The technique was something like > my $obj = \0; # some way of generating a unique reference > $foo{$obj} = 123; > $bar{$obj} = 456; > This allows compile-time "member" checking and perhaps other > advantages that I don't recall right now. > > Who thought of this pattern (was it Schwartz?) and where can I read up > on it again? > > -- > Tim McDaniel, tmcd at panix.com > _______________________________________________ > Austin mailing list > Austin at pm.org > http://mail.pm.org/mailman/listinfo/austin > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/austin/attachments/20070914/5eb6841b/attachment-0003.html From montgomery.conner at gmail.com Fri Sep 14 16:38:35 2007 From: montgomery.conner at gmail.com (Montgomery Conner) Date: Fri, 14 Sep 2007 18:38:35 -0500 Subject: APM: Just need structs In-Reply-To: References: <761AFC9D-BDFA-4AF0-ADA2-EA49484B4D3B@codecafe.com> <20070913174043.M39544@shakabuku.org> Message-ID: Ech, shelling-out is so 20th century! :^) Yeah, if you're going to be shelling-out a lot an an array wouldn't buy you much efficiency. If you need random access to the data you can do it most easily with a hash of (anonymous) hashes like this: %object_type1 = ( id1 => { fs => $filespec, cl => $changelist, bg => $bug_no }, id2 => { fs => $filespec, cl => $changelist, bg => $bug_no }, id3 => { fs => $filespec, cl => $changelist, bg => $bug_no }, id4 => { fs => $filespec, cl => $changelist, bg => $bug_no }, id5 => { fs => $filespec, cl => $changelist, bg => $bug_no }, id6 => { fs => $filespec, cl => $changelist, bg => $bug_no }, ... ); The 'id' can be any unique value you'd like of course... then you can access (get or set) it like this: # retrieve a value my $changelist = $object_type1{id2}->{cl}; # set a value $object_type1{id5}->{bg} = $new_bug; # create a new record $object_type1{id213} = { fs => $filespec, cl => $changelist, bg => $bug_no }; ...which is pretty efficient, and, I think, straightforward to use. Alternatively you could opt to use anonymous arrays and access them by index. BUT if you want (or need) to optimize this process (i.e. avoid shelling-out) you might either try the Inline distribution from CPAN (which would allow you to tie your code into the native language of the objects your dealing with via an XSub wrapper), or if this only interacts with Perforce you could avoid reinventing the wheel and just use something in the P4 namespace from CPAN. Like this guy: http://search.cpan.org/~smee/P4-3.5313/P4.pm . Hope that helps, Montgomery On 9/14/07, tmcd at panix.com wrote: > > On Thu, 13 Sep 2007, Montgomery Conner > wrote: > > If you don't require encapsulation the easiest (and most efficient) > > solution would be to forgo building an object to hold this data: > > there would be no point and there is a semi-trivial amount of > > overhead in doing so. > > Micro-optimization leads to micro-results. What's going to dominate > the runtime of this program is the many many `...` and > open(IN, "...|") calls to external programs. > > > You could use an array instead. > > The three types of objects: > - Filespecs like //depot/dev/foo/bar.java#3 > That's a dead giveaway that it's Perforce. > - Changelist numbers like 67890 > - Bug numbers like 12345 > > A filespec is associated with a changelist. A changelist may be > associated with a bug. I have to do system("p4 ...") to find out what > objects exist and their associations. I need to be able to query > whether I've dealt with an object before, so lookup must be efficient. > There's different data that I want to store with each object type. > > Filespecs obviously wouldn't work as array indices, and searching > array values would be ugly to work with. The changelist numbers and > bug numbers could work as arrays, but I was thinking of hashes anyway. > > -- > Tim McDaniel; Reply-To: tmcd at panix.com > _______________________________________________ > Austin mailing list > Austin at pm.org > http://mail.pm.org/mailman/listinfo/austin > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/austin/attachments/20070914/fa6e8558/attachment-0006.html From montgomery.conner at gmail.com Fri Sep 14 16:38:35 2007 From: montgomery.conner at gmail.com (Montgomery Conner) Date: Fri, 14 Sep 2007 18:38:35 -0500 Subject: APM: Just need structs In-Reply-To: References: <761AFC9D-BDFA-4AF0-ADA2-EA49484B4D3B@codecafe.com> <20070913174043.M39544@shakabuku.org> Message-ID: Ech, shelling-out is so 20th century! :^) Yeah, if you're going to be shelling-out a lot an an array wouldn't buy you much efficiency. If you need random access to the data you can do it most easily with a hash of (anonymous) hashes like this: %object_type1 = ( id1 => { fs => $filespec, cl => $changelist, bg => $bug_no }, id2 => { fs => $filespec, cl => $changelist, bg => $bug_no }, id3 => { fs => $filespec, cl => $changelist, bg => $bug_no }, id4 => { fs => $filespec, cl => $changelist, bg => $bug_no }, id5 => { fs => $filespec, cl => $changelist, bg => $bug_no }, id6 => { fs => $filespec, cl => $changelist, bg => $bug_no }, ... ); The 'id' can be any unique value you'd like of course... then you can access (get or set) it like this: # retrieve a value my $changelist = $object_type1{id2}->{cl}; # set a value $object_type1{id5}->{bg} = $new_bug; # create a new record $object_type1{id213} = { fs => $filespec, cl => $changelist, bg => $bug_no }; ...which is pretty efficient, and, I think, straightforward to use. Alternatively you could opt to use anonymous arrays and access them by index. BUT if you want (or need) to optimize this process (i.e. avoid shelling-out) you might either try the Inline distribution from CPAN (which would allow you to tie your code into the native language of the objects your dealing with via an XSub wrapper), or if this only interacts with Perforce you could avoid reinventing the wheel and just use something in the P4 namespace from CPAN. Like this guy: http://search.cpan.org/~smee/P4-3.5313/P4.pm . Hope that helps, Montgomery On 9/14/07, tmcd at panix.com wrote: > > On Thu, 13 Sep 2007, Montgomery Conner > wrote: > > If you don't require encapsulation the easiest (and most efficient) > > solution would be to forgo building an object to hold this data: > > there would be no point and there is a semi-trivial amount of > > overhead in doing so. > > Micro-optimization leads to micro-results. What's going to dominate > the runtime of this program is the many many `...` and > open(IN, "...|") calls to external programs. > > > You could use an array instead. > > The three types of objects: > - Filespecs like //depot/dev/foo/bar.java#3 > That's a dead giveaway that it's Perforce. > - Changelist numbers like 67890 > - Bug numbers like 12345 > > A filespec is associated with a changelist. A changelist may be > associated with a bug. I have to do system("p4 ...") to find out what > objects exist and their associations. I need to be able to query > whether I've dealt with an object before, so lookup must be efficient. > There's different data that I want to store with each object type. > > Filespecs obviously wouldn't work as array indices, and searching > array values would be ugly to work with. The changelist numbers and > bug numbers could work as arrays, but I was thinking of hashes anyway. > > -- > Tim McDaniel; Reply-To: tmcd at panix.com > _______________________________________________ > Austin mailing list > Austin at pm.org > http://mail.pm.org/mailman/listinfo/austin > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/austin/attachments/20070914/fa6e8558/attachment-0009.html From tshinnic at io.com Fri Sep 14 20:46:27 2007 From: tshinnic at io.com (Thomas L. Shinnick) Date: Fri, 14 Sep 2007 22:46:27 -0500 Subject: APM: Inverted objects? In-Reply-To: References: Message-ID: <6.2.5.6.2.20070914223952.0513fa80@io.com> At 07:02 PM 9/14/2007, Montgomery Conner wrote: >AFAIN this tactic was originally proposed by Damian Conway in his >2000 book 'Object Oriented Perl'... the implementation is typically >called 'inside-out objects'. > >These have been implemented in dozens of ways over the last few >years, but perhaps the best explanation and description is the >documentation that comes with Damian's own Class::Std... here: >http://search.cpan.org/~dconway/Class-Std-v0.0.8/lib/Class/Std.pm > > >good luck, >Montgomery The discussion in Class::InsideOut::Manual::About mentions the other inside-out implementations, and recommends the larger Object::InsideOut or itself, Class::InsideOut. From the reading I would recommend either of these "inspired by" modules over the inspiration. http://search.cpan.org/~dagolden/Class-InsideOut-1.08/ http://search.cpan.org/~jdhedden/Object-InsideOut-3.25/ >On 9/14/07, Tim McDaniel <tmcd at panix.com> wrote: >I dimly recall a presentation about "inverted objects" or some phrase >like that. The standard Perl procedure boils down to > my $obj = {}; > $obj->{foo} = 123; > $obj->{bar} = 456; > >The technique was something like > my $obj = \0; # some way of generating a unique reference > $foo{$obj} = 123; > $bar{$obj} = 456; >This allows compile-time "member" checking and perhaps other >advantages that I don't recall right now. > >Who thought of this pattern (was it Schwartz?) and where can I read up >on it again? > >-- >Tim McDaniel, tmcd at panix.com >_______________________________________________ >Austin mailing list >Austin at pm.org >http://mail.pm.org/mailman/listinfo/austin > > >_______________________________________________ >Austin mailing list >Austin at pm.org >http://mail.pm.org/mailman/listinfo/austin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/austin/attachments/20070914/01b7e9d6/attachment.html From Rohit.Puri at akraya.com Wed Sep 19 14:30:49 2007 From: Rohit.Puri at akraya.com (Rohit Puri) Date: Wed, 19 Sep 2007 14:30:49 -0700 Subject: APM: Java Developer with Perl experience needed for Ebay Message-ID: <8A902C51C81DEC43A6A2A9EFE76D3E0FF5DE86@akrayasbs> Hi, I have an urgent position with one of my Direct Client's for a Core Java Developer. I would really appreciate if you could send me your updated resume along with your contact information and billing rate at rohit.puri at akraya.com . The job location and description are given below. Skills in red must to have Core Java Developer Description: We are looking for exceptional software engineers that have a strong command of build automation tools in a UNIX/Solaris/Linux environment. The ideal candidate has a strong understanding of Java and Perl * Develop new features and maintain a java/perl application in client software tools team * Think ahead to craft scalable solutions to meet the growing needs of client. * Experience with source control tools. * Ability to own the project make files and build scripts, work closely with the release, architecture, engineering leads teams to optimize the software development build system. * An aggressive problem-solver; enjoy debugging challenges. * Strong verbal and written communication skills are a positive due to dynamic nature of discussions with other engineering and product teams. Experience with source control tools. Requirements * Minimum of 5 or more years of experience in sofware development. * Minimum of 2 or more years of experience in Java and Perl. * Experience with shell, make, and GNU tools. * Experience with UNIX, Solaris, Linux. * An organized individual who is very detail-oriented and can develop plans necessary to meet specific goals Job Type: C2H, Duration: 3 Months Contract to Hire Location: Austin, TX Thanks & Regards, Rohit Puri Akraya Inc. 840 W. California St. #220 Sunnyvale, California 94086 Direct Line: 408 .512 .2358 E-mail: rohit.puri at akraya.com ---------------------------------------------- The Right Solutions...on time, within budget! ************************************************************************ "Under Bill s.1618 Title III passed by the 105th U .S. Congress, this mail cannot be considered Spam as long as we include contact information and a remove link for removal from our mailing list. To be removed from our mailing list reply with "REMOVE" in the subject heading and your email address in the body. Include complete address and/or domain/ aliases to be removed. If you still get the emails, please call us at the numbers given above." ************************************************************************ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/austin/attachments/20070919/75e967ad/attachment.html From James.Wickett at ni.com Thu Sep 20 14:02:12 2007 From: James.Wickett at ni.com (James Wickett) Date: Thu, 20 Sep 2007 16:02:12 -0500 Subject: APM: CN=James Wickett/OU=AUS/O=NIC is out of the office. Message-ID: I will be out of the office starting 09/18/2007 and will not return until 09/24/2007. I am at the University of Oklahoma for recruiting this week. I will have access to email throughout the week and will try and respond to emails nightly. However, if you require assistance from the Web Systems Team, please email #Web Admins. Best, James From kh at greenshire.com Thu Sep 20 13:57:05 2007 From: kh at greenshire.com (Keith Howanitz) Date: Thu, 20 Sep 2007 15:57:05 -0500 (CDT) Subject: APM: [SNIP] is out of the office. In-Reply-To: References: Message-ID: How did we end up with so many vacation daemons that are so naively written that they don't check for simple things like Precedence list/bulk? It's a rhetorical question, but wow! Talk about NIH syndrome.