response.writeLine

[Roland Hall]

in message
: Roland Hall wrote:
: > "Bob Barrows [MVP]" wrote in message
: > : >> Dave Anderson wrote:
: >>> Bob Barrows [MVP] wrote:
: >>>> " ... when you call it without using the Call statement"
: >>>>
: >>>> Better?
: >>>
: >>> Sure. My observation was not offered merely for nit picking.
: >>
: >> OK, I see that now. Sorry
: >>
: >>> I am
: >>> curious to know why Call is so overlooked in here. We use it as a
: >>> shop standard *because* it requires parentheses. Among other thins,
: >>> this has the effect of making Sub calls stand out visually.
: >>>
: <snip>
: >>> This conversation has piqued my interest in one thing: Does the
: >>> parentheses = byref rule apply when using Call?
: >>
: >> I don't know. There's nothing in Eric's blog to suggest that there's
: >> any difference, but I'm going to have to try it and see. Be right
: >> back ...
: >
: > I thought there was even though it was used as a function.
: >
: > 3) Call a function or subroutine: Limit = UBound(MyArray)
:
: I don't understand the point: this line is not utilizing the Call
statement

This line was presented in reference to this question:
Do you also require it for calls to builtin methods being called as subs?

: > 3.2) An argument list for a subroutine call (or a function call with
: > no assignment) that uses the Call keyword must be surrounded by
: > parens: Call MySub(MyArg)
:
: Right, but this is saying that the entire list of arguments must be
: surrounded by one set of parentheses.
:
: Call MySub(arg1, arg2,...argN)
:
: What Dave is asking is whether surrounding each individual argument with
: parentheses (in addition to the parens surrounding the entire argument):
:
: Call MySub((arg1), (arg2),...argN)
:
: would force the arguments to be passed byval, which my tests showed to be
: the case.

Well, then I misunderstood the question. I thought he was referring to
functions requiring parens when being called byref, not byval as they relate
to builtin methods.

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

 

[Bob Barrows [MVP]]

This line was presented in reference to this question:
Do you also require it for calls to builtin methods being called as
subs?

Oh, OK. But I'm still puzzled. How does quoting a line from Eric's blog
answer the question I directed to Dave about his "shop standards"?

Oh! Wait, I see. My questions weren't clear. You thought I was asking a more
"generic" question. Never mind.

Bob Barrows

 

[Dave Anderson]

I never use it. because I have an aversion to doing unnecessary
typing.

I would find that easier to believe if you also confessed that you prefer
JScript to VBScript.

So you use it only for Sub calls? How about functions that are being
called as if they were subs? I.E., calls where the return value is
discarded without being assigned to anything?

I'm not sure I follow. Why would I return a value and not use it
(alternately - why would I use a Function to do a Sub's job)? I guess my
answer is yes, but vacuously. We always use parentheses for Function and Sub
calls, utilizing the Call keyword when neccessary.

Do you also require it for calls to builtin methods being called as
subs? E.G., do you require

Call MsgBox("test")

as opposed to

MsgBox "test"

The only built-in *Functions* I know of that do not return values are MsgBox
and InputBox, neither of which I use (and could not use in ASP anyway). In
every other case I can think of, I am calling the Function in order to use
the return value, so the Call keyword could not possibly apply.

As for VBScript Methods, if they do not return a value, then yes:

Call Err.Clear()

...So it appears that the behavior is the same when using Call.

That's interesting -- and the preferred behavior, IMO.

...the parens do indeed override the byref keyword
in the sub statement.

Also interesting. Also preferred.



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Bob Barrows [MVP]]

I would find that easier to believe if you also confessed that you
prefer JScript to VBScript.

Frankly, I find that Jscript forces more typing on me, but that's IMO, of
course. Of course, one of the reasons for this opinion is the intellisense
and autocomplete features in vi6. Forced to use another tool, I might change
my opinion.

I still find vbscript much easier to read and follow that jscript. I know
that the "End If"s etc are a source of derision among non-vb pundits, but I
find it easier to discern the end of nested blocks when reading vbscript as
opposed to:

.....
}
}
}

Of course there are exceptions (similar types of nested blocks are
problematic in vbscript as well as jscript)

But I'm sure this perceived difficulty will be diminished by usage.

I'm not sure I follow. Why would I return a value and not use it
(alternately - why would I use a Function to do a Sub's job)?

For the same reason that MS wrote msgbox the way they did... Why have two
methods that do the same thing? The user has the choice to use, or not use,
the returned value.

I guess
my answer is yes, but vacuously. We always use parentheses for
Function and Sub calls, utilizing the Call keyword when neccessary.



The only built-in *Functions* I know of that do not return values are

Huh? MsgBox is a builtin method that can be called as either a function
(when not discarding the returned value):

if msgbox("Yes or No?",vbyesno) then

or a sub

msgbox "test"

But I guess you've answered my question. You would use Call for the latter.

Bob

PS. Oh, wait. I see you point. Yes, MsgBox and InputBox are functions.

 

[Dave Anderson]

True, also for sub's, but sub's are a not very different from
functions without a return value.

Except, as Bob points alludes, that they require less typing. To put this
back into context, retrace the thread to this Bob Barrows posting:

That was the whole point of bringing up the Call Statement.

False, in the sense of my argument, that real statements, either
native VBscript or inherited from the Server object, cannot be called
with "call".

I was rebutting this: "only for real functions". Is a Sub a real Function?
No - it does not return a value. Yet it can be called with parentheses.

I agree. You should use the proper case for [Write].

Why?

Correctness is reason enough for proper capitalization. Call it "respect for
the reader" if you prefer.

Not in my posting, as I was talking about ASP-VBscript.

Again, let's put it back into context. Your

was incorrectly based on inferences to VBScript Sub and Function handling. I
reiterate: The Response Object has nothing to do with VBScript whatsoever.
Nor JScript. It is an object exposed to the scripting engine, and its
behavior accordingly follows different rules altogether.

Note that all of these are legal:

VBScript ====================
Response.Write "Hello World"
Response.Write("Hello World")
Call Response.Write("Hello World")

JScript ====================
Response.Write("Hello World")
Response.write("Hello World")
Response.WrItE("Hello World")

Note that JScript requires proper case for the Response Object, but not for
its methods. This diverges from the JScript behavior with native JScript
objects.

May very well be generalizing, but not in my posting, as I
was talking about VBscript.

Once you used the Response Object, you were outside VBScript.



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Dave Anderson]

Frankly, I find that Jscript forces more typing on me, but that's
IMO, of course. Of course, one of the reasons for this opinion is the
intellisense and autocomplete features in vi6. Forced to use another
tool, I might change my opinion.

I'm not sure I understand this, as VI6 has intellisense in JScript as
well...

But I'm sure this perceived difficulty will be diminished by usage.

Agreed.



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Evertjan.]

Dave Anderson wrote on 14 jan 2005 in
microsoft.public.inetserver.asp.general:

VBScript ====================
Response.Write "Hello World"
Response.Write("Hello World")
Call Response.Write("Hello World")

You forget that also legal here is:

Response.Write (("Hello World"))

Response.Write ((("Hello World")))

and

x = (("Hello World")):RespoNSe.wriTE x

Once you used the Response Object, you were outside VBScript.

No Dave, you are not, with regard to the working of the argument.

The argument of Response.Write is processed by vbscript.

The argument of Response.Write in vbscript is x as in:

Response.Write x

Making the argument x an unneccessary complex expression
is perfectly legal end perfectly silly.

 

[Dave Anderson]

You forget that also legal here is:

Response.Write (("Hello World"))

Response.Write ((("Hello World")))

and

x = (("Hello World")):RespoNSe.wriTE x

You have completely missed the point. A native VBScript Function or Sub does
NOT produce the same behavior as the methods of the Response Object. To see
what I mean, consider the following:

Sub Output(x)
Response.Write(x)
End Sub

You cannot call this all three ways you can call the Write method of the
Response Object:

Output "Hello World" ' OK
Output("Hello World") ' Fails
Call Output("Hello World") ' OK

The reason you *CAN* with Response.Write is that the Response Object is not
part of VBScript. Until you understand that, there is no point in continuing
this discussion.


--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Evertjan.]

Dave Anderson wrote on 15 jan 2005 in
microsoft.public.inetserver.asp.general:

You have completely missed the point. A native VBScript Function or
Sub does NOT produce the same behavior as the methods of the Response
Object. To see what I mean, consider the following:

"The" point is nice, since my point was NOT to have () around arguments
of statements or functions used as statements. Native or not was only
your point.

Sub Output(x)
Response.Write(x)
End Sub

You cannot call this all three ways you can call the Write method of
the Response Object:

Output "Hello World" ' OK
Output("Hello World") ' Fails
Call Output("Hello World") ' OK

On my system [XPpro] this works fine:

<%
Output "1"
Output("2")
Call Output("3")

sub output(x)
response.write x
end sub
%>

returns: 123

The reason you *CAN* with Response.Write is that the Response Object
is not part of VBScript.

As tested above, you must be in error.

Until you understand that, there is no point
in continuing this discussion.

Why?
Just the opposite:
Having a discussion while agreeing on everything seems pointless to me.
Remember you came up with this point answering me in this
discussion/thread, and if you don't like it, you are off course free not
to answer.

But I don't accept you setting conditions for me, irrespective if you are
in error or not [even though you are incidentally]

 

[Dave Anderson]

"The" point is nice, since my point was NOT to have () around
arguments of statements or functions used as statements. Native or
not was only your point.

Allow me to respond to this in a moment.

As tested above, you must be in error.

I was in error. The point WRT JScript stands on its own merits, however. The
behavior transcends the language because the object is not part of the
language.

Back to VBScript and Response.Write(). I regret that response, as my memory
was obviously no substitute for testing code.

Your point may indeed have been avoiding parentheses in VBScript, and that's
a perfectly acceptible point upon which to differ. In this case, I disagree
with you. I personally think the presence of parentheses makes code more
readable. That this happens to be our shop standard strongly suggests to me
that I am not the only one.



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Evertjan.]

Dave Anderson wrote on 20 jan 2005 in
microsoft.public.inetserver.asp.general:

Your point may indeed have been avoiding parentheses in VBScript, and
that's a perfectly acceptible point upon which to differ. In this
case, I disagree with you. I personally think the presence of
parentheses makes code more readable.

That is not a subtitute for a principally wrong suggestion that is given by
this habit, that the parentheses are part of the [pseudo] statement, as
they are only a complicated way of describing the parameter expression.

I hope you agree this wrong suggestion is a bad thing in a tutorial
environment, such as this NG.

I your production environment, next to the inevitable extra cpu cycles
introduced in a scripting/interpreting sense [perhaps the parentheses are
deleted by optimizing compiler code?]

That this happens to be our shop
standard strongly suggests to me that I am not the only one.

It only suggests to me this shop standard is not educational for new
programmers. Shop standards are no proof of correctnes as such.

 

[Dave Anderson]

That is not a subtitute for a principally wrong suggestion that is
given by this habit, that the parentheses are part of the [pseudo]
statement, as they are only a complicated way of describing the
parameter expression.

The parentheses are not superfluous. The Call Statement makes them
*required*. As the Call Statement is part of the Language, it isn't
pseudo-anything.

I your production environment, next to the inevitable extra cpu cycles
introduced in a scripting/interpreting sense [perhaps the parentheses
are deleted by optimizing compiler code?]

This is a fictional concern. There are plenty of good practices that consume
CPU cycles. That does not make them bad practices. CPU cycles are cheap
compared to developer hours.

Following your line of reasoning, we should not use indentation or comments,
since they consume disk space. Good heavens.


--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Evertjan.]

Dave Anderson wrote on 21 jan 2005 in
microsoft.public.inetserver.asp.general:

That is not a subtitute for a principally wrong suggestion that is
given by this habit, that the parentheses are part of the [pseudo]
statement, as they are only a complicated way of describing the
parameter expression.

The parentheses are not superfluous. The Call Statement makes them
*required*. As the Call Statement is part of the Language, it isn't
pseudo-anything.

No, you are not listening to my argument:

The call statement makes it a [pseudo]function or [pseudo]sub, where it
must adhere to the rules of the use of a function/sub.

The [pseudo]statement should adhere to the statement rules, certainly in
an tutorial sense.

if you use [using two vbscript external examples]:

Response.Write("hello world")

it would be reasonable to use:

Conn.Execute(SQLstring , , 1)

and not understand the generated error.

I your production environment, next to the inevitable extra cpu
cycles introduced in a scripting/interpreting sense [perhaps the
parentheses are deleted by optimizing compiler code?]

This is a fictional concern. There are plenty of good practices that
consume CPU cycles. That does not make them bad practices. CPU cycles
are cheap compared to developer hours.

Certainly, but using extra cpu cycles for a bad habit only makes it a
slightly worse habit.

Following your line of reasoning, we should not use indentation or
comments, since they consume disk space. Good heavens.

In this NG the concern should not be being in cyberheaven, but in showing
the way to sound coding heaven.

Introdusing the above error by association,
like using Conn.Execute(SQLstring , , 1),
ia not showing the right direction.

 

[Dave Anderson]

The call statement makes it a [pseudo]function or [pseudo]sub, where
it must adhere to the rules of the use of a function/sub.

You can't use the Call statement unless it *IS* a function or sub[1]. What
on earth is your distinction? All you have contrived is a pseudo-name for
something that already has a name.

if you use [using two vbscript external examples]:

Response.Write("hello world")

it would be reasonable to use:

Conn.Execute(SQLstring , , 1)

and not understand the generated error.

Just as this:

RS = Conn.Execute(SQLString)

could lead to the belief that this is reasonable:

Conn.Execute(SQLString)

As with any language, OF COURSE you need to learn the rules. But please
don't pretend that the above won't generate a perfectly understandable error
message. Are you claiming you have never used (or failed to use) parentheses
ever?

Perhaps you are claiming that the "Cannot use parentheses when calling a
Sub" error message has proved too difficult for you to overcome, and by
extension, so it must be for the rest of the world. In that case, I concede
the point.

In this NG the concern should not be being in cyberheaven, but in
showing the way to sound coding heaven.

Sound coding is much more than CPU cycles. If "no parentheses" were such a
great idea to begin with, don't you suppose it would have carried over to
VB.NET?

Introdusing the above error by association,
like using Conn.Execute(SQLstring , , 1),
ia not showing the right direction.

Let's get this straight. Calling a sub with parentheses without using the
Call Statement causes an error. We all know that. But you have done nothing
to show that one solution (learning to use the Call Statement) introduces
more coding errors than another (learning to leave off parentheses).



[1] If you want to play semantics and charge that method is neither, fine.
But as with Functions and Subs, the rules are the same. You can use the Call
Statement (or assignment) together with parentheses, or omit both.


--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Evertjan.]

Dave Anderson wrote on 21 jan 2005 in
microsoft.public.inetserver.asp.general:

The call statement makes it a [pseudo]function or [pseudo]sub, where
it must adhere to the rules of the use of a function/sub.

You can't use the Call statement unless it *IS* a function or sub[1].
What on earth is your distinction? All you have contrived is a
pseudo-name for something that already has a name.

Since you don't seem to know what a statement is, and what a function, I
won't cover the rest of your response.

A statement in Basic dialects is a command.
It has to start on a new logical code line.
No code execution is possible without a statement.
A statement cannot return anything.
A new code line can only start with (1) a statement
or (2) a default statement
or (3) be empty.

[The remark statement Rem or ' is just a statement.]
[A line can contain several logical lines separated with a colon [:].


Modern Basics, like vbScript have two default statements:

1 the Let [=asignment] statement has been THE default statement for so
long, that the "let" in itself is no logger available. However theValue =
17 is not a statement by itself in Basic terms, because the underlying
asignment code is that belonging to the original let-statement.

2 The statementized function or sub. This is a defaulting of the call
statement, where the function/sub aquires the habits of a statement,
which I call [pseudo]statement, because it is realy a function/sub.

A function in sensu originalis has to return a value, and could at first,
in historical basic sense, only be used in an expression. A sub
[subroutine] was necessary for callable routines, not having a result.
These subroutines and functuons, not being statements, needed the call
statement for execution [outside an expresion in the case of a function].

An expression, btw, is a string of code that can be parced for a result
value.

========================================

Hereby I rest my case, not wanting to take more time explaining the
principles of basic Basic syntax to you.

Dave, I will not answer a possible reply.

 

[Dave Anderson]

The call statement makes it a [pseudo]function or [pseudo]sub, where
it must adhere to the rules of the use of a function/sub.

You can't use the Call statement unless it *IS* a function or sub[1].
What on earth is your distinction? All you have contrived is a
pseudo-name for something that already has a name.

Since you don't seem to know what a statement is, and what a
function, I won't cover the rest of your response.

You appear to be confusing my use of the term "Call Statement" with some
assertion that I am advocating "calling a statement". You are wrong. I am
using it exactly as Microsoft does:
http://msdn.microsoft.com/library/en-us/script56/html/vsstmcall.asp

Given that */CORRECT/* context, the rest of your post makes no sense, as
yours depends on misinterpreting mine.


--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.