The VB.NET Static declaration:
http://msdn.microsoft.com/en-us/library/z2cty7t8.aspx
The only reference I can find to this question is from 2008:
http://forums.asp.net/t/951620.aspx?what+is+the+equivalent+of+static+from+vb+net+in+c+
Is there an equivalent in recent versions of C#, or still not present? Is there anything particularly wrong about using Static in VB.NET?
C# does not support it and probably won't be because it somehow violates object programming idea of state being part of object, not a method.
Of course one can say that it is only syntactic sugar, and he/she will be event quite right. But still, looking through class code, we expected description of its state variables as a fields of class. Otherwise we should find for it in each and every method.
So this can be simply seen about some high-level decision and your millage may vary here.
Personally, I like the VB procedure-level Static, even if it's not "pure" enough for some folk.
You can set it in declaration and forget it:
Static oClient As HttpClient = New HttpClient()
There's no checking whether a module-level variable needs to be instantiated or not:
If moClient Is Nothing Then moClient = New HttpClient()
And, silly me, I always expect that there is equivalency between C#.NET and VB.NET but I've learned that clinging to that concept is folly, unfortunately.
Related
Trying to program 'with immutability in mind' in VB.NET can be a challenge.
In many cases, creating classes with a parametrized constructor and properties with no setters is a pretty good way to create objects that are immutable (from outside the object).
Sometimes it would be more practical to just use the VB.NET ReadOnly keyword, but:
If the data type of the variable is a reference type, such as an array
or a class instance, its members can be changed even if the variable
itself is ReadOnly.
See here.
Is there a code analysis tool or simple solution that can give me a compilation warning if for instance a string array that is declared ReadOnly has one of its members changed?
That would make the ReadOnly keyword so much more useful. Or is it possible to define such a rule myself in Visual Studio 2022?
Not striving for (functional programming-esque) purity but such an extra check to make the ReadOnly keyword more useful would be pretty handy, so hopefully there is a straightforward way to get such a code check!
I have de-compiled some old code from a legacy VB.NET app using ILSply and this line has appeared:
Operators.ConditionalCompareObjectEqual(safeDataReader["isLoader"], -1, false)
I'm aware this is compiler generated, but its not advised that this code is used in application source code. My question is why is this the case and what should it be in 'normal' code?
The documentation for the method says it right there:
Represents the overloaded Visual Basic equals (=) operator.
Why? I don't "know", but it's easy to make an educated guess.
The semantics of the "=" operator in VB.NET are just a bit different from those of C# and the standard Object.Equals(). The semantics are inherited from VB6 and cannot be changed for backward compatibility reasons. Obviously this method implements the VB6 semantics for the compiler.
It would make an interesting read to come up with a systematic analysis of the differences.
Further thoughts:
The reason it's "not recommended" is because there is no reason to call the method from VB.NET: just use =. In C#, there is no particular reason to invoke the VB6 semantics so the method doesn't make a lot of sense there either.
Obviously, if you are compiling C# code generated from VB.NET, then those are special circumstances: calling the method is the right thing to do, unless you're willing to take the time to analyze the code and prove to yourself that the standard = cn be substituted safely.
I have a problem in understanding OOP...
This is it :
Sometime's you create an object with this syntax:
Object ObjectName = new Object();
But sometimes, we don't need to do that like in Android:
Textview TextviewName;
Or in J2ME:
form formName;
I already searched it and I got some information (but not sure) that this is because of static method... is it true? I think it has a relation with Polymorphism.. is it true?
Thanks all.
PS : Sory if I made some mistakes, English is not my native languange :D
Forget static methods - they're not relevant here. I'd advocate only looking at static methods / elements when you've truly grasped what objects are.
In Java, you can do this:
Object object;
Just as well as you can do this:
Object object = new Object();
In the first example, you're creating a reference but you're not populating that reference with anything, in the second example you're creating a reference and populating it with a new object, on which you can call methods, modify values and so on.
If you try and call methods on the first declaration you won't be able to - there's nothing there. Depending on the language and how you've declared it this might produce an error at runtime or a compile time error (Java does both depending on whether it's a field or a local variable.) The principle though is the same for all OO languages, you can't dereference (call methods, fields, etc.) on a reference that hasn't been populated, because in effect you're trying to call a method on something that isn't there.
you are mixing different languages and it's not the case of static methods nor polymorphism..
i suggest to read a good book of OOP beginning with the basis.. you can find "Thinking in c++" for free on the net..
Your Textview would not be initialized. Any try at using it would result in a NullReference error. In order for an object to actually be created, you have to use the new syntax or a function that returns a valid object.
However, this is a syntax-dependent issue, so first decide what language you want to study. If your Textview had been declared in C++, it would actually create an object, on the stack.
Every time I write trivial getters (get functions that just return the value of the member) I wonder why don't oop languages simply have a 'read only' access modifier that would allow reading the value of the members of the object but does not allow you to set them just like const things in c++.
The private,protected,public access modifiers gives you either full (read/write) access or no access.
Writing a getter and calling it every time is slow, because function calling is slower than just accessing a member. A good optimizer can optimize these getter calls out but this is 'magic'. And I don't think it is good idea learning how an optimizer of a certain compiler works and write code to exploit it.
So why do we need to write accessors, read only interfaces everywhere in practice when just a new access modifier would do the trick?
ps1: please don't tell things like 'It would break the encapsulation'. A public foo.getX() and a public but read only foo.x would do the same thing.
EDIT: I didn't composed my post clear. Sorry. I mean you can read the member's value outside but you can't set it. You can only set its value inside the class scope.
You're incorrectly generalizing from one or some OOP language(s) you know to OOP languages in general. Some examples of languages that implement read-only attributes:
C# (thanks, Darin and tonio)
Delphi (= Object Pascal)
Ruby
Scala
Objective-C (thanks, Rano)
... more?
Personally, I'm annoyed that Java doesn't have this (yet?). Having seen the feature in other languages makes boilerplate writing in Java seem tiresome.
Well some OOP languages do have such modifier.
In C#, you can define an automatic property with different access qualifiers on the set and get:
public int Foo { get; private set; }
This way, the class implementation can tinker with the property to its heart's content, while client code can only read it.
C# has readonly, Java and some others have final. You can use these to make your member variables read-only.
In C#, you can just specify a getter for your property so it can only be read, not changed.
private int _foo;
public int Foo
{
get { return _foo; }
}
Actually, no they aren't the same. Public foo.getX() would still allow the internal class code to write to the variable. A read-only foo.x would be read-only for the internal class code as well.
And there are some languages that do have such modifier.
C# properties allow to define read only properties easily. See this article.
Not to mention Objective-C 2.0 property read-only accessors
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocProperties.html
In Delphi:
strict private
FAnswer: integer;
public
property Answer: integer read FAnswer;
Declares a read-only property Answer that accesses private field FAnswer.
The question largely boils down to: why does not every language have a const property like C++?
This is why it's not in C#:
Anders Hejlsberg: Yes. With respect to
const, it's interesting, because we
hear that complaint all the time too:
"Why don't you have const?" Implicit
in the question is, "Why don't you
have const that is enforced by the
runtime?" That's really what people
are asking, although they don't come
out and say it that way.
The reason that const works in C++ is
because you can cast it away. If you
couldn't cast it away, then your world
would suck. If you declare a method
that takes a const Bla, you could pass
it a non-const Bla. But if it's the
other way around you can't. If you
declare a method that takes a
non-const Bla, you can't pass it a
const Bla. So now you're stuck. So you
gradually need a const version of
everything that isn't const, and you
end up with a shadow world. In C++ you
get away with it, because as with
anything in C++ it is purely optional
whether you want this check or not.
You can just whack the constness away
if you don't like it.
See: http://www.artima.com/intv/choicesP.html
So, the reason wy const works in C++ is because you can work around it. Which is sensible for C++, which has its roots in C.
For managed languages like Java and C#, users would expect that const would be just as secure as, say, the garbage collector. That also implies you can't work around it, and it won't be useful if you can't work around it.
Hello i Have a programa that has starts in a main sub, it executes some code and after that code it opens a form using
System.Windows.Forms.Application.Run(General)
General is a form but also a class, so I wonder what it the pros or cons of using :
System.Windows.Forms.Application.Run(General)
vs
Dim gen as general
System.Windows.Forms.Application.Run(gen)
In the first I am opening a form using the name of the class, and I read that it is best to declare the instance as an object variable.
So far I used the first approach without any problem.
Thanks for your comments !
Yes, your first code snippet gives OOP purists the shivers. Application.Run() requires a form object, you are passing the form type. That this is possible is an anachronism carried over from VB6. It is admittedly very bad style, it prevents programmers from understanding the difference between a type and an object. Something that's crucial to understand to get ahead with object oriented programming. It is also quite lethal when you start using threads.
Your second snippet is closer to what's needed, except that it cannot work. You pass an uninitialized object to Run(). Fix:
Dim gen as General = New General()
System.Windows.Forms.Application.Run(gen)
Or taking advantage of VB.NET syntax:
Dim gen as New General
System.Windows.Forms.Application.Run(gen)
Or since you never actually need the object in the Main method:
System.Windows.Forms.Application.Run(New General())
In the last snippet, you're passing a null reference to the Run() method. Don't forget to create an instance of the form first.