May 15, 2008
"Janice Caron" wrote
> On 14/05/2008, Bill Baxter <dnewsgroup@billbaxter.com> wrote:
>> The more unique
>
> You can't be "more unique". Uniqueness is boolean. :-)

If D had opUnique, it would return int :P

-Steve


May 15, 2008
Robert Fraser wrote:
> Yigal Chripun wrote:
>> I like the general idea, but how many times do you need to import a
>> module like tango.io.Stdout in a file?
>> a related matter: why not separate the logical namespaces from the
>> actual file system organization? something like .net does with its
>> namespaces vs. assemblies?
> 
> I generally think that's a bad idea. It's more cognitive load on the programmer (worrying about what namespace something is in and the fact that a file can cover multiple namespaces). Looking up a particular piece of code is easy for both users and IDEs if there's a 1:1 name:file correspondence.

I'm not sure whether restricting the relation to 1:1 is good or bad. this is a trade-in: you either get a more flexible mechanism albeit more complex, or a simpler mechanism that's less flexible. I don't know what's best for D in this regard.

however, there are other issues here:
for instance, eclipse allows you to define package names for folders
inside the project.
this is useful when your import is a.b.c.d.e.f.ThisIsMyClass;
the syntax allows you to just import/define this with one line, you
don't need to re-create the entire nesting in your code, like C++ needs
for namespaces. this however generates deeply nested folder hierarchies.
you can define a 1:1 relation between a module and a file, but also add
the ability to say to the compiler: the package named: a.b.c.d.e.f is
really just a folder called "f.src".
this way, you'd import derelict packages like:
derelict.openGL.*
derelict.openAL.*
derelict.SDL.*
etc..
and have each of the above packages point to that sub-project's src
directory.
an easy next step would be to define some sort of a manifest file that
contains metadata about the package, the same way Jar files/.net
assemblies are packaged. this allows you to have two different versions
of a package installed on the system without generating conflicts, or
define your folder hierarchy for sub packages to name two example use
cases. I'm sure there are more benefits to such packaging.
May 15, 2008
Ary Borenszweig, el 15 de mayo a las 11:07 me escribiste:
> Bill Baxter wrote:
> >I think it would be convenient if packages could be aliased.
> 
> I'm really amazed that this is a problem. For example in Java, I almost never need to worry about the name of a package or if the package name is long, or how many characters I'll have to write in the import. Why? Simply because I use an IDE that does that for me.

IDEs help to to write code, not read it. Code is readed much more times than it's written, so having a clean reable code is a good thing =)

And BTW, some people don't like IDEs. Things should be easy to do without using an IDE. The problem is the other way arround: in Java you *need* an IDE because all is so redundant.

It's like getters/setters, you can say: in Java I never need to write my getters and setters because the IDE do it for me. In D you don't have to write them either, and for that, you don't have to rely on an IDE and you have shorter, cleaner code which is easier to read and maintain.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
El otro día tenía un plan
Pero después me olvidé y me comí un flan
May 15, 2008
Steven Schveighoffer, el 15 de mayo a las 10:55 me escribiste:
> I admit, after writing all this, it does seem unlikely that you would ever need to use the import foo : bar = baz.

You sometimes do. I ran to that recently using Python, I had a module tipc imported:

import tipc

And then I needed some class named tipc in another module (called comm.msg), so this is not a solution:

import  tipc
from comm.msg import tipc

Solutions:

import tipc
from comm.msg import tipc as tipcmsg
# use tipc and tipcmsg

Or:

import tipc
import comm.msg as msg
# use tipc and msg.tipc
(this is what Bill Baxter proposed for D, I think)

Or:

import tipc
import comm.msg
# use tipc and comm.msg.tipc (which can be too long if typed too often)


-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Did you see the frightened ones?
Did you hear the falling bombs?
Did you ever wonder why we had to run for shelter when the promise of a
brave new world unfurled beneath a clear blue sky?
May 15, 2008
Leandro Lucarella escribió:
> Ary Borenszweig, el 15 de mayo a las 11:07 me escribiste:
>> Bill Baxter wrote:
>>> I think it would be convenient if packages could be aliased.
>> I'm really amazed that this is a problem. For example in Java, I almost never need to worry about the name of a package or if the package name is long, or how many characters I'll have to write in the import. Why? Simply because I use an IDE that does that for me. 
> 
> IDEs help to to write code, not read it. Code is readed much more times
> than it's written, so having a clean reable code is a good thing =)

Exactly. If you read "Float.toString(5);" you first say "Ok, toString must be some static method of some class or struct Float". Then you start searching and realize it's an alias, or an aliased imported symbol. So to actually understand the code you need to make some jumps through the source code... indirections. I prefer to write the fqn if there are ambiguities.

> And BTW, some people don't like IDEs. Things should be easy to do without
> using an IDE. The problem is the other way arround: in Java you *need* an
> IDE because all is so redundant.

I started writing in Java without an IDE. Compile, fix errors, etc. Remember what the name of the method was, and which arguments it accepts. In which package a class is located. Renaming was terribly slow. I can still program in Java without an IDE. But with an IDE my productiviy is really boosted.

In D you also need to make most of these steps, so I do believe that D is less redundant, but an IDE always boosts your productivity.
May 15, 2008
Steven Schveighoffer wrote:
> I admit, after writing all this, it does seem unlikely that you would ever need to use the import foo : bar = baz.

I find it useful for smoothing over std library differences. For example, Phobos's find() function returns -1 if the substring isn't found, while Tango's returns the length of the haystack. I also need the trim() function, which is called strip() in Phobos. So I have something like:

version(inTango)
{
    import tango.text.Util : trim;
    import tango.core.Array : tangoFind = find;

    private int find(char[] haystack, char[] needle)
    {
        uint res = tangoFind(haystack, needle);
        return res == haystack.length ? -1 : res;
    }
}
else
{
    import std.string : find, trim = strip;
}

This way, I can call the trim() and find() functions and expect them to work whichever library is being used.
May 15, 2008
Leandro Lucarella wrote:
> It's like getters/setters, you can say: in Java I never need to write my
> getters and setters because the IDE do it for me. In D you don't have to
> write them either, and for that, you don't have to rely on an IDE and you
> have shorter, cleaner code which is easier to read and maintain.

Err.... you don't? The D convention is to use the property syntax, but you still need to write the methods.
May 15, 2008
Robert Fraser wrote:
> Leandro Lucarella wrote:
>> It's like getters/setters, you can say: in Java I never need to write my
>> getters and setters because the IDE do it for me. In D you don't have to
>> write them either, and for that, you don't have to rely on an IDE and you
>> have shorter, cleaner code which is easier to read and maintain.
> 
> Err.... you don't? The D convention is to use the property syntax, but you still need to write the methods.

In theory, you don't have to because you can just use public members when you start out.  Property syntax gives you a way to hide those members later on if necessary.

In theory only, though, because properties and data members don't behave exactly the same (can't use a property method as an lvalue; can't make delegate of data member with &).  To be *truly* future-proof you still need to start out with your getters and setters, just like in C++/Java.

--bb
May 16, 2008
Bill Baxter wrote:
> In theory, you don't have to because you can just use public members when you start out.  Property syntax gives you a way to hide those members later on if necessary.

You can use public members in C++ and Java, too...
May 16, 2008
Robert Fraser escribió:
> Bill Baxter wrote:
>> In theory, you don't have to because you can just use public members when you start out.  Property syntax gives you a way to hide those members later on if necessary.
> 
> You can use public members in C++ and Java, too...

But if you change them to methods later, at least in Java you'd have to append "()" after each call... or if you want to be standard, rename it to get...()

Or just right click on the field in Eclipse and select Refactor -> Encapsulate Field... ;-)

(well, but that breaks compatibility with existing clients)