From awwaiid at thelackthereof.org  Tue Nov  1 13:51:12 2005
From: awwaiid at thelackthereof.org (Brock)
Date: Tue, 1 Nov 2005 14:51:12 -0700
Subject: [Phoenix-pm] Meeting announcement for Nov 9, 2005
Message-ID: <20051101215112.GD13482@thelackthereof.org>


Phoenix.PM Meeting Announcement

      Time: Wed 16 November 2005 @7:00pm
  Location: Scottsdale Community College, Room CM-424
            http://www.sc.maricopa.edu/sccmap/ for maps
     Topic: Intro to Object-Oriented Programming (part 1)
            Advanced topic TBA
     Other: Wired internet available, bring your laptop+cat5

I look forward to seeing you there!
--Brock


From awwaiid at thelackthereof.org  Tue Nov  1 14:08:37 2005
From: awwaiid at thelackthereof.org (Brock)
Date: Tue, 1 Nov 2005 15:08:37 -0700
Subject: [Phoenix-pm] [gdt@deru.com: Re: Perl Monger meetings at SCC]
Message-ID: <20051101220837.GA22489@thelackthereof.org>


On 2005.10.25.10.35, Scott Walters wrote:
| I think I can make it. Given the excellence of your last intro talk,
| I strongly encourage you to do the swf mp3+slides trick. What happened
| with the vnc2flash trick, anyway?

(thanks for the compliment about the talk)

What happened was I thought I pushed the 'record' button but in fact I
did not. Someday I should play the transcript and try to pretend I'm
doing it live and record that :)

--Brock


From scott at illogics.org  Fri Nov  4 15:29:15 2005
From: scott at illogics.org (Scott Walters)
Date: Fri, 4 Nov 2005 15:29:15 -0800
Subject: [Phoenix-pm] Fwd: A surprising segfault
Message-ID: <20051104232914.GR15273@illogics.org>

----- Forwarded message from Robin Houston <robin at cpan.org> -----

Return-Path: perl5-porters-return-106317-scott=slowass.net at perl.org
X-Original-To: scott at slowass.net
Delivered-To: scott at slowass.net
Received: from lists.develooper.com (x6.develooper.com [63.251.223.186])
	by slowass.net (Postfix) with SMTP id 12FD9553A5
	for <scott at slowass.net>; Fri,  4 Nov 2005 23:24:53 +0000 (GMT)
Received: (qmail 688 invoked by uid 514); 4 Nov 2005 23:19:52 -0000
Mailing-List: contact perl5-porters-help at perl.org; run by ezmlm
Precedence: bulk
list-help: <mailto:perl5-porters-help at perl.org>
list-unsubscribe: <mailto:perl5-porters-unsubscribe at perl.org>
list-post: <mailto:perl5-porters at perl.org>
X-List-Archive: <http://nntp.perl.org/group/perl.perl5.porters/106317>
List-Id: <perl5-porters.perl.org>
Delivered-To: mailing list perl5-porters at perl.org
Received: (qmail 676 invoked from network); 4 Nov 2005 23:19:51 -0000
Delivered-To: perl5-porters at perl.org
X-Spam-Status: No, hits=-2.6 required=8.0
	tests=BAYES_00
X-Spam-Check-By: la.mx.develooper.com
Received-SPF: pass (x1.develooper.com: local policy)
Date: Fri, 4 Nov 2005 23:19:13 +0000
From: Robin Houston <robin at cpan.org>
To: Perl 5 Porters <perl5-porters at perl.org>
Subject: A surprising segfault
Message-ID: <20051104231913.GA20404 at rpc142.cs.man.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
X-Spam-Score: 0.0 (/)
X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1EYAq2-0006Fr-BQ*oK64xxa/oR2*

Do you guys know about this one?

 $ ./perl -e 'map print(reverse), ("")x68'
 Segmentation fault

Someone just mentioned it over on perlmonks.

I haven't looked into it at all, but this is the backtrace:
#0  0x0811f6c4 in Perl_pop_scope (my_perl=0x81ac720) at scope.c:93
#1  0x080e7b8d in Perl_pp_leave (my_perl=0x81ac720) at pp_hot.c:1793
#2  0x080c7036 in Perl_runops_debug (my_perl=0x81ac720) at dump.c:1597
#3  0x08065bee in S_run_body (my_perl=0x81ac720, oldscope=1) at perl.c:2290
#4  0x0806561b in perl_run (my_perl=0x81ac720) at perl.c:2217
#5  0x0805f621 in main (argc=3, argv=0xbfffdc14, env=0xbfffdc24)
    at perlmain.c:103
#6  0x42015704 in __libc_start_main () from /lib/tls/libc.so.6

Any ideas why this might be happening?

Robin

----- End forwarded message -----

From awwaiid at thelackthereof.org  Sat Nov  5 00:29:57 2005
From: awwaiid at thelackthereof.org (Brock)
Date: Sat, 5 Nov 2005 01:29:57 -0700
Subject: [Phoenix-pm] Fwd: A surprising segfault
In-Reply-To: <20051104232914.GR15273@illogics.org>
References: <20051104232914.GR15273@illogics.org>
Message-ID: <20051105082957.GC2792@thelackthereof.org>


Fun! I like how x67 doesn't break it.

--Brock

On 2005.11.04.15.29, Scott Walters wrote:
|...
|  $ ./perl -e 'map print(reverse), ("")x68'
|...

From cakrum at cox.net  Sat Nov  5 06:56:37 2005
From: cakrum at cox.net (Chris Krum)
Date: Sat, 5 Nov 2005 07:56:37 -0700
Subject: [Phoenix-pm] Fwd: A surprising segfault
In-Reply-To: <20051105082957.GC2792@thelackthereof.org>
References: <20051104232914.GR15273@illogics.org>
	<20051105082957.GC2792@thelackthereof.org>
Message-ID: <74667c9187181f4b7a0b14788c11ce67@cox.net>

Must be platform specific. I just tried it on Mac OS X and it didn't 
fault.

On Nov 5, 2005, at 1:29 AM, Brock wrote:

> ./perl -e 'map print(reverse), ("")x68'


From intertwingled at qwest.net  Sat Nov  5 07:01:47 2005
From: intertwingled at qwest.net (Anthony R. Nemmer)
Date: Sat, 05 Nov 2005 08:01:47 -0700
Subject: [Phoenix-pm] Fwd: A surprising segfault
In-Reply-To: <74667c9187181f4b7a0b14788c11ce67@cox.net>
References: <20051104232914.GR15273@illogics.org>	<20051105082957.GC2792@thelackthereof.org>
	<74667c9187181f4b7a0b14788c11ce67@cox.net>
Message-ID: <436CC95B.2070504@qwest.net>

[intertwingled.net::leontopod::-bash] /home/ (Sat Nov 05 07:59:05)
=> perl -e 'map print(reverse), ("")x68'
Segmentation fault
[intertwingled.net::leontopod::-bash] /home/ (Sat Nov 05 07:59:10)
=> perl -v

This is perl, v5.8.4 built for i486-linux

Copyright 1987-2004, Larry Wall

Perl may be copied only under the terms of either the Artistic License 
or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'.  If you have access to the
Internet, point your browser at http://www.perl.com/, the Perl Home Page.

[intertwingled.net::leontopod::-bash] /home/ (Sat Nov 05 07:59:13)
=> uname -a
Linux intertwingled.net 2.4.26 #6 Mon Jun 14 19:07:27 PDT 2004 i686 
unknown unknown GNU/Linux

Tony

Chris Krum wrote:

>Must be platform specific. I just tried it on Mac OS X and it didn't 
>fault.
>
>On Nov 5, 2005, at 1:29 AM, Brock wrote:
>
>  
>
>>./perl -e 'map print(reverse), ("")x68'
>>    
>>
>
>_______________________________________________
>Phoenix-pm mailing list
>Phoenix-pm at pm.org
>http://mail.pm.org/mailman/listinfo/phoenix-pm
>
>
>  
>


-- 

SKYKING, SKYKING, DO NOT ANSWER


From cakrum at cox.net  Sat Nov  5 07:11:50 2005
From: cakrum at cox.net (Chris Krum)
Date: Sat, 5 Nov 2005 08:11:50 -0700
Subject: [Phoenix-pm] Fwd: A surprising segfault
In-Reply-To: <436CC95B.2070504@qwest.net>
References: <20051104232914.GR15273@illogics.org>	<20051105082957.GC2792@thelackthereof.org>
	<74667c9187181f4b7a0b14788c11ce67@cox.net>
	<436CC95B.2070504@qwest.net>
Message-ID: <f77096595b87a8da35b03581780195e4@cox.net>

=> perl -v
This is perl, v5.8.1-RC3 built for darwin-thread-multi-2level
(with 1 registered patch, see perl -V for more detail)
-cut

uname -a
Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005; 
root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC  Power Macintosh powerpc

On Nov 5, 2005, at 8:01 AM, Anthony R. Nemmer wrote:

> [intertwingled.net::leontopod::-bash] /home/ (Sat Nov 05 07:59:05)
> => perl -e 'map print(reverse), ("")x68'
> Segmentation fault
> [intertwingled.net::leontopod::-bash] /home/ (Sat Nov 05 07:59:10)
> => perl -v
>
> This is perl, v5.8.4 built for i486-linux
>
> Copyright 1987-2004, Larry Wall
>
> Perl may be copied only under the terms of either the Artistic License 
> or the
> GNU General Public License, which may be found in the Perl 5 source 
> kit.
>
> Complete documentation for Perl, including FAQ lists, should be found 
> on
> this system using `man perl' or `perldoc perl'.  If you have access to 
> the
> Internet, point your browser at http://www.perl.com/, the Perl Home 
> Page.
>
> [intertwingled.net::leontopod::-bash] /home/ (Sat Nov 05 07:59:13)
> => uname -a
> Linux intertwingled.net 2.4.26 #6 Mon Jun 14 19:07:27 PDT 2004 i686 
> unknown unknown GNU/Linux
>
> Tony
>
> Chris Krum wrote:
>
>> Must be platform specific. I just tried it on Mac OS X and it didn't 
>> fault.
>>
>> On Nov 5, 2005, at 1:29 AM, Brock wrote:
>>
>>
>>> ./perl -e 'map print(reverse), ("")x68'
>>>
>>
>> _______________________________________________
>> Phoenix-pm mailing list
>> Phoenix-pm at pm.org
>> http://mail.pm.org/mailman/listinfo/phoenix-pm
>>
>>
>>
>
>
> -- 
>
> SKYKING, SKYKING, DO NOT ANSWER
>


From cakrum at cox.net  Sat Nov  5 07:26:53 2005
From: cakrum at cox.net (Chris Krum)
Date: Sat, 5 Nov 2005 08:26:53 -0700
Subject: [Phoenix-pm] GUI Abstraction
Message-ID: <666442085ac1ac77bda248a70b001aec@cox.net>

I recently tried to install SPROG (http://sprog.sourceforge.net/) on 
Mac OS X and couldn't get it to work because I couldn't get GTK2 
running. This got me wondering if there was a GUI abstraction layer 
similar to the DBI layer for databases. I couldn't find one but I was 
wondering if the idea had enough merit to be worth starting one of my 
own. Thoughts?

Thanks,
Chris. 


From awwaiid at thelackthereof.org  Sat Nov  5 09:03:12 2005
From: awwaiid at thelackthereof.org (Brock)
Date: Sat, 5 Nov 2005 10:03:12 -0700
Subject: [Phoenix-pm] GUI Abstraction
In-Reply-To: <666442085ac1ac77bda248a70b001aec@cox.net>
References: <666442085ac1ac77bda248a70b001aec@cox.net>
Message-ID: <20051105170312.GD2792@thelackthereof.org>


WxWidgets, and thus WxPerl (wxperl.sf.net) is a good start. It is a
widget set with mulitiple back-ends, such as Gtk+ and Win32 (and mac
somethin).

--Brock

On 2005.11.05.08.26, Chris Krum wrote:
| I recently tried to install SPROG (http://sprog.sourceforge.net/) on 
| Mac OS X and couldn't get it to work because I couldn't get GTK2 
| running. This got me wondering if there was a GUI abstraction layer 
| similar to the DBI layer for databases. I couldn't find one but I was 
| wondering if the idea had enough merit to be worth starting one of my 
| own. Thoughts?
| 
| Thanks,
| Chris. 
| 
| _______________________________________________
| Phoenix-pm mailing list
| Phoenix-pm at pm.org
| http://mail.pm.org/mailman/listinfo/phoenix-pm

From scott at illogics.org  Sat Nov  5 20:01:36 2005
From: scott at illogics.org (Scott Walters)
Date: Sat, 5 Nov 2005 20:01:36 -0800
Subject: [Phoenix-pm] GUI Abstraction
In-Reply-To: <666442085ac1ac77bda248a70b001aec@cox.net>
References: <666442085ac1ac77bda248a70b001aec@cox.net>
Message-ID: <20051106040136.GY15273@illogics.org>

I can't remember what it was called, but there is a module on CPAN that
attempts to rewrite your SQL on the fly to accomodate different databases
and even does software simulations of subquries and such things where
they're lacking. So, sure the idea has merit =P

-scott

On  0, Chris Krum <cakrum at cox.net> wrote:
> I recently tried to install SPROG (http://sprog.sourceforge.net/) on 
> Mac OS X and couldn't get it to work because I couldn't get GTK2 
> running. This got me wondering if there was a GUI abstraction layer 
> similar to the DBI layer databases. I couldn't find one but I was 
> wondering if the idea had enough merit to be worth starting one of my 
> own. Thoughts?
> 
> Thanks,
> Chris. 
> 
> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://mail.pm.org/mailman/listinfo/phoenix-pm

From cakrum at cox.net  Sun Nov  6 11:50:52 2005
From: cakrum at cox.net (Chris Krum)
Date: Sun, 6 Nov 2005 12:50:52 -0700
Subject: [Phoenix-pm] GUI Abstraction
In-Reply-To: <20051106040136.GY15273@illogics.org>
References: <666442085ac1ac77bda248a70b001aec@cox.net>
	<20051106040136.GY15273@illogics.org>
Message-ID: <7e6a1447c29f36e455ca16d4134c55c7@cox.net>

Hey, I like that idea. A GUI layer that divines what toolkit you have 
installed and uses that. And if none is available, it can install TK 
for you. ;-)

Thanks,
Chris.

On Nov 5, 2005, at 9:01 PM, Scott Walters wrote:

> I can't remember what it was called, but there is a module on CPAN that
> attempts to rewrite your SQL on the fly to accomodate different 
> databases
> and even does software simulations of subquries and such things where
> they're lacking. So, sure the idea has merit =P
>
> -scott
>
> On  0, Chris Krum <cakrum at cox.net> wrote:
>> I recently tried to install SPROG (http://sprog.sourceforge.net/) on
>> Mac OS X and couldn't get it to work because I couldn't get GTK2
>> running. This got me wondering if there was a GUI abstraction layer
>> similar to the DBI layer databases. I couldn't find one but I was
>> wondering if the idea had enough merit to be worth starting one of my
>> own. Thoughts?
>>
>> Thanks,
>> Chris.
>>
>> _______________________________________________
>> Phoenix-pm mailing list
>> Phoenix-pm at pm.org
>> http://mail.pm.org/mailman/listinfo/phoenix-pm
>


From benjamin.trussell at asu.edu  Mon Nov  7 15:14:05 2005
From: benjamin.trussell at asu.edu (Benjamin Trussell)
Date: Mon, 07 Nov 2005 16:14:05 -0700
Subject: [Phoenix-pm] Oreilly.com/Perl.com article/tutorial: "Making Sense
	of Subroutines"
Message-ID: <037FF41095AD394DB28A3991559A0FB4A11433@EX04.asurite.ad.asu.edu>


http://www.perl.com/pub/a/2005/11/03/subroutines.html on perl.com ?(as I found it listed on http://www.oreillynet.com/ - a good choice of sites to add to one's list of homepage tabs).


Ben
?


From awwaiid at thelackthereof.org  Tue Nov  8 09:18:25 2005
From: awwaiid at thelackthereof.org (Brock)
Date: Tue, 8 Nov 2005 10:18:25 -0700
Subject: [Phoenix-pm] Meeting topic
Message-ID: <20051108171825.GK2792@thelackthereof.org>


Heya,

I'd like a secondary (at least) presentation at next weeks meeting. It
doesn't have to be anything fancy, just tell us what you've been doing
lately. Volunteer by mailing the list!

--Brock


From awwaiid at thelackthereof.org  Tue Nov 15 12:59:31 2005
From: awwaiid at thelackthereof.org (Brock)
Date: Tue, 15 Nov 2005 13:59:31 -0700
Subject: [Phoenix-pm] 2005-11-16 Meeting Reminder
Message-ID: <20051115205931.GA16987@thelackthereof.org>


Don't forget to come to the meeting tomorrow! Here is the blurb:

      Time: Wed 16 November 2005 @7:00pm
  Location: Scottsdale Community College, Room CM-448
            http://www.sc.maricopa.edu/sccmap/ for maps
     Topic: Intro to Object Programming (part 1?)
            General discussion and news
     Other: Wired internet available, bring your laptop

I'm excited! See you all there :)

--Brock


From scott at illogics.org  Wed Nov 16 15:30:01 2005
From: scott at illogics.org (Scott Walters)
Date: Wed, 16 Nov 2005 15:30:01 -0800
Subject: [Phoenix-pm] 2005-11-16 Meeting Reminder
In-Reply-To: <20051115205931.GA16987@thelackthereof.org>
References: <20051115205931.GA16987@thelackthereof.org>
Message-ID: <20051116233001.GZ15273@illogics.org>

I've got _CGI Programming with Perl_ as a door prize, and a
helpful volunteer is making chocolate chip cookies, even
though they've never been to a PM meeting.

Yo, FYI, y'all!

-scott

On  0, Brock <awwaiid at thelackthereof.org> wrote:
> 
> Don't forget to come to the meeting tomorrow! Here is the blurb:
> 
>       Time: Wed 16 November 2005 @7:00pm
>   Location: Scottsdale Community College, Room CM-448
>             http://www.sc.maricopa.edu/sccmap/ for maps
>      Topic: Intro to Object Programming (part 1?)
>             General discussion and news
>      Other: Wired internet available, bring your laptop
> 
> I'm excited! See you all there :)
> 
> --Brock
> 
> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://mail.pm.org/mailman/listinfo/phoenix-pm

From scott at illogics.org  Thu Nov 17 08:56:07 2005
From: scott at illogics.org (Scott Walters)
Date: Thu, 17 Nov 2005 08:56:07 -0800
Subject: [Phoenix-pm] Meeting minutes: was: Re: 2005-11-16 Meeting Reminder
In-Reply-To: <20051115205931.GA16987@thelackthereof.org>
References: <20051115205931.GA16987@thelackthereof.org>
Message-ID: <20051117165607.GE15273@illogics.org>

Hi everyone,

Here's a synopsis of the meeting.

The chocolate chip cookies were well received. Tricia says you're
all most welcome and proceeded to giggle. 

Brock's notebook was run out of batteries by Brock who abandoned
it on the podeum while he sat down and gabbed.

I discovered that the SCC network was censored. 

Discussion, during and after the presentation, started with the merits
of OO over modules, and moved to versioning, team communication,
chat vs phone vs Wiki vs email. Self-modifying code and instrospection
where philosophcized over as the subjects of PadWalker, B, B::Generate,
and Perl 6 came up. Perl 5 and Perl 6 backwards compatability was
asked about. The coexistance of interest in and suspicion of Perl 6
continues to amaze me.

Brock, at my request, did an impromptu presentation of his work on
Continuity, a Coro/coroutine based Web app environment that abstracts
away the stateless, sessionless nature of HTTP and lets you write
read apps (damnit! About time!). 

An employment fortuitousness presented itself for those who came
to the meeting. 

I injected (invected?) bile on strong typing, Wiki, and about 3/4ths 
of the subjects I usually invect on.

The tone of the meeting was odd, with so many new faces (glad you
all could make it and I hope to see each and every one of you again!)
and so few old faces. On the other hand, most meetings are probably too 
clique-y for new folks. Usually there's both more activities planned and 
more people who want to just gab about Slashdot headlines and catch up with 
friends than pay attention, both of which are generally good things. Oh well. 
I hope people had fun anyway. Even though it was a classroom setting, the
Life hacker stickers and various cool stickers adorned the walls.

Unlike the previous meeting, no attempt was made to record the presentation.

Brock says there are rotated backups of the webserver, so the Wiki is not
lost. Now that I have shell access, I'll try to set up CVS correctly so
that the Wiki can be regressed as needed.

When excited, face blindness and name blindness kicks in for me, so I'm
sorry to everyone I didn't greet -- especially the people I've had
long, interesting conversations with before (d'oh!). I promise, if you attend 
10 or 20 meetings, I will start to remember your face and name. 

On behalf of all of those who attended, I'd like to express my thanks to
SCC for their hospitality.

Thanks,
-scott


On  0, Brock <awwaiid at thelackthereof.org> wrote:
> 
> Don't forget to come to the meeting tomorrow! Here is the blurb:
> 
>       Time: Wed 16 November 2005 @7:00pm
>   Location: Scottsdale Community College, Room CM-448
>             http://www.sc.maricopa.edu/sccmap/ for maps
>      Topic: Intro to Object Programming (part 1?)
>             General discussion and news
>      Other: Wired internet available, bring your laptop
> 
> I'm excited! See you all there :)
> 
> --Brock
> 
> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://mail.pm.org/mailman/listinfo/phoenix-pm

From gthurman at gmail.com  Fri Nov 18 07:06:58 2005
From: gthurman at gmail.com (Gerald Thurman)
Date: Fri, 18 Nov 2005 08:06:58 -0700
Subject: [Phoenix-pm] Potential PERL Course
Message-ID: <188cf8d30511180706s54ac6c31m5544005747e35ff6@mail.gmail.com>

I am happy SCC had an opportunity to have some Perl mongers visit CM-448.

As mentioned at the November meeting, I'd like to offer a "Survey of
Script Programming Languages using PERL, PHP, Python" course during
the Spring 2006 semester at SCC.

The following hyperlink is to a PPP class that I did a couple of years ago.
The content of this website is stale and it needs to be redone, but it offers
an example of what we want to offer.

http://deru.com/~gdt/ppp/

Thank You and I hope Perl mongers return to SCC someday.

From scott at illogics.org  Tue Nov 22 09:32:52 2005
From: scott at illogics.org (Scott Walters)
Date: Tue, 22 Nov 2005 17:32:52 +0000
Subject: [Phoenix-pm] Potential PERL Course
In-Reply-To: <188cf8d30511180706s54ac6c31m5544005747e35ff6@mail.gmail.com>
References: <188cf8d30511180706s54ac6c31m5544005747e35ff6@mail.gmail.com>
Message-ID: <20051122173252.GB4585@illogics.org>

Hi Gerald, everyone,

Thank you very much for your hospitality, and I'd like to make it a 
point to return. We'll have to line up more presenters for next time
to maximize utility of the classroom and data projector.

I know there was some interest in Phoenix.PM in participating in such
a course -- I'd like to stay cc'd on this as it progresses but I'm still
just kicking the idea around.

Thanks,
-scott


On  0, Gerald Thurman <gthurman at gmail.com> wrote:
> I am happy SCC had an opportunity to have some Perl mongers visit CM-448.
> 
> As mentioned at the November meeting, I'd like to offer a "Survey of
> Script Programming Languages using PERL, PHP, Python" course during
> the Spring 2006 semester at SCC.
> 
> The following hyperlink is to a PPP class that I did a couple of years ago.
> The content of this website is stale and it needs to be redone, but it offers
> an example of what we want to offer.
> 
> http://deru.com/~gdt/ppp/
> 
> Thank You and I hope Perl mongers return to SCC someday.
> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://mail.pm.org/mailman/listinfo/phoenix-pm

From scott at illogics.org  Tue Nov 22 15:27:02 2005
From: scott at illogics.org (Scott Walters)
Date: Tue, 22 Nov 2005 23:27:02 +0000
Subject: [Phoenix-pm] 30% of ORA titles this Xmas: Was: A Special Holiday
	Offer from O'Reilly
Message-ID: <20051122232701.GI4585@illogics.org>

----- Forwarded message from kerry at oreilly.com -----

Return-Path: bounce-all_ora_-4695755 at newsletter.oreilly.com
X-Original-To: scott at slowass.net
Delivered-To: scott at slowass.net
Received: from newsletter.oreillynet.com (newsletter.oreillynet.com [209.204.146.25])
	by slowass.net (Postfix) with SMTP id 33D22553A5
	for <scott at slowass.net>; Tue, 22 Nov 2005 23:22:56 +0000 (GMT)
From: kerry at oreilly.com
To: scott at slowass.net
Subject: A Special Holiday Offer from O'Reilly
Date: Tue, 22 Nov 2005 15:02:49 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
List-Unsubscribe: <mailto:leave-all_ora_-4695755H at newsletter.oreilly.com>
Message-Id: <LYRIS-4695755-26650-2005.11.22-15.02.49--scott#slowass.net at newsletter.oreilly.com>

Dear Reader,

In the spirit of the season, we'd like to thank you for subscribing to
O'Reilly's Book and Product Announcements.  We'd also like to make it
easier for you to cozy up with that O'Reilly book you've been wanting to
read.  And books make great gifts, as well!

>From "Adobe Photoshop CS2 One on One," to "Head First Design Patterns,"
"Windows XP for Starters," "The Art of Project Management," and "Makers,"
we've got a title for just about anyone on your list.

>From now through December 31st, get 30% off any books you order from us
through http://www.oreilly.com/buy.

Just use Discount Code HOHOHO when you place your order.  (Due to commerce
laws, this offer only applies to books shipped to US addresses).

Happy Holidays, from everyone at O'Reilly!

You've received this announcement because you have subscribed to
O'Reilly's Book and Product Announcements.  To change your subscription
options, please visit: http://www.oreillynet.com/cs/nl/home.

O'Reilly Media, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
(707) 827-7000

----- End forwarded message -----

From friedman at highwire.stanford.edu  Tue Nov 22 22:13:19 2005
From: friedman at highwire.stanford.edu (Michael Friedman)
Date: Tue, 22 Nov 2005 22:13:19 -0800
Subject: [Phoenix-pm] 30% of ORA titles this Xmas: Was: A Special
	Holiday Offer from O'Reilly
In-Reply-To: <20051122232701.GI4585@illogics.org>
References: <20051122232701.GI4585@illogics.org>
Message-ID: <60308FAC-1054-48C0-8570-B6AD66CD54ED@highwire.stanford.edu>

Heh. I think this is the same discount that Amazon is giving people  
on the books these days.

If you're into buying from giant conglomerates, you know.

-- Mike

On Nov 22, 2005, at 3:27 PM, Scott Walters wrote:

> ----- Forwarded message from kerry at oreilly.com -----
>
> Return-Path: bounce-all_ora_-4695755 at newsletter.oreilly.com
> X-Original-To: scott at slowass.net
> Delivered-To: scott at slowass.net
> Received: from newsletter.oreillynet.com (newsletter.oreillynet.com  
> [209.204.146.25])
> 	by slowass.net (Postfix) with SMTP id 33D22553A5
> 	for <scott at slowass.net>; Tue, 22 Nov 2005 23:22:56 +0000 (GMT)
> From: kerry at oreilly.com
> To: scott at slowass.net
> Subject: A Special Holiday Offer from O'Reilly
> Date: Tue, 22 Nov 2005 15:02:49 -0800
> MIME-Version: 1.0
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> Content-Transfer-Encoding: 8bit
> List-Unsubscribe: <mailto:leave- 
> all_ora_-4695755H at newsletter.oreilly.com>
> Message-Id: <LYRIS-4695755-26650-2005.11.22-15.02.49-- 
> scott#slowass.net at newsletter.oreilly.com>
>
> Dear Reader,
>
> In the spirit of the season, we'd like to thank you for subscribing to
> O'Reilly's Book and Product Announcements.  We'd also like to make it
> easier for you to cozy up with that O'Reilly book you've been  
> wanting to
> read.  And books make great gifts, as well!
>
>> From "Adobe Photoshop CS2 One on One," to "Head First Design  
>> Patterns,"
> "Windows XP for Starters," "The Art of Project Management," and  
> "Makers,"
> we've got a title for just about anyone on your list.
>
>> From now through December 31st, get 30% off any books you order  
>> from us
> through http://www.oreilly.com/buy.
>
> Just use Discount Code HOHOHO when you place your order.  (Due to  
> commerce
> laws, this offer only applies to books shipped to US addresses).
>
> Happy Holidays, from everyone at O'Reilly!
>
> You've received this announcement because you have subscribed to
> O'Reilly's Book and Product Announcements.  To change your  
> subscription
> options, please visit: http://www.oreillynet.com/cs/nl/home.
>
> O'Reilly Media, Inc.
> 1005 Gravenstein Highway North
> Sebastopol, CA 95472
> (707) 827-7000
>
> ----- End forwarded message -----
> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://mail.pm.org/mailman/listinfo/phoenix-pm

---------------------------------------------------------------------
Michael Friedman                     HighWire Press
Phone: 650-725-1974                  Stanford University
FAX:   270-721-8034                  <friedman at highwire.stanford.edu>
---------------------------------------------------------------------



From friedman at highwire.stanford.edu  Tue Nov 22 22:24:49 2005
From: friedman at highwire.stanford.edu (Michael Friedman)
Date: Tue, 22 Nov 2005 22:24:49 -0800
Subject: [Phoenix-pm] inside out objects
Message-ID: <70ADA09B-26E1-4BFA-A57E-5BF6F018597C@highwire.stanford.edu>

So, I just read through _Perl Best Practices_ and it's fantastic.  
It's even well written. And I agree with almost all of Damian's  
recommendations for making more maintainable Perl code... all except  
inside out objects.

However, as I've already had one tranformative religious experience  
from this book (I've changed my braces style), I'm willing to give  
the guy a chance on this one. But I need some more evidence.

Has anyone used inside out objects before? I completely believe that  
they handle encapsulation much better, but what I don't buy is that  
they're actually easier to maintain and equivalently easy to  
understand as the "regular" hash-based objects are.

So, anyone have real world advice on using them?

-- Mike

PS - For those not in the know, inside out objects are identified by  
a unique scalar that acts as an index into a list of hashes, one hash  
for each attribute/field of the object. The values are held in the  
set of hashes in a closure, so absolutely no one but the class itself  
can access them. There is an example in the code block on http:// 
www.windley.com/archives/2005/08/best_practices.shtml, and other  
examples elsewhere that I can't seem to find at the moment. :-(

---------------------------------------------------------------------
Michael Friedman                     HighWire Press
Phone: 650-725-1974                  Stanford University
FAX:   270-721-8034                  <friedman at highwire.stanford.edu>
---------------------------------------------------------------------



From phx-pm-list at grueslayer.com  Wed Nov 23 06:05:40 2005
From: phx-pm-list at grueslayer.com (David A. Sinck)
Date: Wed, 23 Nov 2005 07:05:40 -0700
Subject: [Phoenix-pm]  inside out objects
References: <70ADA09B-26E1-4BFA-A57E-5BF6F018597C@highwire.stanford.edu>
Message-ID: <17284.30516.343052.410444@magnitude.grueslayer.com>



\_ SMTP quoth Michael Friedman on 11/22/2005 22:24 as having spake thusly:
\_
\_ http://www.windley.com/archives/2005/08/best_practices.shtml, and other  

I can't speak for the book, but I can speak for Windley.  Well, speak
well of him, given I took two of the best ever CS classes at UCDavis
from him.  If Phil likes it, it's nearly got to be good.  :-)

I mean, who else dared instruct on string manipulation (concatenation,
substring, left, ...) with his kid's alpha-blocks?  Or demonstrating
the Towers of Hanoi with that colored-disc-stack/rocker thing?  Or
sorting with a handful of broken spaghetti?  He also had a great sense
of humor (or perhaps tolerance ;-) for smartasses in class:

* sinck comes in late to ecs40h
<windley> The fibonacci series is 1 1 2 3 5 8 13 ...
<windley> Who can name another never ending series?
<sinck> "The Cosby Show" ?
<windley> heh
<windley> I was thinking of a numeric series....

:-)

David

From scott at illogics.org  Wed Nov 23 09:06:35 2005
From: scott at illogics.org (Scott Walters)
Date: Wed, 23 Nov 2005 17:06:35 +0000
Subject: [Phoenix-pm] inside out objects
In-Reply-To: <70ADA09B-26E1-4BFA-A57E-5BF6F018597C@highwire.stanford.edu>
References: <70ADA09B-26E1-4BFA-A57E-5BF6F018597C@highwire.stanford.edu>
Message-ID: <20051123170635.GJ4585@illogics.org>

Hi Michael,

I thought it was a cute trick, but I'm surprised it's recommended.
What I do depends on the situation -- the client, the style of the code 
I'm adding to, etc. 

When I don't necessarily care about encapsulation, I use an excellent
package by Juerd called Attribute::Property:

       package Person;
       use Attribute::Property;

       sub new  : New;
       sub name : Property;
       sub age  : Property { /^\d+\z/ and $_ > 0 }

       sub print_stats {
           my $self = shift;
           print "name: ", $self->name, "\n";
           print "age: ", $self->age, "\n";
       }

       sub get_older {
           my $self = shift;
           $self->age++;
       }

       package main;

       my $person = Person->new(name => 'Fred', age => 23);
       $person->get_older;
       $person->name = "Fred Worth";
       $person->print_stats;

A::P creates new methods for you that initialize instance variables from
arguments (just like in Perl 6 -- hence _Perl 6 Now_ including discussion
of it), and it also creates lvalue accessors for the instance data 
when you use the :Property attribute of subroutines. It's a lot less
code to write and the code looks a lot better.

For stuff I use internally, when I want some ecapsulation and not to have to
shift $this, I often use a little package called hashclosure.pm. hashclosure
basically tells Perl that the object's methods are code references inside 
of the hash. The hash contains methods and code references rather than
instance data. Instance data is "my" variables lexically closed over by the 
methods.

  package hashclosure;
  
  sub import {
      my $caller = caller;
      *{$caller.'::AUTOLOAD'} = sub {
          my $method = $AUTOLOAD; $method =~ s/.*:://;
          return if $method eq 'DESTROY';
          my $this = shift;
          local *{$caller.'::this'} = $this;
          if(! exists $this->{$method}) {
              my $super = "SUPER::$method";
              return $this->$super(@_);
          }
          $this->{$method}->(@_);
      }; 
  }
        
  1;

This is the AUTOLOAD glue needed to so that objects created as 
follows work:

  package Person;
  use hashclosure;

  our $this;

  sub new {
      my $class = shift;
      my $name;
      my $age;
      bless { 
          name => sub { $name },
          set_name => sub { $name = shift },
          age  => sub { $age },
          set_age => sub { $age = shift },
          print_stats => sub {
              my $self = shift;
              print "name: ", $self->name, "\n";
              print "age: ", $self->age, "\n"; 
          },  
          get_older => sub {
              my $self = shift;
              $self->age++;
          },
      }, $class;
  } 

Since the "instance data" is lexically closed over by the methods and
scoped to the new { } block, encapsulation is pretty good (PadWalker
and such can still get to it, but XS can do anything). 

Best of all, you don't have to write that annoying $self->{foo} crap --
just $foo will do. That's an improvement even over $self->foo as in A::P.

The AUTOLOAD logic shifts $this for us and sticks it and puts it into
the $this defined by 'out $this'.

Downsides are lack of lvalue accessors (so you can't do $person->name = "Fred")
and the ugly initialization syntax. 

This might be workable with lvalue, but I'd have to do a much larger 
and messier AUTOLOAD to make it happen and my first attempt didn't
pan out.

At the last meeting, I got out my Object::Lexical on the projector and
shoved that in people's faces. It also makes instance data into 
lexicals, but the implementation is completely different (it creates
a new stash for each object created, stuffs closures into it, and
blesses it -- it's probably the strangest thing I've ever done in Perl).
Here's what code using it looks like:

  use Object::Lexical;
  use Sub::Lexical;

  sub new {

    our $this;
    my $name;
    my $age;

    my sub age { $age };
    my sub name { $name };

    sub print_stats {
        print "name: ", $name, "\n";
        print "age: ", $age, "\n";
    }
     
    sub get_older {
        $age++;
    }

    instance();

  } 

It just doesn't get any more clear or concise than that for creating
objects in Perl. instance() serves the same purpose as bless(),
but it does the actual stash-blessing and closure-generating. 
To get this pretty syntax, you need a source filter -- that's what
Sub::Lexical does. For some other idioms that don't use a source
filter, see http://search.cpan.org/~swalters/Object-Lexical-0.02/Lexical.pm.
This module is a bit buggy, by the way, but if anyone actually
has any interest in it, I'll fix the thing.

Regards,
-scott

On  0, Michael Friedman <friedman at highwire.stanford.edu> wrote:
> So, I just read through _Perl Best Practices_ and it's fantastic.  
> It's even well written. And I agree with almost all of Damian's  
> recommendations for making more maintainable Perl code... all except  
> inside out objects.
> 
> However, as I've already had one tranformative religious experience  
> from this book (I've changed my braces style), I'm willing to give  
> the guy a chance on this one. But I need some more evidence.
> 
> Has anyone used inside out objects before? I completely believe that  
> they handle encapsulation much better, but what I don't buy is that  
> they're actually easier to maintain and equivalently easy to  
> understand as the "regular" hash-based objects are.
> 
> So, anyone have real world advice on using them?
> 
> -- Mike
> 
> PS - For those not in the know, inside out objects are identified by  
> a unique scalar that acts as an index into a list of hashes, one hash  
> for each attribute/field of the object. The values are held in the  
> set of hashes in a closure, so absolutely no one but the class itself  
> can access them. There is an example in the code block on http:// 
> www.windley.com/archives/2005/08/best_practices.shtml, and other  
> examples elsewhere that I can't seem to find at the moment. :-(
> 
> ---------------------------------------------------------------------
> Michael Friedman                     HighWire Press
> Phone: 650-725-1974                  Stanford University
> FAX:   270-721-8034                  <friedman at highwire.stanford.edu>
> ---------------------------------------------------------------------
> 
> 
> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://mail.pm.org/mailman/listinfo/phoenix-pm

From awwaiid at thelackthereof.org  Wed Nov 23 09:16:38 2005
From: awwaiid at thelackthereof.org (Brock)
Date: Wed, 23 Nov 2005 10:16:38 -0700
Subject: [Phoenix-pm] inside out objects
In-Reply-To: <20051123170635.GJ4585@illogics.org>
References: <70ADA09B-26E1-4BFA-A57E-5BF6F018597C@highwire.stanford.edu>
	<20051123170635.GJ4585@illogics.org>
Message-ID: <20051123171638.GD25661@thelackthereof.org>

On 2005.11.23.17.06, Scott Walters wrote:
|...
| This is the AUTOLOAD glue needed to so that objects created as 
| follows work:
| 
|   package Person;
|   use hashclosure;
| 
|   our $this;
| 
|   sub new {
|       my $class = shift;
|       my $name;
|       my $age;
|       bless { 
|           name => sub { $name },
|           set_name => sub { $name = shift },
|           age  => sub { $age },
|           set_age => sub { $age = shift },
|           print_stats => sub {
|               my $self = shift;
|               print "name: ", $self->name, "\n";
|               print "age: ", $self->age, "\n"; 
|           },  
|           get_older => sub {
|               my $self = shift;
|               $self->age++;
|           },
|       }, $class;
|   } 
| 
|...

Should that print_stats sub be

  print_stats => sub {
    print "name: $name\n";
    print "age: $age\n";
    $this->other_method_invocation();
  }

without the need to get $self? Also with that example self-method
invocation?

--Brock


From scott at illogics.org  Wed Nov 23 09:31:40 2005
From: scott at illogics.org (Scott Walters)
Date: Wed, 23 Nov 2005 17:31:40 +0000
Subject: [Phoenix-pm] inside out objects
In-Reply-To: <20051123171638.GD25661@thelackthereof.org>
References: <70ADA09B-26E1-4BFA-A57E-5BF6F018597C@highwire.stanford.edu>
	<20051123170635.GJ4585@illogics.org>
	<20051123171638.GD25661@thelackthereof.org>
Message-ID: <20051123173140.GL4585@illogics.org>

Yes, thanks for the fix... I was copying and modifying code and not
testing it. Oops.

-scott

On  0, Brock <awwaiid at thelackthereof.org> wrote:
> On 2005.11.23.17.06, Scott Walters wrote:
> |...
> | This is the AUTOLOAD glue needed to so that objects created as 
> | follows work:
> | 
> |   package Person;
> |   use hashclosure;
> | 
> |   our $this;
> | 
> |   sub new {
> |       my $class = shift;
> |       my $name;
> |       my $age;
> |       bless { 
> |           name => sub { $name },
> |           set_name => sub { $name = shift },
> |           age  => sub { $age },
> |           set_age => sub { $age = shift },
> |           print_stats => sub {
> |               my $self = shift;
> |               print "name: ", $self->name, "\n";
> |               print "age: ", $self->age, "\n"; 
> |           },  
> |           get_older => sub {
> |               my $self = shift;
> |               $self->age++;
> |           },
> |       }, $class;
> |   } 
> | 
> |...
> 
> Should that print_stats sub be
> 
>   print_stats => sub {
>     print "name: $name\n";
>     print "age: $age\n";
>     $this->other_method_invocation();
>   }
> 
> without the need to get $self? Also with that example self-method
> invocation?
> 
> --Brock
> 
> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://mail.pm.org/mailman/listinfo/phoenix-pm

From friedman at highwire.stanford.edu  Mon Nov 28 08:50:31 2005
From: friedman at highwire.stanford.edu (Michael Friedman)
Date: Mon, 28 Nov 2005 08:50:31 -0800
Subject: [Phoenix-pm] inside out objects
In-Reply-To: <20051123170635.GJ4585@illogics.org>
References: <70ADA09B-26E1-4BFA-A57E-5BF6F018597C@highwire.stanford.edu>
	<20051123170635.GJ4585@illogics.org>
Message-ID: <E89BFDA1-706F-426A-A0F3-FE1177473069@highwire.stanford.edu>

Scott,

Thanks! I'm curious, though, about the memory footprint that using  
hashclosure would have. Since each method becomes a closure, I assume  
that means that each method would end up being instantiated in a  
brand new space in memory for each new object you create. Thus, if  
you had 10 objects, you'd have 10 different copies of each method as  
well as 10 copies of the field values. In either the single-hash- 
based object or the inside-out object, the methods are shared between  
all instances of the class, so they only have to go into memory once.

So if you were using 100s of objects, that memory could be  
problematic. :-)

Still, it's a cool way to avoid having to use object syntax within  
the object itself.

The link I included originally is to a new module, Class::Std, which  
is supposed to make using inside out objects much easier. I hope to  
try it out later this week, so I'll let everyone know how it goes.

-- Mike


On Nov 23, 2005, at 9:06 AM, Scott Walters wrote:

> Hi Michael,
>
> I thought it was a cute trick, but I'm surprised it's recommended.
> What I do depends on the situation -- the client, the style of the  
> code
> I'm adding to, etc.
>
> When I don't necessarily care about encapsulation, I use an excellent
> package by Juerd called Attribute::Property:
>
>        package Person;
>        use Attribute::Property;
>
>        sub new  : New;
>        sub name : Property;
>        sub age  : Property { /^\d+\z/ and $_ > 0 }
>
>        sub print_stats {
>            my $self = shift;
>            print "name: ", $self->name, "\n";
>            print "age: ", $self->age, "\n";
>        }
>
>        sub get_older {
>            my $self = shift;
>            $self->age++;
>        }
>
>        package main;
>
>        my $person = Person->new(name => 'Fred', age => 23);
>        $person->get_older;
>        $person->name = "Fred Worth";
>        $person->print_stats;
>
> A::P creates new methods for you that initialize instance variables  
> from
> arguments (just like in Perl 6 -- hence _Perl 6 Now_ including  
> discussion
> of it), and it also creates lvalue accessors for the instance data
> when you use the :Property attribute of subroutines. It's a lot less
> code to write and the code looks a lot better.
>
> For stuff I use internally, when I want some ecapsulation and not  
> to have to
> shift $this, I often use a little package called hashclosure.pm.  
> hashclosure
> basically tells Perl that the object's methods are code references  
> inside
> of the hash. The hash contains methods and code references rather than
> instance data. Instance data is "my" variables lexically closed  
> over by the
> methods.
>
>   package hashclosure;
>
>   sub import {
>       my $caller = caller;
>       *{$caller.'::AUTOLOAD'} = sub {
>           my $method = $AUTOLOAD; $method =~ s/.*:://;
>           return if $method eq 'DESTROY';
>           my $this = shift;
>           local *{$caller.'::this'} = $this;
>           if(! exists $this->{$method}) {
>               my $super = "SUPER::$method";
>               return $this->$super(@_);
>           }
>           $this->{$method}->(@_);
>       };
>   }
>
>   1;
>
> This is the AUTOLOAD glue needed to so that objects created as
> follows work:
>
>   package Person;
>   use hashclosure;
>
>   our $this;
>
>   sub new {
>       my $class = shift;
>       my $name;
>       my $age;
>       bless {
>           name => sub { $name },
>           set_name => sub { $name = shift },
>           age  => sub { $age },
>           set_age => sub { $age = shift },
>           print_stats => sub {
>               my $self = shift;
>               print "name: ", $self->name, "\n";
>               print "age: ", $self->age, "\n";
>           },
>           get_older => sub {
>               my $self = shift;
>               $self->age++;
>           },
>       }, $class;
>   }
>
> Since the "instance data" is lexically closed over by the methods and
> scoped to the new { } block, encapsulation is pretty good (PadWalker
> and such can still get to it, but XS can do anything).
>
> Best of all, you don't have to write that annoying $self->{foo}  
> crap --
> just $foo will do. That's an improvement even over $self->foo as in  
> A::P.
>
> The AUTOLOAD logic shifts $this for us and sticks it and puts it into
> the $this defined by 'out $this'.
>
> Downsides are lack of lvalue accessors (so you can't do $person- 
> >name = "Fred")
> and the ugly initialization syntax.
>
> This might be workable with lvalue, but I'd have to do a much larger
> and messier AUTOLOAD to make it happen and my first attempt didn't
> pan out.
>
> At the last meeting, I got out my Object::Lexical on the projector and
> shoved that in people's faces. It also makes instance data into
> lexicals, but the implementation is completely different (it creates
> a new stash for each object created, stuffs closures into it, and
> blesses it -- it's probably the strangest thing I've ever done in  
> Perl).
> Here's what code using it looks like:
>
>   use Object::Lexical;
>   use Sub::Lexical;
>
>   sub new {
>
>     our $this;
>     my $name;
>     my $age;
>
>     my sub age { $age };
>     my sub name { $name };
>
>     sub print_stats {
>         print "name: ", $name, "\n";
>         print "age: ", $age, "\n";
>     }
>
>     sub get_older {
>         $age++;
>     }
>
>     instance();
>
>   }
>
> It just doesn't get any more clear or concise than that for creating
> objects in Perl. instance() serves the same purpose as bless(),
> but it does the actual stash-blessing and closure-generating.
> To get this pretty syntax, you need a source filter -- that's what
> Sub::Lexical does. For some other idioms that don't use a source
> filter, see http://search.cpan.org/~swalters/Object-Lexical-0.02/ 
> Lexical.pm.
> This module is a bit buggy, by the way, but if anyone actually
> has any interest in it, I'll fix the thing.
>
> Regards,
> -scott
>
> On  0, Michael Friedman <friedman at highwire.stanford.edu> wrote:
>> So, I just read through _Perl Best Practices_ and it's fantastic.
>> It's even well written. And I agree with almost all of Damian's
>> recommendations for making more maintainable Perl code... all except
>> inside out objects.
>>
>> However, as I've already had one tranformative religious experience
>> from this book (I've changed my braces style), I'm willing to give
>> the guy a chance on this one. But I need some more evidence.
>>
>> Has anyone used inside out objects before? I completely believe that
>> they handle encapsulation much better, but what I don't buy is that
>> they're actually easier to maintain and equivalently easy to
>> understand as the "regular" hash-based objects are.
>>
>> So, anyone have real world advice on using them?
>>
>> -- Mike
>>
>> PS - For those not in the know, inside out objects are identified by
>> a unique scalar that acts as an index into a list of hashes, one hash
>> for each attribute/field of the object. The values are held in the
>> set of hashes in a closure, so absolutely no one but the class itself
>> can access them. There is an example in the code block on http://
>> www.windley.com/archives/2005/08/best_practices.shtml, and other
>> examples elsewhere that I can't seem to find at the moment. :-(
>>
>> ---------------------------------------------------------------------
>> Michael Friedman                     HighWire Press
>> Phone: 650-725-1974                  Stanford University
>> FAX:   270-721-8034                  <friedman at highwire.stanford.edu>
>> ---------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> Phoenix-pm mailing list
>> Phoenix-pm at pm.org
>> http://mail.pm.org/mailman/listinfo/phoenix-pm

---------------------------------------------------------------------
Michael Friedman                     HighWire Press
Phone: 650-725-1974                  Stanford University
FAX:   270-721-8034                  <friedman at highwire.stanford.edu>
---------------------------------------------------------------------



From scott at illogics.org  Mon Nov 28 11:45:17 2005
From: scott at illogics.org (Scott Walters)
Date: Mon, 28 Nov 2005 19:45:17 +0000
Subject: [Phoenix-pm] inside out objects
In-Reply-To: <E89BFDA1-706F-426A-A0F3-FE1177473069@highwire.stanford.edu>
References: <70ADA09B-26E1-4BFA-A57E-5BF6F018597C@highwire.stanford.edu>
	<20051123170635.GJ4585@illogics.org>
	<E89BFDA1-706F-426A-A0F3-FE1177473069@highwire.stanford.edu>
Message-ID: <20051128194517.GA1621@illogics.org>

Hi Michael,

Sorry for the slow reply. slowass.net was down for a while. Short
story long -- Google somewhere found links to //reverse.cgi and
//diff.cgi on http://perldesignpatterns.com. /reverse.cgi and /diff.cgi
are CPU-intensive, and the server is slow, so they're listed in
/robots.txt. But //reverse.cgi and /reverse.cgi are not the same
thing. So GoogleBot merrily beat the snot out of the server. This
wouldn't normally be a problem but I had just changed thttpd's
bandwidth allocation to be much higher, and I thought I changed
the CGI cost to match, but I made a math error (who said programmers
don't mean math? How many K*bytes* perseconds is a T1 again? Duh?).
So all of the hundreds of running CGIs runs the machine out of
memory and kills everything else, including inetd and sshd. 
Eventually pings stop coming back too. So, now my thttpd has been 
modded to watch the machine load average, and it's running with 
ulimits. So, I was without email for the entire holiday weekend.
Teh suck. 

Oh -- anoghter lesson for you all -- if your server ever crashes
while CVS has a lock out, and attempts to access the repository 
fail because of a lock, rm -rf .#* in the repisitory directory --
including the .#lock _directory_. Yes, the directory is a lockfile.
I had to rtfs for that bone.

Okay, as to your actual question...

Closures don't exactly copy methods. Hrm, this calls for some stats.
Creating 1000 subs using eval verus closures:

eval:     1088k on startup.... 3664k after execution. delta: 2576k
closures: 1100k on startup.... 1924k after execution. delta: 1814k

The code is below. This isn't a very good example -- normally
methods would have much more data in them, and eval would lose
spectacularly rather than badly.

Creating a closure certainly costs some memory... here, that's 
about 2.5K each. That includes, in this case:

* AV structure (arrayvalue -- just one to hold the pad for the 
  lexicals that each closure binds to)
* CV structure (codevalue -- one for each closure)
* GV structure (globvalue created when the closure is stored
  in the symbol table with *name = sub { ... } -- one for each)
* AV structure (padlist -- one for each)
* AV structure (pad -- one for each)
* SV/RV structure (scalar reference -- one for each variable
  closed by each closure)

If this were actually used to construct and object, you'd also
get:

* PVMG (blessed object)
* hash keys (shared string table)
* SV/RVs for hash values to references to the CV closures 

Off the top of my head, that accounts for close to 2k right there. 
I'm sure I'm forgetting a few things. (See perlguts illustrated
for more information on these datastructures.) This is pretty
low-fat, but ideally, the two AVs would be created per-object
rather than per-method in this arrangement. That would save
most of the overhead. 

Anyway, it isn't the "methods" that are being copied -- it's the
lexical environment that's constructed, for the most part, that
you're paying for. The actual bytecode is shared. The anonymous
syntax of sub { } returns a new reference, but that reference
has its own reference to the bytecode in question, though it has
different references to the padlist and such.

Padlists need some explanation here... each CV might be called 
recursively, so it doesn't just need a pad to hold lexical
variables (of its own and inherited, both) -- it needs a stack
of these, so if it happens to call itself, directly or indirectly,
the new invocation has its own private "scratchpad" for lexical
variables. So each code reference, no matter how generated,
has a its own stack, built-in. Worse, Perl doesn't free 
stack frames after the code has returned -- it's assumed that
if a method recurses to one depth once, it probably will again,
so it's best to keep the memory cached. In some situations, this
results in pathological memory usage. The Towers of Hanoi in
Perl is ugly, memory-usage wise.

Numbers are: after bytecode is compiled; after one object is created; after
1,000 objects are created; the delta from first and last numbers:

1216... 1228... 4156... 2940  the Person hashclosure example from below
1112... 1152... 1324...  212   normal object idiom (modified Person.pm example)

Here's that again with 100,000 objects created:

1112... 1152... 18100k
1216... 1228... 286m

Okay, that's a brutal beating. The normal one ran instantly; the second
one ground the harddrive for close to a minute (this system has 128
megs of RAM). The number just kept climbing and climbing...

But there are a few bad things about this example because the methods are so short:

1. The traditional style pays a tax every time a hash is indexed --
   the padhv instruction must reference an entry in the shared string
   table to get at the hash key, and it must reference the pad entry
   that represents the hash. That's two 32 bit quantities. This happens 
   every time you write $self->{whatever}. The closure version only
   does a padsv operation with one 32 bit index into the pad.
2. The pad/padlist overhead the closure version pays is constant,
   so it's more noticable with lots of instances of small methods.
   2.5k each overhead is a lot to pay for a small method but little
   for a large method. The small methods in this example make it seem
   really obnoxious, which it may well be... but the example doesn't
   help ;)

Conclusion: hashclosure is *fine* for programs with few object instances
and small programs =P 100's of objects is no made problem, but 1000's is.

I've been toying with the idea of making another little B hack.
This time, I want to make something like this work:

package Person;

use ourmeansinstance;  # this hypothetical module has not yet been rated.. er, named

our $this;   # our means instance now!
our $name;
our $age;
our @scars;

sub new {
    bless { }, $this;
}

sub name :lvalue { $name}
sub age :lvalue { $age }
sub get_older { $age++ }
sub new_scar { my $scar = shift; push @scars, $scar; }

This module would have to find the starts of all function/method definitions,
insert a few opcodes to shift @_ into $this, and then insert opcodes to
alias each instance variable ("our" variable) to $self->{whatever}. Eg,
$whatever would be aliased to $self->{whatever}. This would be done using
Data::Alias. Likewise, @scars could be aliased to $self->{scars}, and 
Data::Alias does the right thing.

Disadvantages: longer start-up times for programmers; more overhead for
method alls, especially in objects that have lots of instance fields.
I still haven't fixed B::Generate to build cleanly. 

-scott

On  0, Michael Friedman <friedman at highwire.stanford.edu> wrote:
> Scott,
> 
> Thanks! I'm curious, though, about the memory footprint that using  
> hashclosure would have. Since each method becomes a closure, I assume  
> that means that each method would end up being instantiated in a  
> brand new space in memory for each new object you create. Thus, if  
> you had 10 objects, you'd have 10 different copies of each method as  
> well as 10 copies of the field values. In either the single-hash- 
> based object or the inside-out object, the methods are shared between  
> all instances of the class, so they only have to go into memory once.
> 
> So if you were using 100s of objects, that memory could be  
> problematic. :-)
> 
> Still, it's a cool way to avoid having to use object syntax within  
> the object itself.
> 
> The link I included originally is to a new module, Class::Std, which  
> is supposed to make using inside out objects much easier. I hope to  
> try it out later this week, so I'll let everyone know how it goes.
> 
> -- Mike
> 
> 
> On Nov 23, 2005, at 9:06 AM, Scott Walters wrote:
> 
> > Hi Michael,
> >
> > I thought it was a cute trick, but I'm surprised it's recommended.
> > What I do depends on the situation -- the client, the style of the  
> > code
> > I'm adding to, etc.
> >
> > When I don't necessarily care about encapsulation, I use an excellent
> > package by Juerd called Attribute::Property:
> >
> >        package Person;
> >        use Attribute::Property;
> >
> >        sub new  : New;
> >        sub name : Property;
> >        sub age  : Property { /^\d+\z/ and $_ > 0 }
> >
> >        sub print_stats {
> >            my $self = shift;
> >            print "name: ", $self->name, "\n";
> >            print "age: ", $self->age, "\n";
> >        }
> >
> >        sub get_older {
> >            my $self = shift;
> >            $self->age++;
> >        }
> >
> >        package main;
> >
> >        my $person = Person->new(name => 'Fred', age => 23);
> >        $person->get_older;
> >        $person->name = "Fred Worth";
> >        $person->print_stats;
> >
> > A::P creates new methods for you that initialize instance variables  
> > from
> > arguments (just like in Perl 6 -- hence _Perl 6 Now_ including  
> > discussion
> > of it), and it also creates lvalue accessors for the instance data
> > when you use the :Property attribute of subroutines. It's a lot less
> > code to write and the code looks a lot better.
> >
> > For stuff I use internally, when I want some ecapsulation and not  
> > to have to
> > shift $this, I often use a little package called hashclosure.pm.  
> > hashclosure
> > basically tells Perl that the object's methods are code references  
> > inside
> > of the hash. The hash contains methods and code references rather than
> > instance data. Instance data is "my" variables lexically closed  
> > over by the
> > methods.
> >
> >   package hashclosure;
> >
> >   sub import {
> >       my $caller = caller;
> >       *{$caller.'::AUTOLOAD'} = sub {
> >           my $method = $AUTOLOAD; $method =~ s/.*:://;
> >           return if $method eq 'DESTROY';
> >           my $this = shift;
> >           local *{$caller.'::this'} = $this;
> >           if(! exists $this->{$method}) {
> >               my $super = "SUPER::$method";
> >               return $this->$super(@_);
> >           }
> >           $this->{$method}->(@_);
> >       };
> >   }
> >
> >   1;
> >
> > This is the AUTOLOAD glue needed to so that objects created as
> > follows work:
> >
> >   package Person;
> >   use hashclosure;
> >
> >   our $this;
> >
> >   sub new {
> >       my $class = shift;
> >       my $name;
> >       my $age;
> >       bless {
> >           name => sub { $name },
> >           set_name => sub { $name = shift },
> >           age  => sub { $age },
> >           set_age => sub { $age = shift },
> >           print_stats => sub {
> >               my $self = shift;
> >               print "name: ", $self->name, "\n";
> >               print "age: ", $self->age, "\n";
> >           },
> >           get_older => sub {
> >               my $self = shift;
> >               $self->age++;
> >           },
> >       }, $class;
> >   }
> >
> > Since the "instance data" is lexically closed over by the methods and
> > scoped to the new { } block, encapsulation is pretty good (PadWalker
> > and such can still get to it, but XS can do anything).
> >
> > Best of all, you don't have to write that annoying $self->{foo}  
> > crap --
> > just $foo will do. That's an improvement even over $self->foo as in  
> > A::P.
> >
> > The AUTOLOAD logic shifts $this for us and sticks it and puts it into
> > the $this defined by 'out $this'.
> >
> > Downsides are lack of lvalue accessors (so you can't do $person- 
> > >name = "Fred")
> > and the ugly initialization syntax.
> >
> > This might be workable with lvalue, but I'd have to do a much larger
> > and messier AUTOLOAD to make it happen and my first attempt didn't
> > pan out.
> >
> > At the last meeting, I got out my Object::Lexical on the projector and
> > shoved that in people's faces. It also makes instance data into
> > lexicals, but the implementation is completely different (it creates
> > a new stash for each object created, stuffs closures into it, and
> > blesses it -- it's probably the strangest thing I've ever done in  
> > Perl).
> > Here's what code using it looks like:
> >
> >   use Object::Lexical;
> >   use Sub::Lexical;
> >
> >   sub new {
> >
> >     our $this;
> >     my $name;
> >     my $age;
> >
> >     my sub age { $age };
> >     my sub name { $name };
> >
> >     sub print_stats {
> >         print "name: ", $name, "\n";
> >         print "age: ", $age, "\n";
> >     }
> >
> >     sub get_older {
> >         $age++;
> >     }
> >
> >     instance();
> >
> >   }
> >
> > It just doesn't get any more clear or concise than that for creating
> > objects in Perl. instance() serves the same purpose as bless(),
> > but it does the actual stash-blessing and closure-generating.
> > To get this pretty syntax, you need a source filter -- that's what
> > Sub::Lexical does. For some other idioms that don't use a source
> > filter, see http://search.cpan.org/~swalters/Object-Lexical-0.02/ 
> > Lexical.pm.
> > This module is a bit buggy, by the way, but if anyone actually
> > has any interest in it, I'll fix the thing.
> >
> > Regards,
> > -scott
> >
> > On  0, Michael Friedman <friedman at highwire.stanford.edu> wrote:
> >> So, I just read through _Perl Best Practices_ and it's fantastic.
> >> It's even well written. And I agree with almost all of Damian's
> >> recommendations for making more maintainable Perl code... all except
> >> inside out objects.
> >>
> >> However, as I've already had one tranformative religious experience
> >> from this book (I've changed my braces style), I'm willing to give
> >> the guy a chance on this one. But I need some more evidence.
> >>
> >> Has anyone used inside out objects before? I completely believe that
> >> they handle encapsulation much better, but what I don't buy is that
> >> they're actually easier to maintain and equivalently easy to
> >> understand as the "regular" hash-based objects are.
> >>
> >> So, anyone have real world advice on using them?
> >>
> >> -- Mike
> >>
> >> PS - For those not in the know, inside out objects are identified by
> >> a unique scalar that acts as an index into a list of hashes, one hash
> >> for each attribute/field of the object. The values are held in the
> >> set of hashes in a closure, so absolutely no one but the class itself
> >> can access them. There is an example in the code block on http://
> >> www.windley.com/archives/2005/08/best_practices.shtml, and other
> >> examples elsewhere that I can't seem to find at the moment. :-(
> >>
> >> ---------------------------------------------------------------------
> >> Michael Friedman                     HighWire Press
> >> Phone: 650-725-1974                  Stanford University
> >> FAX:   270-721-8034                  <friedman at highwire.stanford.edu>
> >> ---------------------------------------------------------------------
> >>
> >>
> >> _______________________________________________
> >> Phoenix-pm mailing list
> >> Phoenix-pm at pm.org
> >> http://mail.pm.org/mailman/listinfo/phoenix-pm
> 
> ---------------------------------------------------------------------
> Michael Friedman                     HighWire Press
> Phone: 650-725-1974                  Stanford University
> FAX:   270-721-8034                  <friedman at highwire.stanford.edu>
> ---------------------------------------------------------------------
> 
> 
> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://mail.pm.org/mailman/listinfo/phoenix-pm

From scott at illogics.org  Mon Nov 28 11:54:28 2005
From: scott at illogics.org (Scott Walters)
Date: Mon, 28 Nov 2005 19:54:28 +0000
Subject: [Phoenix-pm] inside out objects
In-Reply-To: <E89BFDA1-706F-426A-A0F3-FE1177473069@highwire.stanford.edu>
References: <70ADA09B-26E1-4BFA-A57E-5BF6F018597C@highwire.stanford.edu>
	<20051123170635.GJ4585@illogics.org>
	<E89BFDA1-706F-426A-A0F3-FE1177473069@highwire.stanford.edu>
Message-ID: <20051128195428.GD1621@illogics.org>

Ooops, forgot the code...

sleep 10;

for my $i (0..1000) {
    # eval qq{
    #     sub foo$i {
    #         my \$x = shift; \$x *= \$i; print "\$i \$x\n";
    #     }
    *{"foo$i"} = sub {
        my $x = shift; $x *= $i; print "\$i \$x\n";
    };
}

sleep 60;

That's the simple eval vs. closure test.

  package hashclosure;

  sub import {
      my $caller = caller;
      *{$caller.'::AUTOLOAD'} = sub {
          my $method = $AUTOLOAD; $method =~ s/.*:://;
          return if $method eq 'DESTROY';
          my $this = shift;
          local *{$caller.'::this'} = $this;
          if(! exists $this->{$method}) {
              my $super = "SUPER::$method";
              return $this->$super(@_);
          }
          $this->{$method}->(@_);
      };
  }
  1;

  package Person;
  use hashclosure;

  our $this;

  sub new {
      my $class = shift;
      my $name;
      my $age;
      bless {
          name => sub { $name },
          set_name => sub { $name = shift },
          age  => sub { $age },
          set_age => sub { $age = shift },
          print_stats => sub {
              print "name: ", $name, "\n";
              print "age: ", $age, "\n";
          },
          get_older => sub {
              $age++;
          },
      }, $class;
  }

sleep 5;

my $person = Person->new;

sleep 5;

my @people;
push @people, Person->new for 1..100000;

sleep 60;


... finally, the normal version...

  package Person;

  sub new {
      my $class = shift;
      bless { name => undef, age => undef }, $class;
  }

sub name { my $self = shift; $self->{name} }
sub set_name { my $self = shift; $self->{name} = shift }
sub age { my $self = shift; $self->{age} }
sub set_age { my $self = shift; $self->{age} = shift }
sub print_stats {
              my $self = shift;
              print "name: ", $self->{name}, "\n";
              print "age: ", $self->{age}, "\n";
          }
sub get_older {
              my $self = shift;
              $self->{age}++;
}

sleep 5;

my $person = Person->new;

sleep 5;

my @people;
push @people, Person->new for 1..100000;

sleep 10;



On  0, Michael Friedman <friedman at highwire.stanford.edu> wrote:
> Scott,
> 
> Thanks! I'm curious, though, about the memory footprint that using  
> hashclosure would have. Since each method becomes a closure, I assume  
> that means that each method would end up being instantiated in a  
> brand new space in memory for each new object you create. Thus, if  
> you had 10 objects, you'd have 10 different copies of each method as  
> well as 10 copies of the field values. In either the single-hash- 
> based object or the inside-out object, the methods are shared between  
> all instances of the class, so they only have to go into memory once.
> 
> So if you were using 100s of objects, that memory could be  
> problematic. :-)
> 
> Still, it's a cool way to avoid having to use object syntax within  
> the object itself.
> 
> The link I included originally is to a new module, Class::Std, which  
> is supposed to make using inside out objects much easier. I hope to  
> try it out later this week, so I'll let everyone know how it goes.
> 
> -- Mike
> 
> 
> On Nov 23, 2005, at 9:06 AM, Scott Walters wrote:
> 
> > Hi Michael,
> >
> > I thought it was a cute trick, but I'm surprised it's recommended.
> > What I do depends on the situation -- the client, the style of the  
> > code
> > I'm adding to, etc.
> >
> > When I don't necessarily care about encapsulation, I use an excellent
> > package by Juerd called Attribute::Property:
> >
> >        package Person;
> >        use Attribute::Property;
> >
> >        sub new  : New;
> >        sub name : Property;
> >        sub age  : Property { /^\d+\z/ and $_ > 0 }
> >
> >        sub print_stats {
> >            my $self = shift;
> >            print "name: ", $self->name, "\n";
> >            print "age: ", $self->age, "\n";
> >        }
> >
> >        sub get_older {
> >            my $self = shift;
> >            $self->age++;
> >        }
> >
> >        package main;
> >
> >        my $person = Person->new(name => 'Fred', age => 23);
> >        $person->get_older;
> >        $person->name = "Fred Worth";
> >        $person->print_stats;
> >
> > A::P creates new methods for you that initialize instance variables  
> > from
> > arguments (just like in Perl 6 -- hence _Perl 6 Now_ including  
> > discussion
> > of it), and it also creates lvalue accessors for the instance data
> > when you use the :Property attribute of subroutines. It's a lot less
> > code to write and the code looks a lot better.
> >
> > For stuff I use internally, when I want some ecapsulation and not  
> > to have to
> > shift $this, I often use a little package called hashclosure.pm.  
> > hashclosure
> > basically tells Perl that the object's methods are code references  
> > inside
> > of the hash. The hash contains methods and code references rather than
> > instance data. Instance data is "my" variables lexically closed  
> > over by the
> > methods.
> >
> >   package hashclosure;
> >
> >   sub import {
> >       my $caller = caller;
> >       *{$caller.'::AUTOLOAD'} = sub {
> >           my $method = $AUTOLOAD; $method =~ s/.*:://;
> >           return if $method eq 'DESTROY';
> >           my $this = shift;
> >           local *{$caller.'::this'} = $this;
> >           if(! exists $this->{$method}) {
> >               my $super = "SUPER::$method";
> >               return $this->$super(@_);
> >           }
> >           $this->{$method}->(@_);
> >       };
> >   }
> >
> >   1;
> >
> > This is the AUTOLOAD glue needed to so that objects created as
> > follows work:
> >
> >   package Person;
> >   use hashclosure;
> >
> >   our $this;
> >
> >   sub new {
> >       my $class = shift;
> >       my $name;
> >       my $age;
> >       bless {
> >           name => sub { $name },
> >           set_name => sub { $name = shift },
> >           age  => sub { $age },
> >           set_age => sub { $age = shift },
> >           print_stats => sub {
> >               my $self = shift;
> >               print "name: ", $self->name, "\n";
> >               print "age: ", $self->age, "\n";
> >           },
> >           get_older => sub {
> >               my $self = shift;
> >               $self->age++;
> >           },
> >       }, $class;
> >   }
> >
> > Since the "instance data" is lexically closed over by the methods and
> > scoped to the new { } block, encapsulation is pretty good (PadWalker
> > and such can still get to it, but XS can do anything).
> >
> > Best of all, you don't have to write that annoying $self->{foo}  
> > crap --
> > just $foo will do. That's an improvement even over $self->foo as in  
> > A::P.
> >
> > The AUTOLOAD logic shifts $this for us and sticks it and puts it into
> > the $this defined by 'out $this'.
> >
> > Downsides are lack of lvalue accessors (so you can't do $person- 
> > >name = "Fred")
> > and the ugly initialization syntax.
> >
> > This might be workable with lvalue, but I'd have to do a much larger
> > and messier AUTOLOAD to make it happen and my first attempt didn't
> > pan out.
> >
> > At the last meeting, I got out my Object::Lexical on the projector and
> > shoved that in people's faces. It also makes instance data into
> > lexicals, but the implementation is completely different (it creates
> > a new stash for each object created, stuffs closures into it, and
> > blesses it -- it's probably the strangest thing I've ever done in  
> > Perl).
> > Here's what code using it looks like:
> >
> >   use Object::Lexical;
> >   use Sub::Lexical;
> >
> >   sub new {
> >
> >     our $this;
> >     my $name;
> >     my $age;
> >
> >     my sub age { $age };
> >     my sub name { $name };
> >
> >     sub print_stats {
> >         print "name: ", $name, "\n";
> >         print "age: ", $age, "\n";
> >     }
> >
> >     sub get_older {
> >         $age++;
> >     }
> >
> >     instance();
> >
> >   }
> >
> > It just doesn't get any more clear or concise than that for creating
> > objects in Perl. instance() serves the same purpose as bless(),
> > but it does the actual stash-blessing and closure-generating.
> > To get this pretty syntax, you need a source filter -- that's what
> > Sub::Lexical does. For some other idioms that don't use a source
> > filter, see http://search.cpan.org/~swalters/Object-Lexical-0.02/ 
> > Lexical.pm.
> > This module is a bit buggy, by the way, but if anyone actually
> > has any interest in it, I'll fix the thing.
> >
> > Regards,
> > -scott
> >
> > On  0, Michael Friedman <friedman at highwire.stanford.edu> wrote:
> >> So, I just read through _Perl Best Practices_ and it's fantastic.
> >> It's even well written. And I agree with almost all of Damian's
> >> recommendations for making more maintainable Perl code... all except
> >> inside out objects.
> >>
> >> However, as I've already had one tranformative religious experience
> >> from this book (I've changed my braces style), I'm willing to give
> >> the guy a chance on this one. But I need some more evidence.
> >>
> >> Has anyone used inside out objects before? I completely believe that
> >> they handle encapsulation much better, but what I don't buy is that
> >> they're actually easier to maintain and equivalently easy to
> >> understand as the "regular" hash-based objects are.
> >>
> >> So, anyone have real world advice on using them?
> >>
> >> -- Mike
> >>
> >> PS - For those not in the know, inside out objects are identified by
> >> a unique scalar that acts as an index into a list of hashes, one hash
> >> for each attribute/field of the object. The values are held in the
> >> set of hashes in a closure, so absolutely no one but the class itself
> >> can access them. There is an example in the code block on http://
> >> www.windley.com/archives/2005/08/best_practices.shtml, and other
> >> examples elsewhere that I can't seem to find at the moment. :-(
> >>
> >> ---------------------------------------------------------------------
> >> Michael Friedman                     HighWire Press
> >> Phone: 650-725-1974                  Stanford University
> >> FAX:   270-721-8034                  <friedman at highwire.stanford.edu>
> >> ---------------------------------------------------------------------
> >>
> >>
> >> _______________________________________________
> >> Phoenix-pm mailing list
> >> Phoenix-pm at pm.org
> >> http://mail.pm.org/mailman/listinfo/phoenix-pm
> 
> ---------------------------------------------------------------------
> Michael Friedman                     HighWire Press
> Phone: 650-725-1974                  Stanford University
> FAX:   270-721-8034                  <friedman at highwire.stanford.edu>
> ---------------------------------------------------------------------
> 
> 
> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://mail.pm.org/mailman/listinfo/phoenix-pm

From benjamin.trussell at asu.edu  Tue Nov 29 08:39:21 2005
From: benjamin.trussell at asu.edu (Benjamin Trussell)
Date: Tue, 29 Nov 2005 09:39:21 -0700
Subject: [Phoenix-pm] Perl.com: "Document Modeling with Bricolage"
Message-ID: <037FF41095AD394DB28A3991559A0FB4B4B329@EX04.asurite.ad.asu.edu>

Apologies to all who've already read this:

	"Document Modeling with Bricolage"
      http://www.perl.com/pub/a/2005/11/23/bricolage_analysis.html

Also related, & shamelessly pulled from the first paragraph in the above article...:
	"Bricolage installation"
	http://www.perl.com/pub/a/2004/10/28/bricolage_installation.html

	"Bricolage configuration"
	http://www.perl.com/pub/a/2005/01/06/bricolage_configuration.html

	Bricolage homepage
	http://www.bricolage.cc/


Ben
?