A related request at the hackathon was access to the JS "debugger" statement.

I think this is asking for is some kind of "trace" api. My impression is that the log messages are usually categorized into some application-provided category names, i.e. trace("myerrors", "bad thing happened");

With that in mind, you can get pretty close already:

log.dart:
class Log {
  static final bool A = false;
  static final bool B_f1 = true;
  void write(String msg) { ... write to file ... }
}

b.dart:
class B {
  ...
  f1() {
    ...
    if (Log.B_f1) Log.write("bad thing happened");
  }
}

That should perform well on Frog and the VM. If it doesn't, we could be a little smarter about constant folding and it would.

The big piece that is missing is something like FILE and LINE. It'd be pretty easy to add something like that, but we'd need to do a bit of design.

FWIW, C# has a rather elegant solution to the trace problem using [Conditional] and compile-time defines. I don't think that would fit well into Dart, though.

This comment was originally written by yiuyu...@google.com

The proposed solution above means I have to physically write if statements for each debug print, an OK work around but not optimal in my opinion. For example if the class has 10 functions, I then have to decide in the Log class which function gets its own flag and which one uses the class's flag (if (Log.B) vs if(Log.B_f1)), doesn't work well when you change method names, and also if I want to turn off debug printing in class B, I will have to edit multiple lines in the Log file.

Well, you can have the conditions defined at whatever granularity you want:

static final bool B = true;
static final bool B_f1 = B && true;
...

now you only need one line to turn "B" off.

How would you do this in other languages?

The arbitrary mixins by class or method name selectors sounds a lot like http://en.wikipedia.org/wiki/AspectJ. But that kind of flexibility never really caught on in mainstream languages. The most compelling use case was logging--but it's a pretty big language feature for just for logging.

(changing area to "language"--I don't think we can do this as a Frog-only feature, VM would need support for it too)

Removed Area-Frog label.
Added Area-Language label.

This comment was originally written by yiuyu...@google.com

static final bool B = true;
static final bool B_f1 = B && true;
...

But then I can't expose B_f1 without exposing other prints in B. I don't know of any main stream language that support such fine grained logging (Python is close, but not on the same metrics). But just because something doesn't exist doesn't mean they are not cool ;).

This comment was originally written by ladicek@gmail.com

The arbitrary mixins by class or method name selectors sounds a lot like http://en.wikipedia.org/wiki/AspectJ. But that kind of flexibility never really caught on in mainstream languages. The most compelling use case was logging--but it's a pretty big language feature for just for logging.

It's not only about logging (well, tracing), it's also about (declarative) transaction demarcation, role based access control etc. Spring (a popular Java framework, or rather a suite of frameworks) uses and popularizes aspects pretty heavily, and I think that Guice has them too (oh, and maybe the last versions of EJB has some sort of method interceptors too, but who cares about EJB?). So I wouldn't exactly say that it never really caught on.

You can do something very simillar in (a lot of) dynamic languages by monkeypatching (which sucks). Dart doesn't allow that, so the only approach now would be to use proxies. Which isn't that bad, actually.

Not sure about language-level support of aspects, but it might be nice. AFAIK, there once was an experimental version of JRockit that had aspects builtin right into the JVM, so... :-)

The original bug is request for a library feature, that could be implemented once reflection support is in place. Somewhere, some discussion of aspects and mixins got thrown in but seems completely extraneous to this bug. There is an open issue for mixins. I don't recall one for aspects, but please don't bother.

Set owner to @gbracha.
Added Accepted label.

Recategorizing as library issue. When suitable base debugging reflection functionality is complete, we could decide what to about this. It is NOT a language issue.

Removed Area-Language label.
Added Area-Library label.

Added Library-Mirrors label.

The VM has a service protocol: https://github.com/dart-lang/sdk/blob/master/runtime/vm/service/service.md

The dart:developer library has a call to trigger the debugger: https://github.com/dart-lang/sdk/blob/master/sdk/lib/developer/developer.dart