Well VB.Net has what appears to be a way of defining accessors that actually allows one to use the accessor as if it where a variable (assignment and fetching) from outside the class. A class definition would look like this:

Public Class Container Protected mContents As Integer

Public Property Contents() As Integer Get Return mContents End Get

Set(ByVal Value As Integer) mContents = Value End Set

End Property

End Class

Of course the getter portion of this is really already part of Smalltalk because it is basically a unary accessor. So there no significant difference with the getter. Of course the first thing you will notice is that the Property (getter and setter combo) does not have the exact same name as the variable. Why? Because it can't; the names will collide and they're case-insensitive. So instead you are forced to place an extraneous character in front of the name. This is going to make the code harder to read and is just plain stupid. Many examples I have seen use lowercase m (I think for "me" or "my"). So basically let's make you remember more syntax and keywords so you can do this:

New Container().Contents = 5

Instead of:

New Container().Contents(5)

Since it really doesn't save anything over:

Public Class Container Protected mContents As Integer

Public Sub Contents(ByVal anInteger As Integer) mContents = anInteger End Sub

Public Function Contents() As Integer Return mContents End Function

End Class

I think I will stick with one thing to remember and one way to code (at least my code) then deal with special syntax. Furthermore, I will consider returning self from the setter in the future (The default in Smalltalk).

For anybody following this Blog. Sorry for not posting in a while. The holidays have been extremely busy. And kept me away from much progress with VB.net. Hopefully that will checnge now.

Visual Basic.NET How to program by Detiel - This is the main book I am using. And I think you have to go pretty deep into the book to see any serious OO. Dont get me wrong I do like the book so far. Tons of info its 1500 pages.

The other book is the Oriely Book mentioned above. I may have been a little quick to judge this book. But my feeling is that the book talks about some OO constructs as it relates to VB early on. But it does this in very bad fashion. Basically it tries to go through a giant list of unrelated things, giving a glimpse of each; some of which are OO related. Could be good for an OO expert, but I would not recommend it for a VB programmer trying to learn OO. At least not at this point

One thing that I have noticed so far (Not sure if this will continue to be true) is that the names shown in the properties tool in VS are the same as the accessors that one would use to change the property through code. This can be a big time saver. And in an OO world this makes a lot of sense. After all both cater to the same audience (the developer). Now of course there will be time when they should not match up directly, or when more complex behavior is provided by the object; but a great majority of the time this should be the pattern and would help Smalltalkers.

Well I use to get fairly upset about the number of widgets VB programmers had available to them. And that they are mostly native widgets that looks and acts better, for the most part. And of course all of those wonderful properties that code be adjust and without the need to write code or even hunt them down. Well I am not as envious anymore. To clarify I come mainly from a VW background.

I have discovered some nasty things about the stock .Net VB widget. Take for example a simple text box. Which is much like a text box and input field in VW. Did you know that you cannot pick the type of data (kind of object) you get from field when retrieving its contents. Not even date or numbers. It is text. It is always. No property for this. With the static typing and automatic casting that takes affect this is less noticeable at first. Even though there are some properties to restrict the input of characters these are extremely limited, most are like uppercase only.

How about a property for mapping that data so that it gets put into an instance variable when it changes. I thought at minimum this would be possible in the Form (Kind of like ApplicationModel) object. And I was hoping for being able to map it to the domain object. Nope on both counts. You are responsible for reaching into the widget and pulling out the text and converting it and adapting it into you domain. No mapping, no value holders, no aspect adaptors, not Type converters, pluggable adaptors, etc. Hey look at the upside - since there is no type you never have to worry about what it takes to add you own custom types.

Know what else, no format property. Can't even format a date's text into a form you pick. Take that a step further and you can forget about PrintConvertors.

Of course many of these issues can be solved by finding or purchasing third party widgets. But that opens a bunch of other issues that I don't have answers for at this time. Like is there a difference between VB and VB.Net controls and if so how will this affect things going forward.

Well this is not a complete dislike. If they get it fixed to work all of the time it may actually be pretty cool. Or at least it may be a cool reason to have Static typing.

Well when I started using VB in Visual Studio, I saw how it started to complete code for me. Basically I type in a class name put the "." Because I am going to send it a message and it presents me a list of messages that the class understands. This appears to include inherited messages. Hey that's pretty cool. Even if I already know the message it can save me some typing. The I thought, well maybe this declaring of the type of object in a variable is not so bad after all. It can now use that information to help me find messages to send. AHAHANNNN No I guess it can't. I DIMmed a variable to contain an instance of random.

DIM Rand = New Random()

Then typed the variable name and the "." To indicate a message sends.

Rand.

And nothing happened. No List of messages was presented. So I typed the first letter of the message. Still nothing. Well this was worthless. So the code complete appears to be worthless. Well actually it is just flaky. It does not get along with the implied Dimming I used. One must explicitly Dim for this to work.

DIM Rand As Random = New Random()

So save time one place and pay for it another. Really silly when the first version was good enough to pass the syntax checker and compilation.

I am mainly a VW person so I speak mainly from that standpoint. Visual Studio has a Multi-Level Undo. This works while editing code and GUIs. The code is not that big of a deal, I don't find myself missing that in VW. However, I certainly miss it in the GUI editor. There have been too many times I have made some change and then accidentally dragged a widget or group somewhere; screwed up the painter in some other way. My choice is normally to try to fixed what I messed up, or abandon my changes and reapply them. The latter is normally the route I take.

You can actually declare a temp variable with the same name as an instances variable. And you do not even receive a warning. These variables will not trash each other, but this is still silly and potentially dangerous. One could potentially be editing a large method and declared a temp variable that is used later in the method as an instance variable. Of course this would have undesired effects.

There are 137 keywords in VB.NET. And this does not include constants that are widely used. Of course many of these are part of the syntax of various statements, which further complicates the learning process. Compare this to Smalltalk that has 6 reserved words. Even after adding in the handful of semi-reserved (these can be used if you really want) words that that the optimizer users, and it is still tons less to remember and learn.

The 2 VB.Net books I have do not start out with any sort of object feel to them. Actually, I am 200 pages into one and the examples are still not Object-Oriented. They have mentioned classes and methods. When methods are mention it seems strange because the syntax is that of sub routines and functions. Syntax is not my main concern here. I am beginning to wonder how OO many VB programmers and programs will be since this does not appear to be a first priority. It reminds me of many C++ programmers I knew that really just wrote C in a C++ compiler.

This Blog covers the learning experience of one seasoned Smalltalker (myself) as I move to VB.Net. It should be understood that while I am seasoned in Smalltalk, I know many different programming languages. While very familiar with BASIC, my exposure to VB over the years has been very limited. In the past I have spent quite a bit of time reading about VB and .NET but really never touched either until now. So this will actually cover my learning experience as it relates to VB, .NET, and Visual Studio (since it has so long since I touched VS). My hope is that both Smalltalk and .NET vendors learn from what is posted here.

Be fully aware that sometimes I will post information here that is not correct. This will not be on purpose. It will just be due to my misunderstanding of the new environment I am entering. However, this confusion itself is a sign of a problem and should probably be considered by .NET vendors. Feel free to correct me if you like through email.

Oh BTW, I decided to remain anonymous here for several reasons. One is the concern that a prospective employer will view me as a Smalltalk bigot. Although I know not yet what I will post, for you are with me at the start of my journey.

I am going to attempt to classify posting into VB Likes, VB Dislikes, and Differences. The first 2 have obvious meanings. The third will mainly contain items where I see significant advantages in 2 contrasting approaches. Of there will be items that will not fit cleanly into one category, but will be placed there anyway.

It may be helpful to know that I am mainly learning from 2 different VB.Net books plus various online resources.