Why does this code work?

[Cor Ligthert [MVP]]

Jon,

I haven't used Cobol, but it sounds like it was using value type
semantics. That's okay, but you need to understand the efficiency
penalties of doing that - and acknowledge that it's *not* the .NET way
of doing things. Why fight against what the framework promotes?

You can transfer a reference to an address not being the actual address that
is tranfered.
Used in performs (advanced for loops) which I have never seen anymore in a
language as advanced it is in extended Cobol versions.

But as I said, have your own ideas, I had the same as yours, mine is
changed, time willl probably learn if that sustains.



In my opinion the goal should be that it is not necessary to learn basic
things. I assume that your new born kids will learn English without any
problem, while it is for a lot of children more difficult than their first
language.



Cor

 

[Jon Skeet [C# MVP]]

You can transfer a reference to an address not being the actual address that
is tranfered.

Care to rephrase that? It doesn't make a lot of sense at the moment.

Used in performs (advanced for loops) which I have never seen anymore in a
language as advanced it is in extended Cobol versions.

But as I said, have your own ideas, I had the same as yours, mine is
changed, time willl probably learn if that sustains.

Well, the framework uses the pattern already. It's not like I'm coming
up with it on my own. It's also used in other platforms such as Java.
It's a pattern which works. It's efficient and readable - you just need
to know the basics of the platform and be capable of reading
documentation. If you can't do those things then you've got no chance
in the first place, IMO.

In my opinion the goal should be that it is not necessary to learn basic
things. I assume that your new born kids will learn English without any
problem, while it is for a lot of children more difficult than their first
language.

If you're suggesting that people shouldn't have to learn the difference
between reference types and value types, I couldn't disagree more.

Let's put this into a more concrete example. Suppose I have a method
AppendData which takes a StringBuilder and appends some data, either to
it or to a copy of it. By your reasoning the method should return a
StringBuilder, because people may not be aware that the StringBuilder
they pass in (as a reference) can be changed during that method.

Now, if they aren't aware that it can happen, they may well assume that
it *can't* happen. If you're going to cope with that possibility, then
you need to make sure you don't violate their assumptions - otherwise
their code will break. So, you'd better take a copy of the
StringBuilder, creating another one, and appending to that before
returning it.

Now imagine someone passes you a StringBuilder with 100,000 characters
in it. See the problem?

In this case, you actually suggested that you just return the same
reference having modified the object in-place. At that point, anyone
who doesn't understand the type system is probably going to end up with
errors sooner or later.


Compare this with my solution: educate people and document what the
method does. You can then write efficient and intuitive methods (names
like "Fill" or "Populate" generally give the game away) which don't
make assumptions that the caller is stupid.

 

[Cor Ligthert [MVP]]

Jon,

You go out of the point, I never have talked about using references or not,
moreover I have said in this thread to use those in an object to pass and
return information.

Moreover, my point is not to use in normal situations the Sub or the Void to
change in an easy way referency types hidden in a method, but to return the
reference. Even if that is technical not needed (as I know). I nowhere have
told people not to learn reference types, I am not against guns (I once did
sport shooting), I am against the wrong use of guns.

Cor

 

[Jon Skeet [C# MVP]]

You go out of the point, I never have talked about using references or not,
moreover I have said in this thread to use those in an object to pass and
return information.

I'm not off the point at all. My StringBuilder analogy is *exactly*
equivalent to the SqlCommand situation - and I note you didn't say
whether or not you'd make a copy.

Do you not accept that if people assume incorrectly that if the
parameter is ByVal then the object can't be changed, then appending to
the StringBuilder that's passed in may surprise them - possibly late?
Why pretend anything is happening other than what is *truly* happening?

Moreover, my point is not to use in normal situations the Sub or the Void to
change in an easy way referency types hidden in a method, but to return the
reference. Even if that is technical not needed (as I know). I nowhere have
told people not to learn reference types, I am not against guns (I once did
sport shooting), I am against the wrong use of guns.

But if you assume that people don't understand reference types, and try
to work round that lack of knowledge by returning things unnecessarily,
you tie yourself in knots as I think I've demonstrated.

Furthermore, it only goes to confuse people who *do* understand
reference types. The first question I'd be asking myself is, "Why is
this returning anything? There's no point if it's just modifying the
object whose reference I'm passing in. Maybe it's copying the object
instead..."

See how instead of increasing readability it's actually reducing it?
It's obscuring the true nature of the method. At some point or another,
people *have* to learn reference type semantics, or they will flounder.
I would prefer to make them learn the truth early rather than postpone
that time by pretending that they don't need to know anything, and that
the way they might incorrectly think things are passed is in fact the
truth.

Jon

 

[Cor Ligthert [MVP]]

Jon,

Maybe I disappoint you, I know what a reference type is and others do
probably as well (at least Juli showed that as well), but that is not the
question.

The question is if you should in our eyes misuse the behaviour of the
reference type.

However,

Furthermore, it only goes to confuse people who *do* understand
reference types. The first question I'd be asking myself is, "Why is
this returning anything? There's no point if it's just modifying the
object whose reference I'm passing in. Maybe it's copying the object
instead..."

It has nothing to do with understand it.

As there is in a void something (in a large program) that changes the
referenced object, than if that is not expected, it can take a long time to
find that. If the reference is returned you have a hint that it can be (and
mostly is) changed.

Cor
..

 

[Jon Skeet [C# MVP]]

Maybe I disappoint you, I know what a reference type is and others do
probably as well (at least Juli showed that as well), but that is not the
question.

I've never suggested that you didn't understand reference type
semantics. However, you've said that you don't think people ought to
*need* to understand them - and that I take issue with.

The question is if you should in our eyes misuse the behaviour of the
reference type.

The ability to read and modify data within an object via a reference is
part of the crucial semantics of a reference type.

Tell me, do you think the Array.Copy method is "misuse"?

However,


It has nothing to do with understand it.

Of course it does. It has everything to do with it, because I expect
that every part of a method signature is there for a purpose. If I
declare a method which takes 5 parameters, I expect all those
parameters to be useful. Likewise, if I declare that a method will
return something, there'd better be a good *reason* for it returning
it.

As there is in a void something (in a large program) that changes the
referenced object, than if that is not expected, it can take a long time to
find that.

But it *should* be expected due to the method name and documentation.

If the reference is returned you have a hint that it can be (and
mostly is) changed.

On the contrary - if something returns a reference, I'd expect that any
new data is in the object whose reference is returned. Returning a
reference in *no* way hints that one of the parameters has had its
contents changed. It just confuses the matter.

Jon

 

[Cor Ligthert [MVP]]

Jon,

I've never suggested that you didn't understand reference type
semantics. However, you've said that you don't think people ought to
*need* to understand them - and that I take issue with.

Where, you do real suprise me, that is something I never would write not
even in the slightest way, I have absolute the oposite opinion and thought
that I have often told that in this thread.

Are you not mixing up this thread with another one?

I try all the time to tell you in this thread that reference type itself is
not the topic.

The ability to read and modify data within an object via a reference is
part of the crucial semantics of a reference type.

Yes but it is not stated that the reference is only usefull as parameter in
a Method as you all the time are suggesting. The reference has more
purposes..

Tell me, do you think the Array.Copy method is "misuse"?

Yes

I like it more as this (but this one is newer)

http://msdn2.microsoft.com/en-us/library/a8ycds2f.aspx

Of course it does. It has everything to do with it, because I expect
that every part of a method signature is there for a purpose. If I
declare a method which takes 5 parameters, I expect all those
parameters to be useful. Likewise, if I declare that a method will
return something, there'd better be a good *reason* for it returning
it.

You can pass 5 parameters to a sub and do nothing with it that has to be
returned.
\\\
Option strict off
Private sub A (byval a as integer, byval b as integer, byval c as integer,
byval d as object, byval f as object)
Messagebox.show (a * b * c * d * f) 'can be write, print, sent or whatever
End sub
///
' that is where a sub in my opinion has to be used.

In any other way I find it C like programming, however I have the idea that
some mean that every method that has been used in C is OOP.

But it *should* be expected due to the method name and documentation.

Will I send you a program written with Dutch names and only Program language
semantic in English?
If a program becomes documentation or intelisence dependend, than it has the
criteria for me to be suspicious.

On the contrary - if something returns a reference, I'd expect that any
new data is in the object whose reference is returned. Returning a
reference in *no* way hints that one of the parameters has had its
contents changed. It just confuses the matter.

Can you reprash this because probably I don't understand it, it sounds so
strange for me that you can state this. I assume that you know that in a non
void method only the declared type is returned.

However every direct or indirect passed reference can be changed. That is
something that gives in my idea the misunderstandings and as I think about
it now should be prohibited. Because it is very easy to return any object or
structure.

Cor

 

[Barry Kelly]

I like it more as this (but this one is newer)

http://msdn2.microsoft.com/en-us/library/a8ycds2f.aspx

DataView.ToTable() instance method - it doesn't take any arguments, so
it appears not to be relevant to the discussion as I understood it.

-- Barry

 

[Cor Ligthert [MVP]]

Jon,

Before you misunderstand me, that is as I think about it now.

Because of backwards compatibility it is of course impossible still to
implement this in VBNet or C#.

Cor

 

[Jon Skeet [C# MVP]]

Where, you do real suprise me, that is something I never would write not
even in the slightest way, I have absolute the oposite opinion and thought
that I have often told that in this thread.

Are you not mixing up this thread with another one?

Absolutely not. Here's what you wrote:

"In my opinion the goal should be that it is not necessary to learn
basic
things."

Reference type semantics count as "basic things" IMO, which means that
to me you're suggesting that it shouldn't be necessary to learn
reference type semantics. As people don't tend to be born with a
knowledge of reference type semantics, anyone who is in the state of
understanding reference type semantics must have learned them.
Therefore, the quote above implies that you believe people shouldn't
need to know reference type semantics. It's pretty simple reasoning.

That's *not* a good goal IMO. Programming without understanding the
basics is never going to be a good idea.

I try all the time to tell you in this thread that reference type itself is
not the topic.

We disagree. Julie didn't understand what was going on because she
apparently thought it was the *object* that was being passed by value,
not the *reference* - until she was reminded. When she was reminded
about reference type semantics, it was obvious to her how the code
worked, as far as I can tell.

Yes but it is not stated that the reference is only usefull as parameter in
a Method as you all the time are suggesting. The reference has more
purposes..

I haven't stated (not even once, let alone "all the time") that
references are only used as parameters. Could you point out where I
supposedly stated that?

Yes

Wow. I suspect we'll have to agree to disagree on this then.

I like it more as this (but this one is newer)

http://msdn2.microsoft.com/en-us/library/a8ycds2f.aspx

That's no good if you want to want to copy stuff into an existing
array, however - which is often the case.

Consider reading data from a stream. The normal way of doing this is to
create a single buffer, and repeatedly read into it. Presumably you
object to Stream.Read's signature as well, thinking it should always
return a new buffer?

You can pass 5 parameters to a sub and do nothing with it that has to be
returned.

I never claimed that it did. I was making the point that every part of
a message signature should be useful (assuming you have complete
control over the signature). Whether parameters are used or not was
another example of this. I hope you would agree that it's confusing to
have parameters which aren't used?

In any other way I find it C like programming, however I have the idea that
some mean that every method that has been used in C is OOP.

You seem to blame a lot of things you don't like on C, whether or not
it has any basis on reality. (As an example, you have repeatedly
claimed that C# has "legacy functions" from C, and have always failed
to provide any examples.)

This has nothing to do with C, and everything to do with the idea that
not all method parameters should be effectively immutable within the
method. Yes, you need to document what changes will occur, but when the
point is quite often *solely* to change the object, I don't think
there's anything wrong with it.

Furthermore, I think it's *bad* to change a method to make it *look*
like it won't be changing the object referred to by the parameter, when
actually you still do. That's the effect the change you suggested would
have (where you just return a reference to the same object, having
changed the contents).

Will I send you a program written with Dutch names and only Program language
semantic in English?
If a program becomes documentation or intelisence dependend, than it has the
criteria for me to be suspicious.

Whereas for me it's suspicious if you don't have the documentation, or
it's inaccurate. There are *lots* of things which essentially require
documentation. In particular, when you don't understand something, that
should be the first place you look.

Can you reprash this because probably I don't understand it, it sounds so
strange for me that you can state this. I assume that you know that in a non
void method only the declared type is returned.

Of course. If you write a method which declares that it will return
something, I will assume there's a reason for that - that you're
providing me with more information than I had before. If I've passed
you a reference as a parameter, I clearly know what that reference is.
Therefore the implication is that you at least might return something
*other* than that reference - suggesting that you'd be copying the data
before modifying the copy and returning a reference to it.

(There is one exception to this, which is when a reference is returned
for the purposes of chaining, such as new
StringBuilder().Append("foo").Append("bar") etc. That's a different
case though.)

However every direct or indirect passed reference can be changed. That is
something that gives in my idea the misunderstandings and as I think about
it now should be prohibited. Because it is very easy to return any object or
structure.

So in order to effectively change *anything* in any parameter, you'd
have to copy the entirety of the data. Consider my StringBuilder
example again (I say "again" - you haven't even mentioned it yet).
Would you create a copy of the StringBuilder? I suspect you'll ignore
this paragraph too, but if you could address this issue it would really
get to the bottom of things, I think.

Note again that you specifically went against your own advice when you
suggested the change to Julie's method - you didn't suggest that the
data should be copied. You went ahead and changed the object - the only
difference was that you returned a reference at the end. How is that
any better?

Jon

 

[Cor Ligthert [MVP]]

Barry,

DataView.ToTable() instance method - it doesn't take any arguments, so
it appears not to be relevant to the discussion as I understood it.

May I asked why you did not answer this to Jon when he did the same with the
CopyTo method, but your statement is wrong.

http://msdn2.microsoft.com/en-us/library/h2b6ehaa.aspx

Cor

 

[Cor Ligthert [MVP]]

Jon,

See my other answer in this thread, it becomes to long, for me is it "I
wished it was".

Therefore I stop with this.

Maybe we discuss this again in future when we both have given our thoughts
some time.

Cor

 

[Cor Ligthert [MVP]]

Jon,

A single addition, this has nothing to do with C# or VBNet, if my wishes are
right, than they both suffer from legacy in this.

Cor

 

[Barry Kelly]

May I asked why you did not answer this to Jon when he did the same with the
CopyTo method, but your statement is wrong.

http://msdn2.microsoft.com/en-us/library/h2b6ehaa.aspx

This is a different overload - as far as I know, the factual statement I
made (http://msdn2.microsoft.com/en-us/library/a8ycds2f.aspx referring
to DataView.ToTable() instance method not taking any arguments) was
correct.

This one you now point to has no need to modify its arguments - its
purpose is to create a new instance. It doesn't mutate the values that
the caller passes it, so as far as I understood the discussion, I still
don't see how it's relevant.

Not to worry.

-- Barry

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

I must say that I agree fully with Jon in this matter.

If you would always return the result even when not needed, you would
have to rely heavily on documentation to know what the methods actually
do. They really turn into the black boxes that you talk about.

Take for an example the signature of a method that would add a watermark
to an image:

public Bitmap AddWatermark(Bitmap originalImage, int x, int y)

Assuming that the method returns the result even if it's not needed,
it's not at all obvious what the method does. It can either create a new
bitmap and return it, or draw on the original bitmap and return another
reference to it. As you need to dispose the bitmaps when you are done
with them, it's important to know if the method creates a new bitmap or
not, and you have to dive into the documentation to find out.

On the other hand, if the method only returns a value when needed, it's
obvious what the method does. If the method creates a new bitmap, it
will be returned. If the method doesn't create a new bitmap, it won't
return one.

If one should always return the result, there are quite some methods in
the framework that needs changing. Like Array.Sort, Array.Reverse,
Array.Clear, Array.Copy, Stream.Read, Buffer.BlockCopy,
StringBuilder.CopyTo, etc...

Jon,

You go out of the point, I never have talked about using references or not,
moreover I have said in this thread to use those in an object to pass and
return information.

Moreover, my point is not to use in normal situations the Sub or the Void to
change in an easy way referency types hidden in a method, but to return the
reference. Even if that is technical not needed (as I know). I nowhere have
told people not to learn reference types, I am not against guns (I once did
sport shooting), I am against the wrong use of guns.

Cor

 

[Cor Ligthert [MVP]]

Goran,

It is nice that you agree with Jon, however you are telling completly what
Juli and I am stating in this thread, so as Jon says that he agrees with
you, than he agrees as well that he was talking about another topic.

I have even stated this in my last message.

If one should always return the result, there are quite some methods in
the framework that needs changing. Like Array.Sort, Array.Reverse,
Array.Clear, Array.Copy, Stream.Read, Buffer.BlockCopy,
StringBuilder.CopyTo, etc...

Where I than add that it is impossible in my opinion because of backwards
compatibility.



Cor.

..

I must say that I agree fully with Jon in this matter.

If you would always return the result even when not needed, you would have
to rely heavily on documentation to know what the methods actually do.
They really turn into the black boxes that you talk about.

Take for an example the signature of a method that would add a watermark
to an image:

public Bitmap AddWatermark(Bitmap originalImage, int x, int y)

Assuming that the method returns the result even if it's not needed, it's
not at all obvious what the method does. It can either create a new bitmap
and return it, or draw on the original bitmap and return another reference
to it. As you need to dispose the bitmaps when you are done with them,
it's important to know if the method creates a new bitmap or not, and you
have to dive into the documentation to find out.

On the other hand, if the method only returns a value when needed, it's
obvious what the method does. If the method creates a new bitmap, it will
be returned. If the method doesn't create a new bitmap, it won't return
one.

If one should always return the result, there are quite some methods in
the framework that needs changing. Like Array.Sort, Array.Reverse,
Array.Clear, Array.Copy, Stream.Read, Buffer.BlockCopy,
StringBuilder.CopyTo, etc...

 

[Cor Ligthert [MVP]]

Doh,

My latest message can be misunderstood, I stated that I wished that it was
in another way but that it is impossible to do now with the languages C# and
VBNet because of backward compatibility.

Cor

I must say that I agree fully with Jon in this matter.

If you would always return the result even when not needed, you would have
to rely heavily on documentation to know what the methods actually do.
They really turn into the black boxes that you talk about.

Take for an example the signature of a method that would add a watermark
to an image:

public Bitmap AddWatermark(Bitmap originalImage, int x, int y)

Assuming that the method returns the result even if it's not needed, it's
not at all obvious what the method does. It can either create a new bitmap
and return it, or draw on the original bitmap and return another reference
to it. As you need to dispose the bitmaps when you are done with them,
it's important to know if the method creates a new bitmap or not, and you
have to dive into the documentation to find out.

On the other hand, if the method only returns a value when needed, it's
obvious what the method does. If the method creates a new bitmap, it will
be returned. If the method doesn't create a new bitmap, it won't return
one.

If one should always return the result, there are quite some methods in
the framework that needs changing. Like Array.Sort, Array.Reverse,
Array.Clear, Array.Copy, Stream.Read, Buffer.BlockCopy,
StringBuilder.CopyTo, etc...

 

[Jon Skeet [C# MVP]]

It is nice that you agree with Jon, however you are telling completly what
Juli and I am stating in this thread, so as Jon says that he agrees with
you, than he agrees as well that he was talking about another topic.

I have even stated this in my last message.


Where I than add that it is impossible in my opinion because of backwards
compatibility.

But the problem is that your reason is that it would be good to do if
it weren't for backward compatibility - whereas Goran and I think that
it's good that it's possible to modify the object an argument refers
to.

Furthermore, Goran's main point, it seemed to me, was that without a
return value it's pretty obvious that the method modifies the object.
*With* a return value it's a lot less obvious exactly what's going to
happen.

I had an interesting thought earlier, by the way - I find it somewhat
amusing that you'd have preferred it if a genuinely useful feature like
this was prohibited, but in the past you've defended VB.NET for
allowing static method calls to look like instance method calls. Now
that *really* reduces readability! (It's nice to know you can make it a
warning or even an error IIRC in VS 2005...)

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

So you have said that returning the result although it's not needed is
making the code less readable?

Goran,

It is nice that you agree with Jon, however you are telling completly what
Juli and I am stating in this thread, so as Jon says that he agrees with
you, than he agrees as well that he was talking about another topic.

I have even stated this in my last message.

If one should always return the result, there are quite some methods in
the framework that needs changing. Like Array.Sort, Array.Reverse,
Array.Clear, Array.Copy, Stream.Read, Buffer.BlockCopy,
StringBuilder.CopyTo, etc...

Where I than add that it is impossible in my opinion because of backwards
compatibility.



Cor.

.

I must say that I agree fully with Jon in this matter.

If you would always return the result even when not needed, you would have
to rely heavily on documentation to know what the methods actually do.
They really turn into the black boxes that you talk about.

Take for an example the signature of a method that would add a watermark
to an image:

public Bitmap AddWatermark(Bitmap originalImage, int x, int y)

Assuming that the method returns the result even if it's not needed, it's
not at all obvious what the method does. It can either create a new bitmap
and return it, or draw on the original bitmap and return another reference
to it. As you need to dispose the bitmaps when you are done with them,
it's important to know if the method creates a new bitmap or not, and you
have to dive into the documentation to find out.

On the other hand, if the method only returns a value when needed, it's
obvious what the method does. If the method creates a new bitmap, it will
be returned. If the method doesn't create a new bitmap, it won't return
one.

If one should always return the result, there are quite some methods in
the framework that needs changing. Like Array.Sort, Array.Reverse,
Array.Clear, Array.Copy, Stream.Read, Buffer.BlockCopy,
StringBuilder.CopyTo, etc...

Jon,

You go out of the point, I never have talked about using references or
not, moreover I have said in this thread to use those in an object to
pass and return information.

Moreover, my point is not to use in normal situations the Sub or the Void
to change in an easy way referency types hidden in a method, but to
return the reference. Even if that is technical not needed (as I know). I
nowhere have told people not to learn reference types, I am not against
guns (I once did sport shooting), I am against the wrong use of guns.

Cor

"Jon Skeet [C# MVP]" <[email protected]> schreef in bericht
I haven't used Cobol, but it sounds like it was using value type
semantics. That's okay, but you need to understand the efficiency
penalties of doing that - and acknowledge that it's *not* the .NET way
of doing things. Why fight against what the framework promotes?
You can transfer a reference to an address not being the actual address
that
is tranfered.
Care to rephrase that? It doesn't make a lot of sense at the moment.

Used in performs (advanced for loops) which I have never seen anymore
in a
language as advanced it is in extended Cobol versions.

But as I said, have your own ideas, I had the same as yours, mine is
changed, time willl probably learn if that sustains.
Well, the framework uses the pattern already. It's not like I'm coming
up with it on my own. It's also used in other platforms such as Java.
It's a pattern which works. It's efficient and readable - you just need
to know the basics of the platform and be capable of reading
documentation. If you can't do those things then you've got no chance
in the first place, IMO.

In my opinion the goal should be that it is not necessary to learn
basic
things. I assume that your new born kids will learn English without any
problem, while it is for a lot of children more difficult than their
first
language.
If you're suggesting that people shouldn't have to learn the difference
between reference types and value types, I couldn't disagree more.

Let's put this into a more concrete example. Suppose I have a method
AppendData which takes a StringBuilder and appends some data, either to
it or to a copy of it. By your reasoning the method should return a
StringBuilder, because people may not be aware that the StringBuilder
they pass in (as a reference) can be changed during that method.

Now, if they aren't aware that it can happen, they may well assume that
it *can't* happen. If you're going to cope with that possibility, then
you need to make sure you don't violate their assumptions - otherwise
their code will break. So, you'd better take a copy of the
StringBuilder, creating another one, and appending to that before
returning it.

Now imagine someone passes you a StringBuilder with 100,000 characters
in it. See the problem?

In this case, you actually suggested that you just return the same
reference having modified the object in-place. At that point, anyone
who doesn't understand the type system is probably going to end up with
errors sooner or later.


Compare this with my solution: educate people and document what the
method does. You can then write efficient and intuitive methods (names
like "Fill" or "Populate" generally give the game away) which don't
make assumptions that the caller is stupid.

 

[Cor Ligthert [MVP]]

Jon,

Furthermore, Goran's main point, it seemed to me, was that without a
return value it's pretty obvious that the method modifies the object.
*With* a return value it's a lot less obvious exactly what's going to
happen.

I have no idea why you state this, it is in my opinion not true, it is
possible to do in both exactly the same with a referenced object. I *wished*
that it was in both probihited

I had an interesting thought earlier, by the way - I find it somewhat
amusing that you'd have preferred it if a genuinely useful feature like
this was prohibited, but in the past you've defended VB.NET for
allowing static method calls to look like instance method calls. Now
that *really* reduces readability! (It's nice to know you can make it a
warning or even an error IIRC in VS 2005...)

I think you are mixing me up with somebody else, this is typical Herfried.
Maybe it was that in my opinion using static/shared classes is not real OOP
beside the main module. (I said *my opinion* everybody may have another
opinion).

I think that the module in VBNet is better to use for shared classes, but
than not as dumb written as mostly is done, I find this is a much nicer
resolution in VBNet. (This is an opinion just from the last month).

Module mymodule
Public Sub whatever(byval myobject as object) 'I Would normally never use
object but to keep it short.
messagebox.show(myobject.ToString)
End sub.
end module

This can be referenced as mymodule.whatever("I find this nicer")

Cor