extending Object type?

[JaedenRuiner]

It has been one of those years, that well, VB.net is becoming more acceptable and so I must by dint of necessity of survival work within its confines, but it is utterly moronic.

Every language has a base "object" type. Now, granted in the older days of structured programming into the early days of the OOP revolution there were things called "simple" types, which had no need of the object overhead, as they were a byte or 8 in size and could easily be realized with registers or small stack pushes/pops. Byte, Char, Int, Word, Long, DWORD, Real, Single, Float, Double, you name it, those "simple" types were just that...simple.

however, with the advent of the further OOP design, I must say VB comes in dead last.

If everything is an object than everything is an object. VB seems to be designed so complete idiots (and i've met quite a few who've managed to obtain degrees) can program. It does all the work. The problem is that it doesn't allow a real programmer to actually program.

now this may seem a bit over kill, and in the past i defined something like this for many languages to handle a coding "standard":

<System.Runtime.CompilerServices.Extension()> _
   Public Function IsValid(ByVal self As Object) As Boolean
      Return (self IsNot Nothing)
   End Function

it may seem pointless,but the idea is that if everything is an object, I can very easily determine if any of my reference types are valid to be dereferenced, and in the grand scheme of the JIT I would expect the optimizer to inline this extension function. However:

dim x as object
if x.IsValid()

Brings up a "late binding" error. Why? An object is an object is an object. What the hell does it care what kind of object it is...What kind of type checking does it need to do to determine if an object has a reference? I'll tell you: none, vb is just moronic.

There are several "methods" that work on every object:
Equals(), GetHashCode, ReferenceEquals(), GetType(), and ToString()...and frankly, this little tiny extension method is the exact same as those, and if it is not, I demand the power to create it as such. An Integer type, which is supposed to be a simple type, can easily call Integer.GetHashCode() and hey, an Integer defined type can even call my little extension above, which is rather erroneous because an Integer type is rarely if ever set to "nothing", but it still can be done. So if every type can be set to Nothing, and thus every type subsequently inherits from object, then why the idiocy in not allowing a global extension that utilizes this universality?

So we can turn Option Strict off, which then causes a massive slow down in the application performance (which i've directly noticed since i turned it on) because of type checking it should never have been performing. as a programmer, if I (or you) don't know what type something is in our code then we don't deserve to be programming and should go back to fast food service.

It is ever so frustrating to call myself a programmer, and then to recognize that everything I know is utterly useless when dealing with a language like VB. Even java (for all its limitations) was better in handling these things, for unlike VB, at least in java, everything truly is considered to be an Object.

 

[JohnH]

The Visual Basic Team : Extension methods and late binding (Extension Methods Part 4)

 

[JaedenRuiner]

First, I put this in the debate section because it wasn't a question. I know why they did what they did...I just disagree.

In the case of late bound calls, however, we can't use the same shadowing semantics that we do with early bound method calls because we don't know the actual type of the object we will be calling the method on, so we don't have a list of methods we can check against at compile time. As a result, the only way we could prevent extension methods from completely breaking existing late bound code was to prevent them from being used on anything typed as object.

That's my issue. I can't do Late Bound Method Resolution with Option Strict ON. So if Option Strict Is ON, the Object Extension method, by very definition can't break the code.

I recognize completely how the Late bound/early bound method resolution works because I've had to do Object V_Table hacking in Delphi and C++, so i understand that at run time, there has to be some dynamic allocations and look ups with the method address v-table to determine at run-time if an object retains a method of said name, as well as if the method parameters match an existing declaration. However, if the Option Strict is ON, this element of the late bound v-table look up should be eliminated, or at best bypassed, because the option strict enforces a guarantee of early bound v-table method resolution.
Thus, If I say:

public class C1
  public Sub Method1
  end sub
end class
public class C2
  public sub Method1
  end sub
end class

<Extension()> _
Public Sub Method1(byval O as Object)
end sub

dim x as Object

if SomeCondition() then
   X = new C1()
else
  X = New C2()
end if

Given that scenario, with Option strict OFF there can be some confusion, because of the late bound method resolution at run time, which means that if the parameter definitions are in any way similar between the three methods, from C1 to Extension, or C2 to Extension, that would cause a severe hitch, but as I have noticed with other such circumstances:

<Extension()>
public Function In(of T)(item as T, paramArray Vals() as T) as boolean
  return vals.IndexOf(item) > -1
end function

Public Enum Sqlcondition
  LessThan
  Equal
  GreaterThan
  [In]
end Enum

dim x as SqlCondition

X.In(LessThan, equal)

This creates a problem, because the compiler cannot determine (for some odd reason) that the nature the .In() call is actually a call to the extension, yet the compiler still attempts to resolve the .IN as a enumerated value within the SqlCondition type. Thus I have to Type Cast that specific enum to integer for the extension method to work, but in this circumstance it makes some sense (not too much because an enumerated value can't be a method) and I don't mind the strict enforcement of a type cast in this situation.

However! With option Strict ON, the first code segment dealing with classes C1 and C2:

dim X as Object
If SomeCondition
  x= New C1
else
  X = new C2
end if

X.method1 <- Raises a Late Bound ERROR!!!!!

The above does not work, because of the necessity of the option strict requiring the Early bound method resolution. Thus a consistent compiler would resolve the effect in this manner:

X.Method1() -> Calls the Extension
If TypeOf X is C1 then DirectCast(X, C1).Method1 -> Calls C1.Method1
If TypeOf X is C2 then DirectCast(X, C2).Method2 -> Calls C2.Method2

Thus, the existence of the Option Strict being ON in this case puts the onus of Type Verification on the Programmer instead of on the compiler at run time. This is beneficial in many ways, reducing the amount of run-time type checking and v-table method resolution, since at compile time the resolved method address is already staticly bound. But as that article pointed out and what I was referencing in my debate of X language versus VB:

This is a little unfortunate, as it is an inconsistency in the language, but we felt it was much better in this case to be safe than it was to be consistent.

I completely disagree with that mentality. I prefer a consistent language to a safe one, and If I screw up, well, that's because I suck, and the same for everyone else. Those limitations are in place for programmers that don't know how to do their job, or are at best lazy about it. I am not, and I know the type of everything at every moment in my code...I have never had a "type" conflict or other such glitch as they are suggesting might occur here when I had Option Strict OFF, but realizing that with option strict off, the run-time type checking and v-table method resolution for all my objects was slowing down the processing I switched it to ON to eliminate some of that unnecessary over head.
This is why I had this placed in the debate forum to see what may come of other explanations and variations in languages...perhaps C# has some different effects better/worse than VB in the .net environment, or perhaps a compare contrast of differing languages, or programming techniques. I prefer consistency in my language because the concept of "safe" = "handcuffs", but perhaps others would suggest a differing point of view about how a safer language might create ease in portability and multiple programmer standardization. etc, etc, etc.

 

[JohnH]

I looked through your first post again and can see no indication that you knew this fact, only a description of the problem and a "why?". In my book that's is just a simple question to a technical VB.Net implementation. But if you want to debate this issue you know all about go ahead, I have some doubt you get more feedback from the resposible team, though. It sounds to me they only had the choice of including Object type or not, not distinguishing between late/early bound calls.