I’m using introspection on a class to get a list of properties, and I’d like to skip over computed properties (without having to switch them to get/set methods). Is there any way to determine if a property is computed?
[code]dim ti as Introspection.TypeInfo
ti= Introspection.GetType(me)
dim p() as Introspection.PropertyInfo=ti.GetProperties
for each pi as Introspection.PropertyInfo in p
dim pt as Introspection.TypeInfo=pi.PropertyType
if pt.IsComputed=false then ////for example
…
[/code]
Getters and setters are not properties, they wrap a property. There just regular properties with a special naming. You’ll find them by doing
Dim mis() As Introspection.MethodInfo = ti.GetMethods()
For Each mi As Introspection.MethodInfo In mis
If mi.Name.Right(4) = ".Get" Then
// you have a getter
ElseIf mi.Name.Right(4) = ".Set" Then
// you have a setter
...
[quote=61989:@Eli Ott]Getters and setters are not properties, they wrap a property. There just regular properties with a special naming. You’ll find them by doing
Dim mis() As Introspection.MethodInfo = ti.GetMethods()
For Each mi As Introspection.MethodInfo In mis
If mi.Name.Right(4) = ".Get" Then
// you have a getter
ElseIf mi.Name.Right(4) = ".Set" Then
// you have a setter
...
[/quote]
If getters and setters are showing up in the method info list, it’s almost certainly a bug.
Of course my comment should read: “There just regular methods with a special naming.”
Joe, they are methods and that is not a bug. Computed properties (= getters and setters) contain code you write, they do not hold a value. So they are methods.
A lot in the IDE is framework internal naming convention stuff (opaque for us users unless you use introspection):
Thanks Eli, but that doesn’t really solve the problem of trying to list out all properties while avoiding computed properties.
Make a class with a computer property and throw this method in there:
[code] dim ti as Introspection.TypeInfo
ti= Introspection.GetType(me)
dim p() as Introspection.PropertyInfo=ti.GetProperties
for each pi as Introspection.PropertyInfo in p
dim pt as Introspection.TypeInfo=pi.PropertyType
dim nm as string=pi.name
MsgBox nm
next
[/code]
It will bring up a msgbox for the computed property and one for the protected, non computed variable.
Unless there is a way to link the GetMethods with the GetProperties, but that seems a bit messy.
That’s the way I do it. Get the names of the .Get / .Set methods and “subtract” them from the properties.
Guess that’ll have to do. Thanks for your help, Eli.
Those .Get and .Set methods don’t show up unless there’s actual code in them. So an empty computed property dosen’t generate any methods to identify it (and had me thinking you all were crazy).
Most likely at least one will be coded and Elis strategy is sound. But just for your info an unsanctioned/unsafe/unreliable/unfullytested way is to use the mAttributes property of PropertyInfo itself. Apparently, instance computed properties have mAttribute 0 (private/protected) and 1 (public), while shared have 2 (private/protected) and 3 (public). Regular properties have higher values.
[code] //first get the propertyinfo of the propertyinfos mAttributes property
dim tipi As Introspection.TypeInfo = GetTypeInfo(Introspection.PropertyInfo)
dim papi(), piAttrib As Introspection.PropertyInfo
papi = tipi.GetProperties
for i As integer = 0 to papi.Ubound
if papi(i).Name = “mAttributes” then
piAttrib = papi(i)
exit for i
end
next
if piAttrib = nil then break //didn’t find mAttributes
//scan a class’ propertyinfos, checking their mAttributes value
dim ti As Introspection.TypeInfo = GetTypeInfo(Class1)
dim pa() As Introspection.PropertyInfo = ti.GetProperties
for i As integer = 0 to pa.Ubound
if piAttrib.Value(pa(i)) <= 3 then
//is computed
else
//is regular
end
next[/code]
Didn’t know that Introspection.MemberInfo could be introspectioned. Thanks, Will.
Given that I wrote some of the code in the compiler and runtime to implement introspection, I think I’m in a fair position to say that it is a bug that those methods are showing up in introspection. The fact that they’re methods is an implementation detail.
“Unsanctioned/unsafe/unreliable” is the kindest way of describing this approach. If you want to see this functionality exposed via PropertyInfo, please file a Feedback request instead of making your code depend on things that will change in the future.
Joe: thank you for the explanation. This is one of the rare cases where it’s a feature not a bug is applicable.
Should I file a request for an IsComputed property on PropertyInfo (and perhaps also mention that computed properties then could be removed from the MethodInfo array)?
[quote=62194:@Eli Ott]Joe: thank you for the explanation. This is one of the rare cases where it’s a feature not a bug is applicable.
Should I file a request for an IsComputed property on PropertyInfo (and perhaps also mention that computed properties then could be removed from the MethodInfo array)?[/quote]
Yes, please file a feature request for IsComputed. As for the bug where computed property accessors show up in the MethodInfo array, it’s already been fixed.
Just checked in Feedback, and guess what: you yourself already requested an IsComputed property - more than five years ago:
[quote]Joseph Ranieri on 13.08.2008 at 10:45
It would be nice if PropertyInfo had an isComputed flag. This is useful when writing debugging tools to find memory leaks, because you can avoid calling getters which return new object (like Window.Graphics).[/quote]
Just for reference: Feedback:3827 now says Implementd
PropertyInfo.IsComputed already exists in both old and new frameworks.
http://documentation.xojo.com/index.php/PropertyInfo.IsComputed
http://developer.xojo.com/propertyinfo$IsComputed
My comment dates back to January 2014.
It’s 2015!?! My eyes date back even further!