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

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.

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

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

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

"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
>
>

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

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

> 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

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