I wish library prefixes would use "::" instead of "."

[Jos Hirth]

The problem with using a "." is that it makes those prefixes compete with your local variables.

E.g. when you import the "path" package, you'd probably use "path" as prefix and then you might want to work with a path... so, naturally you'd like to use "path" as name for your local variable, because that's what you'd call a path.

However, you can't do that, because "path" is already used for the prefix. You'd shadow the prefix.

Basically, I can't do this:

var path = path.join("directory", "file.txt");

But I could do this:

var path = path::join("directory", "file.txt");

Naming things is hard enough as it is. This really bothers me. It really really does.

What am I supposed to do? Add some '$' and/or underscores to my prefixes? The style guide doesn't allow that. It looks pretty noisy, too. "myPath"? "path2"? That would be hideous.

[Justin Fagnani]

I hear you, and sometimes feel the same. I find adding "lib" as a suffix usually suffices though.

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

[Lex Berezhny]

Try:

var file_path = path.join("directory", "file.txt");

A "path" is generic and can point to a directory or to a file, in your case you're pointing to a file so it's more explicit to call your variable file_path. Even better if your file was called something more descriptive than "file" and then your variable could reflect that.

Hope this helps!

 - lex

--

[Justin Fagnani]

On Thu, Jan 22, 2015 at 3:01 PM, Lex Berezhny <l...@damoti.com> wrote:

Try:

var file_path = path.join("directory", "file.txt");

That should be filePath :)

[Jos Hirth]

On Friday, January 23, 2015 at 12:01:56 AM UTC+1, Lex Berezhny wrote:

Try:

var file_path = path.join("directory", "file.txt");

A "path" is generic and can point to a directory or to a file, in your case you're pointing to a file so it's more explicit to call your variable file_path. Even better if your file was called something more descriptive than "file" and then your variable could reflect that.

Well, sometimes you just want to call a path "path", a router "router", a watcher "watcher", and a pool "pool".

It makes of course also sense to use those names for packages. Unsurprisingly, some people did. All of those are actual package names which are all used by the small application I'm currently writing.

Maybe Dart should allow "::" as an alternative more explicit way to refer to those sort-of namespaces. It doesn't have to be a breaking-change. (I wouldn't mind though. The way prefixes currently work is just terrible.)

[Justin Fagnani]

I like prefixes when I dream and pretend that libraries are objects. If Dart ever evolved in that direction, say where libraries were consty singleton things, and you could pass a library reference around, then the current prefix syntax would basically unify with variables.

I actually more dislike the way non-prefixed imports work, because a change in a library can change whether you're calling an instance method or an imported function.

--

[Natalie Weizenbaum]

This doesn't address your general problem, but for the path package in particular the convention is to use "p" as the prefix to avoid exactly this problem. Normally single-letter prefixes are inadvisable, but because path is so omnipresent I think it's more acceptable.

--

[Grant Jason]

+1000 Jos

Always best to minimize confusion, especially in simple cases such as this.

[George Moschovitis]

What am I supposed to do? Add some '$' and/or underscores to my prefixes? The style guide doesn't allow that. It looks pretty noisy, too. "myPath"? "path2"? That would be hideous.

What about

import '....' as PATH;

var path = PATH.join("directory", "file.txt"); 

This worked better with older coding convention for CONST_VARS.

-g.

[Anders Holmgren]

That would be awesome. I really hope libraries evolve that way.

I find it interesting that the examples quoted here are the ones I normally hit this issue with. I don't really hit the problem in general, but rather hit it a lot with a very small number of cases

[Bob Nystrom]

On Thu, Jan 22, 2015 at 3:51 PM, Jos Hirth <google...@kaioa.com> wrote:

Well, sometimes you just want to call a path "path", a router "router", a watcher "watcher", and a pool "pool".

I agree this is a real ergonomics problem, especially with the path package where "path" is just about the most common local variable name in files that use that package.

Like Natalie says, we've locally adopted the convention of using "p" as the prefix when importing path.

I considered calling the package "paths"—and generally having a package naming convention that prefers plurals—specifically to avoid this but the people I talked to on the team about it didn't seem keen on the idea. With "path" in particular, the folks I talked to really wanted it to have a "canonical"-sounding name since it was replacing the Path class, and they felt "paths" or some other name wouldn't convey that.

In general, when I design libraries I try to do one of:

1. Design the library to work well when imported without a prefix.
   
2. Give it a name unlikely to collide with local variables where it's used.
   
3. Give it a name with an underscore.

The last one is the easy way. Prefixes and variables actually do have a different naming convention, but it's only apparent when the name is multiple words. :)

The first two are more art than science.

There's lots of examples of where I haven't done this well, but I personally like library names that sound more like "mass nouns" or describe the concept of the library more than the thing it contains. For example, "watching" instead of "watcher", or "compression" instead of "compressor". Doing that avoids taking precious noun names for libraries.

Cheers!

- bob

[Jos Hirth]

Underscores... heh. Yea, library prefixes look just like everything else unless they happen to contain an underscore character.

Just adding "_lib" to everything would work:

var path = path_lib.join("directory", "file.txt");

Or a trailing underscore:

var path = path_.join("directory", "file.txt");

Ugh. :)

Still, using the somewhat popular "::" syntax looks a lot cleaner:

var path = path::join("directory", "file.txt");

This also doesn't prevent it from being a first-class thingy. You could pass it around like that, too:

whatever(path::);

A bit odd, but I'd rather have this minor oddity over in some edge-case corner than having to deal with those naming conflicts all over the place.

[Thomas Løcke]

+1

path::join - YES! 

path.join - Noooooooooo..... 

[Paul Brauner]

If Dart wants to eventually catch up to beta/newspeak, it should probably not start syntactically telling apart calling a method from accessing a library's function.

[Jos Hirth]

On Tuesday, January 27, 2015 at 9:57:28 AM UTC+1, Paul Brauner wrote:

If Dart wants to eventually catch up to beta/newspeak, it should probably not start syntactically telling apart calling a method from accessing a library's function.

If you import a library as "foo", "foo.bar()" would still work. (It's too late for breaking this.)

The difference is that "foo::" wouldn't be shadowed by a local variable called "foo". So, you could write "var foo = foo::bar();".