Requiring Lexical $_ / Obliterating Global $_?

Discussion in 'Perl Misc' started by Tim McDaniel, Sep 12, 2008.

  1. Tim McDaniel

    Tim McDaniel Guest

    Currently I do
    local $_;
    at the start of each sub, but it's an annoyance and it's not
    fail-safe (I can forget).

    Just found out about Perl 5.10. Pretty cool.

    Lexical $_

    The default variable $_ can now be lexicalized, by declaring it
    like any other lexical variable, with a simple
    my $_;

    The operations that default on $_ will use the lexically-scoped
    version of $_ when it exists, instead of the global $_.

    In a map or a grep block, if $_ was previously my'ed, then the $_
    inside the block is lexical as well (and scoped to the block).

    In a scope where $_ has been lexicalized, you can still have
    access to the global version of $_ by using $::_, or, more simply,
    by overriding the lexical declaration with our $_. (Rafael
    Garcia-Suarez)

    I like the convenience of the implicit USE of $_ in things like
    "s/foo/bar/", but I've had an abhorrence of implicitly-declared
    variables since FORTRAN days, and hatred of accidental variable
    leakage since C.

    Is there any way that I can dispose of any possibility of accidentally
    using the global dynamic variable $_? That is, where by default

    foreach (@array)

    errors out (ideally at compile time), requiring that I do

    foreach my $_ (@array)

    or declare it per sub or whatever I like?

    Should I look into playing with main's package symbol table (I know
    nothing about the subject other than that it exists)?

    --
    Tim McDaniel,
    Tim McDaniel, Sep 12, 2008
    #1
    1. Advertising

  2. On Fri, 12 Sep 2008 16:58:14 +0000, Tim McDaniel wrote:

    > Currently I do
    > local $_;
    > at the start of each sub, but it's an annoyance and it's not fail-safe
    > (I can forget).
    >
    > Just found out about Perl 5.10. Pretty cool.
    >
    > Lexical $_
    >
    > The default variable $_ can now be lexicalized, by declaring it like
    > any other lexical variable, with a simple
    > my $_;
    >
    > The operations that default on $_ will use the lexically-scoped
    > version of $_ when it exists, instead of the global $_.
    >
    > In a map or a grep block, if $_ was previously my'ed, then the $_
    > inside the block is lexical as well (and scoped to the block).
    >
    > In a scope where $_ has been lexicalized, you can still have access
    > to the global version of $_ by using $::_, or, more simply, by
    > overriding the lexical declaration with our $_. (Rafael
    > Garcia-Suarez)
    >
    > I like the convenience of the implicit USE of $_ in things like
    > "s/foo/bar/", but I've had an abhorrence of implicitly-declared
    > variables since FORTRAN days, and hatred of accidental variable leakage
    > since C.
    >
    > Is there any way that I can dispose of any possibility of accidentally
    > using the global dynamic variable $_? That is, where by default
    >
    > foreach (@array)
    >
    > errors out (ideally at compile time), requiring that I do
    >
    > foreach my $_ (@array)
    >
    > or declare it per sub or whatever I like?


    If I read that correctly, using 'my $_;' once at the top of your program
    should do what you want.

    HTH,
    M4
    Martijn Lievaart, Sep 13, 2008
    #2
    1. Advertising

  3. Tim McDaniel

    Dr.Ruud Guest

    Tim McDaniel schreef:

    > Currently I do
    > local $_;
    > at the start of each sub


    Why? At least I never needed to do that, and I assume virtually nobody
    does.

    The rule is simple:
    Either a sub can change $_ in a documented way, or it leaves it
    untouched.

    --
    Affijn, Ruud

    "Gewoon is een tijger."
    Dr.Ruud, Sep 13, 2008
    #3
  4. On 2008-09-13 08:23, Martijn Lievaart <> wrote:
    > On Fri, 12 Sep 2008 16:58:14 +0000, Tim McDaniel wrote:
    >> Currently I do
    >> local $_;
    >> at the start of each sub, but it's an annoyance and it's not fail-safe
    >> (I can forget).
    >>
    >> Just found out about Perl 5.10. Pretty cool.
    >>
    >> Lexical $_

    [...]
    >>
    >> I like the convenience of the implicit USE of $_ in things like
    >> "s/foo/bar/", but I've had an abhorrence of implicitly-declared
    >> variables since FORTRAN days, and hatred of accidental variable leakage
    >> since C.
    >>
    >> Is there any way that I can dispose of any possibility of accidentally
    >> using the global dynamic variable $_? That is, where by default
    >>
    >> foreach (@array)
    >>
    >> errors out (ideally at compile time), requiring that I do
    >>
    >> foreach my $_ (@array)
    >>
    >> or declare it per sub or whatever I like?

    >
    > If I read that correctly, using 'my $_;' once at the top of your program
    > should do what you want.


    I don't think so. In that case, if he forgets to declare $_ in a sub,
    the globally defined lexical $_ will be used, which isn't much of an
    improvement over using the predefined $_. In both cases the omission
    will not be noticed and two subs may inadvertently change the same $_.

    hp
    Peter J. Holzer, Sep 13, 2008
    #4
  5. On 2008-09-13 10:19, Dr.Ruud <> wrote:
    > Tim McDaniel schreef:
    >> Currently I do
    >> local $_;
    >> at the start of each sub

    >
    > Why? At least I never needed to do that, and I assume virtually nobody
    > does.


    I needed to do that in a number of cases. I've never made a habit of it
    although I can see why that might be a good idea.

    >
    > The rule is simple:
    > Either a sub can change $_ in a documented way, or it leaves it
    > untouched.
    >


    Right. And if your sub should leave $_ untouched, but either changes it
    itself (e.g., by using "while (<>) {}") or calls another sub which does,
    then adding "local $_;" at the start ensures that your sub indeed leaves
    $_ untouched (as far as the caller can tell).

    hp
    Peter J. Holzer, Sep 13, 2008
    #5
  6. Tim McDaniel

    Tim McDaniel Guest

    In article <>,
    Dr.Ruud <> wrote:
    >Tim McDaniel schreef:
    >
    >> Currently I do
    >> local $_;
    >> at the start of each sub

    >
    >Why? At least I never needed to do that, and I assume virtually
    >nobody does.
    >
    >The rule is simple:
    >Either a sub can change $_ in a documented way, or it leaves it
    >untouched.


    That's like saying "In FORTRAN, the rule is simple: never use an
    undeclared variable". What about typos and oversights? If having
    rules was sufficient to prevent bugs, there'd be little need for error
    messages or warnings.

    But I didn't consider sufficiently the fact that foreach, map, and
    grep localize changes to $_. If I do an accidental "s///" without
    "=~", then the bug will probably be noticed just because it's using a
    unexpected value of $_ rather than whatever variable I meant.
    "while (<>)" and explicit assignment to $_ (to make further m// and
    s/// actions more consise) are the only idioms I can think of where a
    persistent change to $_ occurs naturally.

    But I do both of those with some frequency.

    --
    Tim McDaniel; Reply-To:
    Tim McDaniel, Sep 14, 2008
    #6
  7. On Sat, 13 Sep 2008 13:46:08 +0200, Peter J. Holzer wrote:

    > I don't think so. In that case, if he forgets to declare $_ in a sub,
    > the globally defined lexical $_ will be used, which isn't much of an
    > improvement over using the predefined $_. In both cases the omission
    > will not be noticed and two subs may inadvertently change the same $_.


    You are right.

    But then, where draw the line? Every block? Every sub? I can see the
    advantage of implicitly my-ing $_ in every sub, but it's not very logical
    in my eyes.

    The question by the OP, forbidding to use global $_, is a definite
    improvement, still leaves room for errors, but would be worthwhile none
    the less.

    M4
    Martijn Lievaart, Sep 14, 2008
    #7
  8. Tim McDaniel

    Tim McDaniel Guest

    In article <>,
    Martijn Lievaart <> wrote:
    >On Sat, 13 Sep 2008 13:46:08 +0200, Peter J. Holzer wrote:
    >
    >> I don't think so. In that case, if he forgets to declare $_ in a
    >> sub, the globally defined lexical $_ will be used, which isn't much
    >> of an improvement over using the predefined $_. In both cases the
    >> omission will not be noticed and two subs may inadvertently change
    >> the same $_.

    >
    >You are right.
    >
    >But then, where draw the line? Every block? Every sub?


    I'd like to draw the line in the same place I draw the line on
    declaring any other variable. I want a way to make $_ work by the
    same rules as any other variable, except for being the implicit
    operand in a number of operators.

    I would do
    foreach my $_ (...)
    in the same circumstances that I would do
    foreach my $i (...)
    or
    my $_;
    in the same circumstances that I would do
    my $file_line;
    Because of the ugliness of this [1]
    while (defined(my $_ = <FILE>)) {
    I'd probably have to make $_ a block or sub my variable to be able to
    still write
    while (<FILE>) {

    Perhaps, in places where I have to use < Perl 5.10, I should be
    local-ing it in more places, in the ways shown above.


    [footnote 1] Can I just say that I still can't wrap my head around how
    a declaration can be buried in the middle of a statement, which is
    bizarre to someone who grew up on FORTRAN, C, or most procedural
    languages, and that its "enclosing" scope is outside the {...}?

    --
    Tim McDaniel; Reply-To:
    Tim McDaniel, Sep 14, 2008
    #8
  9. Tim McDaniel

    Dr.Ruud Guest

    Tim McDaniel schreef:

    > [ accidently changing $_ ]
    > What about typos and oversights? If having
    > rules was sufficient to prevent bugs, there'd be little need for error
    > messages or warnings.


    I find it hard to come up with an example of that in the last year, in
    the group of about 30 Perl developers that I work with.
    The only one I remember is a bug found in legacy code that looks like
    $s =~ /x/ and /y/ and run();
    which was probably once $_ oriented code (I never actually checked).


    > If I do an accidental "s///" without
    > "=~", then the bug will probably be noticed just because it's using a
    > unexpected value of $_ rather than whatever variable I meant.


    Yes, that is one that someone might do wrong. The scope of an implicit
    localized $_ is best small, often not more than 1 or 2 lines.
    Just use a "for my $_value (@values) { ... }" where feasible.

    I do see some use now for something like "DEBUG>1 and local $_;" at the
    start of each sub.


    > explicit assignment to $_ (to make further m// and
    > s/// actions more consise)


    Stop doing that. You can use

    for ( $scalar ) { ... }

    and code like

    s/^\s+//, s/\s+$//, s/\s+/ /g for $old, $new;

    instead.

    --
    Affijn, Ruud

    "Gewoon is een tijger."
    Dr.Ruud, Sep 14, 2008
    #9
  10. On Sun, 14 Sep 2008 11:08:14 -0500, Tim McDaniel wrote:

    > In article <>, Martijn Lievaart
    > <> wrote:
    >>On Sat, 13 Sep 2008 13:46:08 +0200, Peter J. Holzer wrote:
    >>
    >>> I don't think so. In that case, if he forgets to declare $_ in a sub,
    >>> the globally defined lexical $_ will be used, which isn't much of an
    >>> improvement over using the predefined $_. In both cases the omission
    >>> will not be noticed and two subs may inadvertently change the same $_.

    >>
    >>You are right.
    >>
    >>But then, where draw the line? Every block? Every sub?

    >
    > I'd like to draw the line in the same place I draw the line on declaring
    > any other variable. I want a way to make $_ work by the same rules as
    > any other variable, except for being the implicit operand in a number of
    > operators.


    The implication of such is that simply ::$_ should not be defined[1].
    Which could be set by a (to be proposed) pragma I suppose. I like it.

    > [footnote 1] Can I just say that I still can't wrap my head around how a
    > declaration can be buried in the middle of a statement, which is bizarre
    > to someone who grew up on FORTRAN, C, or most procedural languages, and
    > that its "enclosing" scope is outside the {...}?


    To me, having moved from FORTRAN/Basic/COBOL to C to C++ to Perl a.o., it
    is bizarre not to be able to do this. Although I can see why embedding a
    complex declaration in the middle of a C statement would pose a parsing
    challenge.

    [1] Not set to undef, just does not exist!
    Martijn Lievaart, Sep 14, 2008
    #10
  11. Tim McDaniel

    Tim McDaniel Guest

    In article <>,
    Dr.Ruud <> wrote:
    >I do see some use now for something like "DEBUG>1 and local $_;" at
    >the start of each sub.


    Where DEBUG is a numeric constant? I think it's a nightmare to have
    code change its behavior in subtle ways while debugging. ("Subtle
    ways" meaning not the usual debug actions, like outputting log
    messages, assertion checking, and such, which usually shouldn't affect
    the program's state.) A $_ leakage problem would silently go away the
    moment you turned on debugging!

    >> explicit assignment to $_ (to make further m// and
    >> s/// actions more consise)

    >
    >Stop doing that.


    That came across as rather a harsh command and, um, you're not my
    boss.

    >You can use
    >
    > for ( $scalar ) { ... }
    >
    >and code like
    >
    > s/^\s+//, s/\s+$//, s/\s+/ /g for $old, $new;
    >
    >instead.


    Thank you for the suggestions, though I'd like to mull over how
    understandable "foreach" with one item would be to other readers.

    --
    Tim McDaniel; Reply-To:
    Tim McDaniel, Sep 14, 2008
    #11
  12. Tim McDaniel

    Dr.Ruud Guest

    Tim McDaniel schreef:
    > Dr.Ruud:


    >> I do see some use now for something like "DEBUG>1 and local $_;" at
    >> the start of each sub.

    >
    > Where DEBUG is a numeric constant?


    Put

    use constant DEBUG => 0;

    in a convenient place. That DEBUG is actually a "constant sub". Perl's
    compiler uses this to ignore that code, so it will not be compiled but
    skipped. See `perldoc constant` for details.


    > I think it's a nightmare to have
    > code change its behavior in subtle ways while debugging.


    That is exactly why the ">1" is there, so you can still set DEBUG to 1
    to not have the line.
    Give it more thought, because it is useful.


    $ perl -MO=Deparse -e'
    use constant DEBUG => 0;
    DEBUG>1 and local $_;
    '
    use constant ('DEBUG', 0);
    '???';
    -e syntax OK


    $ perl -MO=Deparse -e'
    use constant DEBUG => 1;
    DEBUG>1 and local $_;
    '
    use constant ('DEBUG', 1);
    '???';
    -e syntax OK


    $ perl -MO=Deparse -e'
    use constant DEBUG => 2;
    DEBUG>1 and local $_;
    '
    use constant ('DEBUG', 2);
    local $_;
    -e syntax OK


    The 1 is arbitrary, you can set the lower limit as high as you need.


    As you know, because "local $_;" sets $_ to undef, it can expose some
    bugs, like in

    $ perl -wle 's/a/b/'
    Use of uninitialized value in substitution (s///) at -e line 1.

    (I am assuming that "use strict; use warnings;" are in every file.)



    > ("Subtle
    > ways" meaning not the usual debug actions, like outputting log
    > messages, assertion checking, and such, which usually shouldn't affect
    > the program's state.) A $_ leakage problem would silently go away the
    > moment you turned on debugging!


    Once you grok the ">1", you'll see that you have the choice.


    >>> explicit assignment to $_ (to make further m// and
    >>> s/// actions more consise)

    >>
    >> Stop doing that.

    >
    > That came across as rather a harsh command and, um, you're not my
    > boss.


    One is what one reads. I can't mind you picking it up as harsh, because
    I can't know in what mood you will be when reading what I wrote. Always
    read such things as if written by a friend, it really helps.

    And it was a reference to the well known story that starts with "Doctor,
    it hurts when I do this.".


    >> You can use
    >>
    >> for ( $scalar ) { ... }
    >>
    >> and code like
    >>
    >> s/^\s+//, s/\s+$//, s/\s+/ /g for $old, $new;
    >>
    >> instead.

    >
    > Thank you for the suggestions, though I'd like to mull over how
    > understandable "foreach" with one item would be to other readers.


    Do with it whatever you want. I like it a lot.
    My second example has two items, but only after I substituted "$input"
    by "$old, $new".

    --
    Affijn, Ruud

    "Gewoon is een tijger."
    Dr.Ruud, Sep 14, 2008
    #12
  13. Tim McDaniel

    Ben Morrow Guest

    Quoth :
    > Currently I do
    > local $_;
    > at the start of each sub, but it's an annoyance and it's not
    > fail-safe (I can forget).
    >
    > Just found out about Perl 5.10. Pretty cool.
    >
    > Lexical $_

    <snip>
    >
    > Is there any way that I can dispose of any possibility of accidentally
    > using the global dynamic variable $_? That is, where by default


    You want to tie (the global) $_ to a class that looks like

    sub FETCH { croak "Global \$_ forbidden" }
    sub STORE { croak "Global \$_ forbidden" }

    I swear there's a module on CPAN that implements this, but I can't find
    it :(.

    Ben

    --
    It will be seen that the Erwhonians are a meek and long-suffering people,
    easily led by the nose, and quick to offer up common sense at the shrine of
    logic, when a philosopher convinces them that their institutions are not based
    on the strictest morality. [Samuel Butler, paraphrased]
    Ben Morrow, Sep 14, 2008
    #13
  14. On Mon, 15 Sep 2008 00:23:46 +0200, Dr.Ruud wrote:

    > Tim McDaniel schreef:


    >> Thank you for the suggestions, though I'd like to mull over how
    >> understandable "foreach" with one item would be to other readers.


    [ piggying here, didn't see the original ]

    As it's a fairly standard idiom, I would expect any competent Perl
    programmer to either know it, or look it up.

    HTH,
    M4
    Martijn Lievaart, Sep 15, 2008
    #14
  15. On 2008-09-14 16:08, Tim McDaniel <> wrote:
    > In article <>,
    > Martijn Lievaart <> wrote:
    >>On Sat, 13 Sep 2008 13:46:08 +0200, Peter J. Holzer wrote:
    >>
    >>> I don't think so. In that case, if he forgets to declare $_ in a
    >>> sub, the globally defined lexical $_ will be used, which isn't much
    >>> of an improvement over using the predefined $_. In both cases the
    >>> omission will not be noticed and two subs may inadvertently change
    >>> the same $_.

    >>
    >>You are right.
    >>
    >>But then, where draw the line? Every block? Every sub?

    >
    > I'd like to draw the line in the same place I draw the line on
    > declaring any other variable. I want a way to make $_ work by the
    > same rules as any other variable, except for being the implicit
    > operand in a number of operators.
    >
    > I would do
    > foreach my $_ (...)
    > in the same circumstances that I would do
    > foreach my $i (...)


    I would not want this.

    foreach (...) {
    }

    already implicitely declares a new $_ for a defined scope. Making the
    declaration explicit just adds noise, not readability. Same for map and
    grep.

    However:

    > my $_;
    > in the same circumstances that I would do
    > my $file_line;


    I agree with this, and I'd like a less ugly version of this:

    > Because of the ugliness of this [1]
    > while (defined(my $_ = <FILE>)) {


    (Actually, I'm not even sure if this does what I think it should do
    (restrict the scope of $_ to the body of the loop).

    hp
    Peter J. Holzer, Sep 15, 2008
    #15
  16. Tim McDaniel

    Ben Morrow Guest

    Quoth "Peter J. Holzer" <>:
    > On 2008-09-14 16:08, Tim McDaniel <> wrote:
    >
    > I agree with this, and I'd like a less ugly version of this:
    >
    > > Because of the ugliness of this [1]
    > > while (defined(my $_ = <FILE>)) {


    There's no need for it to be that ugly: you get the 'defined' for free:

    ~% perl -MO=Deparse -e'while (my $x = <>) {1}'
    while (defined(my $x = <ARGV>)) {
    '???';
    }
    -e syntax OK

    > (Actually, I'm not even sure if this does what I think it should do
    > (restrict the scope of $_ to the body of the loop).


    You get a fresh copy of $_ for each iteration:

    ~% echo "\n" | perl5.10.0 -lE'
    print "global ", \$_;
    my $_;
    print "outer ", \$_;
    my @a;
    while (my $_ = <>) {
    print "inner ", \$_;
    push @a, \$_; # we must keep a ref, or perl reuses
    } # the memory anyway
    print "outer ", \$_'
    global SCALAR(0x28361380)
    outer SCALAR(0x28361340)
    inner SCALAR(0x28361680)
    inner SCALAR(0x28307310)
    outer SCALAR(0x28361340)

    Ben

    --
    We do not stop playing because we grow old;
    we grow old because we stop playing.
    Ben Morrow, Sep 15, 2008
    #16
  17. Martijn Lievaart <> wrote:
    > On Mon, 15 Sep 2008 00:23:46 +0200, Dr.Ruud wrote:
    >
    >> Tim McDaniel schreef:

    >
    >>> Thank you for the suggestions, though I'd like to mull over how
    >>> understandable "foreach" with one item would be to other readers.

    >
    > [ piggying here, didn't see the original ]
    >
    > As it's a fairly standard idiom, I would expect any competent Perl
    > programmer to either know it, or look it up.



    While it is a common enough idiom, I still don't like it "bare".

    I usually take the extra 4 seconds to type something like

    for ( $scalar ) # because I'm gonna do a bunch of pattern matches


    --
    Tad McClellan
    email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
    Tad J McClellan, Sep 16, 2008
    #17
  18. Tim McDaniel

    Ben Morrow Guest

    Quoth Tad J McClellan <>:
    > Martijn Lievaart <> wrote:
    > > On Mon, 15 Sep 2008 00:23:46 +0200, Dr.Ruud wrote:
    > >
    > >> Tim McDaniel schreef:

    > >
    > >>> Thank you for the suggestions, though I'd like to mull over how
    > >>> understandable "foreach" with one item would be to other readers.

    > >
    > > [ piggying here, didn't see the original ]
    > >
    > > As it's a fairly standard idiom, I would expect any competent Perl
    > > programmer to either know it, or look it up.

    >
    >
    > While it is a common enough idiom, I still don't like it "bare".
    >
    > I usually take the extra 4 seconds to type something like
    >
    > for ( $scalar ) # because I'm gonna do a bunch of pattern matches


    This is clearly a stylistic matter, so I should probably stay out of it,
    but...

    I really don't like comments like that. IMHO comments should explain
    algorithms and the purpose of the content of the code, not the syntax.
    If you don't think

    for ($scalar) {
    s/foo/bar/;
    s/baz/quux/;
    }

    is clear enough as it stands, I would say you should pick a clearer
    idiom rather than try to explain an unclear one with a comment.

    Of course, with 5.10 you can say

    given ($scalar) {
    s/foo/bar/;
    }

    without fear of misunderstanding (once everyone's familiar with 5.10 :)).

    Ben

    --
    All persons, living or dead, are entirely coincidental.
    Kurt Vonnegut
    Ben Morrow, Sep 16, 2008
    #18
  19. Tim McDaniel

    Tim McDaniel Guest

    In article <>,
    Peter J. Holzer <> wrote:
    >On 2008-09-14 16:08, Tim McDaniel <> wrote:
    >> I would do
    >> foreach my $_ (...)
    >> in the same circumstances that I would do
    >> foreach my $i (...)

    >
    >I would not want this.
    >
    > foreach (...) {
    > }
    >
    >already implicitely declares a new $_ for a defined scope.


    But they're different scopes: "my" is lexical scopes but the implicit
    declaration is dynamic scope. Dynamic Scope Considered Harmful.

    --
    Tim McDaniel; Reply-To:
    Tim McDaniel, Sep 16, 2008
    #19
  20. Tim McDaniel

    Tim McDaniel Guest

    In article <>,
    Martijn Lievaart <> wrote:
    >On Mon, 15 Sep 2008 00:23:46 +0200, Dr.Ruud wrote:
    >
    >> Tim McDaniel schreef:

    >
    >>> Thank you for the suggestions, though I'd like to mull over how
    >>> understandable "foreach" with one item would be to other readers.

    >
    >[ piggying here, didn't see the original ]
    >
    >As it's a fairly standard idiom,


    I've never seen
    for ($some_scalar) {...}
    While I've not read much Perl code written by others, I've not seen it
    in examples either. ... though when looking up something else in
    "man perlsyn", I see it's used there.

    It's also not intuitive to me. I'm used to foreach iterating over a
    list. My first thought was "you're guaranteed that there's no list.
    Why bother with a 'loop' that you know will run only once?"

    {
    local $_ = $some_scalar;
    ...
    }
    is equivalent even down to allowing "last" and "continue" blocks.

    While it's a few characters longer, it's also immediately clear what's
    going on. And with "my $_ = ...", it's got lexical scoping.

    --
    Tim McDaniel; Reply-To:
    Tim McDaniel, Sep 16, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Garrick
    Replies:
    0
    Views:
    545
    Garrick
    Sep 27, 2005
  2. Eric
    Replies:
    2
    Views:
    1,382
    Tommy
    Feb 13, 2004
  3. Jay Douglas
    Replies:
    4
    Views:
    704
    Jay Douglas
    Mar 6, 2004
  4. Matt
    Replies:
    0
    Views:
    322
  5. UJ

    Requiring SSL

    UJ, Nov 7, 2005, in forum: ASP .Net
    Replies:
    4
    Views:
    480
    =?Utf-8?B?Q3VydF9DIFtNVlBd?=
    Nov 7, 2005
Loading...

Share This Page