On 2013-08-23 18:48, Robert Schadek wrote:

> I do as well, but this will lead to template bloat, as many people will
> tell you, and log("device id: %s".format(device.id)); is
> not so bad.

Won't it be just as much template bloat using "format"?

-- 
/Jacob Carlborg

On 08/23/2013 10:34 PM, Jacob Carlborg wrote:
> On 2013-08-23 18:48, Robert Schadek wrote:
>
>> I do as well, but this will lead to template bloat, as many people will
>> tell you, and log("device id: %s".format(device.id)); is
>> not so bad.
>
> Won't it be just as much template bloat using "format"?
>
well yes, but log(A...)(A a) { format("...", a); } is worse ;-)

On 08/23/2013 10:08 PM, Jonathan M Davis wrote:
> On Friday, August 23, 2013 21:47:44 Johannes Pfau wrote:
>
>> Make the templated function a stub which redirects to a function which uses normal function arguments and rely on inlining?
> Inlining will have no effect on __FILE__ and __LINE__, and it would be a bug if it did, because they're supposed to give the file and line number of the source code, whereas inlining only affects the generated binary.
>
> - Jonathan M Davis
I think I came up with something good looking. A regex explains it best.

log // still returns the default logger
(LOGGER\.)?log\((LOGLEVEL,)? (CONDITION,)? (MESSAGE)?\) // normal
logging without template bloat
(LOGGER\.)?logf\((LOGLEVEL,)? (CONDITION,)? (MESSAGE), (ARGS,)*\) //
printf logging with templates bloat

I push the changes and the new docu (which needs some more work). Good
night everybody.

On 8/23/13 1:10 PM, Robert Schadek wrote:
> On 08/23/2013 09:41 PM, Andrei Alexandrescu wrote:
>> (Just hanging this to a random comment in this thread.) I think
>> there's some pretty good work on logging by myself and another poster
>> (Jose?) that has since gone abandoned. It included some nice approach
>> to conditional logging and had both compile-time and run-time
>> configurability
>
> Yes I know, but as you said, it got abandoned. So something must have
> been wrong.
> I rather start something fresh and argue about whats wrong with that,
> than argue
> whats wrong with something old that has been already argued about and
> got abandoned.
>

Great. There was nothing wrong with it except it got no more work. I'd expect a new framework to be at least as good if not better.

Andrei

Am Fri, 23 Aug 2013 16:08:40 -0400
schrieb "Jonathan M Davis" <jmdavisProg@gmx.com>:

> On Friday, August 23, 2013 21:47:44 Johannes Pfau wrote:
> > Am Fri, 23 Aug 2013 15:16:05 -0400
> > 
> > schrieb "Jonathan M Davis" <jmdavisProg@gmx.com>:
> > > On Friday, August 23, 2013 19:21:33 Gary Willoughby wrote:
> > > > I don't think you can bloat a simple logger too much with templates. It's a pretty simple framework.
> > > 
> > > If __FILE__ and __LINE__ are template arguments to a logging function rather than function arguments (and you can't make __FILE__ and __LINE__ default function arguments if the function is variadic as it would have to be to support format strings), then you get a new template instantation every single time that you call the function, unless you call it more than once on the same line (which you're unlikely to ever do).
> > > 
> > > I want to think that there's a way to handle this if you get clever, but I can't think of a clever way to get around the problem at the moment.
> > > 
> > > - Jonathan M Davis
> > 
> > Make the templated function a stub which redirects to a function which uses normal function arguments and rely on inlining?
> 
> Inlining will have no effect on __FILE__ and __LINE__, and it would be a bug if it did, because they're supposed to give the file and line number of the source code, whereas inlining only affects the generated binary.

I think you misunderstood. If you write code like this:

void log(string file = __FILE__)() //A template
{
    logImpl(file);
}
void logImpl(string file){} //Not a template

The compiler can always inline the log template. So there's no template bloat as there will be effectively no instances of log. Instead it will be inlined and logImpl will be called directly just as if you manually called logImpl(__FILE__).

On 08/23/2013 11:49 PM, Andrei Alexandrescu wrote:
> On 8/23/13 1:10 PM, Robert Schadek wrote:
>> On 08/23/2013 09:41 PM, Andrei Alexandrescu wrote:
>>> (Just hanging this to a random comment in this thread.) I think there's some pretty good work on logging by myself and another poster (Jose?) that has since gone abandoned. It included some nice approach to conditional logging and had both compile-time and run-time configurability
>>
>> Yes I know, but as you said, it got abandoned. So something must have
>> been wrong.
>> I rather start something fresh and argue about whats wrong with that,
>> than argue
>> whats wrong with something old that has been already argued about and
>> got abandoned.
>>
>
> Great. There was nothing wrong with it except it got no more work. I'd expect a new framework to be at least as good if not better.
>
> Andrei
>
Of course, it has to be phobos worthy.

On Thursday, 22 August 2013 at 22:01:09 UTC, Jonathan M Davis wrote:
> On Thursday, August 22, 2013 23:36:48 David Nadlinger wrote:
>> On Thursday, 22 August 2013 at 15:51:53 UTC, Craig Dillabaugh
>> 
>> wrote:
>> > Do you really find the three extra characters a big problem.
>> 
>> They are unnecessary. If you want to make clear you are dealing
>> with logging, you can just write something along the lines of:
>> 
>> import log = std.logger;
>> log.error("123");
>
> I'd oppose warning, critical, error, etc. because they're not verbs like
> functions are supposed to be. It's variables or properties which are nouns.
> So, while I agree that the module system makes it so that the name clashes
> shouldn't be a big deal, I disagree with the names anyway and would still
> prefer logWarning to warning.
>
> - Jonathan M Davis

OTOH, they are used in just about every logging API ever devised. Everybody knows what they mean. I just don't see the need to reinvent these words and make them longer by adding log. I seriously hate it.

It clutters code (once you've read your thousand's log instruction, it hurts), adds ugly and useless redundancy and nothing else to its understanding. This alone is far worse than not using verbs.

On Saturday, August 24, 2013 16:49:24 SomeDude wrote:
> OTOH, they are used in just about every logging API ever devised. Everybody knows what they mean. I just don't see the need to reinvent these words and make them longer by adding log. I seriously hate it.
> 
> It clutters code (once you've read your thousand's log instruction, it hurts), adds ugly and useless redundancy and nothing else to its understanding. This alone is far worse than not using verbs.

Well, we're going to have to agree to disagree on that point. Functions are supposed to be verbs. They're only nouns if they're properties, in which case, they're emulating variables, which are nouns. And I'd consider following the proper naming conventions like that to be far more important than saving a few characters.

- Jonathan M Davis

On 08/24/2013 08:01 PM, Jonathan M Davis wrote:
> On Saturday, August 24, 2013 16:49:24 SomeDude wrote:
>> OTOH, they are used in just about every logging API ever devised. Everybody knows what they mean. I just don't see the need to reinvent these words and make them longer by adding log. I seriously hate it.
>>
>> It clutters code (once you've read your thousand's log instruction, it hurts), adds ugly and useless redundancy and nothing else to its understanding. This alone is far worse than not using verbs.
> Well, we're going to have to agree to disagree on that point. Functions are supposed to be verbs. They're only nouns if they're properties, in which case, they're emulating variables, which are nouns. And I'd consider following the proper naming conventions like that to be far more important than saving a few characters.
>
> - Jonathan M Davis
luckily all log functions are called log and logf now.

On Friday, 23 August 2013 at 20:11:38 UTC, H. S. Teoh wrote:
> On Fri, Aug 23, 2013 at 12:41:45PM -0700, Andrei Alexandrescu wrote:
> [...]
>> (Just hanging this to a random comment in this thread.) I think
>> there's some pretty good work on logging by myself and another
>> poster (Jose?) that has since gone abandoned. It included some nice
>> approach to conditional logging and had both compile-time and
>> run-time configurability.
> [...]
>
> Where's the code?
>
>
> T

https://github.com/D-Programming-Language/phobos/pull/432
(got from http://wiki.dlang.org/Review_Queue)