November 04, 2013
On Monday, 4 November 2013 at 17:08:21 UTC, Robert Schadek wrote:
>> 4.
>>
>> Static "namespace" classes are redundant and should be replaced with
>> module-scope globals.
> not sure either

My concern here is that if we need explicit additional symbol qualification to avoid collisions, D module system has failed. But I believe it actually works just fine, the problem is in habit of using imports in a way similar to C++ includes. Phobos should do more about endorsing power usage of D modules, not resort to demands of unad(a/o)pted ones :)
November 04, 2013
On Monday, 4 November 2013 at 13:46:58 UTC, Dicebot wrote:
> Ok, finally making some conclusions.

Sorry if late or already discussed: I think would be useful to provide a way to define the default logger module-wise. Something like:

// myapp/feature.d
module myapp.feature;
import std.logging;

// define the log category for this module
mixin LogCategory!("myapp.feature");

/* The LogCategory would inject something like:
  ref Logger logger(LogLevel level)
  {
    find the first in this order
      LogManager.logger("myapp.feature"),
      LogManager.logger("myapp"),
      LogManager.defaultLogger();
  }
*/

void fun()
{
  warn("ups");
  // the std.logging.warn() should get the Logger from
  // the current module's function 'logger' or a default one.
}

November 04, 2013
On Monday, 4 November 2013 at 21:31:52 UTC, Tavi Cacina wrote:
> On Monday, 4 November 2013 at 13:46:58 UTC, Dicebot wrote:
>> Ok, finally making some conclusions.
>
> Sorry if late or already discussed: I think would be useful to provide a way to define the default logger module-wise. Something like:

In general it should be possible to implement by inspecting a fully qualified module name passed in logging payload and multiplexing based on it. Only thing that concerns me is choosing between module-filtered and global output for any given log statement, which is what I have mentioned in my overview.
November 05, 2013
On Monday, 21 October 2013 at 08:50:50 UTC, Robert Schadek wrote:
>> disk. That feature proved very useful.
> That was a feature you added or was it part of the logging library?

We added it. I don't know of any logging library doing that.
November 05, 2013
On 11/04/2013 06:27 PM, Dicebot wrote:
> On Monday, 4 November 2013 at 17:08:21 UTC, Robert Schadek wrote:
>>> 4.
>>>
>>> Static "namespace" classes are redundant and should be replaced with module-scope globals.
>> not sure either
>
> My concern here is that if we need explicit additional symbol qualification to avoid collisions, D module system has failed. But I believe it actually works just fine, the problem is in habit of using imports in a way similar to C++ includes. Phobos should do more about endorsing power usage of D modules, not resort to demands of unad(a/o)pted ones :)
Can you give an example, I'm not sure if I know what you mean.
November 06, 2013
On Tuesday, 5 November 2013 at 08:38:34 UTC, Robert Schadek wrote:
> Can you give an example, I'm not sure if I know what you mean.

Currently common approach is just adding top-level module imports like this:

```
module app;
import std.algorithm;
```

It has several issues:

1) Name clash if two modules define same symbol
2) Difficulties with tracking unused imports
3) Compilation speed penalty because of eager import in case it is only used in uninstantiated code branch.

However, D has 3 totally awesome import features that help to address all of this issues:

1) aliasing imports
```
import algo = std.algorithm;
```

It creates the very same namespace one is trying to achieve with namespace struct but without extra unused symbols and with full user control. Benefits both readability of application (obvious where namespace comes from) and readability of imported module (less redundant nesting)

2) importing specific symbols
```
import std.algorithm : remove;
```

Often module is used only for one or two functions. Mentioning those explicitly will avoid accidental clashes with irrelevant module symbols and acts as a nice self-documentation tool.

3) scope-local imports
```
template tmpl(T)
{
    import std.algorithm : remove;
}
```

scope local imports are just awesome. Paired with explicit symbol mentioning they almost completely eliminate risk of symbol clashes and make it easy to remove unused imports as you change the code. Also they don't happen unless scope is actually instantiated and thus can save some compilation times.

If all these nice tools D provides are used, any concern about symbol naming becomes irrelevant and having module-scope global names with no extra qualification becomes most KISS thing to do.
November 06, 2013
On 11/06/2013 02:21 PM, Dicebot wrote:

I see
November 07, 2013
On 2013-11-06 14:21, Dicebot wrote:
> On Tuesday, 5 November 2013 at 08:38:34 UTC, Robert Schadek wrote:
>> Can you give an example, I'm not sure if I know what you mean.
>
> Currently common approach is just adding top-level module imports like
> this:
>
> ```
> module app;
> import std.algorithm;
> ```
>
> It has several issues:
>
> 1) Name clash if two modules define same symbol
> 2) Difficulties with tracking unused imports
> 3) Compilation speed penalty because of eager import in case it is only
> used in uninstantiated code branch.
>
> However, D has 3 totally awesome import features that help to address
> all of this issues:
>
> 1) aliasing imports
> ```
> import algo = std.algorithm;
> ```
>
> It creates the very same namespace one is trying to achieve with
> namespace struct but without extra unused symbols and with full user
> control. Benefits both readability of application (obvious where
> namespace comes from) and readability of imported module (less redundant
> nesting)
>
> 2) importing specific symbols
> ```
> import std.algorithm : remove;
> ```
>
> Often module is used only for one or two functions. Mentioning those
> explicitly will avoid accidental clashes with irrelevant module symbols
> and acts as a nice self-documentation tool.
>
> 3) scope-local imports
> ```
> template tmpl(T)
> {
>      import std.algorithm : remove;
> }
> ```

4) static imports

static import std.stdio;

void main ()
{
    std.stdio.writeln("foo"); // fully qualified name is required
}

2 + 3) combining selective and renamed imports

import io = std.stdio : println = writeln;

void main ()
{
    println("foo");
    io.writeln("bar");
}

6) aliases

import std.stdio;
alias println = writeln;

void main ()
{
    println("foo");
}

-- 
/Jacob Carlborg
November 07, 2013
On Thursday, 7 November 2013 at 09:09:13 UTC, Jacob Carlborg wrote:
> 4) static imports
>
> static import std.stdio;
>
> void main ()
> {
>     std.stdio.writeln("foo"); // fully qualified name is required
> }
>
> 2 + 3) combining selective and renamed imports
>
> import io = std.stdio : println = writeln;
>
> void main ()
> {
>     println("foo");
>     io.writeln("bar");
> }
>
> 6) aliases
>
> import std.stdio;
> alias println = writeln;
>
> void main ()
> {
>     println("foo");
> }

Yeah, also good additions! I do favor renamed imports over static ones in most code because fully qualified names tend to be rather long for anything other than Phobos. It is still extremely useful for code generation stuff though.
November 12, 2013
On Tuesday, 5 November 2013 at 02:51:54 UTC, SomeDude wrote:
> We added it. I don't know of any logging library doing that.

It's BufferingForwardingAppender in log4net. We use it to improve logging performance.
3 4 5 6 7 8 9 10 11 12 13
Next ›   Last »