Re: dataAccess V4 Ca client propertyId questions

[Marty Kraimer <mrk@aps.anl.gov>]

I do agree that find and traverse and propertyViewer are a way to introspect.
But yes I was looking for something more for introspection, i.e. type_info.
Perhaps this caused much of the confusion.

I suspect, however, that specifying how type_info is defined will lead to lots of debate starting with the definition of primitive types and then strings and arrays and then structured data.

In the V4 dbdClass wiki I encountered the same problem and could not resolve the debate even with myself.
Also why should dbdClass do this itself instead of a common approach. But I think this will cause a serious debate.

Marty


On Jun 29, 2005, at 9:13 AM, Ralph Lange wrote:

> Marty Kraimer wrote:
> > On Jun 28, 2005, at 8:28 AM, Ralph Lange wrote:
> > > I don't understand. The main feature of dataAccess *is* an introspection interface. Always has been. From day one for the last five years. The traverse() methods have been there for ages.
> > > So: By supporting dataAccess I am supporting an introspection interface. Of course.
>  (from Latin introspicere, “to look within”).
>
> For me, the concept of the dataAccess interface itself *is* introspective. The client uses "find" and "traverse" methods rather than a fixed number of fixed structured types (as in CA for V3). There's no way for the client to know what's behind the DA interface unless querying it. It has to "look within" to find out.
>
> (It seems to me that) for you the term introspection only applies if the client has a method that explicitly returns the underlying primitive type of a piece of data.
>
> While I agree that we need such functionality, I still think that your (assumed) definition of the term 'introspection' is too narrow.
>
> > I take it to mean that the following is done when a CA client introspects
> >
> > CA provides a propertyCatalog.
> > The client implements a propertyViewer which has all the overloaded reveal methods. By seeing which overloadsed method is called it can determine what type associated with the propertyId.
>
>
> Note that even such a (admittedly too complicated) way of getting the type info would still be perfectly introspective. (According to my definition.)
>
> Ralph