From: Igor Zhbanov <i.zhbanov at samsung.com>
To: powertop@lists.01.org
Subject: Re: [Powertop] [RFC][PATCH 1/2] Adding report generator facility
Date: Wed, 10 Oct 2012 16:49:01 +0400 [thread overview]
Message-ID: <50756EBD.6000703@samsung.com> (raw)
In-Reply-To: 20121009191147.GC3633@swordfish
[-- Attachment #1: Type: text/plain, Size: 2327 bytes --]
Sergey Senozhatsky wrote:
> On (10/09/12 21:25), Igor Zhbanov wrote:
>>> - I think null formatter could be a basic class with default
>>> implementation (null) of virtual functions, rather than separate
>>> implementation of basic formatter interface (abstract class).
>> One more note.
>>
>> In my opinion making an empty implementation of the functions
>> inside the interface class is not good.
>>
>> The first reason, if now the programmer will forget to implement
>> some method of the abstract interface, the program will not compile,
>> instead of getting empty implementation and doing nothing.
> yes, this is valid point, but at the same time also one of the reasons we have commit
> review ;-)
>> Second, I don't like to mix all types of report formatters because some
>> of them would use string to hold the result, while another (probably XML)
>> could use tree for DOM implementation). And not every formatter need
>> escaping string function. So I have provides report_formatter_base
>> as a common part for CSV and HTML report formatters but not for
>> NULL formatter.
> in my example I don't think we mix anything. we just define a sub-set of common
> funictions and implementations via base_impl classes. while this looks like a win
> for current case (2 clases using string storage, so no code duplication), it may be
> not as cool if every formatter class would use different data storage type:
> xml, json, proto buff, whatever.
I think that if other formatters would have something common, then we will
create another base class for them, e.g. DOM-based storage. And it could be
that these formatters will not need to use string storage and related
functions.
I have tried to make classes simple as possible without unneeded members.
So I use the abstract interface that every formatter must implement.
And so I have used one base class for CSV and HTML formatters that
implements
common part of them (related to string storage).
But there could be more base classes containing common parts of another
formatters.
--
Best regards,
Igor Zhbanov,
Expert Software Engineer,
phone: +7 (495) 797 25 00 ext 3806
e-mail: i.zhbanov(a)samsung.com
ASWG, Moscow R&D center, Samsung Electronics
12 Dvintsev street, building 1
127018, Moscow, Russian Federation
next reply other threads:[~2012-10-10 12:49 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-10 12:49 Igor Zhbanov [this message]
-- strict thread matches above, loose matches on Subject: below --
2012-10-10 15:53 [Powertop] [RFC][PATCH 1/2] Adding report generator facility Chris Ferron
2012-10-10 15:39 Sergey Senozhatsky
2012-10-09 19:31 Sergey Senozhatsky
2012-10-09 19:11 Sergey Senozhatsky
2012-10-09 19:03 Sergey Senozhatsky
2012-10-09 18:55 Sergey Senozhatsky
2012-10-09 17:25 Igor Zhbanov
2012-10-09 17:02 Igor Zhbanov
2012-10-08 16:57 Sergey Senozhatsky
2012-10-05 10:15 Igor Zhbanov
2012-10-04 21:17 Sergey Senozhatsky
2012-10-04 21:07 Sergey Senozhatsky
2012-10-04 16:08 Ferron, Chris E
2012-10-03 17:05 Igor Zhbanov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50756EBD.6000703@samsung.com \
--to=powertop@lists.01.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.