Ant wrote:
> On Sat, 03 Jul 2004 21:15:33 -0400, Andrew Edwards wrote:
> 
> 
>>Regan Heath wrote:
>>
>>Sorry old chap, it isn't available for windows: though I eagerly
>>anticipate it's arival. Better yet "DMD" on OpenBSD! Oh well.
>>If I'm not mistaken, it does allow you to customize the kbd_mapping, which is just as effective.
>>
> 
> 
> I'm a eclipse user (at work-windows) that never saw Visual Studio.
> I started leds after trying jext and admire
> it's simplicity and effectiveness
> and after rejecting eclipse on linux just because it's so slow.
> 
> leds still doesn't compile since dmd 0.91
> see the Walter explanations on the "import bug - severe"
> thread I started on the the D.bugs group.

I don't see why this is such a big show stopper Ant. I just compiled
dui_00.13_97 on WinXP Pro with DMD v0.94 simply by inserting the
following alias on line 101 of src/dui/ObjectG.d

alias Object.toString toString;

No problems encountered whatsoever!

> so after that here is the keys configuration screenshot:
> 
> http://leds.sourceforge.net/prefEditorKeys.html
> 
> leds is being developed with leds and only recently I'm trying to
> make it user friendly.
> This issue was broght up before and I kinda of promissed that
> I would included several preconfigured keyboard mapping.
> 
> Please email me your preferred (default for some IDE not customized)
> keyboard mapping but be prepared to wait :(.
> 
> Ant
> 

On Sun, 04 Jul 2004 04:43:07 -0400, Andrew Edwards wrote:

> Ant wrote:
>> 
>> leds still doesn't compile since dmd 0.91
>> see the Walter explanations on the "import bug - severe"
>> thread I started on the the D.bugs group.
> 
> I don't see why this is such a big show stopper Ant. I just compiled dui_00.13_97 on WinXP Pro with DMD v0.94 simply by inserting the following alias on line 101 of src/dui/ObjectG.d
> 
> alias Object.toString toString;

It's ridiculous!
Do I have to look for all name colisions? no way!

getSize(out int, out int) on duiWindows
colides with getSize(char[]) std.file!

:(

When Walter fixes the multiple std import conflicts
and the overload bug all this will go away.

Ant

Ant wrote:
> On Sun, 04 Jul 2004 04:43:07 -0400, Andrew Edwards wrote:
> 
> 
>>Ant wrote:
>>
>>>leds still doesn't compile since dmd 0.91
>>>see the Walter explanations on the "import bug - severe"
>>>thread I started on the the D.bugs group.
>>
>>I don't see why this is such a big show stopper Ant. I just compiled
>>dui_00.13_97 on WinXP Pro with DMD v0.94 simply by inserting the
>>following alias on line 101 of src/dui/ObjectG.d
>>
>>alias Object.toString toString;
> 
> 
> It's ridiculous!
> Do I have to look for all name colisions? no way!
> 
> getSize(out int, out int) on duiWindows
> colides with getSize(char[]) std.file!

Probably a feature added after dui_00.13_97 (windows version). I had no
such problem. I did however, spent quite some time removing deprecated
features from the source.

To alleviate the name collision problem, I (usually) explicitly qualify
all imported functions.

  std.file.getSize("test.d");
  duiWindows.getSize(ivar1, ivar2);

It does require a bit more typing, but as long as the import structure
remains the same, there is virtually no way my code will become
ambiguous.

On another note, can I grab a copy of your windows makefile for leds?
I've been at it since last eve and I still haven't figured out how to
build one yet.

Thanks,
Andrew

> 
> :(
> 
> When Walter fixes the multiple std import conflicts
> and the overload bug all this will go away.
> 
> Ant
> 

On Sun, 04 Jul 2004 13:22:30 -0400, Andrew Edwards wrote:

> 
> To alleviate the name collision problem, I (usually) explicitly qualify
> all imported functions.
> 
>    std.file.getSize("test.d");
>    duiWindows.getSize(ivar1, ivar2);

but how do you know all function and methods?
you have to inspect all imports and your class hierarchy!
it's not possible.

> 
> On another note, can I grab a copy of your windows makefile for leds? I've been at it since last eve and I still haven't figured out how to build one yet.
> 

sure.
(please follow the discussion at
http://groups.yahoo.com/group/duitoolkit/ )

Ant

On Fri, 2 Jul 2004 19:11:44 +0000 (UTC), Ant <Ant_member@pathlink.com>
wrote:

>Shouldn't new languages be aware of IDEs?
>features and sintax should be designed having in mind
>that IDEs are here to help on the development cycle.

Well, it's waaaay too late for D to include this kind of feature, but...

I've always thought it would be beneficial to create a logical tie between a comment and the line (or block) of code to which that comment belongs. Rather than a comment just being a line of text appearing before or after (or to the right of) a given line of code, the comment would be an ATTRIBUTE of an expression.

To give a quick example of what I'm talking about, pretend that the # symbol is a comment marker. In the following line of code, there are four different comments:

MyObject #instance = (new Object(#parent, #child)).#getInstance();

...so, one line of code might contain four different comments. Or a single comment might be logically tied to multiple lines (or an entire block) of code. Of course, a really great IDE wouldn't display the # characters like I have. Instead, it might use a pale yellow background (or a dotted underline...or whatever) for each component of the expression for which a comment was attached. Hovering the mouse over the appropriate part of the expression would reveal the comment.

(...or something like that...)

Of course, it would be very difficult to implement comments like this in an ordinary source file. For it to work, the comments would have to be a part of a separate metadata file with links back to the lines and blocks in the source file.

If comments were implemented this way, it would be possible, using a diff of the source file, to determine which comments might be out-dated (since the expressions to which those comments were linked had undergone changes).

It would also be possible to include, as comments, a diverse array of different types of media, like graphics, sound files, and presentations. It would also be possible to create, in a comment, a hyperlink to another location in the source code, even if the line number of the hyperlink target changed over time.

In short, I think there's a vast arena of unexplored possibilities that become possible when you include source metadata files as part of the source code for an application. Incidentally, I'm aware of the metadata used by the .NET framework, but that's different. MSIL metadata is used in the execution of the program. The source metadata that I'm talking about would only be used used as a tool to aid programmers in documentation and code navigation.

But it would be nearly impossible to use language features like this unless direct support for them was built into the IDE. And it would prevent anyone from using plain vanilla text editors to edit the source. In fact, the only way that such a language/IDE would ever be developed would be if they were developed in parallel, allowing the IDE ideas to feed into the brainstorming of the language development (and vice versa). So, I'm somewhat skeptical that these types of tools will ever become commonplace.

But those are some ideas that I've been thinking about for a long time.

This is where an old proposal for a 'property' keyword would have helped quite nicely.  Plus its just good to make this sort of thing explicit, IMHO.  For those who don't remember the version I was supporting, here's a brief recap... ;)

property TYPE IDENT {
  IDENT = DEFAULT_VALUE; // optional
  get(out TYPE IDENT2) {
    // code for gettor.  can have 0, 1, or several of these.
  }
  set(in TYPE IDENT2) {
    // code for settor.  can have 0, 1, or several of these.
  }
}

Actually I think it was slightly different, but its been a while.  If settors are absent, then its read-only.  If gettors are absent, then the value is directly readable, as if it were a normal data field / member variable.  I really don't know why this didn't fly.  Such is the way of things, I guess.

As it is, I'm with Walter on the intellisense issue, assuming I understand him right.  Just show fields as fields and methods as methods.  Let the coder decide whether or not to treat them as properties.  This should work fine unless you're wanting to issue edit-time warnings of passing invalid types to settors or the like.

-Chris S.
-Invironz