How about GetTypeInfo(Class.Property) -> PropertyInfo?

General
1

To get PropertyInfo on a particular property, we currently have to cycle through all the properties of the class’ TypeInfo. What I’d like instead is something like this:

dim prop as Introspection.PropertyInfo = GetTypeInfo( MyClass.MyProperty )
// or
dim c as new MyClass
dim prop as Introspection.PropertyInfo = Introspection.PropertyInfoOf( c.MyProperty )

Here’s an example of where I’d use this. We have an Orm framework that let’s you define a Converter for a property. A Converter has ToDatabase and FromDatabase methods that work to massage our data the way we want. For example, we prefer empty strings to be stored as NULL or some fields to be encrypted when written and decrypted when read. Our converters do this and more.

But during setup, the only way to assign a converter is by property name. The event looks like this:

Event FieldConverterFor(propertyName As String, propInfo As Introspection.PropertyInfo) As OrmBaseConverter
  select case propertyName
  case "MyProperty"
    return NullOnEmptyConverter.GetInstance
  end select
End Event

Notice we pass in the PropertyInfo, but there is no way to compare it directly. This means, if we change a property name, we have to remember to go change the text behind it too.

If we were passing in a class, we could compare with if Introspection.GetTypeInfo( someClass ) = GetTypeInfo( MyClass ) then..., and I’d love to do the same with a property. We could then rewrite our code this way so the compiler could help prevent errors:

select case propInfo
case GetTypeInfo( MyClass.MyProperty )
...

Comments before I file a feature request for this? And @Joe Ranieri , is it even doable?

2

How would you deal with a class like this:

Class MyClass
  Dim Foo As Integer
  Sub Foo()
  End Sub
  Sub Foo(x As Integer)
  End Sub
End Class
4

Interesting, I hadn’t considered that.

I guess one of two ways: If you think you’ll ever introduce a way to get MethodInfo directly, then it would have to be with new calls, e.g., GetPropertyInfo, GetMethodInfo. Otherwise, if GetTypeInfo only works on Class or Property, the presence of same-named methods wouldn’t matter. GetTypeInfo( MyClass.Foo ) would always mean the property.

(I’m sure there is a valid use-case, but why you’d want to name methods the same as a property eludes me.)

5

Question, why would that be a problem ? If there is, I’d like to know so I may support your request.

6

[quote=320472:@Kem Tekinay]
I’m sure there is a valid use-case, but why you’d want to name methods the same as a property eludes me.[/quote]
That you might not consider doing this doesn’t mean no one has or will :stuck_out_tongue:

7

In my example (matching a property in a Select Case statement), how would you match a property without resorting to a name comparison somewhere? I simply can’t see a way currently, and as soon as I use the property name, the compiler stops helping me.

8

introspection stops helping you as far as the compiler is concerned about the second you use it since its all runtime information :slight_smile:

When I’ve done code like this before it used code generated ahead of time from the db model and never dynamically so the compiler could actually do type checking at compile time not runtime

9

If my wish is fulfilled, the compiler would help.

if propInfo = GetTypeInfo( MyClass.Prop ) then ...

In the future, if I change the name of the property to something else or delete it altogether, I won’t be able to compile.

10

That still doesn’t fix the fundamental issue that you cant tell if you have type mismatches, or other issues the compiler can/should catch for you, at compile time
Using introspection means you cant tell until runtime - there’s no way around that.
So you pretty much have to have 100% code coverage for tests to catch anything like this.

What I mentioned does catch the errors at compile time.
It had to because I wrote that before introspection existed way back in 2005/2006

11

<https://xojo.com/issue/47502>