EPICS Home EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

Format page
for printing


Search Tech-talk
2002  2003  2004  <2005>  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  <2005>  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>
Subject: Re: dataAccess V4 Ca client propertyId questions
From: Marty Kraimer <[email protected]>
To: EPICS Core Talk <[email protected]>
Date: Wed, 29 Jun 2005 11:33:01 -0500

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
Replies:
Re: dataAccess V4 primitive types Ralph Lange
References:
dataAccess V4 Ca client propertyId questions Marty Kraimer
Re: dataAccess V4 Ca client propertyId questions Kay-Uwe Kasemir
Re: dataAccess V4 Ca client propertyId questions Marty Kraimer
Re: dataAccess V4 Ca client propertyId questions Ralph Lange
Navigate by Date:
Prev: Re: More flexible record scanning Andrew Johnson
Next: Re: views Andrew Johnson
Index: 2002  2003  2004  <2005>  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: dataAccess V4 Ca client propertyId questions Ralph Lange
Next: Re: dataAccess V4 primitive types Ralph Lange
Index: 2002  2003  2004  <2005>  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·