Re: Still Not sure if I agree with myself.
On Sunday, Sep 14, 2003, at 14:00 US/Pacific, Todd W. wrote:
[..]
Beacuse of @ISA being lexically declared, it can't inherit from other
modules. And remember, for a logical scope to be called a closure, you
have
to be dealing with lexical values.
p0: I knew there was a 'rational' explanation why it is
an 'our @ISA' vice a 'my @ISA' but had not taken the time
to walk it through
p1: Since I am not 'presuming' any lexical values,
merely a stack of subs - I think 'block' should be
the assertion. It may be a closure, but it will be a block
so that one can 'manage' the 'name space' issues:
# package main
{
package Foo;
...
}
# back to package main
that part makes good enough sense, eh no?
But I think the part that scares me is that
my $action = {
doDaemon = sub { . },
...
};
would get us into the same 'space'?
Not if you declare $action to have its own file or block scope. You
would
have to define an accessor to access $action.
p2. Normally I do that so that it is in package 'main' so
that I do not have to create an external PM that will
manage it This specfic variant was poking at the idea
of saving on typing the 'sub doDamon {}' and then hanging
it in the Hash of Subs with
{ doDaemon = \doDaemon , }
p3. What I was partially looking at was a
'simpler' way from my traditional approach of
'things that look like subs should be stuffed into a sub, as
somewhere along the line they May get clustered into a PM
somewhere and the code then is simpler to maintain.
And in this case taking advantage of the 'block' that would
allow me to declare a 'package' namespace as one more step
in the general process of getting there...
[..]
If you have a reuseable component that dispatches other
components you can call it an application server, for some
definitions of an application server.
p4. This just makes me NERVOUS. My normal habit is
make it work
congeal together what is common to all
If they really have a common base not unique to this project
then distill that common base out for re-use...
at which point, I fear I agree with the YA_CGI_AppServer
notion for, as you not SomDefofAppServer... It just worries me.
ciao
drieux
---
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Still Not sure if I agree with myself.
Drieux [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On Sunday, Sep 14, 2003, at 14:00 US/Pacific, Todd W. wrote:
[..]
Beacuse of @ISA being lexically declared, it can't inherit from other
modules. And remember, for a logical scope to be called a closure, you
have to be dealing with lexical values.
snip /
p1: Since I am not 'presuming' any lexical values,
merely a stack of subs - I think 'block' should be
the assertion. It may be a closure, but it will be a block
so that one can 'manage' the 'name space' issues:
# package main
{
package Foo;
...
}
# back to package main
that part makes good enough sense, eh no?
Yep. The end of the block reinstates the package to the one in effect before
the package was changed inside the block, with the added benefit ( or
drawback, depending on which side of the data hiding war you are on ) of
lexical identifiers being hidden from the code outside of the block.
snip /
If you have a reuseable component that dispatches other
components you can call it an application server, for some
definitions of an application server.
p4. This just makes me NERVOUS. My normal habit is
make it work
congeal together what is common to all
If they really have a common base not unique to this project
then distill that common base out for re-use...
at which point, I fear I agree with the YA_CGI_AppServer
notion for, as you not SomDefofAppServer... It just worries me.
I agree with you. At this point, its not about writing reuseable components,
its about making those reuseable components _easy_ to reuse. I guess the
best I can do for you is to resuggest checking out the appservers on CPAN.
Actually write the same app multiple times, once using CGI::Application,
once using Template::Toolkit and Class::DBI, and so on. Then audit the
sources for the ideas you like best.
have fun,
Todd W.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Still Not sure if I agree with myself.
Drieux [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On Friday, Sep 12, 2003, at 18:54 US/Pacific, Todd W. wrote:
[..]
I dont think you can call that a closure yet. You would have to be
defining
subroutines that refer to lexical variables outside of the subroutine
or
something along those lines:
[EMAIL PROTECTED] trwww]$ perl
{
my $dog = 'spot';
sub dogsName {
my $pooch = $dog;
return(my dog is $pooch);
}
}
[..]
Mea Kulpa! What Was I Thinking? I just did the
perldoc -q closure
but. hum...
{
package Foo::Bar
use base qw/Foo/;
...
}
Would seem to meet the minimum requirement, since
the 'use base' there deals with the @ISA for that
package name space...
The block is still not a closure, because @ISA must be a package global for
the inhertance mechanism to work its magic.
use base qw/Foo/;
is semantically the same as:
our(@ISA) = qw/Foo/;
As a matter of fact, declaring @ISA as a lexical will effectively disable
inheritance for a given module:
[EMAIL PROTECTED] trwww]$ perl
use warnings;
use strict;
use CGI;
{
package Foo;
our(@ISA) = qw/CGI/;
}
# inerited class method
print Foo-escapeHTML('foobar'), \n;
Ctrl-D
fooamp;bar
and then:
[EMAIL PROTECTED] trwww]$ perl
use warnings;
use strict;
use CGI;
{
package Foo;
my(@ISA) = qw/CGI/;
}
print Foo-escapeHTML('foobar'), \n;
Ctrl-D
Can't locate object method escapeHTML via package Foo at - line 10.
Beacuse of @ISA being lexically declared, it can't inherit from other
modules. And remember, for a logical scope to be called a closure, you have
to be dealing with lexical values.
But I think the part that scares me is that
my $action = {
doDaemon = sub { . },
...
};
would get us into the same 'space'?
Not if you declare $action to have its own file or block scope. You would
have to define an accessor to access $action.
I'm not sure I really want to actually create YA_CGI_AppServer,
although, I fear that I am in dire meandering towards that sort
of 'can one create a general enough solution'
Since, well, uh, one of my doodles is about passing in a
reference to an object, and such things ... Since the basic
'shell' of a CGI script still looks like:
snip CGI parser example /
make_header_and_send($page_type, $page);
so that of course yearns to be in a module, rather than
as something one would cut and paste into each new CGI script...
But looking at your diagramme, I think I can see why you
are pointing towards a YA_CGI_AppServer
If you have a reuseable component that dispatches other components you can
call it an application server, for some definitions of an application
server.
Todd W.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Still Not sure if I agree with myself.
On Thu, 11 Sep 2003 at 14:13, drieux opined:
[snip]
d: sub should { defined($REQ_PARAMS-{$_[0]}); }
d:
d: sub doDaemon {
d:
d: }
d: sub kickDaemon { $me=shift; $me-doDaemon(@_); }
d: # the synonym trick...
d:
d:Which still gives me a HASH to manage, plus the actual Sub.
true, but you can use the hash for more than just a way to determine if a
called method exists. for an example, take a look at my form checker
tutorial:
http://www.peacecomputers.com/form_checker/
you'll see the %REQ_PARAMS hash lists each parameter it expects to receive
for every action, and also provides some basic criteria that each
parameter must pass to be considered acceptable.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Still Not sure if I agree with myself.
Drieux [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
This discussion goes along with the one you are having with fliptop.
One of my first question is - why the 'closure' eg:
{
package FOO;
}
Or is that simply to make 'clear' that outside of
the Closure it is still package 'main'???
I dont think you can call that a closure yet. You would have to be defining
subroutines that refer to lexical variables outside of the subroutine or
something along those lines:
[EMAIL PROTECTED] trwww]$ perl
{
my $dog = 'spot';
sub dogsName {
my $pooch = $dog;
return(my dog is $pooch);
}
}
print dogsName(), \n;
print Share your dog '$dog' with me\n;
Ctrl-D
my dog is spot
Share your dog '' with me
Only the sub dogsName() knows the value of $dog. NOW the braces are a
closure for the lexical. Before that they just made up a block. The last
line of code above explodes with strict.
So, when you do your:
{
package FOO;
}
And you define lexicals in there, only functions internal to the block have
access to the lexical. If you put each class in its own file, you get the
same behavior because files have thier own scope.
In OO terms, this is called 'private static members'
snip /
Which leads me to my second set of question,
as a general habit I tend to make 'private-ish' methods
with the _ prefix such as
sub _some_private_method { }
is there some 'general access' mechanism by which one can
ask for the LIST of all methods that an 'object' CanDo???
Or should one have a 'register_of_parser_methods' approach
that one can query?
I followed your link ( that I affectionately snipped ), but it was a couple
days ago.
If your hell-bent on writing YA_CGI_AppServer, then check out how the
currently existing ones handle dispatching. CGI::Application is an excellent
example and easy to follow because its simple. There are others, too.
I like to write my own application server components because it is fun to
see one evolve from an empty text file to set of directories worthy of CVS:
http://waveright.homeip.net/~trwww/api.gif
But sometimes its funner to pretend everything is a jigsaw puzzle. Making
CGI::Application, CGI::Session, Class::DBI, and Template::Toolkit work
together transparently has been interesting. Perhaps one day it will be done
=0).
Todd W.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Still Not sure if I agree with myself.
On Friday, Sep 12, 2003, at 18:54 US/Pacific, Todd W. wrote:
[..]
I dont think you can call that a closure yet. You would have to be
defining
subroutines that refer to lexical variables outside of the subroutine
or
something along those lines:
[EMAIL PROTECTED] trwww]$ perl
{
my $dog = 'spot';
sub dogsName {
my $pooch = $dog;
return(my dog is $pooch);
}
}
[..]
Mea Kulpa! What Was I Thinking? I just did the
perldoc -q closure
but. hum...
{
package Foo::Bar
use base qw/Foo/;
...
}
Would seem to meet the minimum requirement, since
the 'use base' there deals with the @ISA for that
package name space...
But I think the part that scares me is that
my $action = {
doDaemon = sub { . },
...
};
would get us into the same 'space'?
I'm not sure I really want to actually create YA_CGI_AppServer,
although, I fear that I am in dire meandering towards that sort
of 'can one create a general enough solution'
Since, well, uh, one of my doodles is about passing in a
reference to an object, and such things ... Since the basic
'shell' of a CGI script still looks like:
my $request = $ENV{'REQUEST_METHOD'};
my ($page_type,$page) = (text/html);
if( defined($request) $request =~ m/^POST|GET|HEAD$/)
{
my $queryString = ($request eq 'POST' )?
STDIN : $ENV{'QUERY_STRING'};
#
# a. get the query string into a useable manner
# b. verify that the query string has what you need
# and is safe, sane and sober
# c. given some key in that query string select the
#right method for making a response
#
} else {
#
# Deal with being passed an unsupported Request Method
#
}
make_header_and_send($page_type, $page);
so that of course yearns to be in a module, rather than
as something one would cut and paste into each new CGI script...
But looking at your diagramme, I think I can see why you
are pointing towards a YA_CGI_AppServer
ciao
drieux
---
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Still Not sure if I agree with myself.
On Mon, 8 Sep 2003 at 15:36, drieux opined:
drieux - since no one has responded, i'll take a stab at some of the
issues you bring up.
d:One of my first question is - why the 'closure' eg:
d:
d:{
d: package FOO;
d:
d:}
d:
d:Or is that simply to make 'clear' that outside of
d:the Closure it is still package 'main'???
from 'programming perl, 3rd edition', page 260:
closure gives us a way to set values used in a subroutine when you define
it, not just when you call it
so while i can see a reason for using closure like this:
{
my %REQ_PARAMS = {
action1 = { # some specifications for action1 },
action2 = { # some specifications for action2 },
etc
};
sub req_params {
return $REQ_PARAMS{shift-action};
}
}
i'm not sure what the benefit of putting the whole damn package inside a
closure is. perhaps someone else can provide a reason or example of its
benefits?
d:Which leads me to my second set of question,
d:
d: as a general habit I tend to make 'private-ish' methods
d: with the _ prefix such as
d:
d: sub _some_private_method { }
d:
d:is there some 'general access' mechanism by which one can
d:ask for the LIST of all methods that an 'object' CanDo???
not that i know of.
d:Or should one have a 'register_of_parser_methods' approach
d:that one can query?
i would guess most people probably list the available (public) methods in
the pod documentation.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Still Not sure if I agree with myself.
On Thursday, Sep 11, 2003, at 05:51 US/Pacific, fliptop wrote:
[..]
drieux - since no one has responded, i'll take a stab at some of the
issues you bring up.
[..]
Thanks for the feed back.
In the code that I implemented, I did not use the Closure
to 'wrap' my Package - but I think as a 'GP safety' I
probably would, in case I needed to have variables that
belonged in the Package Space as you noted.
The second thing that SMACKED ME upside the head as I
was working out 'what is the ugly here'?
simply because
$obj-can($do);
does not mean
$obj-should($do);
The problem I am looking for in my should() method
is a programatic way to solve Which Method to invoke
the correct sub to deal with a query string. I have
a tough enough time keeping my code in line as it is,
I really do not want it to be reading POD when it should
be working and generating HTML 8-)
My traditional trick is of the form
my $qs = make_hash_of_query_string($request);
my $actions = {}; # the hash of subs
my $callForm = $qs-{'callForm'} || 'main_display'; # get the callForm
parameter
my $page = (defined($action-{'callForm'}) ? # is it defined
$action-{'callForm'}-($qs) :
main_display($qs);
Which of course requires me to maintain the Hash of $actions
so that I 'register' by hand, each of the Subs that SHOULD
be used in the cgi code. A problem that I do not escape
if I have to maintain a similar list of which 'callForms'
are legitimate tokens to be returned from the browser.
So while the UNIVERSAL::can is able to check for a
given 'symbol' and return a reference to it I was
sorta wanting something that would return a list of all
of the symbols that would return something in can()...
So that I could keep the list of 'But Not These'...
Which is merely the reverse, and perchance Worse notion
since the maintanance of that DarkUgly has to know all
of the things to exclude... To cite the Immortals
Run Away!
ciao
drieux
---
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Still Not sure if I agree with myself.
On Thu, 11 Sep 2003 at 07:55, drieux opined:
d:simply because
d:
d: $obj-can($do);
d:
d:does not mean
d:
d: $obj-should($do);
d:
d:The problem I am looking for in my should() method
d:is a programatic way to solve Which Method to invoke
d:the correct sub to deal with a query string. I have
d:a tough enough time keeping my code in line as it is,
d:I really do not want it to be reading POD when it should
d:be working and generating HTML 8-)
the way i do it is to assign an action to each form. each action has
associated parameters. the form sends the action in an input
type=hidden tag.
d:
d:My traditional trick is of the form
d:
d: my $qs = make_hash_of_query_string($request);
d: my $actions = {}; # the hash of subs
d: my $callForm = $qs-{'callForm'} || 'main_display'; # get the callForm
d:parameter
d:
d: my $page = (defined($action-{'callForm'}) ? # is it defined
d: $action-{'callForm'}-($qs) :
d: main_display($qs);
d:
d:Which of course requires me to maintain the Hash of $actions
d:so that I 'register' by hand, each of the Subs that SHOULD
d:be used in the cgi code. A problem that I do not escape
d:if I have to maintain a similar list of which 'callForms'
d:are legitimate tokens to be returned from the browser.
another way is to check the list of acceptable 'actions' in the module
constructor, then if you pass an action method that's not defined, return
an error. for example:
package Foo;
use Carp;
{
my %REQ_PARAMS = (
action1 = { # criteria for action 1 },
action2 = { # criteria for action 2 },
etc...
);
sub req_params {
return $REQ_PARAMS{shift-action};
}
}
sub new {
my ($class, %args) = @_;
croak missing action arg unless defined $args{action};
my $self = bless {
_ACTION = $args{action}
}, $class;
croak method $args{action} not found unless $self-req_params;
return $self;
}
sub action { shift-{_ACTION} }
then in your script:
#!/usr/bin/perl -w
use Foo;
my $f1 = Foo-new( action = 'action2' ); # works ok
my $f2 = Foo-new( action = 'action6' ); # shits the bed
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Still Not sure if I agree with myself.
On Thursday, Sep 11, 2003, at 12:17 US/Pacific, fliptop wrote:
[..]
the way i do it is to assign an action to each form. each action has
associated parameters. the form sends the action in an input
type=hidden tag.
oh yes, in this case the 'trigger' I use in say
input type=hidden name=callForm value=doDaemon
This way we do not have to have 'one cgi script' per action.
My general strategy is to just pass along the HASH of
the query string and leave them up to the subs to sort out
which they need, which they use, yada-yada.
d:My traditional trick is of the form
d:
d: my $qs = make_hash_of_query_string($request);
d: my $actions = {}; # the hash of subs
oh, sorry, maybe if I broke that out
my $action = {
doDaemon = \doDameon,
showDaemon = \show_daemon,
kickDaemon = \doDameon,
};
It would be more obvious that my idea is to KNOW that
a given 'callForm' value returned from the browser is
associated with a given method that would deal with
the rest of the pack up some HTML and ship it back.
The 'kickDaemon' variant in there is when I have already
worked out that it would be a possible 'callForm' value
that can be passed to this CGI, from some other piece
of code, and that the difference between what kickDaemon()
and doDaemon() do ultimately was so negligible that I just
put a 'flag foo' into the later and consolidated code...
d: my $callForm = $qs-{'callForm'} || 'main_display'; # get the
callForm
d:parameter
d:
d: my $page = (defined($action-{'callForm'}) ? # is it defined
d: $action-{'callForm'}-($qs) :
d: main_display($qs);
d:
d:Which of course requires me to maintain the Hash of $actions
[..]
{
my %REQ_PARAMS = (
action1 = { # criteria for action 1 },
action2 = { # criteria for action 2 },
etc...
);
[..]
That was what I was trying to mostly avoid. The idea of
the 'should()' would take me along the line
my $page = ($obj-should($action-{'callForm'})) ?
$obj-${$action-{'callForm'}}($qs) :
$obj-call_form_error($qs);
hence the should look like
my $REQ_PARM = {
doDaemon = 1,
};
sub should { defined($REQ_PARAMS-{$_[0]}); }
sub doDaemon {
}
sub kickDaemon { $me=shift; $me-doDaemon(@_); }
# the synonym trick...
Which still gives me a HASH to manage, plus the actual Sub.
ciao
drieux
---
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Still Not sure if I agree with myself.
Currently I am in the midst of an argument
with myself about tactics and strategies
for doing CGI coding. The side effect of
which lead me to wonder about some prejudices
I seem to have about when, where and how to
cut over to using/creating a Perl Module for
code re-use. Some of this comes from debating
ideas from Learning Perl Objects, References Modules.
cf: http://www.oreilly.com/catalog/lrnperlorm/
One of my first question is - why the 'closure' eg:
{
package FOO;
}
Or is that simply to make 'clear' that outside of
the Closure it is still package 'main'???
The demonstration code that goes with my longer
write up of my 'issues' -
cf http://www.wetware.com/drieux/CS/Proj/TPFH/a_bci.html
started out Strictly as a simple illustratoin of
how a command line interface piece of code CAN be written.
Unfortunately I decided to take that other look,
and hack around with other ways of doing things,
a brief coding interlude which as most of us know is similar
to a 'brief psychotic episode' but occasionally less functional.
The gooder news is that this has the look and feel
of a 'faster' way to go about playing with ideas
that one thinks need to be culled out into a
separate stand alone perl module. The information
section of course is that I am not sure that 'abusing'
the 'can()' the way I did will survive more than
that demonstration piece of code.
Which leads me to my second set of question,
as a general habit I tend to make 'private-ish' methods
with the _ prefix such as
sub _some_private_method { }
is there some 'general access' mechanism by which one can
ask for the LIST of all methods that an 'object' CanDo???
Or should one have a 'register_of_parser_methods' approach
that one can query?
ciao
drieux
---
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
