May 16, 2008
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
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
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
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
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
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).
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
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
June 10, 2008
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
1 2 3
Next ›   Last »