- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
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:
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.
Admin
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
Admin
ahh now you see, your pathetic attempts at creating a third level directory have failed young tacos
Admin
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.
Admin
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:
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.
Admin
You do, however, then go make a long called "integer". :P "whole" might be a better name to avoid the confusing synonym...
Admin
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.
Admin
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.
Admin
Most of the times it will be an Integer !
Admin
It's actually yes on the Pascal (note I didn't say "Object Pascal" or "Delphi" here. :-)
I'm pretty aware of that, since Delphi has been my primary development tool since version 1 was released. :-)
Admin
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.
Admin
Congratulations on winning the "WTF Comment of the day" award!
What the heck are you talking about?
Admin
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?
Admin
You really want Hungarian in the code? There. :)
Admin
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...
Admin
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.
Admin
Hear bloody hear! I don't personally like VB or anything like it, but I couldn't agree more with this one
Admin
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,
Or, 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: 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.