July 13, 2014 Re: Review: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dragos Carp | On Sunday, 13 July 2014 at 13:30:20 UTC, Dragos Carp wrote:
>>
>> But creating x , necessary, function with only slightly different names is also very non idiomatic D code. Anyway I'm working on that.
>
> For the conditional variants, wouldn't be enough an overload with
> the condition on the first position?
people hated it and writeln like logging makes this impossible anyway
|
July 13, 2014 Re: Review: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | On 2014-07-13 14:21, Dicebot wrote: > It is effectively same as using static namespace class but C-style - > mangling namespace into function name. `log.error` looks descriptive > enough to me. I think most usage would _not_ look like that because of the free functions. -- /Jacob Carlborg |
July 13, 2014 Re: Review: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | On 2014-07-13 14:45, Dicebot wrote: > Exactly. I think this should be popularized as default style via > std.logger documentation. If that's the style everyone is encouraged to use, why not force it then? -- /Jacob Carlborg |
July 13, 2014 Re: Review: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On Sunday, 13 July 2014 at 14:12:56 UTC, Jacob Carlborg wrote:
> On 2014-07-13 14:45, Dicebot wrote:
>
>> Exactly. I think this should be popularized as default style via
>> std.logger documentation.
>
> If that's the style everyone is encouraged to use, why not force it then?
because if you force it, you can not choose to do it differently
|
July 13, 2014 Re: Review: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Robert burner Schadek | On Sunday, 13 July 2014 at 13:37:13 UTC, Robert burner Schadek
wrote:
> On Sunday, 13 July 2014 at 13:30:20 UTC, Dragos Carp wrote:
>>>
>>> But creating x , necessary, function with only slightly different names is also very non idiomatic D code. Anyway I'm working on that.
>>
>> For the conditional variants, wouldn't be enough an overload with
>> the condition on the first position?
>
> people hated it and writeln like logging makes this impossible anyway
write/writeln are generic functions that are used for producing
plain-text output in line oriented format (.csv, etc.) or not
line oriented format (json, xml, etc.). This text is human
readable, but not necessary user friendly.
A logging facility need to produce both human readable and user
friendly messages.
I would prefer:
info("%s is the answer", true);
instead of
info(true, " is the answer");
The variant without format specifier also makes the
internationalization of the log entries almost impossible.
IMHO these are some good reasons why the logging facility should
not try to support the variants that the std.stdio with
write/f/ln provides.
|
July 13, 2014 Re: Review: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | Am 13.07.2014 14:45, schrieb Dicebot:
> On Sunday, 13 July 2014 at 12:41:59 UTC, sigod wrote:
>> I use my own log module like this:
>> ```
>> import log = util.log;
>>
>> log.info(...);
>> log.debug(...);
>> // etc
>> ```
>
> Exactly. I think this should be popularized as default style via
> std.logger documentation.
Yeah, I guess that should be fine, too.
|
July 13, 2014 Re: Review: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dragos Carp | On Sunday, 13 July 2014 at 14:25:42 UTC, Dragos Carp wrote: > > write/writeln are generic functions that are used for producing > plain-text output in line oriented format (.csv, etc.) or not > line oriented format (json, xml, etc.). This text is human > readable, but not necessary user friendly. > > A logging facility need to produce both human readable and user > friendly messages. > > I would prefer: > info("%s is the answer", true); write infof("%b is the answer", true); and it works write now > instead of > info(true, " is the answer"); > > The variant without format specifier also makes the > internationalization of the log entries almost impossible. > > > IMHO these are some good reasons why the logging facility should > not try to support the variants that the std.stdio with > write/f/ln provides. there also good points for it. * people expect it after using write * sometimes it is less work typing * there is no reason to limit it arbitrarily * ... |
July 13, 2014 Re: Review: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sönke Ludwig | On Sunday, 13 July 2014 at 14:32:40 UTC, Sönke Ludwig wrote:
> Am 13.07.2014 14:45, schrieb Dicebot:
>> On Sunday, 13 July 2014 at 12:41:59 UTC, sigod wrote:
>>> I use my own log module like this:
>>> ```
>>> import log = util.log;
>>>
>>> log.info(...);
>>> log.debug(...);
>>> // etc
>>> ```
>>
>> Exactly. I think this should be popularized as default style via
>> std.logger documentation.
>
> Yeah, I guess that should be fine, too.
I guess it is settled then
|
July 13, 2014 Re: Review: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Robert burner Schadek | > write infof("%b is the answer", true); and it works write now This is clear... the argument was against "info" (without format specifier). > there also good points for it. > * people expect it after using write This is a different module. Btw. std.file.write looks completely different :) > * sometimes it is less work typing With more work, if you later need to internationalize your application. > * there is no reason to limit it arbitrarily Simple is better than complex. |
July 13, 2014 Re: Review: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dragos Carp | On Sunday, 13 July 2014 at 14:53:20 UTC, Dragos Carp wrote: >> write infof("%b is the answer", true); and it works write now > > This is clear... the argument was against "info" (without format > specifier). > then I did not get it. > >> there also good points for it. >> * people expect it after using write > > This is a different module. Btw. std.file.write looks completely > different :) > >> * sometimes it is less work typing > > With more work, if you later need to internationalize your > application. std.string.translate and map are already in place. > >> * there is no reason to limit it arbitrarily > > Simple is better than complex. it is hardly complex |
Copyright © 1999-2021 by the D Language Foundation