www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Proposal: Package aliases

reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Using packages for modules in D is good.  It prevents name clashes.  But 
you need a unique package name.  The more unique (i.e. longer), the more 
a pain it becomes to use a bunch of modules from that package.

For example in Java, all of SWT is in the org.eclipse.swt package.  For 
DWT Frank just shortened the package to "dwt" because having to type 
something longer so many times would be a pain (and I guess because dwt 
isn't really an Eclipse project.)

Anyway, putting code inside uniquely named packages is a good thing. 
But nobody wants package names to be very long, because you have to type 
them every time you do an import.  Hence we have "std", and "tango". 
The longest "vendor" package name I know of is "derelict".  And quite a 
bit of D code out there uses no package at all.

I think it would be convenient if packages could be aliased.

Right now this is not possible:

   alias tango.io tio; // this alias actually compiles, but...
   import tio.Stdout;  // import using it doesn't work

(Note for the Tango non-savvy: import tango.io.Stdout *is* valid.)

So my proposal is simply to make the above code work.
I was actually mildly surprised that it didn't.

If we had this then people would be more free to name their packages 
whatever they like, comfortable in the knowledge that users will only 
have to type the full package name once.

--bb
May 14 2008
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Bill Baxter wrote:

 Using packages for modules in D is good.  It prevents name clashes.  But 
 you need a unique package name.  The more unique (i.e. longer), the more 
 a pain it becomes to use a bunch of modules from that package.
 
 For example in Java, all of SWT is in the org.eclipse.swt package.  For 
 DWT Frank just shortened the package to "dwt" because having to type 
 something longer so many times would be a pain (and I guess because dwt 
 isn't really an Eclipse project.)
 
 Anyway, putting code inside uniquely named packages is a good thing. But 
 nobody wants package names to be very long, because you have to type 
 them every time you do an import.  Hence we have "std", and "tango". The 
 longest "vendor" package name I know of is "derelict".  And quite a bit 
 of D code out there uses no package at all.
 
 I think it would be convenient if packages could be aliased.
 
 Right now this is not possible:
 
   alias tango.io tio; // this alias actually compiles, but...
   import tio.Stdout;  // import using it doesn't work
 
 (Note for the Tango non-savvy: import tango.io.Stdout *is* valid.)
 
 So my proposal is simply to make the above code work.
 I was actually mildly surprised that it didn't.
 
 If we had this then people would be more free to name their packages 
 whatever they like, comfortable in the knowledge that users will only 
 have to type the full package name once.


Another possibility would be a new form of "with" for packages:

with(dwt.widgets) {
   import Button,Control,Display,Shell;
}

--bb
May 14 2008
next sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
Bill Baxter wrote:

 Bill Baxter wrote:

 Using packages for modules in D is good.  It prevents name clashes. 
 But you need a unique package name.  The more unique (i.e. longer),
 the more a pain it becomes to use a bunch of modules from that package.

 For example in Java, all of SWT is in the org.eclipse.swt package. 
 For DWT Frank just shortened the package to "dwt" because having to
 type something longer so many times would be a pain (and I guess
 because dwt isn't really an Eclipse project.)

 Anyway, putting code inside uniquely named packages is a good thing.
 But nobody wants package names to be very long, because you have to
 type them every time you do an import.  Hence we have "std", and
 "tango". The longest "vendor" package name I know of is "derelict". 
 And quite a bit of D code out there uses no package at all.

 I think it would be convenient if packages could be aliased.

 Right now this is not possible:

   alias tango.io tio; // this alias actually compiles, but...
   import tio.Stdout;  // import using it doesn't work

 (Note for the Tango non-savvy: import tango.io.Stdout *is* valid.)

 So my proposal is simply to make the above code work.
 I was actually mildly surprised that it didn't.

 If we had this then people would be more free to name their packages
 whatever they like, comfortable in the knowledge that users will only
 have to type the full package name once.


 
 Another possibility would be a new form of "with" for packages:
 
 with(dwt.widgets) {
   import Button,Control,Display,Shell;
 }
 
 --bb


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?
May 14 2008
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Yigal Chripun wrote:

 Bill Baxter wrote:

 Bill Baxter wrote:

 Using packages for modules in D is good.  It prevents name clashes. 
 But you need a unique package name.  The more unique (i.e. longer),
 the more a pain it becomes to use a bunch of modules from that package.

 For example in Java, all of SWT is in the org.eclipse.swt package. 
 For DWT Frank just shortened the package to "dwt" because having to
 type something longer so many times would be a pain (and I guess
 because dwt isn't really an Eclipse project.)

 Anyway, putting code inside uniquely named packages is a good thing.
 But nobody wants package names to be very long, because you have to
 type them every time you do an import.  Hence we have "std", and
 "tango". The longest "vendor" package name I know of is "derelict". 
 And quite a bit of D code out there uses no package at all.

 I think it would be convenient if packages could be aliased.

 Right now this is not possible:

   alias tango.io tio; // this alias actually compiles, but...
   import tio.Stdout;  // import using it doesn't work

 (Note for the Tango non-savvy: import tango.io.Stdout *is* valid.)

 So my proposal is simply to make the above code work.
 I was actually mildly surprised that it didn't.

 If we had this then people would be more free to name their packages
 whatever they like, comfortable in the knowledge that users will only
 have to type the full package name once.


 Another possibility would be a new form of "with" for packages:

 with(dwt.widgets) {
   import Button,Control,Display,Shell;
 }

 --bb


 
 I like the general idea, but how many times do you need to import a
 module like tango.io.Stdout in a file?


I was just trying to use something a lot of people would recognize.  A 
better example would be dwt:

import dwt.DWT;

import dwt.dwthelper.Runnable;

import dwt.widgets.Display;
import dwt.widgets.Shell;
import dwt.widgets.CoolBar;
import dwt.widgets.CoolItem;
import dwt.widgets.ToolBar;
import dwt.widgets.ToolItem;

import dwt.events.ControlEvent;
import dwt.events.ControlAdapter;

import dwt.layout.FillLayout;
import dwt.layout.FormLayout;
import dwt.layout.FormData;
import dwt.layout.FormAttachment;
import dwt.layout.GridLayout;
import dwt.layout.GridData;

import dwt.graphics.Rectangle;

import dwt.opengl.GLCanvas;
import dwt.opengl.GLData;


It would be nice if the redundancy could be reduced somehow.



 a related matter: why not separate the logical namespaces from the
 actual file system organization? something like .net does with its
 namespaces vs. assemblies?


Can you explain what .NET does a little more?  I'm not familiar with it.

--bb
May 14 2008
parent Yigal Chripun <yigal100 gmail.com> writes:
Bill Baxter wrote:

 Yigal Chripun wrote:

 Bill Baxter wrote:

 Bill Baxter wrote:

 Using packages for modules in D is good.  It prevents name clashes.
 But you need a unique package name.  The more unique (i.e. longer),
 the more a pain it becomes to use a bunch of modules from that package.

 For example in Java, all of SWT is in the org.eclipse.swt package.
 For DWT Frank just shortened the package to "dwt" because having to
 type something longer so many times would be a pain (and I guess
 because dwt isn't really an Eclipse project.)

 Anyway, putting code inside uniquely named packages is a good thing.
 But nobody wants package names to be very long, because you have to
 type them every time you do an import.  Hence we have "std", and
 "tango". The longest "vendor" package name I know of is "derelict".
 And quite a bit of D code out there uses no package at all.

 I think it would be convenient if packages could be aliased.

 Right now this is not possible:

   alias tango.io tio; // this alias actually compiles, but...
   import tio.Stdout;  // import using it doesn't work

 (Note for the Tango non-savvy: import tango.io.Stdout *is* valid.)

 So my proposal is simply to make the above code work.
 I was actually mildly surprised that it didn't.

 If we had this then people would be more free to name their packages
 whatever they like, comfortable in the knowledge that users will only
 have to type the full package name once.


 Another possibility would be a new form of "with" for packages:

 with(dwt.widgets) {
   import Button,Control,Display,Shell;
 }

 --bb


 I like the general idea, but how many times do you need to import a
 module like tango.io.Stdout in a file?


 
 I was just trying to use something a lot of people would recognize.  A
 better example would be dwt:
 
 import dwt.DWT;
 
 import dwt.dwthelper.Runnable;
 
 import dwt.widgets.Display;
 import dwt.widgets.Shell;
 import dwt.widgets.CoolBar;
 import dwt.widgets.CoolItem;
 import dwt.widgets.ToolBar;
 import dwt.widgets.ToolItem;
 
 import dwt.events.ControlEvent;
 import dwt.events.ControlAdapter;
 
 import dwt.layout.FillLayout;
 import dwt.layout.FormLayout;
 import dwt.layout.FormData;
 import dwt.layout.FormAttachment;
 import dwt.layout.GridLayout;
 import dwt.layout.GridData;
 
 import dwt.graphics.Rectangle;
 
 import dwt.opengl.GLCanvas;
 import dwt.opengl.GLData;
 
 
 It would be nice if the redundancy could be reduced somehow.
 
 

 a related matter: why not separate the logical namespaces from the
 actual file system organization? something like .net does with its
 namespaces vs. assemblies?


 
 Can you explain what .NET does a little more?  I'm not familiar with it.
 
 --bb


.net uses assemblies. ON MSDN they like to refer to them as "logical
dlls" they are closer to Java's Jar files more than DLLs, I think.
such an assembly contains all the code to be run (I think in MSIL
format) together with a manifest file with metadata, like versions,
namespace mappings and such ( I don't know what it contains exactly, but
it would be easy to find out).

units. when compiling you give the compiler the assemblies and it uses
the metadata inside to map assemblies to namespaces.
also, an assembly can contain compiled code from different languages due
to the nature of .net.
that's just some info I've found via google. Someone more knowledgeable
in this could provide more details. something similar to this scheme can
be added to D's DDL, or something similar.
Java uses Jar files to package their libs/executables and .net uses
those assemblies. D still uses dlls which we all know their problems.
maybe even adopting such a scheme could be used to make D packages
portable. maybe via providing a version for each OS (similar to mac OSX
fat binaries) and allowing the compiler to chose the correct version, or
using some portable format, though this would be optional if at all
available, since we all use D cause it's a natively compiled language :)

for that to work We just need to find a scheme that allows portability
without affecting performance. I'm sure it is possible without creating
our own 500MB (I don't know the exact size) runtime like .net has or a
VM somilar to Java's.
May 16 2008
prev sibling next sibling parent Derek Parnell <derek nomail.afraid.org> writes:
On Thu, 15 May 2008 02:06:44 +0300, Yigal Chripun wrote:


 a related matter: why not separate the logical namespaces from the
 actual file system organization? something like .net does with its
 namespaces vs. assemblies?


It would be useful to separate the file system assumptions from the
package/module name, but there would still have to be some mechanism for
the compiler to map package/module names to the file system. It has to read
those files at compile time so it has to know where to get a module's file
from. The current mechanism works but it enforces a number of restrictions
on us. 

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
15/05/2008 12:09:15 PM
May 14 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
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.
May 14 2008
parent Yigal Chripun <yigal100 gmail.com> writes:
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
prev sibling parent Fawzi Mohamed <fmohamed mac.com> writes:
On 2008-05-14 23:29:37 +0200, Bill Baxter <dnewsgroup billbaxter.com> said:


 Bill Baxter wrote:

 [...]
 I think it would be convenient if packages could be aliased.
 
 Right now this is not possible:
 
   alias tango.io tio; // this alias actually compiles, but...
   import tio.Stdout;  // import using it doesn't work
 
 (Note for the Tango non-savvy: import tango.io.Stdout *is* valid.)
 
 So my proposal is simply to make the above code work.
 I was actually mildly surprised that it didn't.
 
 If we had this then people would be more free to name their packages 
 whatever they like, comfortable in the knowledge that users will only 
 have to type the full package name once.


 
 Another possibility would be a new form of "with" for packages:
 
 with(dwt.widgets) {
    import Button,Control,Display,Shell;
 }
 
 --bb


I understand from where this idea comes, and it could be useful 
especially when you start writing a module named baz, and later you 
want to move it to foo.baz you can do it with minimal changes.

At the beginning I thought that it was a very good idea, but thinking 
more about it I am not so sure anymore.
It would make automatic parsing, and grepping the source more complex 
but you gain some typing work.

You can replace all occurences of the module using some regexp and 
dired in emacs, or any other editor that supports interactive regexp 
substitution on groups of files.
It is not perfect because in the worst case you are mixing qualified 
accesses (that need a change from import baz to import baz=foo.baz) and 
unqualified accesses (that needs import foo.baz).
One can always replace import baz with import foo.baz; alias foo.baz baz;
This is not very nice, but neither so ugly...

Of your proposals I like the first (make alias of modules usable for 
other imports) much more than the with syntax. It makes things more 
uniform and one might reasonably expect it to work, but as said I am 
quite neutral about this feature (it will make IDE, and external tools 
work more complex), but if available I would probably use it.

Fawzi
May 16 2008
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
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. So instead of 
worrying about structuring a source file just to get the imports right, 
aliasing imports and making things shorter, I just need to worry about 
the problem I need to solve, algorithms, etc.

If you have only one way to import a module, than it becomes simple: you 
don't have to think how you'll import import it, you just do it.

I also find useless and confusing to alias imported symbols like "import 
foo : bar = baz"... who actually uses that? What for?

Just some thoughts...

(I'm sorry I always mention an IDE and stuff like that, but the point 
is, I can focus on the problem instead of on the structure of the source 
file)
May 15 2008
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Ary Borenszweig" wrote

 I also find useless and confusing to alias imported symbols like "import 
 foo : bar = baz"... who actually uses that? What for?


The main reason is if you have two different modules that contain the same 
symbol names.

The main place I use it is for tango.text.convert.*  the Integer and Float 
modules both have toString functions defined.  If you import both, you need 
to fully qualify the name, however, if you do:

import Int = tango.text.convert.Integer;
import Float = tango.text.convert.Float;

Then you can easily specify which module's function you wanted:

Int.toString(5);
Float.toString(5);

I imagine you could do it similarly with the syntax you identified:

import tango.text.convert.Integer : toString = intToString;
import tango.text.convert.Float : toString = floatToString;

But that is only if you need the toString.  If you wanted to use other 
functions in those modules, then you would use the other method (scoping the 
entire import).

I admit, after writing all this, it does seem unlikely that you would ever 
need to use the import foo : bar = baz.

But I think it would be very useful to import multiple modules from the same 
package.

-Steve
May 15 2008
next sibling parent Leandro Lucarella <llucax gmail.com> writes:
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


Or:

import tipc
import comm.msg as msg

(this is what Bill Baxter proposed for D, I think)

Or:

import tipc
import comm.msg



-- 
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
prev sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
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
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
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
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
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
parent reply Leandro Lucarella <llucax gmail.com> writes:
Ary Borenszweig, el 15 de mayo a las 18:58 me escribiste:

 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.


This is not a problem when there is locality. If modules, classes and
functions are small (they should be :), you don't have to remember a lot
of stuff. I find myself doing a lot of aliases and I never find myself in
the situation where I don't know where things come from.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
- Que hacés, ratita?
- Espero un ratito...
May 16 2008
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Leandro Lucarella wrote:

 Ary Borenszweig, el 15 de mayo a las 18:58 me escribiste:

 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.


 
 This is not a problem when there is locality. If modules, classes and
 functions are small (they should be :), you don't have to remember a lot
 of stuff. I find myself doing a lot of aliases and I never find myself in
 the situation where I don't know where things come from.


Not you... but other readers of your code? :-)
May 16 2008
parent Leandro Lucarella <llucax gmail.com> writes:
Ary Borenszweig, el 16 de mayo a las 11:59 me escribiste:

This is not a problem when there is locality. If modules, classes and
functions are small (they should be :), you don't have to remember a lot
of stuff. I find myself doing a lot of aliases and I never find myself in
the situation where I don't know where things come from.


 
 Not you... but other readers of your code? :-)


I don't remember any complains =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Y Gloria Carrá, Gloria Estephan, Gloria Gaynor y Gloria Trevi.
	-- Peperino Pómoro
May 16 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
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
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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 15 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
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 15 2008
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
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)
May 15 2008
parent Leandro Lucarella <llucax gmail.com> writes:
Ary Borenszweig, el 15 de mayo a las 22:05 me escribiste:

 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)


Exactly.

I don't think this video says anything people here don't know, but just in
case:
http://www.archive.org/download/SeanKellyRecoveryfromAddiction/Recovery_from_Addiction.mov

BTW, is Plone's Sean Kelly related to Tango's Sean Kelly? =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
You look so tired-unhappy,
bring down the government,
they don't, they don't speak for us.
May 16 2008
prev sibling next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 14/05/2008, Bill Baxter <dnewsgroup billbaxter.com> wrote:

 The more unique


You can't be "more unique". Uniqueness is boolean. :-)
May 15 2008
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
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. :-)


Thanks for the info, professor.

--bb
May 15 2008
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"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
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Steven Schveighoffer wrote:

 "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 
 
 


Lol, that's quite 1.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jun 10 2008
prev sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Bill Baxter wrote:

 I think it would be convenient if packages could be aliased.
 
 Right now this is not possible:
 
   alias tango.io tio; // this alias actually compiles, but...
   import tio.Stdout;  // import using it doesn't work
 
 (Note for the Tango non-savvy: import tango.io.Stdout *is* valid.)
 
 So my proposal is simply to make the above code work.
 I was actually mildly surprised that it didn't.


After reading everyone's replies I think I am also somewhat ambivalent 
about this proposal.   Copy-paste is not hard with any half decent text 
editor.  And while long preambles full of redundant import statements 
may look like a waste of space, it's not particularly hard to read 
something like this:

import dwt.DWT;
import dwt.graphics.Color;
import dwt.graphics.Rectangle;
import dwt.graphics.GC;
import dwt.widgets.Display;
import dwt.widgets.Shell;
import dwt.widgets.Widget;
import dwt.widgets.Composite;
import dwt.widgets.Tree;
import dwt.widgets.TreeItem;
import dwt.widgets.Text;
import dwt.widgets.Listener;
import dwt.widgets.Event;
import dwt.layout.FillLayout;
import dwt.custom.TreeEditor;

Plus you can always make your own package subset public-import module if 
you want.

--bb
May 16 2008