On Thu, 2010-11-04 at 08:37 -0400, Michel Fortin wrote:
> Le 2010-11-04 ? 6:34, Jonathan M Davis a ?crit :
> 
> > Regardless, I think that using a final, uninstantiatable class is the best way to create a namespace within a module in D at the moment.
> 
> It does pollute the object code with a useless vtable and ClassInfo object though. As long as there aren't too many of them it's probably fine.
> 
> Another way to achieve what you want would be:
> 
> 	template X() {
> 		void func();
> 	}
> 	mixin X x;
> 
> 	// now you can do
> 	x.func();


Unfortunately, that doesn't work with operator overloading, so it's out of the question for environment.

-Lars

On Thu, 04 Nov 2010 06:34:58 -0400, Jonathan M Davis <jmdavisProg at gmx.com>
wrote:
[snip]
> Regardless, I think that using a final,
> uninstantiatable class is the best way to create a namespace within a
> module in
> D at the moment.

What's the advantages of this over a struct with static members functions?

On Thursday, November 04, 2010 11:55:47 Robert Jacques wrote:
> On Thu, 04 Nov 2010 06:34:58 -0400, Jonathan M Davis <jmdavisProg at gmx.com>
> wrote:
> [snip]
> 
> > Regardless, I think that using a final,
> > uninstantiatable class is the best way to create a namespace within a
> > module in
> > D at the moment.

That's essentially what you're doing except that it's a class rather than a struct. And since structs _have_ to be constructable (thanks to them having to have an init property), it works better to use a class which you can stop from being constructed.

- Jonathan M Davis

On Thu, 04 Nov 2010 18:04:11 -0400, Jonathan M Davis <jmdavisProg at gmx.com> wrote:

> On Thursday, November 04, 2010 11:55:47 Robert Jacques wrote:
>> On Thu, 04 Nov 2010 06:34:58 -0400, Jonathan M Davis
>> <jmdavisProg at gmx.com>
>> wrote:
>> [snip]
>>
>> > Regardless, I think that using a final,
>> > uninstantiatable class is the best way to create a namespace within a
>> > module in
>> > D at the moment.
>
> That's essentially what you're doing except that it's a class rather
> than a
> struct. And since structs _have_ to be constructable (thanks to them
> having to
> have an init property), it works better to use a class which you can
> stop from
> being constructed.

Isn't that what @disable was for?

On Thursday, November 04, 2010 15:20:42 Robert Jacques wrote:
> On Thu, 04 Nov 2010 18:04:11 -0400, Jonathan M Davis <jmdavisProg at gmx.com>
> 
> wrote:
> > On Thursday, November 04, 2010 11:55:47 Robert Jacques wrote:
> >> On Thu, 04 Nov 2010 06:34:58 -0400, Jonathan M Davis
> >> <jmdavisProg at gmx.com>
> >> wrote:
> >> [snip]
> >> 
> >> > Regardless, I think that using a final,
> >> > uninstantiatable class is the best way to create a namespace within a
> >> > module in
> >> > D at the moment.
> > 
> > That's essentially what you're doing except that it's a class rather
> > than a
> > struct. And since structs _have_ to be constructable (thanks to them
> > having to
> > have an init property), it works better to use a class which you can
> > stop from
> > being constructed.
> 
> Isn't that what @disable was for?

That's what I used in datetime - I made Clock final and used @disable on this() (as opposed to Lars, who made his class both abstract and final), so you can't create it. But since structs _must_ have an init property, I don't see how you can possibly prevent them from being constructed.

- Jonathan M Davis

On Thu, 04 Nov 2010 18:28:40 -0400, Jonathan M Davis <jmdavisProg at gmx.com> wrote:

> On Thursday, November 04, 2010 15:20:42 Robert Jacques wrote:
>> On Thu, 04 Nov 2010 18:04:11 -0400, Jonathan M Davis <jmdavisProg at gmx.com>
>>
>> wrote:
>> > On Thursday, November 04, 2010 11:55:47 Robert Jacques wrote:
>> >> On Thu, 04 Nov 2010 06:34:58 -0400, Jonathan M Davis
>> >> <jmdavisProg at gmx.com>
>> >> wrote:
>> >> [snip]
>> >>
>> >> > Regardless, I think that using a final,
>> >> > uninstantiatable class is the best way to create a namespace
>> within a
>> >> > module in
>> >> > D at the moment.
>> >
>> > That's essentially what you're doing except that it's a class rather
>> > than a
>> > struct. And since structs _have_ to be constructable (thanks to them
>> > having to
>> > have an init property), it works better to use a class which you can
>> > stop from
>> > being constructed.
>>
>> Isn't that what @disable was for?
>
> That's what I used in datetime - I made Clock final and used @disable on
> this()
> (as opposed to Lars, who made his class both abstract and final), so you
> can't
> create it. But since structs _must_ have an init property, I don't see
> how you
> can possibly prevent them from being constructed.

You're right in that you can always declare a variable of type struct, but then again you can always declare a variable of type final abstract class, so I'm not sure what that buys you. Also, interfaces support static members and so can be used as namespaces as well.