constant references

[Zytan]

Are they possible? I am passing in a large array of Bytes, thus I
don't want to use ByVal.

Zytan

[Branco Medeiros]

Zytan wrote:

Are they possible? I am passing in a large array of Bytes, thus I
don't want to use ByVal.

When you pass an array by value, there's no copy of the array
contents, just of the array *variable*.

HTH.

Regards,

Branco,

[Zytan]

Branco,

I had actually typed up a lengthy post asking about that, as well, and
Google Groups did something strange, and loaded a new page, erasing
the whole thing (one major flaw of web apps -- load a new page by
accident, and say goodbye to all your work), so I forgot about it, and
just asked the basic question.

I was going to ask if array variables are like C++ arrays (i.e. like
pointers), so that even if the 'pointer' is const, you can still
change what it points to (unless that is also const). All VB .NET
help files and tutorials never even touch upon these things. Very
annoying. It's like they think the programmer shouldn't be thinking
about these things...

Anyway... that leads to the question:

How can I pass in an array to a function/sub so that the entire array
is const and cannot be changed? Or should I be using C# instead for
such functionality?

Thanks for your reply,

Zytan

[Herfried K. Wagner [MVP]]

"Zytan" <zy**********@yahoo.comschrieb:

How can I pass in an array to a function/sub so that the entire array
is const and cannot be changed? Or should I be using C# instead for
such functionality?

This cannot be done, not in VB and not in C#. You'd have to pass a copy of
the array or a proxy object to the function.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Stephany Young]

This is one of those:

Patient: "Doctor! It hurts when I do this."
Doctor: "Well don't do that!"

questions.

If you don't want the passed in array changed in your function, then don't
change it in your function!
"Zytan" <zy**********@yahoo.comwrote in message
news:11**********************@v33g2000cwv.googlegr oups.com...

Branco,

I had actually typed up a lengthy post asking about that, as well, and
Google Groups did something strange, and loaded a new page, erasing
the whole thing (one major flaw of web apps -- load a new page by
accident, and say goodbye to all your work), so I forgot about it, and
just asked the basic question.

I was going to ask if array variables are like C++ arrays (i.e. like
pointers), so that even if the 'pointer' is const, you can still
change what it points to (unless that is also const). All VB .NET
help files and tutorials never even touch upon these things. Very
annoying. It's like they think the programmer shouldn't be thinking
about these things...

Anyway... that leads to the question:

How can I pass in an array to a function/sub so that the entire array
is const and cannot be changed? Or should I be using C# instead for
such functionality?

Thanks for your reply,

Zytan

[Zytan]

Herfried,

This cannot be done, not in VB and not in C#. You'd have to pass a copy of
the array or a proxy object to the function.

I cannot *believe* this cannot be done. Wow... Ouch!

I know I can pass a copy (made with care) of the array, so that any
changes made within the function will not affect the original. But,
creating a copy of an array is a horrible thing to do when it needn't
be done... What terrible programming that would be, indeed. In my
case, I have an array of several MB in size.

Please elaborate on "proxy object".

Thanks for your reply,

Zytan

[Zytan]

Stephany,

This is one of those:

Patient: "Doctor! It hurts when I do this."
Doctor: "Well don't do that!"

questions.

If you don't want the passed in array changed in your function, then don't
change it in your function!

No, no, no! This is very, very bad way of thinking about it. My
program doesn't change the array inside of the function. Really. I'm
a good programmer. Trust me. But, the point is... I don't trust
myself. The reason "const" exists is to prevent me from making
mistakes. Even the smartest of us make mistakes. The compiler helps
us avoid pitfalls with concepts like "const" and encapsulation. They
force good programming. That's why good programmers use them. I
can't even begin to explain how astonished I am at your reply...

I am further astonished that VB offers no way to protect programmers
from being stupid with passing in arrays. And that even C# doesn't
have this. I am just amazed... the fact that all VB programmers out
there in VB land are programming without this protection... and now
your reply makes more sense to me. Because it's the only solution, it
is the only way you CAN think about it. Amazing. (that is... unless
the proxy objects that Herfried mentioned are a solution...?)

Zytan

[Herfried K. Wagner [MVP]]

"Zytan" <zy**********@yahoo.comschrieb:

>This cannot be done, not in VB and not in C#. You'd have to pass a copy
of
the array or a proxy object to the function.

Please elaborate on "proxy object".

\\\
Public Class ArrayProxy(Of T)
Private m_Array() As T

Public Sub New(ByVal Array() As T)
m_Array = Array
End Sub

Default Public ReadOnly Property Items(ByVal Index As Integer) As T
Get
Return m_Array(Index)
End Get
End Property
End Class
....
Dim Names() As String = ...
Foo(..., New ArrayProxy(Of String())(Names)), ...)
///

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Stephany Young]

Yes you're absolutely right - the best of us do make mistakes.

That is why we have robust debugging and testing techniques.

Checking that some variable that shouldn't be modified hasn't been is the
most the most basic of those techniques.
"Zytan" <zy**********@yahoo.comwrote in message
news:11*********************@v45g2000cwv.googlegro ups.com...

Stephany,

>This is one of those:

Patient: "Doctor! It hurts when I do this."
Doctor: "Well don't do that!"

questions.

If you don't want the passed in array changed in your function, then
don't
change it in your function!

No, no, no! This is very, very bad way of thinking about it. My
program doesn't change the array inside of the function. Really. I'm
a good programmer. Trust me. But, the point is... I don't trust
myself. The reason "const" exists is to prevent me from making
mistakes. Even the smartest of us make mistakes. The compiler helps
us avoid pitfalls with concepts like "const" and encapsulation. They
force good programming. That's why good programmers use them. I
can't even begin to explain how astonished I am at your reply...

I am further astonished that VB offers no way to protect programmers
from being stupid with passing in arrays. And that even C# doesn't
have this. I am just amazed... the fact that all VB programmers out
there in VB land are programming without this protection... and now
your reply makes more sense to me. Because it's the only solution, it
is the only way you CAN think about it. Amazing. (that is... unless
the proxy objects that Herfried mentioned are a solution...?)

Zytan

[Cor Ligthert [MVP]]

Zytan,

This discussion is already from the first beta versions. In my idea are you
right, but this seems to be a hobby from the main architect from the Net
languages. (And unchangable now of course)

Cor

"Zytan" <zy**********@yahoo.comschreef in bericht
news:11*********************@v45g2000cwv.googlegro ups.com...

Stephany,

>This is one of those:

Patient: "Doctor! It hurts when I do this."
Doctor: "Well don't do that!"

questions.

If you don't want the passed in array changed in your function, then
don't
change it in your function!

No, no, no! This is very, very bad way of thinking about it. My
program doesn't change the array inside of the function. Really. I'm
a good programmer. Trust me. But, the point is... I don't trust
myself. The reason "const" exists is to prevent me from making
mistakes. Even the smartest of us make mistakes. The compiler helps
us avoid pitfalls with concepts like "const" and encapsulation. They
force good programming. That's why good programmers use them. I
can't even begin to explain how astonished I am at your reply...

I am further astonished that VB offers no way to protect programmers
from being stupid with passing in arrays. And that even C# doesn't
have this. I am just amazed... the fact that all VB programmers out
there in VB land are programming without this protection... and now
your reply makes more sense to me. Because it's the only solution, it
is the only way you CAN think about it. Amazing. (that is... unless
the proxy objects that Herfried mentioned are a solution...?)

Zytan

[Branco Medeiros]

Zytan wrote:
<snip>

The reason "const" exists is to prevent me from making
mistakes. Even the smartest of us make mistakes. The compiler helps
us avoid pitfalls with concepts like "const" and encapsulation. They
force good programming. That's why good programmers use them. I
can't even begin to explain how astonished I am at your reply...

I am further astonished that VB offers no way to protect programmers
from being stupid with passing in arrays. And that even C# doesn't
have this. I am just amazed... the fact that all VB programmers out
there in VB land are programming without this protection... and now
your reply makes more sense to me. Because it's the only solution, it
is the only way you CAN think about it. Amazing. (that is... unless
the proxy objects that Herfried mentioned are a solution...?)

Unfortunatelly, there's no const propagation *in .Net*, as far as I
can't tell (I guess C++ programs that use const like this aren't CLS
compatible).

The only resort for the mindfull programmer is strong faith or relying
on the "AsReadOnly" that certain objects expose. But then,
unfortunately, the erroneous access will only be caught at run time,
not a compile time as it should be...

Sad, indeed...

Regards,

Branco.

[Brian Gideon]

On Feb 1, 6:36 pm, "Zytan" <[e-mail]:

Stephany,

This is one of those:

Patient: "Doctor! It hurts when I do this."
Doctor: "Well don't do that!"

questions.

If you don't want the passed in array changed in your function, then don't
change it in your function!

No, no, no! This is very, very bad way of thinking about it. My
program doesn't change the array inside of the function. Really. I'm
a good programmer. Trust me. But, the point is... I don't trust
myself. The reason "const" exists is to prevent me from making
mistakes. Even the smartest of us make mistakes. The compiler helps
us avoid pitfalls with concepts like "const" and encapsulation. They
force good programming. That's why good programmers use them. I
can't even begin to explain how astonished I am at your reply...

I am further astonished that VB offers no way to protect programmers
from being stupid with passing in arrays. And that even C# doesn't
have this. I am just amazed... the fact that all VB programmers out
there in VB land are programming without this protection... and now
your reply makes more sense to me. Because it's the only solution, it
is the only way you CAN think about it. Amazing. (that is... unless
the proxy objects that Herfried mentioned are a solution...?)

Zytan

Zytan,

Even in C++ const didn't guarentee much since the reference's
constness could be casted away. I think it was left out of C# because
the cost versus benefit of it tipped toward the unfavorable
direction. Implementing const reference parameters would add a
substantial amount of complexity to the language.

The best way to guarentee that an object's state cannot be changed is
to make it immutable.

Another strategy would be to use an interface or proxy object.
Though, I don't think either could absolutely be enforced at compile
time. A proxy object would probably be the best of two.

Brian

[lord.zoltar]

On Feb 1, 3:24 pm, "Zytan" <[e-mail]:

Are they possible? I am passing in a large array of Bytes, thus I
don't want to use ByVal.

Zytan

Have you tried using ByRef? Look up passing variables ByRef for
VB .NET.

[Zytan]

Herfried,

Thanks proxy object code sample. (I just learned how the Default
keyword works... neat!)

Dim Names() As String = ...
Foo(..., New ArrayProxy(Of String())(Names)), ...)

I think you mean: Note the lack of () after "String". I couldn't get
it to compile your way.

Foo(..., New ArrayProxy(Of String)(Names)), ...)

Ok... this solution is lacking in that the Foo function cannot discern
the length of the array. Ouch. Not only that, but to pass in the
length of the array to Foo, the caller can also not discern its length
for the same reason. You must use the length of the array that it was
constructed from (Names.Length, in this case). It's ugly. Also, all
of this mess just to do what "const" does in C++ <sigh It's just all
ugly... I can't help it, it's the truth.

But, thanks for your input, Herfried. It's nice to be able to
consider all possibilities.

Zytan

[Zytan]

Stephany,

Yes you're absolutely right - the best of us do make mistakes.

That is why we have robust debugging and testing techniques.

Yes.

Checking that some variable that shouldn't be modified hasn't been is the
most the most basic of those techniques.

No. Leaving such a simple, laborious task to the compiler is one of
the basic of those techniques.

No human can possibly read code like English, and look over a function
in a swift manner, and determine that the constant variables are
unchanging. What happens if one of them is passed to another
function? You have to either look at that function's code, and all
it's inner function calls, all the way down the stack / tree, and
then, if you haven't missed anything (and, since when is any human
perfect), you can determine that the code is correct. If you're
incorrect, hopefully you'll catch the bug during runtime development
and not after deployment, where it's 100 times more costly to fix than
during runtime development.

OR... you could use "const" -- 5 letters -- and let the compiler
notify you during COMPILE time which is 1/10th as costly as catching
it during beta testing. The compiler can go through all your code,
and determine at all levels that the variable is not being changed.
You can create "const" class functions to ensure the class data
members remain unchanged, and these are only allowed to be call other
functions that promise the same thing. All caught at compile time.

This is several ORDERS OF MAGNITUDE more robust than "human checking".

Besides, who has time to check code? Who does this? Even if you
*could* check all that code, and were as perfect as a machine, why
would you want to waste your time doing this? The time would be
better spend writing more robust code, letting the compiler check all
of that for you, removing any worries / intellectual barriers that you
may have about potential broken code.

Zytan

[Zytan]

Brian,

Even in C++ const didn't guarantee much since the reference's
constness could be casted away.

No. It guarantees a LOT. I use it regularly on large projects. It
helps enforce design issues where certain elements of my code just
should not be allowed to mess with certain data. It is extremely
important. Also, for all the elsewhere mentioned reasons in another
post of mine, such as catching bugs at compile time, make it
priceless. It just forces good programming. How can you beat that?

Yes, you can cast it away -- but not with 'normal' C++ code. Casting
away const is not allowed. You can get around it with fancy C++ code
to trick the compiler into accessing that memory, but it's really just
a high level way of writing assembly. So, yes, it's not 100% bullet
proof. But, that's not the point. The point is the immense gain you
get, from being forced to write good code, from using it.

Just because someone can pick a lock, it doesn't mean you should stop
locking your door. Now imagine a lock that forces the door to be
locked, and forces you to have the keys on you, every time you leave.
Anything that forces good habits is a good idea.

I think it was left out of C# because
the cost versus benefit of it tipped toward the unfavorable
direction. Implementing const reference parameters would add a
substantial amount of complexity to the language.

Really? I don't really know. It's just sad that it doesn't exist...

The best way to guarantee that an object's state cannot be changed is
to make it immutable.

Ok. Something else for me to learn. Any places I can get started on
researching this? Any help is appreciated.

Another strategy would be to use an interface or proxy object.
Though, I don't think either could absolutely be enforced at compile
time. A proxy object would probably be the best of two.

Thanks for the suggestion. This was mentioned above, and for
something where it is critical (i.e. it warrants the extra hassle
involved), it certainly could be used.

Zytan

[Stephany Young]

Well, all I can really say is ...

If you need the features exposed by the C++ language and the C++ compiler so
badly then I don't understand why you are not using that instead of bleating
on about something that just "ain't gonna happen".
"Zytan" <zy**********@yahoo.comwrote in message
news:11**********************@a34g2000cwb.googlegr oups.com...

Stephany,

>Yes you're absolutely right - the best of us do make mistakes.

That is why we have robust debugging and testing techniques.

Yes.

>Checking that some variable that shouldn't be modified hasn't been is the
most the most basic of those techniques.

No. Leaving such a simple, laborious task to the compiler is one of
the basic of those techniques.

No human can possibly read code like English, and look over a function
in a swift manner, and determine that the constant variables are
unchanging. What happens if one of them is passed to another
function? You have to either look at that function's code, and all
it's inner function calls, all the way down the stack / tree, and
then, if you haven't missed anything (and, since when is any human
perfect), you can determine that the code is correct. If you're
incorrect, hopefully you'll catch the bug during runtime development
and not after deployment, where it's 100 times more costly to fix than
during runtime development.

OR... you could use "const" -- 5 letters -- and let the compiler
notify you during COMPILE time which is 1/10th as costly as catching
it during beta testing. The compiler can go through all your code,
and determine at all levels that the variable is not being changed.
You can create "const" class functions to ensure the class data
members remain unchanged, and these are only allowed to be call other
functions that promise the same thing. All caught at compile time.

This is several ORDERS OF MAGNITUDE more robust than "human checking".

Besides, who has time to check code? Who does this? Even if you
*could* check all that code, and were as perfect as a machine, why
would you want to waste your time doing this? The time would be
better spend writing more robust code, letting the compiler check all
of that for you, removing any worries / intellectual barriers that you
may have about potential broken code.

Zytan

[Brian Gideon]

On Feb 2, 11:58 am, "Zytan" <[e-mail]:

Brian,

Even in C++ const didn't guarantee much since the reference's
constness could be casted away.

No. It guarantees a LOT. I use it regularly on large projects. It
helps enforce design issues where certain elements of my code just
should not be allowed to mess with certain data. It is extremely
important. Also, for all the elsewhere mentioned reasons in another
post of mine, such as catching bugs at compile time, make it
priceless. It just forces good programming. How can you beat that?

Yes, you can cast it away -- but not with 'normal' C++ code. Casting
away const is not allowed. You can get around it with fancy C++ code
to trick the compiler into accessing that memory, but it's really just
a high level way of writing assembly. So, yes, it's not 100% bullet
proof. But, that's not the point. The point is the immense gain you
get, from being forced to write good code, from using it.

Just because someone can pick a lock, it doesn't mean you should stop
locking your door. Now imagine a lock that forces the door to be
locked, and forces you to have the keys on you, every time you leave.
Anything that forces good habits is a good idea.

Yes, you're right. I may have been a little overzealous on my point.
At the very least const adds metadata that would let the caller know
that the method claims to not modify the state of the parameter. It's
up to the developer of that method to comply with what's advertised in
the metadata.

I think it was left out of C# because
the cost versus benefit of it tipped toward the unfavorable
direction. Implementing const reference parameters would add a
substantial amount of complexity to the language.

Really? I don't really know. It's just sad that it doesn't exist...

That doesn't necessarily mean it won't be added in the future. But, I
suspect the chances are not good for C# and even worse for VB.

>

The best way to guarantee that an object's state cannot be changed is
to make it immutable.

Ok. Something else for me to learn. Any places I can get started on
researching this? Any help is appreciated.

It's not a particularly clever concept or anything. All you do is
make sure the methods on a class have no side-effects to the object
from which they are called. The String data type is an example of an
immutable class.

Another strategy would be to use an interface or proxy object.
Though, I don't think either could absolutely be enforced at compile
time. A proxy object would probably be the best of two.

Thanks for the suggestion. This was mentioned above, and for
something where it is critical (i.e. it warrants the extra hassle
involved), it certainly could be used.

It's partially related to mutability. The difference with the proxy
object is that the real object is mutable, but the proxy is not. Like
you said, it's not something you're going to want to create for every
class.

[Zytan]

If you need the features exposed by the C++ language and the C++ compiler so

badly then I don't understand why you are not using that instead of bleating
on about something that just "ain't gonna happen".

Stephany, This isn't a VB vs. C++ issue. It's language independent.
This is off topic.

Zytan

[Zytan]

Brian,

Thanks again for your reply.

Yes, you're right. I may have been a little overzealous on my point.
At the very least const adds metadata that would let the caller know
that the method claims to not modify the state of the parameter. It's
up to the developer of that method to comply with what's advertised in
the metadata.

Yup, it's a godsend. I didn't realize its power until I started
making use of it. I imagine most people haven't experienced this, and
they probably think I am crazy since "if you don't want anything to
change the data, just make sure your code doesn't change it." When I
first implemented it, and it forced me to refactor about 50 functions,
some of them being major refactors, I realized it was helping me
maintain blackbox / encapsulation style programming. I was like,
"Wow." But, almost no code I see makes use of it, even professional
code...

That doesn't necessarily mean it won't be added in the future. But, I
suspect the chances are not good for C# and even worse for VB.

I imagine you are right. If no one cares... why implement it? They
have new .NET functionality to write, after all. Time is limited.

It's not a particularly clever concept or anything. All you do is
make sure the methods on a class have no side-effects to the object
from which they are called. The String data type is an example of an
immutable class.

Aaaah. I see.

Thanks for your time -- everybody -- it is appreciated.

Zytan

[Herfried K. Wagner [MVP]]

<lo*********@gmail.comschrieb:

>Are they possible? I am passing in a large array of Bytes, thus I
don't want to use ByVal.

Have you tried using ByRef? Look up passing variables ByRef for
VB .NET.

This would even be dangerous because it allows the method to change the
reference passed to the method in the parameter! 'ByVal' and 'ByRef' are
not really related to the OP's problem, although 'ByVal' is much more
appropriate here.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Herfried K. Wagner [MVP]]

"Stephany Young" <noone@localhostschrieb:

Well, all I can really say is ...

If you need the features exposed by the C++ language and the C++ compiler
so badly then I don't understand why you are not using that instead of
bleating on about something that just "ain't gonna happen".

Hm... I think it's interesting that someone shows his/her interest in
functionality similar to 'const'. I believe that adding a similar concept
to .NET has been considered, but maybe it's worth to reconsider it.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Stephany Young]

You get no argument from me on that count Herfried.

I was responding to the OP's rant that basically was saying that VB.NET was
unusable because it didn't have this particular 'feature' and that it had to
be 'fixed' immediately.

I have no problem at all about a debate on whether or not such a concept
should or shouldn't be included in a future relase of the language.
"Herfried K. Wagner [MVP]" <hi***************@gmx.atwrote in message
news:%2***************@TK2MSFTNGP06.phx.gbl...

"Stephany Young" <noone@localhostschrieb:

>Well, all I can really say is ...

If you need the features exposed by the C++ language and the C++ compiler
so badly then I don't understand why you are not using that instead of
bleating on about something that just "ain't gonna happen".

Hm... I think it's interesting that someone shows his/her interest in
functionality similar to 'const'. I believe that adding a similar concept
to .NET has been considered, but maybe it's worth to reconsider it.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Cor Ligthert [MVP]]

Zytan,

Before I wrote this I have looked at the calendar, and it is really 2007.

I thought that I was back in 1967 while I was reading your response.

Although I agree with you in concept is it now much to late start again a
discussion.

As the Arabs had than won the Arab-Isrealy war, than a lot of things would
probably look different now, however you cannot change history (beside in
the schoolbooks of course).

Cor

"Zytan" <zy**********@yahoo.comschreef in bericht
news:11**********************@a34g2000cwb.googlegr oups.com...

Stephany,

>Yes you're absolutely right - the best of us do make mistakes.

That is why we have robust debugging and testing techniques.

Yes.

>Checking that some variable that shouldn't be modified hasn't been is the
most the most basic of those techniques.

No. Leaving such a simple, laborious task to the compiler is one of
the basic of those techniques.

No human can possibly read code like English, and look over a function
in a swift manner, and determine that the constant variables are
unchanging. What happens if one of them is passed to another
function? You have to either look at that function's code, and all
it's inner function calls, all the way down the stack / tree, and
then, if you haven't missed anything (and, since when is any human
perfect), you can determine that the code is correct. If you're
incorrect, hopefully you'll catch the bug during runtime development
and not after deployment, where it's 100 times more costly to fix than
during runtime development.

OR... you could use "const" -- 5 letters -- and let the compiler
notify you during COMPILE time which is 1/10th as costly as catching
it during beta testing. The compiler can go through all your code,
and determine at all levels that the variable is not being changed.
You can create "const" class functions to ensure the class data
members remain unchanged, and these are only allowed to be call other
functions that promise the same thing. All caught at compile time.

This is several ORDERS OF MAGNITUDE more robust than "human checking".

Besides, who has time to check code? Who does this? Even if you
*could* check all that code, and were as perfect as a machine, why
would you want to waste your time doing this? The time would be
better spend writing more robust code, letting the compiler check all
of that for you, removing any worries / intellectual barriers that you
may have about potential broken code.

Zytan

[=?Utf-8?B?VGVycnk=?=]

I know I am a little late in joining this discussion, but I was just reading
something in the documentation that may be of some help - not sure since I
have not tried it yet. New to the .Net Framework version 2 is the
"Array.AsReadOnly" Generic Method that retrurns a read-only wrapper for the
specified array. So if you passed the original array (reference) byval, the
first line of code could be something like:
TheArray = Array.AsReadOnly(TheArray) ' assuming the param was "TheArray"
Then it seems to me that the compiler should find and flag any attempts to
modify the array. And of course, the byval keeps the original reference from
being modified.
I am fairly new to .net myself, so maybe I am on the wrong track here, but
it sounds like it should work.
--
Terry
"Zytan" wrote:

Branco,

I had actually typed up a lengthy post asking about that, as well, and
Google Groups did something strange, and loaded a new page, erasing
the whole thing (one major flaw of web apps -- load a new page by
accident, and say goodbye to all your work), so I forgot about it, and
just asked the basic question.

I was going to ask if array variables are like C++ arrays (i.e. like
pointers), so that even if the 'pointer' is const, you can still
change what it points to (unless that is also const). All VB .NET
help files and tutorials never even touch upon these things. Very
annoying. It's like they think the programmer shouldn't be thinking
about these things...

Anyway... that leads to the question:

How can I pass in an array to a function/sub so that the entire array
is const and cannot be changed? Or should I be using C# instead for
such functionality?

Thanks for your reply,

Zytan

[Zytan]

On Feb 2, 6:54 pm, "Herfried K. Wagner [MVP]" <hirf-spam-me-
[e-mail]:

Hm... I think it's interesting that someone shows his/her interest in
functionality similar to 'const'. I believe that adding a similar concept
to .NET has been considered, but maybe it's worth to reconsider it.

My point exactly, Herfried. My original post was how to replicate the
functionality, since VB does have "Const" in some parts of the
language. Since discovering it cannot be replicated in full, it is
certainly a legitimate point to raise concern that this feature should
be added for the numerous benefits I have mentioned. Unfortunately,
since most people have never made use of such features, even when they
are using languages that support them. So, they wouldn't really "get"
why it is so invaluable. I made effort to explain most of the major
reasons pretty clearly (there are more, such as how "const" protects
code from improper changes of OTHER programmers not-in-the-know, or
even yourself 6 months from now when you've forgotten how some
function works). But, it's hard for people to listen when they think
I am attacking their language. I am pointing out its weaknesses,
yes. This is how change begins. I do the same with all languages I
use. I guess, also, you don't miss anything you've never had. I
didn't care that all languages didn't have "const" functionality until
I used it. People here are acting like the old me. But, I listened
when someone said I should be using "const", and I started using it.
In this manner, I stumbled upon how useful it was -- I couldn't
possibly have known every benefit it brought without using it
personally (although most of them were found by listening to others).
I wish you all could share this experience. Maybe that's why
intelligent people have said programmers should learn a new language
every year... I should try that. There's probably tons of things I
am missing that I don't realize, yet.

Zytan

[Zytan]

Stephany,

You get no argument from me on that count Herfried.

Herfried is agreeing with me that it is useful to considering new
language features.

I have no problem at all about a debate on whether or not such a concept
should or shouldn't be included in a future release of the language.

Now you are agreeing with me. We are currently HAVING such a debate.

I was responding to the OP's rant that basically was saying that VB.NET was
unusable because it didn't have this particular 'feature' and that it had to
be 'fixed' immediately.

I said VB .NET is unusable, and must be fixed immediately... because
it doesn't have "const"!?
Unbelievable.
My discussion with you ends now.

Zytan

[Zytan]

Cor,

Before I wrote this I have looked at the calendar, and it is really 2007.

I thought that I was back in 1967 while I was reading your response.

Although I agree with you in concept is it now much to late start again a
discussion.

As the Arabs had than won the Arab-Isrealy war, than a lot of things would
probably look different now, however you cannot change history (beside in
the schoolbooks of course).

Thanks for the insults.

You're telling me that the... compiler... cannot do *compile time
checks* to ensure a variable is NOT changed inside of a function?

Exactly what history must be changed in order for someone to improve
the compiler?

Maybe if we all edit wikipedia, perceived history will change, and
someone will realize it is actually possible, and then someone will
improve the compiler.

Zytan

[Zytan]

Terry,

I know I am a little late in joining this discussion, but I was just reading
something in the documentation that may be of some help - not sure since I
have not tried it yet. New to the .Net Framework version 2 is the
"Array.AsReadOnly" Generic Method that returns a read-only wrapper for the
specified array. So if you passed the original array (reference) byval, the
first line of code could be something like:
TheArray = Array.AsReadOnly(TheArray) ' assuming the param was "TheArray"
Then it seems to me that the compiler should find and flag any attempts to
modify the array. And of course, the byval keeps the original reference from
being modified.

Thanks for the reply. Branco mentioned this earlier, and he claimed
that it still would only be caught at run time. I am not sure, I'd
have to test and see. But, this is better than nothing. And it's
better than proxy objects because it is specifically designed for
this, needing much less code. I'll give it a shot.

Thanks,

Zytan

[Zytan]

New to the .Net Framework version 2 is the

"Array.AsReadOnly" Generic Method that returns a read-only wrapper for the
specified array.

This works, but note that the result is a collection. It is not
something you can just drop into existing code.

Zytan

[Brian Gideon]

On Feb 5, 7:36 am, "Zytan" <[e-mail]:

Terry,

I know I am a little late in joining this discussion, but I was just reading
something in the documentation that may be of some help - not sure since I
have not tried it yet. New to the .Net Framework version 2 is the
"Array.AsReadOnly" Generic Method that returns a read-only wrapper for the
specified array. So if you passed the original array (reference) byval, the
first line of code could be something like:
TheArray = Array.AsReadOnly(TheArray) ' assuming the param was "TheArray"
Then it seems to me that the compiler should find and flag any attempts to
modify the array. And of course, the byval keeps the original reference from
being modified.

Thanks for the reply. Branco mentioned this earlier, and he claimed
that it still would only be caught at run time. I am not sure, I'd
have to test and see. But, this is better than nothing. And it's
better than proxy objects because it is specifically designed for
this, needing much less code. I'll give it a shot.

Thanks,

Zytan

Zytan,

ReadOnlyCollection is a proxy object because it can masquerade as an
IList like the original collection. The read-only check is performed
at runtime.

Brian

[Herfried K. Wagner [MVP]]

"Zytan" <zy**********@yahoo.comschrieb:

>Before I wrote this I have looked at the calendar, and it is really 2007.

I thought that I was back in 1967 while I was reading your response.

Although I agree with you in concept is it now much to late start again a
discussion.

As the Arabs had than won the Arab-Isrealy war, than a lot of things
would
probably look different now, however you cannot change history (beside in
the schoolbooks of course).

[...]
Exactly what history must be changed in order for someone to improve
the compiler?

The 'const' attribute could be stored as an attribute in the parameters'
metadata, similar to how it is done for optional parameters and parameter
default values. That's not the problem.

The main problem I see is that the .NET Framework's class library currently
does not make use of such an attribute, but this would be crucial for its
overall success because most of the code makes calls to this class library.
In addition, all 3rd-party code would have to be reworked to make use of
const-correctness.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Zytan]

Herfried,

The 'const' attribute could be stored as an attribute in the parameters'
metadata, similar to how it is done for optional parameters and parameter
default values. That's not the problem.

Ok. That was my understanding.

The main problem I see is that the .NET Framework's class library currently
does not make use of such an attribute, but this would be crucial for its
overall success because most of the code makes calls to this class library.
In addition, all 3rd-party code would have to be reworked to make use of
const-correctness.

In my experience with C++, I've made use of the Win32 API which is
written in C, which doesn't use "const" (please correct me if I am
wrong). But, I still implemented "const" myself, for my own
libraries, and derived a benefit from them.

But, I do see your point. If almost ALL of the program's data is
passed to library calls, and this data disallows change, the library
functions will complain that they are expected data they are allowed
to modify.

However, consider a next generation .NET could implement "const" --
even only partially -- to the library, without any detriment to
existing code. A function that never changed its parameter data will
not care that it is no longer allowed to change it. Also, such
functions will continue to accept ANY type of data (readonly or not).
VB programmers could continue on with no knowledge of the changes...

No major internal architectures must change to make this happen, as we
seen with the VB6 to VB.NET switch. And, it can be introduced
incrementally. This is Good News.

Zytan