July 14, 2014
On 07/14/2014 01:45 PM, ponce via Digitalmars-d wrote:
>
> Not everyone will ever get satisfied.
Indeed. I can only compromise so much, until it becomes compromised.
July 14, 2014
On 14/07/14 11:35, Dicebot wrote:

> Yes, something like separate "partially static" import type.

I doesn't need language support. Just have a single function, "log", which returns a struct. The struct have all the "error", "warning" and so on, functions.

-- 
/Jacob Carlborg
July 14, 2014
On Monday, 14 July 2014 at 14:24:39 UTC, Jacob Carlborg wrote:
> On 14/07/14 11:35, Dicebot wrote:
>
>> Yes, something like separate "partially static" import type.
>
> I doesn't need language support. Just have a single function, "log", which returns a struct. The struct have all the "error", "warning" and so on, functions.

It is exactly what I don't want to see, it is an aberration. Never ever.

D unit of encapsulation is module. Any other "namespace" solutions must die after proper torture. However we do miss sane built-in compromise between overly verbose static imports and overly clashing normal imports - this need to be solved via language feature in the long term because it is fundamental module system use case.
July 14, 2014
On Monday, 14 July 2014 at 15:34:12 UTC, Dicebot wrote:
> On Monday, 14 July 2014 at 14:24:39 UTC, Jacob Carlborg wrote:
>> On 14/07/14 11:35, Dicebot wrote:
>>
>>> Yes, something like separate "partially static" import type.
>>
>> I doesn't need language support. Just have a single function, "log", which returns a struct. The struct have all the "error", "warning" and so on, functions.
>
> It is exactly what I don't want to see, it is an aberration. Never ever.
>
> D unit of encapsulation is module. Any other "namespace" solutions must die after proper torture. However we do miss sane built-in compromise between overly verbose static imports and overly clashing normal imports - this need to be solved via language feature in the long term because it is fundamental module system use case.

One option could be to relax `static import` to allow module-qualified usage too. Until then `import mod = pkg.mod;` is a good simple idiom that fits existing module system.
July 14, 2014
"Dicebot"  wrote in message news:veqlcdugugxpffajprsj@forum.dlang.org... 

> D unit of encapsulation is module. Any other "namespace" solutions must die after proper torture.

Just use this in the next release!

extern(C++, log)
{
extern(D):
  ... functions ...
}
July 14, 2014
On Monday, 14 July 2014 at 11:35:16 UTC, Robert burner Schadek via Digitalmars-d wrote:
> ? could you rephrase, I can not grasp your point (points)

The point is that the most crucial aspect of logging is being able to filter or put triggers on the logs in pre-existing external logging-solutions without having to modify the frameworks you use. Therefore a standardized structure that fits common patterns in online services would be beneficial.

E.g.:

If I use vibe.d on AppEngine then I want to redirect the vibe.d logging to the AppEngine logging-service without requiring vibe.d authors to know AppEngine or me to change vibe.d.

I'd like to plug in a "logging redirection handler" in the D runtime with the ability to filter/translate the logging severity level (at least corresponding to the severity levels: library/internal, debug, info, warning, error, critical) and the source.

So in the logging-handler you need to the following information:
1. source (e.g. vibe.d)
2. severity level
3. message (just a string)
4. time (but that can be inferred by the logging handler)

Not particularly complicated, I think, but the logging functionality should match up to the requirements (for ease of use, ability to scale etc)
July 14, 2014
On Monday, 14 July 2014 at 15:43:33 UTC, Daniel Murphy wrote:
> "Dicebot"  wrote in message news:veqlcdugugxpffajprsj@forum.dlang.org...
>
>> D unit of encapsulation is module. Any other "namespace" solutions must die after proper torture.
>
> Just use this in the next release!
>
> extern(C++, log)
> {
> extern(D):
>   ... functions ...
> }

Not helping :grumpy:
July 14, 2014
>
> There is still a problem: the analogy, that log/logf is similar to write/writef, is not right anymore. Please correct me if I'm wrong... but AFAIK write converts every argument to string and the output device has no mean to choose a preferred representation of the arguments.
>
> It will be a surprise if I replace
>    log(a, b, c);
> with
>    logf("%s%s%s", a, b, c);
> and possibly get different results.
>


If you are just using default logging, they are the same.  Point is that it
allows for different results based on logging configuration/implementation.
 The logf version says the logging output has to be exactly that string, in
all instances.  The other says here is some things I want logged, and the
logging can decide how to output them.


July 14, 2014
>
> The point is that the most crucial aspect of logging is being able to filter or put triggers on the logs in pre-existing external logging-solutions without having to modify the frameworks you use.


Important, but I'd hesitate to call it the most crucial aspect...  that honour probably goes to 'write messages to a sink'

The stated goal of this log library is to provide a base with common useful functionality, in a way that can be extended to fit more complicated use cases.  I'd argue that what you are talking about fits into the 'more complicated' - the log API should definitely allow this, in a way that it can be plugged in without log using code having to change, but I don't believe the functionality needs to be in the base library (at this time).


July 14, 2014
>
> > Not everyone will ever get satisfied.
> Indeed. I can only compromise so much, until it becomes compromised.
>

Naming is one of the two hard problems (along with cache invalidation and
off-by-one errors).

We can argue about these things forever, but ultimately all that really matters is: does it do what we need?  As long as the API works, and lets one build fancier functionality underneath, it is good.  (Though, in my experience, any API written will be wrong the first try)


That said, my bikeshed preferences are:
 - namespaced log.info, log.warning, etc
 - info(f) matching write(f)
 - conditionals as an extension/wrapper, not part of base