www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D and IDEs

reply Ant <Ant_member pathlink.com> writes:
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.

D already has a problem with the properties,
it's goind to be very difficult for an IDE
to figure out when a method should or not be presented as
a property.

maybe there are other examples but I just wanted to raise
this issue (4 years too late unfortunatly).

Ant
Jul 02 2004
next sibling parent reply kinghajj <kinghajj_member pathlink.com> writes:
In article <cc4c1g$bui$1 digitaldaemon.com>, Ant says...

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.

D already has a problem with the properties,
it's goind to be very difficult for an IDE
to figure out when a method should or not be presented as
a property.

maybe there are other examples but I just wanted to raise
this issue (4 years too late unfortunatly).

Ant


DIDE is a good IDE. It doesn't "auto-complete", so don't be lazy! Type it in all
yourself instead of having an IDE find members of a class or structure for you.
Jul 02 2004
next sibling parent Andy Friesen <andy ikagames.com> writes:
kinghajj wrote:


 DIDE is a good IDE. It doesn't "auto-complete", so don't be lazy! Type it in
all
 yourself instead of having an IDE find members of a class or structure for you.


Why on Earth is letting an editor help out lazy?  It's not like you can 
type the identifier better or faster, or that the code will somehow be 
better because every character was the result of a human pressing a key.

Typing is effectively manual labour.  I don't like manual labour. 
(especially with all the RSI that goes on where keyboards are concerned)

  -- andy
Jul 02 2004
prev sibling next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <cc4fo2$h39$1 digitaldaemon.com>, kinghajj says...

In article <cc4c1g$bui$1 digitaldaemon.com>, Ant says...

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.

D already has a problem with the properties,
it's goind to be very difficult for an IDE
to figure out when a method should or not be presented as
a property.

maybe there are other examples but I just wanted to raise
this issue (4 years too late unfortunatly).

Ant


DIDE is a good IDE. It doesn't "auto-complete", so don't be lazy! Type it in all
yourself instead of having an IDE find members of a class or structure for you.


Sorry, my fault, I should have added:

Ant, Author of leds, arguably the best IDE for D ever!
grab the excelent and free leds at:

http://leds.sourceforge.net

:)

leds does do "auto-complete" but auto-complete has nothing to do
with laziness or how fast you type. Auto complete, at least on leds,
exposes (or reminds) the public interface of any class on your
application and libs.
If you are working on a small example/test applications
that you build yourself that's probably a small help.
When working on a large application intellisence is just a smart
and convinient way IDEs have to quickly show you the API documentation.
leds intellisense is more then that, leds is free check it for yourself.

To me calling intellisence a tool for lazy people shows that you didn't
really understand it's usefullness, can you agree that it is more then
a typing help?

but I insiste on the original issue. Coding with notepad it's old
and new languages should be tools friendly. Having a reasonable
development environment can be an important feature to make
or break a language.

Ant
Jul 02 2004
parent "Blandger" <zeroman aport.ru> writes:
 Ant, Author of leds, arguably the best IDE for D ever!
 grab the excelent and free leds at:
 http://leds.sourceforge.net
 :)


As for me I looking forward to try it on window for the couple of months. ;)


 leds does do "auto-complete"


Especially this.


 leds intellisense is more then that, leds is free check it for yourself.


I can't because I don't have a Linux on my desktop. :(


 Having a reasonable
 development environment can be an important feature to make
 or break a language.


Totally agree.

Yuriy.
Jul 03 2004
prev sibling parent "Phill" <phill pacific.net.au> writes:
"kinghajj" <kinghajj_member pathlink.com> wrote in message
news:cc4fo2$h39$1 digitaldaemon.com...

 In article <cc4c1g$bui$1 digitaldaemon.com>, Ant says...

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.

D already has a problem with the properties,
it's goind to be very difficult for an IDE
to figure out when a method should or not be presented as
a property.

maybe there are other examples but I just wanted to raise
this issue (4 years too late unfortunatly).

Ant


 DIDE is a good IDE. It doesn't "auto-complete", so don't be lazy! Type it


in all

 yourself instead of having an IDE find members of a class or structure for


you.


Yep DIDE is great.
Maybe you meant to say that it does auto-complete
instead of what you actually said.

I think that auto-complete is more to do with
productivity than lazyiness, although somtimes it
annoys me when it completes somthing
when I dont want it to,
then I have to erase, and try to type the word again.

BTW ant also has a great editor.

Phill.



 Jul 02 2004



prev sibling next sibling parent reply Andy Friesen <andy ikagames.com>  writes:


Ant 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.
 
 D already has a problem with the properties,
 it's goind to be very difficult for an IDE
 to figure out when a method should or not be presented as
 a property.
 
 maybe there are other examples but I just wanted to raise
 this issue (4 years too late unfortunatly).


I agree completely.

Properties are, strictly speaking, necessarily "evil" because they can 
never be first class types in a language.  (the whole point, after all, 
is that getting or setting their value doesn't really do that at all)

Despite all that, the darned things are just too useful to let go of.  I 
would be happier if they were "magical" class members which could not be 
interacted with in any way other than 'get' and 'set'.  Without any 
other symbol using up the name, the ambiguities dissappear.

Now that I've typed all that out, though, it seems to me that figuring 
out what's going on should be easy to work out:

     'obj.function' is a property read
     'obj.function=' is a property write
     '&obj.function' is a delegate constructor
     'obj.function(' is a method call

So maybe it's not such a big deal. :)

  -- andy



 Jul 02 2004



 next sibling parent reply Trejkaz Xaoza <trejkaz xaoza.net>  writes:


Andy Friesen wrote:

 Ant 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.
 
 D already has a problem with the properties,
 it's goind to be very difficult for an IDE
 to figure out when a method should or not be presented as
 a property.
 
 maybe there are other examples but I just wanted to raise
 this issue (4 years too late unfortunatly).


 
 I agree completely.
 
 Properties are, strictly speaking, necessarily "evil" because they can
 never be first class types in a language.  (the whole point, after all,
 is that getting or setting their value doesn't really do that at all)
 
 Despite all that, the darned things are just too useful to let go of.  I
 would be happier if they were "magical" class members which could not be
 interacted with in any way other than 'get' and 'set'.


Well, there are the cases where you have something like this...

    public int getValue()
    {
        return foo;
    }

But I would argue that in this case, it shouldn't be treated as a property,
since it isn't returning the actual property.

Properties in most cases are really just a dirty workaround for making
read-only properties.  It would be neat if a language would get this
feature natively.  Then we wouldn't have to use one dirty hack (using
property syntax to call a method) to implement another hack (using methods
to implement read-only properties.)  It seems somewhat dirty that we have
to go through methods when we're dealing with properties the whole time.

I don't know what the syntax would look like though in any case.

I suppose the most common case would be something like

    public(read) int value;

Default for variables would be private as always, but public(read) would
allow you to open the ability to read the value, without permitting it to
be written.

If you wanted some wacky access like public read, protected write, you would
have to use

    public(read) protected(write) int value;

Anyway this is just a nice-to-have, I don't honestly expect any usable
language to do this kind of thing soon, without using the method-style
properties.

TX

-- 
'Every sufficiently advanced technology is indistinguishable from magic' -
Arthur C Clarke
'Every sufficiently advanced magic is indistinguishable from technology' -
Tom Graves

             Email: Trejkaz Xaoza <trejkaz xaoza.net>
          Web site: http://xaoza.net/trejkaz/
         Jabber ID: trejkaz jabber.xaoza.net
   GPG Fingerprint: 9EEB 97D7 8F7B 7977 F39F  A62C B8C7 BC8B 037E EA73



 Jul 02 2004



  parent  "Bent Rasmussen" <exo bent-rasmussen.info>  writes:


 Properties in most cases are really just a dirty workaround for making
 read-only properties.  It would be neat if a language would get this
 feature natively.  Then we wouldn't have to use one dirty hack (using


Eiffel does.* It is not possible to do object.field = value, unless object =
this. This is quite nice. But having both get and set be transparent allows
you to move transparently between a field and a computation  without
affecting external code.

* afaik



 Jul 02 2004



prev sibling  parent  "C. Sauls" <ibisbasenji yahoo.com>  writes:


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



 Jul 06 2004



prev sibling next sibling parent  "Walter" <newshound digitalmars.com>  writes:


"Ant" <Ant_member pathlink.com> wrote in message
news:cc4c1g$bui$1 digitaldaemon.com...

 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.


D is pretty friendly to IDEs, it's far, far easier to parse than C++.


 D already has a problem with the properties,
 it's goind to be very difficult for an IDE
 to figure out when a method should or not be presented as
 a property.


I'd take the straightforward approach and represent it as a property if it
is a data member, and a function if it is a method member.


 maybe there are other examples but I just wanted to raise
 this issue (4 years too late unfortunatly).

 Ant





 Jul 02 2004



prev sibling next sibling parent reply Mista <stoop hotpop.com>  writes:


Ant 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.


No ofcourse not.
The goal should be a good language for the user, not for other programs.
IDE's can be made to overcome problems, that's not the problem for 'new' 
languages to solve.



 Jul 03 2004



  parent reply Andy Friesen <andy ikagames.com>  writes:


Mista wrote:


 Ant 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.


 
 
 No ofcourse not.
 The goal should be a good language for the user, not for other programs.
 IDE's can be made to overcome problems, that's not the problem for 'new' 
 languages to solve.


I disagree.  If computers can easily understand the source code, then 
those computers can help us feeble humans out better.  Besides, 
simplicity usually benefits both humans and computers at the same time. 
  It's not a case of having to sacrifice one for the other.

The best example of this is in the difference between Microsoft's Visual 

editor highlights classes, namespaces, and other symbols with different 
colours, always provides *correct* drop-down auto-completion, and even 
underlines syntax errors on the fly.  The C++ editor can do none of 
these things, presumably because of the sheer complexity of C++.

At any rate, ease of implementation was and is an overt goal guiding the 
design of D, and I think it has achieved that admirably.

Now we just need something as good as Visual Studio for it. :)

  -- andy



 Jul 03 2004



 next sibling parent  Sean Kelly <sean f4.ca>  writes:


In article <cc75gv$1gn9$1 digitaldaemon.com>, Andy Friesen says...

The best example of this is in the difference between Microsoft's Visual 

editor highlights classes, namespaces, and other symbols with different 
colours, always provides *correct* drop-down auto-completion, and even 
underlines syntax errors on the fly.  The C++ editor can do none of 
these things, presumably because of the sheer complexity of C++.


More likely because Visual Studio .NET shipped incomplete :)  The Visual Studio
2003 editor is a vast improvement over the 2002 editor if you're interested in
things like intellisense.  For D I've been using emacs and found it superior in
some ways to Visual Studio, though it still has a few kinks to work out.  But
then I don't much care about intellisense and the other new editor features.


Now we just need something as good as Visual Studio for it. :)


When I see "IDE" I think debugger.  If Visual Studio could debug D apps as well
as it can C++ apps I would dance for joy.

Sean



 Jul 03 2004



prev sibling next sibling parent reply Ant <Ant_member pathlink.com>  writes:


In article <cc75gv$1gn9$1 digitaldaemon.com>, Andy Friesen says...

Mista wrote:


 Ant 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.


 
 
 No ofcourse not.
 The goal should be a good language for the user, not for other programs.
 IDE's can be made to overcome problems, that's not the problem for 'new' 
 languages to solve.


I disagree.  If computers can easily understand the source code, then 
those computers can help us feeble humans out better.  Besides, 
simplicity usually benefits both humans and computers at the same time. 
  It's not a case of having to sacrifice one for the other.

The best example of this is in the difference between Microsoft's Visual 

editor highlights classes, namespaces, and other symbols with different 
colours, always provides *correct* drop-down auto-completion, and even 
underlines syntax errors on the fly.  The C++ editor can do none of 
these things, presumably because of the sheer complexity of C++.

At any rate, ease of implementation was and is an overt goal guiding the 
design of D, and I think it has achieved that admirably.


that's what I mean.


Now we just need something as good as Visual Studio for it. :)


(can I plug leds here? better not...)

Ant



 Jul 03 2004



  parent reply Regan Heath <regan netwin.co.nz>  writes:


On Sat, 3 Jul 2004 21:31:51 +0000 (UTC), Ant <Ant_member pathlink.com> 
wrote:

 In article <cc75gv$1gn9$1 digitaldaemon.com>, Andy Friesen says...

 Mista wrote:


 Ant 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.



 No ofcourse not.
 The goal should be a good language for the user, not for other 
 programs.
 IDE's can be made to overcome problems, that's not the problem for 
 'new'
 languages to solve.


 I disagree.  If computers can easily understand the source code, then
 those computers can help us feeble humans out better.  Besides,
 simplicity usually benefits both humans and computers at the same time.
  It's not a case of having to sacrifice one for the other.

 The best example of this is in the difference between Microsoft's Visual

 editor highlights classes, namespaces, and other symbols with different
 colours, always provides *correct* drop-down auto-completion, and even
 underlines syntax errors on the fly.  The C++ editor can do none of
 these things, presumably because of the sheer complexity of C++.

 At any rate, ease of implementation was and is an overt goal guiding the
 design of D, and I think it has achieved that admirably.


 that's what I mean.


 Now we just need something as good as Visual Studio for it. :)


 (can I plug leds here? better not...)


I have not used it yet, I'm on windows... does it have a keyboard mapping 
which is identical to Visual Studio?
I find it really irritating to have to learn a new keyboard mapping for 
every editor I might want to use.
If leds has a Visual Studio keyboard mapping, and runs on windows, then I 
will switch to it.

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/



 Jul 03 2004



 next sibling parent reply Andrew Edwards <ridimz_at yahoo.dot.com>  writes:


Regan Heath wrote:

 On Sat, 3 Jul 2004 21:31:51 +0000 (UTC), Ant <Ant_member pathlink.com> 
 wrote:
 

 In article <cc75gv$1gn9$1 digitaldaemon.com>, Andy Friesen says...


 Mista wrote:


 Ant 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.




 No ofcourse not.
 The goal should be a good language for the user, not for other 
 programs.
 IDE's can be made to overcome problems, that's not the problem for 
 'new'
 languages to solve.



 I disagree.  If computers can easily understand the source code, then
 those computers can help us feeble humans out better.  Besides,
 simplicity usually benefits both humans and computers at the same time.
  It's not a case of having to sacrifice one for the other.

 The best example of this is in the difference between Microsoft's Visual

 editor highlights classes, namespaces, and other symbols with different
 colours, always provides *correct* drop-down auto-completion, and even
 underlines syntax errors on the fly.  The C++ editor can do none of
 these things, presumably because of the sheer complexity of C++.

 At any rate, ease of implementation was and is an overt goal guiding the
 design of D, and I think it has achieved that admirably.


 that's what I mean.


 Now we just need something as good as Visual Studio for it. :)



 (can I plug leds here? better not...)


 
 
 I have not used it yet, I'm on windows... does it have a keyboard 
 mapping which is identical to Visual Studio?
 I find it really irritating to have to learn a new keyboard mapping for 
 every editor I might want to use.
 If leds has a Visual Studio keyboard mapping, and runs on windows, then 
 I will switch to it.


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.


 Regan.
 





 Jul 03 2004



 next sibling parent  Regan Heath <regan netwin.co.nz>  writes:


On Sat, 03 Jul 2004 21:15:33 -0400, Andrew Edwards 
<ridimz_at yahoo.dot.com> wrote:

 Regan Heath wrote:

 On Sat, 3 Jul 2004 21:31:51 +0000 (UTC), Ant <Ant_member pathlink.com> 
 wrote:


 In article <cc75gv$1gn9$1 digitaldaemon.com>, Andy Friesen says...


 Mista wrote:


 Ant 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.




 No ofcourse not.
 The goal should be a good language for the user, not for other 
 programs.
 IDE's can be made to overcome problems, that's not the problem for 
 'new'
 languages to solve.



 I disagree.  If computers can easily understand the source code, then
 those computers can help us feeble humans out better.  Besides,
 simplicity usually benefits both humans and computers at the same 
 time.
  It's not a case of having to sacrifice one for the other.

 The best example of this is in the difference between Microsoft's 
 Visual

 editor highlights classes, namespaces, and other symbols with 
 different
 colours, always provides *correct* drop-down auto-completion, and even
 underlines syntax errors on the fly.  The C++ editor can do none of
 these things, presumably because of the sheer complexity of C++.

 At any rate, ease of implementation was and is an overt goal guiding 
 the
 design of D, and I think it has achieved that admirably.


 that's what I mean.


 Now we just need something as good as Visual Studio for it. :)



 (can I plug leds here? better not...)



 I have not used it yet, I'm on windows... does it have a keyboard 
 mapping which is identical to Visual Studio?
 I find it really irritating to have to learn a new keyboard mapping for 
 every editor I might want to use.
 If leds has a Visual Studio keyboard mapping, and runs on windows, then 
 I will switch to it.


 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.


If this is the case, great, but could it ship with some pre defined 
keyboard mappings, like Visual Studio's.
It would make it easier to convert users of other IDE's :)

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/



 Jul 03 2004



prev sibling  parent reply Ant <duitoolkit yahoo.ca>  writes:


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.

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



 Jul 03 2004



  parent reply Andrew Edwards <ridimz_at yahoo.dot.com>  writes:


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
 





 Jul 04 2004



  parent reply Ant <duitoolkit yahoo.ca>  writes:


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



 Jul 04 2004



  parent reply Andrew Edwards <ridimz_at yahoo.dot.com>  writes:


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
 





 Jul 04 2004



  parent  Ant <duitoolkit yahoo.ca>  writes:


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



 Jul 04 2004



prev sibling  parent  Billy Zelsnack <billy_zelsnack yahoo.com>  writes:


 I have not used it yet, I'm on windows... does it have a keyboard 
 mapping which is identical to Visual Studio?
 I find it really irritating to have to learn a new keyboard mapping for 
 every editor I might want to use.
 If leds has a Visual Studio keyboard mapping, and runs on windows, then 
 I will switch to it.


The ide deal breaker for me is the lack of workspace whiz 
(wwhiz.com) file globber equivalent. omg. Any editor without 
it feels like my hands are wrapped in duct tape.



 Jul 03 2004



prev sibling  parent  "Bent Rasmussen" <exo bent-rasmussen.info>  writes:


 At any rate, ease of implementation was and is an overt goal guiding the
 design of D, and I think it has achieved that admirably.

 Now we just need something as good as Visual Studio for it. :)


You hear that Ant -- we're counting on you! :-)


   -- andy





 Jul 03 2004



prev sibling  parent  Benji Smith <dlanguage xxagg.com>  writes:


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.


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

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.



 Jul 05 2004