August 22, 2013
On 08/22/2013 05:51 PM, Craig Dillabaugh wrote:
> Do you really find the three extra characters a big problem.
>
> Log() vs. logLog()  //OK, that is kind of ugly.
> Info() vs logInfo()
> Warning() vs logWarning()
> Error() vs logError()
>
> Its only three extra characters and they are all in the sweet spot on my QWERTY keyboard :o)
>
> I guess my concern would be that if you want to use camelCase and start with a lower case letter, there are not a tonne of options.

You are properly right, but ultimately I would like to write log(),
warning(), ... but that did
not fly last time. log!Warning() would also be fine but that leads to
other problems.
Anyway, changing to lower, logLog or something else isn't really a
problem IMO when
a consensus has been found.
August 22, 2013
On Thursday, 22 August 2013 at 16:03:01 UTC, Robert Schadek wrote:
> On 08/22/2013 05:51 PM, Craig Dillabaugh wrote:
>> Do you really find the three extra characters a big problem.
>>
>> Log() vs. logLog()  //OK, that is kind of ugly.
>> Info() vs logInfo()
>> Warning() vs logWarning()
>> Error() vs logError()
>>
>> Its only three extra characters and they are all in the sweet
>> spot on my QWERTY keyboard :o)
>>
>> I guess my concern would be that if you want to use camelCase and
>> start with a lower case letter, there are not a tonne of options.
>
> You are properly right, but ultimately I would like to write log(),
> warning(), ... but that did
> not fly last time. log!Warning() would also be fine but that leads to
> other problems.
> Anyway, changing to lower, logLog or something else isn't really a
> problem IMO when
> a consensus has been found.

It seems like Jacob's suggestion (if you like that) solves both
of our problems.
August 22, 2013
On 2013-08-22 18:01, develop32 wrote:

> Why logging functions accept only a string? I would expect it to behave
> as std.stdio with its variadic parameters.
>
> It would be more straightforward to write logging code:
>
> log("Moving ", data, " to ", destination);
>
> Where 'data' and 'destination' are any variables. I use such setup in my
> projects and it helps greatly to identify what went wrong when not using
> a debugger.

Good point, and formatted output as well:

logf("Moving % to %", data, destination);

-- 
/Jacob Carlborg
August 22, 2013
On 2013-08-22 18:02, Robert Schadek wrote:

> You are properly right, but ultimately I would like to write log(),
> warning(), ... but that did
> not fly last time. log!Warning() would also be fine but that leads to
> other problems.
> Anyway, changing to lower, logLog or something else isn't really a
> problem IMO when
> a consensus has been found.

With my suggestion you can use the with-statement as well if you are performing a lot of logging:

with (log)
{
    error("bar");
    info("foo");
}

-- 
/Jacob Carlborg
August 22, 2013
On 08/22/2013 05:59 PM, Jacob Carlborg wrote:
> My suggestion is you define a single function "log". This returns an instance of the current/default logger. The logger, be it a struct or class, have one method for each logging level. The default logging level would use opCall, resulting in this API:
>
> log("asd"); // log with default level
> log.warning("foo"); // log with warning level
> log.error("asd"); //
>
> And so on. Then you would only have one function at the module level.
>
I like this part. But you will still need two more module level function
to set and get the global LogLevel. And log would have to return by ref
to assign a new defaultLogger.
But still, I like that very much, even though this is still in conflict
with std.math.log.
August 22, 2013
On Thursday, 22 August 2013 at 16:16:37 UTC, Jacob Carlborg wrote:
> On 2013-08-22 18:01, develop32 wrote:
>
>> Why logging functions accept only a string? I would expect it to behave
>> as std.stdio with its variadic parameters.
>>
>> It would be more straightforward to write logging code:
>>
>> log("Moving ", data, " to ", destination);
>>
>> Where 'data' and 'destination' are any variables. I use such setup in my
>> projects and it helps greatly to identify what went wrong when not using
>> a debugger.
>
> Good point, and formatted output as well:
>
> logf("Moving % to %", data, destination);

maybe it is bad idea, but string.format can be used too.

log(format("Moving %s to %s", data, destination);
August 22, 2013
On 08/22/2013 06:01 PM, develop32 wrote:
> Why logging functions accept only a string? I would expect it to behave as std.stdio with its variadic parameters.
>
> It would be more straightforward to write logging code:
>
> log("Moving ", data, " to ", destination);
>
> Where 'data' and 'destination' are any variables. I use such setup in my projects and it helps greatly to identify what went wrong when not using a debugger.
>
I thought about that. IMO this would create very heavy template bloat,
because you would also have to pass __LINE__, __FUNCTION__ as template
arguments.
Whats so wrong with log("%s %s %s %s".format("Moving", "data", "to",
destination)); This way you don't have to remember to place the spaces
left and right.
August 22, 2013
On 08/22/2013 06:17 PM, Jacob Carlborg wrote:
> On 2013-08-22 18:02, Robert Schadek wrote:
>
> With my suggestion you can use the with-statement as well if you are performing a lot of logging:
>
> with (log)
> {
>     error("bar");
>     info("foo");
> }
>
yes, I believe you're right, but I have not coded/tested it yet
August 22, 2013
Am Thu, 22 Aug 2013 19:13:05 +0200
schrieb Robert Schadek <realburner@gmx.de>:

> On 08/22/2013 06:01 PM, develop32 wrote:
> > Why logging functions accept only a string? I would expect it to behave as std.stdio with its variadic parameters.
> >
> > It would be more straightforward to write logging code:
> >
> > log("Moving ", data, " to ", destination);
> >
> > Where 'data' and 'destination' are any variables. I use such setup in my projects and it helps greatly to identify what went wrong when not using a debugger.
> >
> I thought about that. IMO this would create very heavy template bloat,
> because you would also have to pass __LINE__, __FUNCTION__ as template
> arguments.
> Whats so wrong with log("%s %s %s %s".format("Moving", "data", "to",
> destination)); This way you don't have to remember to place the spaces
> left and right.

The problem is that format allocates using the GC. Functions like writefln can be much more efficient so if the backend is a FileLogger it could take advantage of that. But IIRC it's not simple to implement this 'forwarding' with classes / interfaces as you'll need templated functions...
August 22, 2013
On 08/22/2013 07:48 PM, Johannes Pfau wrote:
> The problem is that format allocates using the GC. Functions like writefln can be much more efficient so if the backend is a FileLogger it could take advantage of that. But IIRC it's not simple to implement this 'forwarding' with classes / interfaces as you'll need templated functions...
yes, but as you said it is not simple. If it where a template the
assignable default logger concept would not work,
as it would instantiate the template of the base class. I don't think
that this is possible (plz proof me wrong).
IMO the default logger concept is more important.