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.

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.

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). the idea is that you use namespaces in your C# code, as logical code 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 # 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
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.

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.

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.

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.

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.

than it's written, so having a clean reable code is a good thing =)

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.


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


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