View mode: basic / threaded / horizontal-split · Log in · Help
May 15, 2008
Re: Proposal: Package aliases
"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
Re: Proposal: Package aliases
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
Re: Proposal: Package aliases
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
Re: Proposal: Package aliases
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
Re: Proposal: Package aliases
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
Re: Proposal: Package aliases
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
Re: Proposal: Package aliases
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
Re: Proposal: Package aliases
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
Re: Proposal: Package aliases
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
Re: Proposal: Package aliases
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)
1 2 3
Top | Discussion index | About this forum | D home