EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Record support and user-defined fields
From: Benjamin Franksen <[email protected]>
To: [email protected]
Date: Fri, 8 Jul 2005 22:13:44 +0200
On Friday 08 July 2005 20:19, Andrew Johnson wrote:
> Benjamin Franksen wrote:
> > 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).
>
> It also documents the methods available for the record support user,
> and means we don't have to have your parallel xxxStructSupport.h file
> which contains just those declarations.  The DBD file contains the
> *complete* interface to the structure and its methods, and the record
> support code that calls it is easier to understand.  

I agree that the documentation aspect and the simplicity of one less 
file to look at are good arguments. I still find it ugly, but heck, so 
is real life.

> It would be possible to replace the line
>      method("STATUS constrain(ValType &value)")
> with something like
>      method(constrain) {
>          returns(STATUS)
>          argument(value, reference(ValType))
>      }
> but IMHO that would be pointless - it's less flexible, a lot more
> effort to parse and convert, and totally unnecessary since the only
> direct interface we're providing to the structure is through C++ code
> anyway.

I completely agree. Unless we really design YAPL (Yet Another 
Programming Language), that is...

> > One minor detail: We should have a consistent scheme for C/C++
> > entities generated from dbd definitions.
>
> Agreed, although we might need reminding about that later once we get
> to that level of detail.

Ok.

> > Wow. A dedicated DBD/DB extension language. Let me think a while
> > about /that/ one, before I comment...
>
> Please don't spend time on that, IMHO it's way too ambitious to ever
> happen (unless you're also offering to do all the work implementing
> it as well...).

If my employer pays me to do it...<grin>

Cheers,
Ben

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: Re: Record support and user-defined fields Andrew Johnson
Next: Re: V4 EpicsString Benjamin Franksen
Index: 2002  2003  2004  <20052006  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 Marty Kraimer
Index: 2002  2003  2004  <20052006  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 ·