Re: [LONG] Re: Why code completion and early error checking are needed

From: Steven T. Hatton (susudata_at_setidava.kushan.aa)
Date: 06/06/04 

Date: Sun, 06 Jun 2004 14:53:35 -0400

Mark A. Gibbs wrote:

>
>
> Steven T. Hatton wrote:
>
>> Mark A. Gibbs wrote:
>>
>>>its own merits. am i correct in assuming that your thesis is that one of
>>>the guiding principles in the evolution of the c++ language should be
>>>the ease with which machines can deduce code given partial samples?
>>
>>
>> No. You are incorrect.
>
> see, right about there would have been an intelligent time to tell me
> what was incorrect and what would have been correct.

I didn't care to elabourate my guiding principals. From the subject of this
thread, it should be clear where my objectives lie.

I grow weary of being told how I should behave myself.

>> Google only takes a few seconds to search the entire internet. It
>> shouldn't
>> be that hard to build useful indexes of the available resources.
>> Currently it is not possible to rely on the implementation providing
>> interface declarations for the Standard Libraries.
>
> that would be an ide issue, not a language issue.

No. That is a language specefication issue. The C++ Standard does not
require the Standard Library provide any kind of retrievable representation
of its interface. I believe this to be an ommision due to error.
 
>> If you type std::vector that means the one from the Standard. If you
>> have a using declaration in your code for indi::math::vector and nothing
>> else to
>> inject the name vector, then it means your vector. If there is
>> ambiguity, then you need to resolve it manually.
>
> so you have to type the entire fully qualified name?

If you want the the unique representation of the name in a scope where it is
otherwise ambiguous, yes. That's how the language works.

 
>> And that demonstrates what is wrong with C++'s fragmented naming system.
>
> opinion != fact. why you would consider c++'s "naming system"
> "fragmented" is beyond me. do you believe that c++ source and header
> files should be forced to contain one and only one class
> definition/declaration, and should be named after that class? and that
> the files should be in folder hierarchy based on namespace membership?

No. Why would you think that? If you are basing that on the Java model,
then you do not correctly understand Java. But as far as header files and
implementation files go. I do not believe the C++ Standard specifies
anything called a header file. Perhaps I should say conventional usage
employs a fragmented naming system, and the Standard implicitly presupposes
its use.

> that's a very clever solution in a way that somehow manages to be
> completely not clever at all.
>
> first, c++ allows the creation of lightweight worker classes - in my
> experience, those are very common when using riaa or the adaptor
> pattern. you want a file for every tiny little worker class? what about
> meta-classes that are never intended to be directly used except via
> macros? what about free functions?

For any of that to be relevant, your assumption would need to be correct. It
isn't.

> second, you would be assuming certain capabilities on the file system
> being used for c++ development.

No. I would be placing requierments on the naming system used to identify
resources used by the C++ implementation.

> third, why in gods name would you want to force a programmer into
> putting huge amounts of code into single files just because they share
> the name of the class?
>
> shall i go on?

To what end?
 
> since it seems that i am lousy at assuming your point, perhaps you could
> explicitly tell me exactly what about the "naming system" is
> "fragmented", hm?

I don't really care to share more of my design ideas on this matter, at this
point.
 
>>>but in c++ the header to import is not well-known, not only because no
>>>part of it can be deduced from the type name, but because the possiblity
>>>of nesting includes within other includes. for example, consider
>>>std::string. obviously the correct include in this case is <string>, but
>>>indulge me momentarily. imagine you have thousands of headers for
>>>classes that use strings internally. how is the compiler to know that
>>>you specifically want <string> and do not wish to come by string by some
>>>other means?
>>
>>
>> #include <string>
>
> ? do you even read what i write?

To the extent that what you wrote made senes, I gave the best answer
possible.

>>>it cannot be argued that programmers will only want to include the
>>>actual base declaration header for a type. it may be by design that
>>><string> is not included directly, for several reasons, including
>>>precompiled headers and the potential to transparently replace usage of
>>>std::string in the library with something_else::string at some future
>>>date.
>>
>>
>> I don't see how this has any bearing on the subject. Are you suggesting
>> names should be introduced into your program through indirect inclusion?
>
> should? no. could? yes, i am indeed.
>
> //file win_something.hpp
> typedef HANDLE something_handle;
>
> //file linux_something.hpp
> typedef void* something_handle;
>
> //file something_something.hpp
> typedef some_struct something_handle;
>
> //file something.hpp
> #if defined WINDOWS
> #include "win_something.hpp"
> #elif defined LINUX
> #include "linux_something.hpp"
> #elif defined SOMETHING_ELSE
> #include "something_something.hpp"
> #endif
>
> flexibility is nice.

Some people believe the use of goto is a good solution to branching
situations for the same reason.

>> I believe you are demonstrating what is wrong with the current C++
>> standard. There is nothing valuable gained by this incoherence, and much
>> lost.
>
> i am? please don't tell me you would use code completion facilities - in
> *any* language - without reading the documentation. once again, do you
> even read what i write?

If I have a hundred or so header files for a toolkit, and they have a
coherent, rational naming scheme that corresponds to what they hold, once I
understand how the naming scheme works, and how the names of classes
correspond to functionality, there is often no need to consult the
documentation for every individual component of the toolkit. Furthermore,
it is often the case that names can be a bit hard to remember exactly. Was
that XHBoxSlider or XHSliderBox? Was that contained in <xhbox.h> or
<xbox.h>?
 
> maybe, but that would depend on what those "standard means" are, would
> it not? i cannot see any way to do it, and you have not proposed any.

Why should I? Actually, I learned something last night about a likely
future direction of C++ which is forcing me to rethink a lot of this. It's
potentially a very positive direction as long as Stroustrup can keep the
dogs at bay.
 
> saying something "should" be done because it is "good" is rather
> disingenious. i mean, no ***, sherlock. if it were possible to have
> every good feature of every language and still maintain c++'s power,
> flexibility and portability, and be backwards compatible, what even
> partly intelligent person would say no? and yes, some sacrifices can and
> have been made for progress.

I really don't know what you mean by "power". The fact that C++ presents so
many obstacles to ease of use is a weakness. Java seems, from the evidence
I've seen, to be as portable, or more portable than C++.

>> If anything, I believe the exercise of specifying how this interface
>> mechanism can be provided will reveal many things that should and can be
>> changed for the better without negatively impacting the language.
>
> that's good. and quite welcome. specify away.

That is more easily said than done. The C++ community has a tendency to
reject ideas out of hand without considering their merit.
 
> "willing to drop some legacy code"? perhaps. what code, specifically?
> show your work.

Why should I? What have you done to earn it?
 
> i disagree on the first point. code generation, and smart ides are nifty
> tools, yes. but if flexibility and expressive power must be sacrificed
> for their sake, i side with the nays.

I'm actually more optimistic now that ever.
 
> my point was that the complexity involved in implementing this would be
> immense. any standard specification for how this should be done would be
> similarly immense.

There is a significant difference between specifying how to fully implement
IDE support for C++ and specifying the language in such a way as to remove
unnecessary obstacles to implementing such support.
 
>> The question was about an IDE. I was trying to determine if any IDEs
>> currently provide the kind of functionality I'm interested in. If they
>> do, then at least I know it's possible.
>
> was that the question? the question i read was: "Can anybody provide
> a reasoned, objective rationale for why the proposed support would
> significantly and negatively impact C++?"

Please consult this relevant reference and see if you can figure it out for
yourself:
http://www.bartleby.com/64/1.html
 
>> I don't believe you are getting my point. It should provide a standard
>> means of structure libraries of any size. I don't believe this is all
>> the compicated.
>
> and my point - including all the evidence i provided - was that i do.
> you're welcome to explain how it could be acclomplished.

I don't care to share my thoughts on this matter.

> perhaps. we do have a committee to make these decisions you know. all
> you need to do is say what changes for what benefits.

I've made some suggestions. I may make more. But why should I?

>> The FAQ specifically states that the newsgroup is open to discussion of
>> "future directions" for C++.
>
> it does? "Only post to comp.lang.c++ if your question is about the C++
> language itself. For example, C++ code design, syntax, style, rules,
> bugs, etc. Ultimately this means your question must be answerable by
> looking into the C++ language definition as determined by the ISO/ANSI
> C++ Standard document, and by planned extensions and adjustments." [5.9]
>
> on the other hand:
>
> " # comp.std.c++
>
> * Discussion directly related to the evolving ANSI/ISO C++ standard
> * The evolving ANSI/ISO C++ standard is discussed below"
>
> mark

Read the whole FAQ. People tend to view that particular item in isolation
and therefore draw incorrect conclusion. 

-- 
STH 
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org  SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org
Loading