Experimental Physics and Industrial Control System
|
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 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|