Nut upsdev - Dec 2012 - libnutconf: specific C++ accessors technique proposition

?Hello fellow developers,

yesterday, I was thinking about how to implement specific config.
attributes accessors in section-based nut config. files so that
it's nice to use and consistent with NutConfiguration, UpsmonConfiguration
and UpsdConfiguration config. classes (where it's done via Settable
attributes).

The GenericConfiguration class provides generic access to name/value
items of config. sections. The specialised classes (like e.g. UpsConfiguration)
shall inherit the mechanism from GenericConfiguration and are supposed to
provide specialised (and typed) access to the config. attributes.
Now, the obvious choice is to write getters/setters for them; however,
this way, the access will be different than access to section-less config.
files attributes.
What I came with is a template class (see "redirect" in the sample
code attached)
that overloads the cast operator and the assignment operator (and possibly
others)
and therefore gives the user the possibility to execute code (the
getters/setters)
while the code looks just like r/w access to a variable (with certain
restrictions, though).

Now, the mechanism looks kind of cool, but is also a bit technically complex,
not to mention that it's disputable whether such masking of code execution
is a good idea.  I can imagine that it can be quite confusing for an outsider...
So, do you think that it's worth it or should I better keep the code less
"smart"
but more simple (now, when I'm writing that, it seems to answer itself...)?

Thanks for the consult,

Regards,

--
V?clav Krpec
Network UPS Tools project
Eaton Opensource Team




-----------------------------
Eaton Elektrotechnika s.r.o. ~ S?dlo spolecnosti, jak je zaps?no v rejstr?ku:
Kom?rovsk? 2406, Praha 9 - Horn? Pocernice, 193 00, Cesk? Republika ~ Jm?no,
m?sto, kde byla spolecnost zaregistrov?na: Praha ~ Identifikacn? c?slo (ICO):
498 11 894
-----------------------------

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: redirect.cpp
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20121204/9793d3d6/attachment.ksh>

Hi Vasek, Hi all,

although your technical proposition is funny, I am not sure it makes a
serious difference and a big advantage compared to simple getter/setter
function calling.
Moreover, I am not sure that this code will be really used widely. So the
user can call methods instead of using variable assignation.

Regards,

Emilien

PS: Sure your example/way is very interesting for C++ theory and exercises
;)


2012/12/4 <VaclavKrpec at eaton.com>
> Hello fellow developers,
>
> yesterday, I was thinking about how to implement specific config.
> attributes accessors in section-based nut config. files so that
> it's nice to use and consistent with NutConfiguration,
UpsmonConfiguration
> and UpsdConfiguration config. classes (where it's done via Settable
> attributes).
>
> The GenericConfiguration class provides generic access to name/value
> items of config. sections. The specialised classes (like e.g.
> UpsConfiguration)
> shall inherit the mechanism from GenericConfiguration and are supposed to
> provide specialised (and typed) access to the config. attributes.
> Now, the obvious choice is to write getters/setters for them; however,
> this way, the access will be different than access to section-less config.
> files attributes.
> What I came with is a template class (see "redirect" in the
sample code
> attached)
> that overloads the cast operator and the assignment operator (and possibly
> others)
> and therefore gives the user the possibility to execute code (the
> getters/setters)
> while the code looks just like r/w access to a variable (with certain
> restrictions, though).
>
> Now, the mechanism looks kind of cool, but is also a bit technically
> complex,
> not to mention that it's disputable whether such masking of code
execution
> is a good idea.  I can imagine that it can be quite confusing for an
> outsider...
> So, do you think that it's worth it or should I better keep the code
less
> "smart"
> but more simple (now, when I'm writing that, it seems to answer
itself...)?
>
> Thanks for the consult,
>
> Regards,
>
> --
> V?clav Krpec
> Network UPS Tools project
> Eaton Opensource Team
>
>
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? enlev?e...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20121204/4bc0550e/attachment.html>