• Perry Pederson (unregistered) in reply to Shaun
    Shaun:
    Jojosh_the_Pi:
    MaW:
    I like my languages with lots of type information in the syntax. The very thought of a function which doesn't have an explicit return type is quite awful, which doesn't help me out when I'm writing Perl.

    Hooray for the Variant type!

    As a young programmer, for about 2 weeks, I thought that was a pretty cool feature of VB6. Never touched Variants again.

    Maybe someone who's used VB more could tell of a good reason to use it. (JeffS?)

    There is NEVER a good reason to use variants. Okay, so everything in Classic ASP is a variant, but that is why I will never touch it again (unless there is major $ involved.)

    Oh, Au Contraire on the "There is NEVER a good reason to use variants":

    If you are calling a VB6 COM object from an ASP (not .NET) web page, all 'byref' variables being passed to the COM object need to be defined as variant parameters in the VB6 code.

    Example to increment a 'byref' variable by one from a call to a COM object from an asp page:

    asp code:

    dim valueToIncrement
    dim incrementValueBy
    dim comObject
    
    ' Initialize
    valueToIncrement = 0
    incrementValueBy = 1
    
    set comObject = Server.CreateObject("MyVB6App.MyVB6Class")
    
    comObject.Increment(valueToChange, incrementValueBy);
    
    set comObject = nothing  ' dispose the COM object
    

    Code in VB6 COM object: Note the parameter types.

    Public Sub Increment(byref valueToChange as variant, incrementValueBy as Integer)

    valueToChange = valueToChange + incrementValueBy

    end Sub

    If the (byref) 'valueToChange' was defined as an integer insted of a variant, the asp page will throw a type mismatch error when it attempts to call the VB6 COM object.

    Variants are manditory to pass byref parameters from an asp page to a VB6 COM object.

    And to the VB-haters: Get a life. I'm writing C# client applications that call a legacy app written in VB6.0, and VB does the job just fine. Sure, if we had to start all over I'd pick C# or Java, but those languages weren't mature enough when the legacy app was being developed. It's way too risky to think of a rewrite just for the sake of rewriting when the app runs perfectly well and is maintainable.

  • utunga (unregistered)

    wait.. Alex poses this zen question..

    link = "<a href=" & RootLevel() & "/foo/bar.asp>bar"

    for which the response, already given, is

    link = bar

    but, wait, young grasshopper, surely the question you should be asking is:

    link = "<a href=" & RootLevel()& "/bzz/foo/bar/bar.asp>bar"

    and would that be

    link = bar

    or, in otherwords, in non-moon bat language

    link = bar

    and.. uh.. is that just not totally what the wtf erm, is?

    or am i too drunk and should be prevented from operating a heavy keyboard around machinery

  • utunga (unregistered) in reply to utunga

    ahh now you see, your pathetic attempts at creating a third level directory have failed young tacos

  • Le Poete (unregistered) in reply to Perry Pederson
    Perry Pederson:
    Shaun:
    Jojosh_the_Pi:
    MaW:
    I like my languages with lots of type information in the syntax. The very thought of a function which doesn't have an explicit return type is quite awful, which doesn't help me out when I'm writing Perl.

    Hooray for the Variant type!

    As a young programmer, for about 2 weeks, I thought that was a pretty cool feature of VB6. Never touched Variants again.

    Maybe someone who's used VB more could tell of a good reason to use it. (JeffS?)

    There is NEVER a good reason to use variants. Okay, so everything in Classic ASP is a variant, but that is why I will never touch it again (unless there is major $ involved.)

    Oh, Au Contraire on the "There is NEVER a good reason to use variants":

    If you are calling a VB6 COM object from an ASP (not .NET) web page, all 'byref' variables being passed to the COM object need to be defined as variant parameters in the VB6 code.

    Example to increment a 'byref' variable by one from a call to a COM object from an asp page:

    asp code:

    dim valueToIncrement
    dim incrementValueBy
    dim comObject
    
    ' Initialize
    valueToIncrement = 0
    incrementValueBy = 1
    
    set comObject = Server.CreateObject("MyVB6App.MyVB6Class")
    
    comObject.Increment(valueToChange, incrementValueBy);
    
    set comObject = nothing  ' dispose the COM object
    

    Code in VB6 COM object: Note the parameter types.

    Public Sub Increment(byref valueToChange as variant, incrementValueBy as Integer)

    valueToChange = valueToChange + incrementValueBy

    end Sub

    If the (byref) 'valueToChange' was defined as an integer insted of a variant, the asp page will throw a type mismatch error when it attempts to call the VB6 COM object.

    Variants are manditory to pass byref parameters from an asp page to a VB6 COM object.

    And to the VB-haters: Get a life. I'm writing C# client applications that call a legacy app written in VB6.0, and VB does the job just fine. Sure, if we had to start all over I'd pick C# or Java, but those languages weren't mature enough when the legacy app was being developed. It's way too risky to think of a rewrite just for the sake of rewriting when the app runs perfectly well and is maintainable.

    You don't need to declare you VB6 parameters as variant when called from ASP. Ever heard of casting? ASP does have casting functions like CInt, CLng, CStr, etc... to cast its variant variables to the correct type before calling an external function. And that is often a required step when assigning ASP variables to ADODB.Command parameters and I don't think they would rewrite the ADODB object with variant parameters.

  • Helio (unregistered) in reply to chrismcb
    chrismcb:
    I don't understand why people dislike hungarian in a well typed language?

    So when you are reading the code, in this well typed language, and you see a variable "foo." What type is it?

    If you ask me, the reason to "hungarianize" (or not) your variables lies not in whether they are strong typed, but in whether there are other, easier hints on their types.

    Most languages, when properly used, will allow you to write systems composed of invokation units (functions, methods, etc) that never span over your editor's window. When a variable's entire lifespan remains visible on screen, there is little need to make its type explicit on its name.

    For example, in the code snippet below:

    String convert(String amount)
    {
      if (amount == null)
        throw new IllegalArgumentException(
          "Amount string must not be null");
    
      String trimmed = amount.trim();
      if ("".equals(trimmed))
        throw new IllegalArgumentException(
          "Amount string must not be empty");
    
      long value = Long.parseLong(trimmed);
      long integer = value / 100;
      long fraction = value % 100;
      return integer + "." + (fraction < 9 ? "0" : "") + fraction;
    }
    

    There is no need to name "amount" something like "strAmount"; its declaration remains visible for as long as it is used. Nor is it needed to change "fraction" to "lngFraction", since the variable is only used right after it is defined.

  • (cs) in reply to Helio
    Helio:
    chrismcb:
    I don't understand why people dislike hungarian in a well typed language?

    So when you are reading the code, in this well typed language, and you see a variable "foo." What type is it?

    If you ask me, the reason to "hungarianize" (or not) your variables lies not in whether they are strong typed, but in whether there are other, easier hints on their types.

    Most languages, when properly used, will allow you to write systems composed of invokation units (functions, methods, etc) that never span over your editor's window. When a variable's entire lifespan remains visible on screen, there is little need to make its type explicit on its name.

    For example, in the code snippet below:

    String convert(String amount)
    {
      if (amount == null)
        throw new IllegalArgumentException(
          "Amount string must not be null");
    
      String trimmed = amount.trim();
      if ("".equals(trimmed))
        throw new IllegalArgumentException(
          "Amount string must not be empty");
    
      long value = Long.parseLong(trimmed);
      long integer = value / 100;
      long fraction = value % 100;
      return integer + "." + (fraction < 9 ? "0" : "") + fraction;
    }
    

    There is no need to name "amount" something like "strAmount"; its declaration remains visible for as long as it is used. Nor is it needed to change "fraction" to "lngFraction", since the variable is only used right after it is defined.

    You do, however, then go make a long called "integer". :P "whole" might be a better name to avoid the confusing synonym...

  • dkf (unregistered) in reply to The MAZZTer
    The MAZZTer:
    You do, however, then go make a long called "integer". :P "whole" might be a better name to avoid the confusing synonym...
    Also, calling an integral value "fraction" is deeply strange; "remainder" or "mod100" would have been far better.

    For longer code, I prefer type/usage suffixes. I think they read more naturally than a hungarian prefix hiccough.

    I try very hard to avoid (non-constant) global values, both because they're potentially stamping on the toes of much code, and because they're usually bottlenecks (or worse) for threaded programs.

  • Helio (unregistered) in reply to The MAZZTer
    The MAZZTer:
    You do, however, then go make a long called "integer". :P "whole" might be a better name to avoid the confusing synonym...

    Yes. I usually give more thought than that to my variable names, although a long is an integer... mathematically speaking. Then again, my point is that when you code to short invokation units, the names you use are often secondary -- good names will certainly contribute to make the code clearer, but you'll generally be able to figure out the purpose of even badly named variables.

  • Nikolas (unregistered) in reply to chrismcb
    chrismcb:

    I don't understand why people dislike hungarian in a well typed language?

    So when you are reading the code, in this well typed language, and you see a variable "foo." What type is it?

    Most of the times it will be an Integer !

  • (cs) in reply to Freddy Bob
    Freddy Bob:
    Yes and no on the Pascal, hence my question.

    It's actually yes on the Pascal (note I didn't say "Object Pascal" or "Delphi" here. :-)

    Freddy Bob:
    Delphi (Object Pascal) made this a little clearer by introducing an implicit Result variable. Assigning to that set the return value and reading from it got the 'current' value for the function without causing recursion.

    I'm pretty aware of that, since Delphi has been my primary development tool since version 1 was released. :-)

  • (cs) in reply to Shaun
    Shaun:
    There is NEVER a good reason to use variants. Okay, so everything in Classic ASP is a variant, but that is why I will never touch it again (unless there is major $ involved.)

    There's a reason for the old saying "Never say never", ignorant youngster. :-)

    Variants are actually required for dealing with COM objects on the Windows platform for cross-language compatibility reasons. COM is one place there's a good reason to use variants, and therefore proof positive that your comment doesn't hold water.

  • (cs) in reply to Le Poete
    Le Poete:
    You don't need to declare you VB6 parameters as variant when called from ASP. Ever heard of casting? ASP does have casting functions like CInt, CLng, CStr, etc... to cast its variant variables to the correct type before calling an external function. And that is often a required step when assigning ASP variables to ADODB.Command parameters and I don't think they would rewrite the ADODB object with variant parameters.

    Congratulations on winning the "WTF Comment of the day" award!

    What the heck are you talking about?

  • Andrew (unregistered) in reply to Freddy Bob
    Freddy Bob:
    KenW:
    Freddy Bob:
    for iLoop = 1 to iCount RootLevel = RootLevel & "../" next
    Forgive my ignorance here (or bless it) but is that recursing? Inside a loop?

    Nope. In VB(A/6), that's how you assign a return value to a function. Used to be that way in Pascal, too.

    Yes and no on the Pascal, hence my question. FunctionName := 'Some string'; sets the return value but FunctionName := FunctionName + 'some string'; or SomeVariable := FunctionName + 'some string'; from within FunctionName would cause a recurse (and a curse again).

    To get the same effect without the recursion would need. SomeVar := 'A'; SomeVar := SomeVar + 'B'; SomeVar := SomeVar + 'C'; FunctionName := SomeVar;

    Delphi (Object Pascal) made this a little clearer by introducing an implicit Result variable. Assigning to that set the return value and reading from it got the 'current' value for the function without causing recursion.

    Pascal recursion, as described here, is still very sensible. A left-hand-side function name is a variable, and gets assigned a value. The right-hand-side function name is a recursive function call, and produces a value. This is no stranger than scalar assignment.

    x := x + 1; {* scalar assignment } FunctionName := FunctionName + 1; { Recursive function assignment *}

    No one is surprised that the 'x' on the right is a value contributing to the 'x' on the left. Why is a function name any different?

  • anon (unregistered) in reply to Helio
    chrismcb:
    I don't understand why people dislike hungarian in a well typed language?

    You really want Hungarian in the code? There. :)

    String atvalt(String mennyiseg)
    {
      if (mennyiseg == null)
        throw new IllegalArgumentException(
          "Mennyiseg string nem lehet null");
    
      String kurtitott = mennyiseg.trim();
      if ("".equals(kurtitott))
        throw new IllegalArgumentException(
          "Mennyiseg string nem lehet ures");
    
      long ertek = Long.parseLong(kurtitott);
      long egesz = ertek / 100;
      long maradek = ertek % 100;
      return egesz + "." + (maradek < 9 ? "0" : "") + maradek;
    }
    
  • (cs) in reply to anon
    anon:

    You really want Hungarian in the code? There. :)

    String atvalt(String mennyiseg)
    
    

    En is neha hasznalom magyar mikor irom a szamitogepen.

    I always get a kick out of the Hungarian word for "computer", namely "szamitogep", literally "counting machine". This is a szamitogep...

  • Hill (unregistered) in reply to stevekj
    stevekj:
    anon:

    You really want Hungarian in the code? There. :)

    String atvalt(String mennyiseg)
    
    

    En is neha hasznalom magyar mikor irom a szamitogepen.

    I always get a kick out of the Hungarian word for "computer", namely "szamitogep", literally "counting machine". This is a szamitogep...

    Okay, those posters are pretty cool. But WTF is up with the bizarre combinatoric explosion of purchasing options?? "Click here to buy One Curta Poster and One HP Poster if you're International" etc. That's quite strange.

    Hill cap -> craaazy. I'll say.

  • Simmo (unregistered) in reply to Perry Pederson
    Perry Pederson:

    And to the VB-haters: Get a life. I'm writing C# client applications that call a legacy app written in VB6.0, and VB does the job just fine. Sure, if we had to start all over I'd pick C# or Java, but those languages weren't mature enough when the legacy app was being developed. It's way too risky to think of a rewrite just for the sake of rewriting when the app runs perfectly well and is maintainable.

    Hear bloody hear! I don't personally like VB or anything like it, but I couldn't agree more with this one

  • steve (unregistered)

    It's (fairly) obvious what this code does, and why someone thought they needed it.

    Suppose your page is named /foo/bar/index.asp It needs to include /inc/global.css

    The proper way to do this is, of course,

    <link rel="stylesheet" type="text/css" href="/inc/global.css" />
    Or,
    <base href="http://example.org/" />
    <link rel="stylesheet" type="text/css" href="inc/global.css" />
    Clueless ASP programmer doesn't know any of this, but recalls that "../" takes you to the parent directory. So, obviously the solution is a function to return "../../" - the correct number of ../ sequences to get you from "/foo/bar" to "/". The actual HTML that they generate looks like:
    <link rel="stylesheet" type="text/css" href="../../inc/global.css" />
    However, the biggest WTF is not that they're doing this; as stupid as it is, it works just fine. The "what could go wrong here" has nothing to do with that code.

    I'm left wondering, is their server configured correctly? Because although it might make me ask "WTF", there's really absolutely nothing wrong with a relative URL like "../../inc/global.css". It may be the "wrong way" to do it, but it shouldn't break anything.

    The simple fact of the matter is that their server had better be configured to give me an error page if I ask for "http://example.org/../". A malicious user could type that into the address bar perfectly well without any help from server-side code. Fixing the code won't fix the vulnerability, if one exists, because it's a setting in the server config, not the code.

  • KarinanoRm (unregistered)
    Comment held for moderation.

Leave a comment on “Back That URL Up”

Log In or post as a guest

Replying to comment #130927:

« Return to Article