From: thayer@cs.columbia.edu (Charles Thayer)
Subject: Re: OOP?  Dynamic Loading of C code and packages for perl
Bcc: thayer
Organization: Columbia University Department of Computer Science
Date: Sun, 11 Oct 1992 09:32:00 GMT

In article <jbone.718653194@manufing> jbone@manufing.dell.com (Jeff Bone) writes:
>I think this is a Really Good Idea(tm).  One suggestion --- I think some
>thought should be given to an object storage manager, perhaps based on
>the dbm family, which would swap objects into and out of a cache on

That's going a little far on the changes side, but I understand what sorts
of frustrations generate this.

Perhaps a better more general change would be one in which perl supported
a bound section that would go straight to a user routine.  For example:

sub foo {
  local($a,$b,$c)=@_;
  print "$c\n";
  return ["$a $b"];
}

the '["$a $b"]' would call a user-written c-subroutine (see your usub
dir of the perl source.)  This routine would be written and compiled
in C and take and return a string.  And [["$a $b baz"] `ypmatch foo bar`]
would do what you'd expect too.

How is this any different than &userfoo()?
It's not, it just more blunt, and it's syntactic sugar that makes perl
look more like smalltalk.  Besides its less typing so it must be okay :)

How does this help the problem of persistent object brokering?
It doesn't, because that's not perl.  Many other people have done
that already, use their stuff and compile it in.  I hate when things
are unnecessarily bloated instead of using already existing tools 
more effectively (eg. what is nfs doing in my kernel?)  

How would you use it to make perl object-oriented and provide persistence?
I would take either siod (scheme in one defun --see comp.lang.scheme)
or tcl (tool command language --see comp.lang.tcl)  And use those
as a backend to an object-oriented system.  The only addition you
make to one of these two is to add the appropriate calls to something
like ``callv(eval,...''.

Why siod or tcl?
Scheme is object-oriented enough for provide a reasonable mechanism
for perl, plus the read and print syntaxes are reasonable for providing
persistence.  Tcl is even better because the only data type (well almost,
basically) is the string type --perfect for flushing everything to disk.

Last thoughts?
Far too many to mention now, it's getting late.  But here's the top of
my list:
[soapbox (tm)mtr]
I would like to see tcl used as a front-end to the suggested '[]'
syntax.  The reason is that tcl is a very reasonable, small, embedded
command language, which could be easily put in any C program.  There
are already tcl/sybase/curses/xwindows/motif/oracle/snmp/...
combinations out there.  If these tools were all talking to each other
with the tcl-send command I could stop worrying about which toolchest
to use when tackling something, since they would already work
together.

other thoughts near the top of the list: 
-Someone's already written a dld based dynamic object loader in tcl.
-There are versions of tcl that already dynamically load missing
symbols.
-Someone's already written a sybased tcl.
-Tcl could implement struct for perl.
-We could get rid of some of the features already in perl.

/charles
PS. $.02
PPS. It's 5:00am here #include <std_dumb_disclaimer>.
-- 
==============================================================================
Charles Thayer, Columbia University, Dept. CS, Tech-staff... my words only.
Newsgroups: comp.lang.perl