Make a Parameter CONST?

[Brien King]

Re: Make a Parameter CONST?

David,

Yes, this is exactly what I was getting at. To me it's a safety issue more
then anything. I want to avoid introducing subtle bugs that are hard to
find. If you pass an object to someone elses method (say a 3rd Party), you
don't know what they are doing with your object and therefore you can't
guarntee the state of the object you passed in (unless you work around this
issue) once the method returns.


Brien King

"david" <david@woofix.l ocal.dom> wrote in message
news:slrndio3ot .edn.david@loca lhost.localdoma in...[color=blue]
> On 2005-09-17, m.posseth <michelp@nohaus ystems.nl> wrote:[color=green]
>> after rethinking ,,, i provided a workaround but it is absolutely
>> useless
>>
>> why the $##$$# would you do that if you could just as easily use a local
>> (
>> in the same class as the method ) contstant value
>>
>> maybe we should ask you what is your situation in wich you think this is
>> needed ???
>>
>> as i said i would not pass a contstant value at all to a parameter , i
>> would
>> make it a class construct parameter and call it with a read only property
>> in
>> the method itself[/color]
>
> You're missing the point. What the OP wants is to pass reference types
> to a method and ensure that the method won't change the contents of the
> passed object. It would look something like this...
>
> Public Sub Foo(ByConst list As ArrayList)
>
> Console.Writeli ne(list(0)) ' This is OK
> list(0) = "Hello" ' This would be a compile error
>
>
> Because the list parameter is declared const, the Foo method can't
> change the contents. This is a very common construct in C++, but
> isn't supported in the CLR or the Framework.
>
>
>
>
>
>
>[color=green]
>>
>> regards
>>
>> Michel Posseth [MCP]
>>
>>
>>
>>
>> "Brien King" <spammehere@arc aderestoration. com> wrote in message
>> news:erx4YvyuFH A.2008@TK2MSFTN GP10.phx.gbl...[color=darkred]
>>> If I have a parameter that has an Object type (as opposed to something
>>> like a string), can I make that parameter a CONST?
>>>
>>> Right now, if you pass an object into a sub/function, that sub/function
>>> can modify the object no matter how it's defined (ByVal or ByRef).
>>>
>>> In some cases, I want to make sure that you cannot modify the object.
>>> Is
>>> there a way to do that in VS2003 or the up comming VS2005?
>>>
>>>
>>> Thanks,
>>>
>>>
>>> Brien King
>>>[/color]
>>
>>[/color][/color]

[david]

Re: Make a Parameter CONST?

On 2005-09-18, Brien King <spammehere@arc aderestoration. com> wrote:[color=blue]
>
> Technically, a String is an Object in .NET so you would expect the same
> behaviour, but it behaves as I would expect it to. The first Message box is
> Empty, the second has a value.[/color]

You're interpreting this wrong. A string is an object, and is passed
just like any other object in the system.

The only difference is that strings don't have any methods on them that
can actually modify the object. That's why they're immutable; it's not
any kind of special language construct, it's just the way the class is
defined. If you define your own class that has only ReadOnly properties
and methods, you can get this same behavior (in fact, that's exactly
what others have been mentioning as a partial workaround).
[color=blue]
> Now I had made the wrong assumption up to this point, that it actually made
> a copy of the object that is being passed in and that it wouldn't modify the
> original object. If I wanted to modify the original object I would have had
> to specify ByRef. To me is was the same as passing in someting in C++ as &
> or passing in as const &. Apparently I was wrong.[/color]

Yep, it's sort of like passing a pointer in C++. You can't modify the
pointer itself as it exists in the caller, but you can modify the object
the pointer points to.

Just to complicate things, ValueTypes like Structures in .Net *are*
copied when you declare a ByVal parameter. This can all seem a little
different at first glance, but parameter passing is a very important
concept to get your head around.


[color=blue]
>
> I don't need to work around it, I just needed to be aware that is the way it
> works. Because it behaves this way, it would be EASY to introduce subtle
> bugs into the code due to the fact that it DOES modify the original object.
>
> It would be Nice to be able to specify that a Parameter is CONST so that the
> compiler would catch an assignment to that parameter. The main reason for
> me to use that is to ensure that every INPUT parameter is exactly that.
> INPUT.
>
>
>
> Brien King
>
>
> "DWS" <DWS@discussion s.microsoft.com > wrote in message
> news:2F53C4B1-E2D8-4D42-8C56-E31428902882@mi crosoft.com...[color=green]
>> Brien,
>> Your right the sub or function can modify the objects you pass to em!
>>
>> Byval the sub can modify a temporary copy of the object.
>> Byref the sub can modify the object.
>>
>> Good Luck
>> DWS
>>
>> Byval = a copy of the object. its just a copy so when you return from the
>> sub or function the original object is not changed.
>>
>> ByRef = the actual object.
>>
>>
>>
>>
>> Byref = the function can actually change the object.
>>
>>[/color]
>[/color]

[Brien King]

Re: Make a Parameter CONST?

So, when I do

Dim myString as String
myString = "This is a string"

Does it create a new instance of a String type and assign that to myString?
or does it actually modify the object that is myString? If the first part
is true, that would explain the difference in behavior that I am seeing.

So, if the = does create a new instance of the type (or assigns the pointer
to another instance) then I could look at ByVal and ByRef as this; ByVal is
a Pointer to an Instance of a Class. ByRef is a Pointer to a Poitner to an
Instance of a Class. Correct?


Brien King


"david" <david@woofix.l ocal.dom> wrote in message
news:slrndirc5m .g7n.david@loca lhost.localdoma in...[color=blue]
> On 2005-09-18, Brien King <spammehere@arc aderestoration. com> wrote:[color=green]
>>
>> Technically, a String is an Object in .NET so you would expect the same
>> behaviour, but it behaves as I would expect it to. The first Message box
>> is
>> Empty, the second has a value.[/color]
>
> You're interpreting this wrong. A string is an object, and is passed
> just like any other object in the system.
>
> The only difference is that strings don't have any methods on them that
> can actually modify the object. That's why they're immutable; it's not
> any kind of special language construct, it's just the way the class is
> defined. If you define your own class that has only ReadOnly properties
> and methods, you can get this same behavior (in fact, that's exactly
> what others have been mentioning as a partial workaround).
>[color=green]
>> Now I had made the wrong assumption up to this point, that it actually
>> made
>> a copy of the object that is being passed in and that it wouldn't modify
>> the
>> original object. If I wanted to modify the original object I would have
>> had
>> to specify ByRef. To me is was the same as passing in someting in C++ as
>> &
>> or passing in as const &. Apparently I was wrong.[/color]
>
> Yep, it's sort of like passing a pointer in C++. You can't modify the
> pointer itself as it exists in the caller, but you can modify the object
> the pointer points to.
>
> Just to complicate things, ValueTypes like Structures in .Net *are*
> copied when you declare a ByVal parameter. This can all seem a little
> different at first glance, but parameter passing is a very important
> concept to get your head around.
>
>
>[color=green]
>>
>> I don't need to work around it, I just needed to be aware that is the way
>> it
>> works. Because it behaves this way, it would be EASY to introduce subtle
>> bugs into the code due to the fact that it DOES modify the original
>> object.
>>
>> It would be Nice to be able to specify that a Parameter is CONST so that
>> the
>> compiler would catch an assignment to that parameter. The main reason
>> for
>> me to use that is to ensure that every INPUT parameter is exactly that.
>> INPUT.
>>
>>
>>
>> Brien King
>>
>>
>> "DWS" <DWS@discussion s.microsoft.com > wrote in message
>> news:2F53C4B1-E2D8-4D42-8C56-E31428902882@mi crosoft.com...[color=darkred]
>>> Brien,
>>> Your right the sub or function can modify the objects you pass to em!
>>>
>>> Byval the sub can modify a temporary copy of the object.
>>> Byref the sub can modify the object.
>>>
>>> Good Luck
>>> DWS
>>>
>>> Byval = a copy of the object. its just a copy so when you return from
>>> the
>>> sub or function the original object is not changed.
>>>
>>> ByRef = the actual object.
>>>
>>>
>>>
>>>
>>> Byref = the function can actually change the object.
>>>
>>>[/color]
>>[/color][/color]

[david]

Re: Make a Parameter CONST?

On 2005-09-18, Brien King <spammehere@arc aderestoration. com> wrote:[color=blue]
> So, when I do
>
> Dim myString as String
> myString = "This is a string"
>
> Does it create a new instance of a String type and assign that to
> myString? or does it actually modify the object that is myString? If
> the first part is true, that would explain the difference in behavior
> that I am seeing.[/color]

The first one. It creates a new String instance.
[color=blue]
>
> So, if the = does create a new instance of the type (or assigns the
> pointer to another instance) then I could look at ByVal and ByRef as
> this; ByVal is a Pointer to an Instance of a Class. ByRef is a
> Pointer to a Poitner to an Instance of a Class. Correct?[/color]

Right. I think that's a very useful way to look at it.

[m.posseth]

Re: Make a Parameter CONST?

well thanks for clearing things ,,,,,

I was already thinking that i might have understood something totally wrong
... ( as i am not a native english speaker ,,, this might happen )


But it is clear to me know where we started thinking different , I presented
the workaround as the easy solution to the question , while you who has
worked with the concept in C++ sees this as comparing apples with pears
:-) . obviously the two do not match at all, i do understand that


regards

Michel Posseth










"david" <david@woofix.l ocal.dom> wrote in message
news:slrndir3fm .g4j.david@loca lhost.localdoma in...[color=blue]
> On 2005-09-18, m.posseth <michelp@nohaus ystems.nl> wrote:[color=green]
>> Hmm well we are obviously not talking the same language :-)
>>
>> when i said
>>[color=darkred]
>>>>>why the $##$$# would you do that if you could just as easily use a
>>>>>local
>>>>>(
>>>>>in the same class as the method ) contstant value[/color]
>>
>> I was refering to the previous answer i had given ( as i feel that
>> encapsulation in a class is a much better aproach )
>>[color=darkred]
>>> I'm curious what you mean here, but I must admit I'm not sure what
>>> you're getting at or what it's relevance is.[/color]
>>
>> Please tell me what is wrong with defining a class with friend / public
>> readonly properties that can only be set during construction from the
>> outside , as a workaround for the problem[/color]
>
> You're right, we're not talking the same language. The paragraph I said
> I didn't understand what you meant was "If i rethink this in a OOP way
> it isn`t so difficult to acomplish at all ( define the needed business
> rules in some objects on demand )", which is a whole lot more obscure
> than what you just said. But no matter...
>[color=green]
>> Your answer was No and i have given an alternative aproach ,,,, and after
>> rereading the original question i believe it is verry relevant .... if
>> you
>> feel that it isn`t then let the TS decide if this might be an alternative
>> ,
>> as it is obvious that he comes here for a solution of his problem .[/color]
>
> No, Jesse posted more or less the same thing. Wrapping the object in
> read-only class or interface is the standard response given to this,
> and it's certainly relevant.
>
> Of course, it's also quite limited and not really a reasonable replacement
> at all except in very simple circumstances. All in all, I agree with
> the arguments against const parameters that people like Anders Hejlberg
> have made, but it's a very useful construct that isn't easily duplicated
> in .Net, and I think the idea that the equivalent is somehow easy to
> accomplish is simply wrong.
>[/color]

[DWS]

Re: Make a Parameter CONST?

Thus your query

"Brien King" wrote:
[color=blue]
> DWS,
>
> Sorry, but that is not what happens, and thus my query. In .NET, if you
> pass an object ByVal, it does NOT copy the object itself and the original
> object DOES get modified. I have tested this, and it's easy to demonstrate.
>
> Here is a quick example:
>
> Public Class TTestClass
> Private m_myVar As String
> Property MyVar() As String
> Get
> Return m_myVar
> End Get
> Set(ByVal Value As String)
> m_myVar = Value
> End Set
> End Property
> End Class
>
> Private Sub Button4_Click(B yVal sender As System.Object, ByVal e As
> System.EventArg s) Handles Button4.Click
> Dim testClass As New TTestClass
> Dim testString As String
>
> ModifyMyTestCla ss(testClass)
> MessageBox.Show (testClass.MyVa r)
>
> ModifyMyTestStr ingByVal(testSt ring)
> MessageBox.Show (testString)
>
> ModifyMyTestStr ingByRef(testSt ring)
> MessageBox.Show (testString)
>
> End Sub
>
> Private Sub ModifyMyTestCla ss(ByVal P_testClass As TTestClass)
> P_testClass.MyV ar = "This shouldn't leave this method... but it does!"
> End Sub
>
> Private Sub ModifyMyTestStr ingByVal(ByVal P_testString As String)
> P_testString = "This won't leave this method..."
> End Sub
>
> Private Sub ModifyMyTestStr ingByRef(ByRef P_testString As String)
> P_testString = "This WILL leave this method..."
> End Sub
>
> When you run that code, you'll see the message "This shouldn't leave this
> method... but it does!".
>
> Technically, a String is an Object in .NET so you would expect the same
> behaviour, but it behaves as I would expect it to. The first Message box is
> Empty, the second has a value.
>
> Now I had made the wrong assumption up to this point, that it actually made
> a copy of the object that is being passed in and that it wouldn't modify the
> original object. If I wanted to modify the original object I would have had
> to specify ByRef. To me is was the same as passing in someting in C++ as &
> or passing in as const &. Apparently I was wrong.
>
> I don't need to work around it, I just needed to be aware that is the way it
> works. Because it behaves this way, it would be EASY to introduce subtle
> bugs into the code due to the fact that it DOES modify the original object.
>
> It would be Nice to be able to specify that a Parameter is CONST so that the
> compiler would catch an assignment to that parameter. The main reason for
> me to use that is to ensure that every INPUT parameter is exactly that.
> INPUT.
>
>
>
> Brien King
>
>
> "DWS" <DWS@discussion s.microsoft.com > wrote in message
> news:2F53C4B1-E2D8-4D42-8C56-E31428902882@mi crosoft.com...[color=green]
> > Brien,
> > Your right the sub or function can modify the objects you pass to em!
> >
> > Byval the sub can modify a temporary copy of the object.
> > Byref the sub can modify the object.
> >
> > Good Luck
> > DWS
> >
> > Byval = a copy of the object. its just a copy so when you return from the
> > sub or function the original object is not changed.
> >
> > ByRef = the actual object.
> >
> >
> >
> >
> > Byref = the function can actually change the object.
> >
> >[/color]
>
>[/color]