Dart Namespaces

[Laurențiu T.]

Hello,

How would one translate the following pseudocode to Dart in it's new no-namespace approach?

namespace Playful {
    void nickname();
}

namespace Person {
    void name();
}

namespace Locatable {
    void geolocation();
}

class Alice implements Locatable, Playful, Person,  {
    // ...
}


function show_on_map(Locatable locatable) {
    // ...
}


function start_game(Playful playful) {
    // ...
}


function bill(Person person) {
    // ...
}

[Ladislav Thon]

How would one translate the following pseudocode to Dart in it's new no-namespace approach?

What do you mean by namespace? I assume you are actually talking about interfaces -- just use classes instead, because all classes implicitly define an interface. So...
 

class Playful {
    void nickname();
}

class Person {
    void name();
}

class Locatable {

    void geolocation();
}

class Alice implements Locatable, Playful, Person,  {
    // ...
}


function show_on_map(Locatable locatable) {
    // ...
}


function start_game(Playful playful) {
    // ...
}


function bill(Person person) {
    // ...
}

That's all.

LT

[Lasse R.H. Nielsen]

On Mon, Oct 29, 2012 at 9:33 AM, Laurențiu T. <source...@gmail.com> wrote:

Hello,

How would one translate the following pseudocode to Dart in it's new no-namespace approach?

What new no-namespace approach?

Dart never had namespaces. 

You can semi-simulate name-spaces by using imports with prefixes, or you can use a class as a name-space (just as you have always been able to).

 

Your example looks like it would have used "interface". Instead you just make it an abstract class.

/L

--
Lasse R.H. Nielsen - l...@google.com  

'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 København K - Denmark - CVR nr. 28 86 69 84

[Laurențiu T.]

Sorry it's early in the morning. Dunno why I wrote "namespaces" instead of "interfaces"

[Don Olmstead]

Since namespaces were brought up I've been wondering why Dart doesn't allow you to declare one? Its useful within a library to group a bunch of functions together under one name, and to me it feels wrong when I have to create a class that will never be instantiated which contains nothing but static methods.

The Futures class is a good candidate for being a namespace rather than a class. It just has a static method and there's no reason to create a Futures class ever.

--
Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart
 
 

[Bob Nystrom]

On Mon, Oct 29, 2012 at 8:07 AM, Don Olmstead <don.j.o...@gmail.com> wrote:

Since namespaces were brought up I've been wondering why Dart doesn't allow you to declare one?

It does. They're libraries! :)

 

Its useful within a library to group a bunch of functions together under one name, and to me it feels wrong when I have to create a class that will never be instantiated which contains nothing but static methods.

Yeah, I wouldn't do a class here, I'd do a separate library and then import with a prefix.

 

The Futures class is a good candidate for being a namespace rather than a class. It just has a static method and there's no reason to create a Futures class ever.

Ugh, Futures is a good candidate for just being deleted. It contains exactly one method which returns a new Future. It should just go away and instead let you do:

new Future.waitAll(Collection<Future> futures);

There may be some issues with the type signature, though? Now that I think about it, maybe I should file a bug for this...

OK: http://code.google.com/p/dart/issues/detail?id=6385

- bob

[Don Olmstead]

Yea I know you can namespace a library but having to go that route for a handful of functions seems overkill. Then the clients have to import every sub-library within your library, and the developer has to make sure it conforms with pub. At that point its less work on everyone to just use a class with nothing but static members even though free functions would be the better design.

Its not a deal breaker for me to not have it. I was just curious if there was some reason the Dart team was against being able to explicitly declare a namespace around some functions.

[Bob Nystrom]

On Mon, Oct 29, 2012 at 6:16 PM, Don Olmstead <don.j.o...@gmail.com> wrote:

Yea I know you can namespace a library but having to go that route for a handful of functions seems overkill. Then the clients have to import every sub-library within your library,

True. :(

 

and the developer has to make sure it conforms with pub.

Not necessarily. I just said make it a library, not a package. You can have a package with multiple libraries, so splitting stuff into a sub-lib doesn't mean you have to make a new pubspec and stuff.

At that point its less work on everyone to just use a class with nothing but static members even though free functions would be the better design.

Its not a deal breaker for me to not have it. I was just curious if there was some reason the Dart team was against being able to explicitly declare a namespace around some functions.

I know if the language designers are actively against it. I could be wrong, but I think that they would say that libraries are that namespace. It's just that using them that way makes some stuff cumbersome because Dart doesn't allow multiple libraries in one file.

Cheers,

- bob

[Ross Smith]

Yea I know you can namespace a library but having to go that route for a handful of functions seems overkill. Then the clients have to import every sub-library within your library,

> True. :(

Really?  I'm using this approach and it seems to work for me.  The top-level library just needs to 'export' the sub-libraries.  Then your user can just import the top-level library if he wants 'it all', or pick and choose.  I kind of like it a lot :)

[Bob Nystrom]

On Mon, Oct 29, 2012 at 6:40 PM, Ross Smith <ross.m...@gmail.com> wrote:

Yea I know you can namespace a library but having to go that route for a handful of functions seems overkill. Then the clients have to import every sub-library within your library,

> True. :(

Really?  I'm using this approach and it seems to work for me.  The top-level library just needs to 'export' the sub-libraries.  Then your user can just import the top-level library if he wants 'it all', or pick and choose.  I kind of like it a lot :)

Yup, that works fine, but you lose the original prefix at that point. If you want to split things into multiple namespace and have them retain those as prefix or qualifiers of some sort, re-export doesn't help you as much.

Cheers!

- bob

[Kai Sellgren]

Since we are on this topic...

One thing I've been thinking about is that let's assume a very typical MVC application with a Foo controller class and a Foo model class. Let's say you have this hierarchy:

controllers/Foo.dart
models/Foo.dart

If they are on the same library called MyApp, then obviously the names conflict. You could postfix them as FooController and FooModel which to me is a bit awkward. Alternatively, we could just have them as separate libraries. We could either go into a mess by defining both as distinct libraries:

library foo_controller;

library foo_model;

or we could define a library for every controller and model:

library controllers;

class Foo {}
class Bar {}

library models;

class Foo {}
class Bar {}

which leads us to the point that what if we have two or more applications: MyApp, BackendApp and QuxApp -- they all need their own set of controllers and models and other classes. Do we then just prefix the library names of our controllers library:

library myapp_controllers;

class Foo {}
class Bar {}

library quxapp_controllers;

class Foo {}
class Bar {}

and so forth. We have plenty of choices to go for. I think the simplest is to have an app as a single library, and then just prefix/postfix accordingly:

library myapp;

class FooController {} // Defined in controllers/FooController.dart
class FooModel {} // Defined in models/FooModel.dart

That should work, but I was wondering if someone else has opinions regarding this.

[Ladislav Thon]

I think the simplest is to have an app as a single library, and then just prefix/postfix accordingly:

library myapp;

class FooController {} // Defined in controllers/FooController.dart
class FooModel {} // Defined in models/FooModel.dart

Yeah. Everybody else is doing it, so why can't we?

LT

[Bob Nystrom]

I don't have a strong opinion here, but if this were me, I would probably postfix the class name, but only one of them. Most likely:

class Foo {} // Model.

class FooController {} // Controller.

But then I'm never really sure what a "controller" is supposed to be anyway...

- bob

--