Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Re: Converting configuration back to JSON (unparsing)
(Francis Dupont)
2. Re: Converting configuration back to JSON (unparsing)
(Francis Dupont)
3. Re: Converting configuration back to JSON (unparsing)
(Francis Dupont)
----------------------------------------------------------------------
Message: 1
Date: Thu, 23 Feb 2017 20:32:43 +0000
From: Francis Dupont <[email protected]>
To: Tomek Mrugalski <[email protected]>
Cc: [email protected]
Subject: Re: [kea-dev] Converting configuration back to JSON
(unparsing)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Tomek Mrugalski writes:
> W dniu 23.02.2017 o 20:36, Francis Dupont pisze:
> >> The class is going to be named ToElement()?
> > => CfgToElement but it is an abstract class so classes will derived
> > from it.
> Huh? I thought toElement will be a method that will be implemented in
> each existing class, so no extra classes needed at all.
=> abstract == the class defines the virtual toElement method as = 0
(i.e. it gives only the type).
> >> Having it be ToElement::toElement() seems a bit off.
> >
> > => the only place you should get it is in a doxygen comment
> > (and remember it is an instance method).
> There should be no extra class. There should be CfgMgr::toElement() that
> creates map element, puts all parameters it stores and then call
> toElement() on all of its children (CfgOpionDef::toElement(),
> CfgSubnets4::toElement(), etc.).
=> s/CfgMgr/SrvConfig/ and it is not an extra class but an abstract class
(an abstract template in fact as a few derived classes require
extra parameters, e.g. address family).
> >> What about something more like Configurable which defines toElement()
> >> method.
> > => it is more Configured than Configurable but this does not catch
> > the fact the derived class must implement a toElement() method.
> > So ToElement seems a natural name.
> >
> > I've just updated fdunparse private branch to these new names.
> > And BTW there is no ToElement::toElement found by grep (:-).
> That's the problem of implementing code before there's an agreement how
> the code should look like.
=> change a name is not an issue but to know if something can be
implemented and with what effort requires experiments.
> When we planned the work, it was decided on a meeting to use 1205 for
> mini-design (that's what we're doing right now) and #5114 for the actual
> implementation.
=> this is why there is a trac1205 branch and no trac5114.
> > PS: for pretty print I believe a function is better (and less intrusive)
> > than to extend an existing method. I'll take the corresponding ticket
> > and change the code (and use it to not write whole configs for unit tests
> > twice :-).
> If it wasn't clear from the meeting, we do not need pretty print right
> now.
=> I am an human being so I need pretty printing. As I kept the code
somewhere I just propose to include it. And I am sure it will be useful,
for instance when toElement does not what was expected str/toJSON becomes
unreadable very quickly.
> Sure, it would be nice if the JSON returned was nicely indented,
> but that is not something that is really needed.
=> it is not needed for the control/command channel, it is needed for us.
> We're short on time and we can't spend time on things that are nice
> to have, but not necessary. Even if you write it, nobody would be
> able to review it.
=> it is already written and it will save time in debug...
> That's sad, but true. We have very limited manpower right now and we
> need to be careful, which tickets we spend time on.
=> it is my time...
Regards
Francis Dupont <[email protected]>
------------------------------
Message: 2
Date: Thu, 23 Feb 2017 20:41:01 +0000
From: Francis Dupont <[email protected]>
To: Thomas Markwalder <[email protected]>
Cc: Francis Dupont <[email protected]>, [email protected]
Subject: Re: [kea-dev] Converting configuration back to JSON
(unparsing)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Thomas Markwalder writes:
> My point is that objects that embody our configuration may have other
> things in common eventually besides just implementing a toElement() method.
=> if this happens we can change the name at that time.
> If Configurable::toElement() is an abstract method it would be pretty
> clear that anything deriving from it has to implement it.
=> not only it must but if it is not it will not build. I know the
signature / implementation split design comes from outside C++ but
there is no reason to not use it.
> If that's the criteria you would need a separate base class for
> every abstract method.
=> for every independent/not-related abstract method? IMHO it is the
right idea. It costs a few line in a header, a ": public name" in
derived class declarations and you can cut & paste the doxygen comment
of the method from a known source. In fact it is a smart form of
code sharing, I can't see a reason to not use it.
Regards
Francis Dupont <[email protected]>
------------------------------
Message: 3
Date: Thu, 23 Feb 2017 20:45:53 +0000
From: Francis Dupont <[email protected]>
To: Thomas Markwalder <[email protected]>
Cc: [email protected]
Subject: Re: [kea-dev] Converting configuration back to JSON
(unparsing)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Thomas Markwalder writes:
> Good point, coding before design will get you everytime ;)
=> the design was in #1205, the code helped to improve the design
and raised a few things, for instance the unexpected requirement
for an unordered comparison function.
Regards
Francis Dupont <[email protected]>
------------------------------
Subject: Digest Footer
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
------------------------------
End of kea-dev Digest, Vol 35, Issue 4
**************************************
