[Date Prev][Date Next][Thread Prev][Thread Next][Minivend by date
][Minivend by thread
]
Thank You! Re: [mv] Wishlist, request for namespace
****** message to minivend-users from cfm@maine.com ******
On Sun, Jul 23, 2000 at 07:08:15AM -0400, Mike Heins wrote:
> ****** message to minivend-users from Mike Heins <mikeh@minivend.com> ******
>
> Quoting cfm@maine.com (cfm@maine.com):
> > ****** message to minivend-users from cfm@maine.com ******
> >
> >
> > I'd like to put these on wishlist ;^)
> >
> > 1)
> > We've been building our custom minivend libraries in lib/Vend and
> > now wish to move them out to /usr/lib/perl5/MV because we want to share
> > them with other non-minivend scripts. That's a bigger than minivend
> > issue, but we can risk it; I'm mostly concerned that minivend not claim
> > that space. With name change, maybe that is moot?
>
> I don't understand all of this. There is nothing at all stopping you
> from:
>
> cp -ra /usr/local/minivend/lib/Vend /usr/lib/perl5/site_perl
I must have written that all wrong because someone else replied in
similar vein. What I want is to guarantee that if we build a module
MV::Extra.pm there will never be a conflict within minivend.
Right now @INC would find either /usr/lib/perl5/MV/Extra and
/var/mvend403/lib/MV/Extra and not in order we'd want:
/var/mvend403 /var/mvend403/lib /usr/lib/perl5/5.005/i386-linux
/usr/lib/perl5/5.005 /usr/local/lib/site_perl/i386-linux /usr/local/lib/site_perl
/usr/lib/perl5 .
That would be a mess if the distribution included a MV::Extra.pm. Naturally
this did not occur to us **before** we started putting things in that structure,
so, <ahem>, can you promise never to use MV::*.pm?
> >
> > 2)
> > What is most sensible way to do this:
> >
> > [embed]
> > my ($foo);
> > $foo=new bar;
> >
> > [/embed]
> >
> > Other minivend stuff
> >
> > [embed]
> >
> > return $foo->blat;
> >
> > [/embed]
> >
> > Where [embed] tag is a fancy version of Mike's unsafe perl tag, eg
> > it permits direct raw access to everything bypassing Safe. What we
> > want is for $foo to live for duration of that page, maybe the
> > same scope as $CGI? I think what we're looking for is another
> > shortlived namespace that gets set up on a per page basis. We don't
> > want it to go into Session. Is that what Scratch does? Am I making
> > any sense?
>
>
> and
>
> UserTag embed hasEndTag
> UserTag embed Routine <<EOR
> use MV::foo;
> use bar;
> use MV::buzz;
> use MV::baz;
> sub {
> eval @_;
> }
> EOR
>
> And there is no reason to use "my $foo" when you can say:
>
> [embed]
> use vars qw/$foo/;
> $foo = new bar;
> [/embed]
>
> some stuff
>
> [embed]
> return $foo->blat;
> [/embed]
That is very cool. Me, I've never seen a global var I didn't
suspect; maybe I'm too suspicious. We've been writing everything
as though the scope was only the single eval. Maybe it was
in [perl]?
cfm
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<TITLE>flypage.html</TITLE>
</HEAD>
<BODY ALINK="#990000" BGCOLOR="#F0FFC8" LINK="#3FBBEF" TEXT="#000000" VLINK="#664CCF" >
[embed]
{
# package Page; # or pick namespace to guarantee no conflict
use strict 'vars';
use vars qw(@OUT %opt);
$opt{1}="Left Foot";
$opt{2}="Left Foot";
$opt{3}="Left Foot";
push @OUT,"Hello";
return '';
}
[/embed]
<BR>And this is vanilla minivend code<BR>
[embed]
{
# package Page;
use strict 'vars';
use vars qw(@OUT %opt); # repeated use seems ok so can be modular
push @OUT,"World<P>";
for (sort keys %opt) {
push @OUT,$opt{$_},',<BR>';
}
push @OUT,"Right!<BR>";
return join '',@OUT;
}
[/embed]
</BODY>
</HTML>
--
Christopher F. Miller, Publisher cfm@maine.com
MaineStreet Communications, Inc 208 Portland Road, Gray, ME 04039
1.207.657.5078 http://www.maine.com/
Database publishing, e-commerce, office/internet integration, Debian linux.
-
To unsubscribe from the list, DO NOT REPLY to this message. Instead, send
email with 'UNSUBSCRIBE minivend-users' in the body to Majordomo@minivend.com.
Archive of past messages: http://www.minivend.com/minivend/minivend-list
