Logical On

[Cor]

Hi group,

A question to the group, would it not be for a lot of the users better when
there was beside "Option strict on" an "Option logical Strict on".

I was automaticaly writting Textbox1.text = 0.tostring. I know what it has
to be, but I did this automaticly.

I find this crazy, it cannot be something else than a string, so the
compiler must have to find this very easy, but for the puritains, than that
option, than they can set it off.

I think that for a lot of VB users this kind of things is more important
than operator overloading or other more C behaviour (I understand a lot of
sophisticated users want it, so I would not say, don't let them make it, but
I think that this "Option logical strict on" would get 90% of the users
while operator overloading maybe 10%).

Just a thougth?

Cor

[hexathioorthooxalate]

From my perspective what you are saying is that a numeric literal is an
object and therefore has a set of methods etc. These methods should show up
as they do for all other objects in the IDE etc. You are mooting a new
compiler directive to enforce formal casting/conversion as you put it for
the "Puritans" - basically when the compiler directive is present,
conversion of types for all objects is performed explicitly (through methods
like toString()) and not implicitly.

If I have understood this correctly, doesn't the following code snippet
demonstrate this (albeit without an additional compiler directive).

Dim cmp As String = "fred"
If "".CompareTo(cm p)=0 .....

vs.

If cmp.CompareTo(" ")=0 ....
Both string comparisons being logically equivalent but the former drawing
attention to the fact that a String is an object.

But here, the object is a string, not a numeric literal. So, you are wanting
to make things consistent with full IDE support etc for the former (you type
in 0. and up come a set of methods etc) and more stringent compilation when
the compiler directive is present.

If so, what is 0, a Long, Integer, Float etc, and what set of default
methods are available (other than toString()) when methods for a numeric
literal are accessed through dot notation? And, most importantly, wouldn't
they be different depending on the numeric literal type and, if so, how
would the compiler know?

I look forward to reading followup posts in this thread. But yes, I am
convinced what you are proposing, if it could be implemented, would be of
more general use than operator overloading and the like.

Hexathioorthoox alate
"Cor" <no*@non.com> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..

Hi group,

A question to the group, would it not be for a lot of the users better when there was beside "Option strict on" an "Option logical Strict on".

I was automaticaly writting Textbox1.text = 0.tostring. I know what it has
to be, but I did this automaticly.

I find this crazy, it cannot be something else than a string, so the
compiler must have to find this very easy, but for the puritains, than that option, than they can set it off.

I think that for a lot of VB users this kind of things is more important
than operator overloading or other more C behaviour (I understand a lot of
sophisticated users want it, so I would not say, don't let them make it, but I think that this "Option logical strict on" would get 90% of the users
while operator overloading maybe 10%).

Just a thougth?

Cor

[Fergus Cooney]

Hiya Hex,

I'm not sure what you're saying, but I think what Cor is saying is that

Option Strict On
Dim S as String
S = 3 'Compiler error

is Option Strict going a bit too far and that
S = 3
should do an implicit conversion (not late-bound) because "what else
<could> it be?".

Is that what you understood and were agreeing with? I couldn't really tell,
I'm afraid.

Regards,
Fergus

--
(Please ignore this - there's a feud going on)
=============== =============== =============== =====
Quote of the day
Herfried:
I don't need/want human interaction.
=============== =============== =============== =====

[Herfried K. Wagner [MVP]]

* "Cor" <no*@non.com> scripsit:

A question to the group, would it not be for a lot of the users better when
there was beside "Option strict on" an "Option logical Strict on".

I was automaticaly writting Textbox1.text = 0.tostring. I know what it has
to be, but I did this automaticly.

I find this crazy, it cannot be something else than a string, so the
compiler must have to find this very easy, but for the puritains, than that
option, than they can set it off.

You would like ro skip the 'ToString()' part with 'Option Strict On'?

--
Herfried K. Wagner
MVP · VB Classic, VB.NET
<http://www.mvps.org/dotnet>

[Herfried K. Wagner [MVP]]

* "Fergus Cooney" <fi****@post.co m> scripsit:

I'm not sure what you're saying, but I think what Cor is saying is that

Option Strict On
Dim S as String
S = 3 'Compiler error

is Option Strict going a bit too far and that
S = 3
should do an implicit conversion (not late-bound) because "what else
<could> it be?".

The next time somebody wants to assign an object of type 'Bla'. Should
the implicit conversion call its 'ToString' method too? Yes -- there is
only one way to assign an object to a string: get its string
representation.

IMO that doesn't make sense because it will cause a lot of ambiguity.

--
Herfried K. Wagner
MVP · VB Classic, VB.NET
<http://www.mvps.org/dotnet>

[Herfried K. Wagner [MVP]]

* "hexathioorthoo xalate" <ru***@REMOVESP AM.clara.co.uk> scripsit:

From my perspective what you are saying is that a numeric literal is an
object and therefore has a set of methods etc. These methods should show up
as they do for all other objects in the IDE etc. You are mooting a new
compiler directive to enforce formal casting/conversion as you put it for
the "Puritans" - basically when the compiler directive is present,
conversion of types for all objects is performed explicitly (through methods
like toString()) and not implicitly.

If I have understood this correctly, doesn't the following code snippet
demonstrate this (albeit without an additional compiler directive).

Dim cmp As String = "fred"
If "".CompareTo(cm p)=0 .....

vs.

If cmp.CompareTo(" ")=0 ....
I think Cor would prefer something like:

\\\
If 8.CompareTo("8" ) = 0 Then...
///
If so, what is 0, a Long, Integer, Float etc, and what set of default
methods are available (other than toString()) when methods for a numeric
literal are accessed through dot notation? And, most importantly, wouldn't
they be different depending on the numeric literal type and, if so, how
would the compiler know?

AFAIU Cor would first call the 'ToString' method implicitly (at compile
time) and then call the method of the string object.

--
Herfried K. Wagner
MVP · VB Classic, VB.NET
<http://www.mvps.org/dotnet>

[Cor]

Herfried,

An IDE or compiler or whatever name you give must have use some
intelligence.
It is a tool for a programmer, not other than Word is a tool for someone who
writes a letter.

dim a as string = 0 can only be a one position string with the unicode 0.

But I find that Option Strict On has a lot of good things when it is not so
predictable.

Therefore I think an Option Logical Strict On, that does an implicit
conversion (not late-bound) because "what else <could> it be?" (as Fergus
said it) would be a greath benefit for the VB.net language.

Cor

[Herfried K. Wagner [MVP]]

* "Cor" <no*@non.com> scripsit:

An IDE or compiler or whatever name you give must have use some
intelligence.
ACK. But the actions must be forseeable to the programmer. There must
not be any ambiguities.
It is a tool for a programmer, not other than Word is a tool for someone who
writes a letter.
100% ACK.
dim a as string = 0 can only be a one position string with the unicode 0.
Would you expect a 'NullChar' or the string containing "0"?
Therefore I think an Option Logical Strict On, that does an implicit
conversion (not late-bound) because "what else <could> it be?" (as Fergus
said it) would be a greath benefit for the VB.net language.

I think it won't be a benefit, but that's my personal opinion.

--
Herfried K. Wagner
MVP · VB Classic, VB.NET
<http://www.mvps.org/dotnet>

[Cor]

Hi Herfried,

Would you expect a 'NullChar' or the string containing "0"?

No never, I would impliciet writing for that

dim a as string = nothing 'why else exist that

and I thougth a "0" is a unicode 0, if I am wrong, than is that beside this
discussion.

But this are just examples of course.

And I thought that afterwards, when the IDE does it and not the compiler,
it can even be automicly when you leave the row. And then:
dim a as string = 0 becomes automaticly dim a as string = "0"

When you then want to change it why not.
For me it is something the same as setting the cases automaticly.

Cor

[Herfried K. Wagner [MVP]]

* "Cor" <no*@non.com> scripsit:

Would you expect a 'NullChar' or the string containing "0"?
No never, I would impliciet writing for that

dim a as string = nothing 'why else exist that

and I thougth a "0" is a unicode 0, if I am wrong, than is that beside this
discussion.

You implicitly want to call the 'ToString' method. But here is one
"problem":

Let's write this:

\\\
Dim s As String = 22.4
///

On a German language system 'ToString()' will return "22,4", on an
English language system "22.4". This would occur if the conversion is
done at runtime, but which conversion should be done at compile time?
And I thought that afterwards, when the IDE does it and not the compiler,
it can even be automicly when you leave the row. And then:
dim a as string = 0 becomes automaticly dim a as string = "0"

Ah... you only want an "improvemen t" of the IDE?

--
Herfried K. Wagner
MVP · VB Classic, VB.NET
<http://www.mvps.org/dotnet>