On Friday 08 July 2005 01:23, Andrew Johnson wrote:
> Benjamin Franksen wrote:
> > What I proposed for the IVOA/IVOV example is easily adapted to
> > other scenarios, like simulation stuff, or alarm limit handling.
> > Ok, all this needs a developer who writes the code and (more
> > importantly) designs an appropriate interface that is general
> > enough to be used in any record type that needs such a facility.
>
> I think you persuaded me about that, although I think I might
> simplify your syntax a little (and forget what I said earlier about
> separating class and struct). How about this DBD syntax:
>
> struct (drvLimits, ValType) {
> field(high, ValType)
> field(low, ValType)
> method("STATUS constrain(ValType &value)")
> }
I'm fine with this. I didn't give the concrete syntax a lot of thought.
Personally, I don't like the C++-template syntax at all, it is much too
verbose for my taste. The above proposal is better, although one could
nitpick that it is a bit irregular, since the first element of the list
in '(structName, TypeVar1, TypeVar2,...)' has different meaning than
the following ones. I don't have a better proposal at hand, though.
Another point: What is the use of the method definition, apart from
generating a C++ member declaration? If there is no other use, we can
avoid it by using a regular top-level procedure, as shown in my
proposal on the wiki. I ask because I find it somewhat ugly to cite a
foreign language (C++) term inside the dbd file. I know, we already do
this for DBF_NO_ACCESS fields, but I never liked that one either (and I
believe it can be avoided, too).
> The presence of one or more ValType arguments after the struct name
> causes a template struct definition to be generated (without it, we
> just get a regular struct definition):
>
> template <typename ValType>
> struct drvLimits {
> ValType high;
> ValType low;
> STATUS constrain(ValType &value);
> }
>
> The implementation of the drvLimits::constrain() method has to be
> provided externally, just as with your code
One minor detail: We should have a consistent scheme for C/C++ entities
generated from dbd definitions. If record types are translated to
'struct xxxRecord {...}' as before (and not just 'struct ao {...}',
then we should also generate
struct drvLimitsStruct {...}
and also name menu type definitions generated from
menu(scan) {
choice(passive,"Passive")
...
}
as
enum scanMenu {
scanPassive,
...
}
plus
epicsString scanMenuNames[];
> > OTOH, it would of course be great if we could assemble all these
> > pieces at record load time, rather than compile it into the record
> > type, so that each record will only have what it really uses. I
> > just can't see how to do this in a manner that is at the same time
> > efficient and safe. Well, apart from developing yet another
> > programming language for the task.
>
> Unfortunately that's probably what we'd have to do, so I'm not trying
> to think that one out any more.
Wow. A dedicated DBD/DB extension language. Let me think a while
about /that/ one, before I comment...
Cheers,
Ben
- Replies:
- Re: Record support and user-defined fields Andrew Johnson
- References:
- V4 iocRecord: forward linking Ralph Lange
- Re: Record support and user-defined fields Benjamin Franksen
- Re: Record support and user-defined fields Andrew Johnson
- Navigate by Date:
- Prev:
property hierarchy and performance Jeff Hill
- Next:
V4 EpicsString Benjamin Franksen
- 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: Record support and user-defined fields Andrew Johnson
- Next:
Re: Record support and user-defined fields 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
|