Re: Turbo questions

Jolyon Smith wrote:

In article <44ed35d6$1@xxxxxxxxxxxxxxxxxxxxxx>, Allen Bauer says...

It's in the language... so it's a feature. Pretty simple. They
don't somwhow exist outside the language :-).

But they do - those things are just ways of laying out memory.

Those "things" aren't language features - the way that working with
those things is made easier is the feature.

Isn't that all part of the feature package? I think we're not sharing
the same dictionary here. I view the whole "interfaces" thing
including the memory layout, the behind-the-scenes compiler magic, and
any RTL helper functions as all being part and parcel to the "feature"
as a whole. Using your dictionary, it is easy for me to agree. Here...
use mine... I think this is called being in violent agreement ;-).


Ok.. I thought that was what we were talking about. The fact that MS
controls the platform and is free to introduce technologies. Just
as we are free to wrap those technologies... or ignore them.

Yes, but the types of language features I have in mind aren't
"wrappers" around technologies. I am thinking more of things that
don't - or shouldn't - have any dependency on OS services or
technologies.

e.g. function overloading, generics, inlining, etc etc

I think the fog is beginning to lift... You're wanting language
features to be done because they are useful independently of the
underlying platform or its general direction, right? I think we've
been doing that. Function inlining was added to Delphi/.NET and
Delphi/Win32 in which there is no analog on the platforms. Ultimately,
it will always boil down to return on investment. If there is a choice
between feature A and feature B, where feature A will benefit 60% of
the customers and feature B will only benefit 20% of them... which one
takes precedence?

Notice that in the function overloading case the need was essentially
an internal one - Borland had two languages and had to make a change
to one to improve compatability with the other (I never suggested
that such changes were purely academic in nature - of course there is
always a need).

This is something I want to get better at. I agree. We need to be
more and more proactive rather than reactive. Some things you have to
react to, while there are plenty of areas where we can be proactive.

But they didn't have to wait for Win32 to support function
overloading in order to do it.

'zactly. It was still borne out of a need. In fact, it is very
refreshing to be able to exert that level of control over the
Delphi/Object Pascal language. I think it is safe to say that without
that level of control, Delphi would be a very different animal today.
I'm sure MS holds the same view for VB and C#...

--
Allen Bauer
Developer Tools Group
Chief Scientist
Borland
http://blogs.borland.com/abauer
.

Relevant Pages

  • Re: Is it possible to use the value of the PROGRAM ID within the source code?
    ... > Now you claim the language's 'hiding' features make the stack invisible to ... EXIT, RETN, and the setting of the RCW on ENTR are independent of language. ... Moreover, precisely because memory *is* dynamically allocated, there is no ... any Unisys MCP customer is welcome to file a New Feature Suggestion ...
    (comp.lang.cobol)
  • Re: operation on module arguments
    ... But the logic to have this feature in the ... language is pretty reasonable, so I was not too greedy, was I? ... memory for storing a real variable, and let the variable name 'A' refer to that bit of memory." ... It means, for example, that the compiler can't pass A around like a real variable, because when the compiler passes it to a subroutine that might modify it, the compiler also has to pass along the instructions that go with it. ...
    (comp.lang.fortran)
  • Re: Relative merits of Lisp-1 vs. Lisp-2?
    ... If reading data that might be ill-formed, defining your language to ... to dismiss my concern about this issue as irrelevant and unimportant, ... This argument would apply to *any* proposed new feature, ... incompatibilities were simply the result of someone doing something ...
    (comp.lang.lisp)
  • Re: Graphic GUI C
    ... features in C99) is also a feature of C++. ... expect the C language and the C standard library to do everything; ... nothing is more commonplace than the need for one or more libraries in ... The same is true inside of WSH where all of the functionality ...
    (comp.lang.c)
  • Re: Whats the deal with C99?
    ... be in the language. ... languages by itself speaks volumes about what programmers want. ... There's no feature added to C99 that addresses even one thing that has ... There's no controversy about memory management? ...
    (comp.lang.c)