www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Suggestion: module opcall

reply bobef <ads asd.asd> writes:
Hello all,

I want to suggest adding module opCall to D (to D1 as well please :). Please
excuse me if has been suggested before. Something like this:

module mymodule.trace;

static char[] opCall() {
  return  "whatever";
}

module mymodule.main;

void main() {
  mymodule.trace();
}

The need for this is because often a module happens to be named as the
functionality it contains and you have to write the stuff two times. For
example to stdout something with Tango one needs to
tango.io.Stdout.Stdout("whatever"); It would be much nicer to just write
tango.io.Stdout("whatever"); Other cases don't come to mind at the moment, but
I have thought about this many times in my work...

Regards,
bobef
Jan 08 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
bobef Wrote:
 The need for this is because often a module happens to be named as the
functionality it contains and you have to write the stuff two times.<

A design bug in the D1 module system is that when you import foo normally you import in the namespace both the module name and the names it contains. So if you have foo inside foo you are in troubles. I'm waiting such design errors to be fixed still. Anyway, you can solve your problem like this: from foo import foo; now you don't need to call foo two names to use it. So for *this purpose* I think your proposal is bad (it may be good for other purposes). Bye, bearophile
Jan 08 2009
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Jan 9, 2009 at 2:33 AM, bearophile <bearophileHUGS lycos.com> wrote:
 bobef Wrote:
 The need for this is because often a module happens to be named as the
functionality it contains and you have to write the stuff two times.<

A design bug in the D1 module system is that when you import foo normally you import in the namespace both the module name and the names it contains. So if you have foo inside foo you are in troubles. I'm waiting such design errors to be fixed still.

I think this problem you refer to only applies to modules without package names. I.e. "module Foo" containing "class Foo". Things seem to work ok if you have "module x.Foo" with "class Foo" inside. So you are saying you want this to be an error? import std.string; void foo() { std.string.format("hi"); // error no such symbol "std.string" format("hi"); // ok }
 Anyway, you can solve your problem like this:
 from foo import foo;

He can solve his problem by using Python with semicolons? I don't think that really solves it though. The original request used the full package name. I'm a big fan of static imports, but I have to agree that I just can't bring myself to use static imports when the names are things like mylibs.util.Array.Array. It just looks stupid. But when you have a module that basically implements only one class what *should* you call that module? There's no good way to do it, except to try to organize your library like Phobos and put lots of stuff in every module. So I think there is a need for a way to have eponymous one-class modules. The D package stuff seems to have been inspired largely by Java's, but the big difference is that in java it's always one-module<=>one-class so they don't have this problem. But I don't think module opCall is the right solution. It looks ok for the Stdout case because typical usage of Stdout is Stdout(). But what about .flush? For that you'd still be doing tango.io.Stdout.Stdout.flush. If anything it's more like a module opDot that you want. I don't think that's really the right way to go either, though. I think the situation is more like the template stuff. template Foo(T) { void Foo(T x) { } } Foo(3); /// Foo.Foo not needed Compare with: static import Foo; auto x = new Foo; // Foo.Foo should not be needed if class Foo is the only thing inside Foo. On the other hand, I'd really like to see the template thing fixed so there's some way to put private stuff inside there too. Similarly it'd be nice if it would work for modules as long as class Foo was the only non-public thing. I think both cases might be made cleaner by some judicious re-use of the 'this' keyword. Such as: template AReallyLongTemplateNameIDontWannaTypeTwice(T) { void this(T x) { } } and with the modules it would be: module pkg.Foo; class this { // Hi I'm the single representative class for Foo, implicitly accessible via the module name pkg.Foo. } I love how I don't have to change all the constructor names in D whenever I change a class name. Extending that DRY goodness to templates (and maybe modules too) would be nice I think. --bb
Jan 08 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:

I think this problem you refer to only applies to modules without package
names.  I.e. "module Foo" containing "class Foo".  Things seem to work ok if
you have "module x.Foo" with "class Foo" inside.<

Right. But why settle with a half-backed module system when there are more logic ways to design it? :-)
 So you are saying you want this to be an error?
 
 import std.string;
 void foo() {
     std.string.format("hi");  // error no such symbol "std.string"
     format("hi");   // ok
 }

The following examples show what I mean: import std.string; void foo() { std.string.format("hi"); // OK, "std.string" name exists in the current scope. format("hi"); // Error, "format" name is absent. } import std.string: format; void foo() { std.string.format("hi"); // Error, "std" name is absent. format("hi"); // OK. } import std.string: *; void foo() { std.string.format("hi"); // Error, "std" name is absent. format("hi"); // OK, all names inside "std.string" are now present in the current scope. } import std.string; import std.string: format; void foo() { std.string.format("hi"); // OK. format("hi"); // OK. } This doesn't solve all problems, but it's a good step toward improving the situation.
auto x = new Foo;  // Foo.Foo should not be needed if class Foo is the only
thing inside Foo.<

That's a special casing, it may look handy, but it may also lead to troubles later. So I think it's better to keep things tidy, and avoid that. D allows enough things (renamed imports, alias, and selective imports) to solve such problems already.
 template AReallyLongTemplateNameIDontWannaTypeTwice(T) {
      void this(T x) { }
 }

You can write that in D1 as: void aReallyLongTemplateNameIDontWannaTypeTwice(T)(T x) { }
I love how I don't have to change all the constructor names in D whenever I
change a class name.<

I agree, but for example when you define a opCmp of a struct you have to do: struct Foo { int x; int opCmp(Foo other) { ... As you can see the name Foo is repeated two times, and I don't like that much (I don't use an IDE able to refractor names). In D1 I sometimes solve that small problem like this: struct Foo { int x; int opCmp(typeof(*this) other) { ... Or like this: struct Foo { int x; alias typeof(*this) TyThis; int opCmp(TyThis other) { ... Bye, bearophile
Jan 08 2009
prev sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Jan 9, 2009 at 10:23 AM, bearophile <bearophileHUGS lycos.com> wrote:
 Bill Baxter:

I think this problem you refer to only applies to modules without package
names.  I.e. "module Foo" containing "class Foo".  Things seem to work ok if
you have "module x.Foo" with "class Foo" inside.<

Right. But why settle with a half-backed module system when there are more logic ways to design it? :-)
 So you are saying you want this to be an error?

 import std.string;
 void foo() {
     std.string.format("hi");  // error no such symbol "std.string"
     format("hi");   // ok
 }

The following examples show what I mean: import std.string; void foo() { std.string.format("hi"); // OK, "std.string" name exists in the current scope. format("hi"); // Error, "format" name is absent. }

Ok. You mean like Python. I guess people here have bullied you into stop using that phrase. :-) That would be fine by me. I'm also a big supporter of static import by default. But I think it still doesn't solve the Stdout.Stdout annoyance does it?
auto x = new Foo;  // Foo.Foo should not be needed if class Foo is the only
thing inside Foo.<

That's a special casing, it may look handy, but it may also lead to troubles later. So I think it's better to keep things tidy, and avoid that. D allows enough things (renamed imports, alias, and selective imports) to solve such problems already.

If you think so, then you should argue for removal of the special case stuff for templates too. On the other hand, if it worked for modules templates and classes, then would it be all that much of a special case?
 template AReallyLongTemplateNameIDontWannaTypeTwice(T) {
      void this(T x) { }
 }

You can write that in D1 as: void aReallyLongTemplateNameIDontWannaTypeTwice(T)(T x) { }

Ok, bad example. Try that for a template that defines a constant or an alias. template AReallyLongTemplateNameIDontWannaTypeTwice(T) { alias T[] ReallyLongTemplateNameIDontWannaTypeTwice; } --bb
Jan 08 2009
parent "Nick Sabalausky" <a a.a> writes:
----- Original Message ----- 
From: "Bill Baxter" <wbaxter gmail.com>
Newsgroups: digitalmars.D
To: "digitalmars.D" <digitalmars-d puremagic.com>
Sent: Thursday, January 08, 2009 8:49 PM
Subject: Re: Suggestion: module opcall


 On Fri, Jan 9, 2009 at 10:23 AM, bearophile <bearophileHUGS lycos.com>
 wrote:
 Bill Baxter:

I think this problem you refer to only applies to modules without package
names.  I.e. "module Foo" containing "class Foo".  Things seem to work ok
if you have "module x.Foo" with "class Foo" inside.<

Right. But why settle with a half-backed module system when there are more logic ways to design it? :-)
 So you are saying you want this to be an error?

 import std.string;
 void foo() {
     std.string.format("hi");  // error no such symbol "std.string"
     format("hi");   // ok
 }

The following examples show what I mean: import std.string; void foo() { std.string.format("hi"); // OK, "std.string" name exists in the current scope. format("hi"); // Error, "format" name is absent. }

Ok. You mean like Python. I guess people here have bullied you into stop using that phrase. :-)

My apologies for that ;-)
 That would be fine by me.  I'm also a big supporter of static import by
 default.

 But I think it still doesn't solve the Stdout.Stdout annoyance does it?


auto x = new Foo;  // Foo.Foo should not be needed if class Foo is the
only thing inside Foo.<

That's a special casing, it may look handy, but it may also lead to troubles later. So I think it's better to keep things tidy, and avoid that. D allows enough things (renamed imports, alias, and selective imports) to solve such problems already.

If you think so, then you should argue for removal of the special case stuff for templates too. On the other hand, if it worked for modules templates and classes, then would it be all that much of a special case?
 template AReallyLongTemplateNameIDontWannaTypeTwice(T) {
      void this(T x) { }
 }

You can write that in D1 as: void aReallyLongTemplateNameIDontWannaTypeTwice(T)(T x) { }

Ok, bad example. Try that for a template that defines a constant or an alias. template AReallyLongTemplateNameIDontWannaTypeTwice(T) { alias T[] ReallyLongTemplateNameIDontWannaTypeTwice; }

I was just thinking earlier, it would be nice if could handle const templates just like we do class templates and function templates: --------------- // Before: template SomeCodeToMixin(alias name) { const char[] SomeCodeToMixin = "int "~name~";"; } // After: const char[] SomeCodeToMixin(alias name) = "int "~name~";"; --------------- Nice as that would be, it unfortunately still doesn't solve this (which I do a lot): --------------- template SomeCodeToMixin(alias a) { const char[] SomeCodeToMixin = "int "~a~";"; pragma(msg, "SomeCodeToMixin: "~SomeCodeToMixin); } --------------- For that (...deja vu?), I'd like to have: --------------- template SomeCodeToMixin(alias a) { const char[] this = "int "~a~";"; pragma(msg, this.nameof~": "~this); } --------------- Ditto on how good D's naming is for constructors/destructors. That was one of the early things that really impressed me. (I may have double-posted, sorry about that.)
Jan 08 2009