Board index » delphi » Re: Why no language improvements?

Re: Why no language improvements?


2005-03-10 02:29:29 AM
delphi121
Quote
It's optional insofar as foreach / for...in is concerned. But insofar
as implementing IEnumerable is concerned, it isn't optional.
Yes, I know, that is what I have been trying to say :-) It seems dumb to me
that everywhere else, you have to implement an interface. But in this
one solitary case, that isn't required. IMO it would be sensible to have
only the one option : implement IEnumerable.
Cheers,
Jim Cooper
__________________________________________
Jim Cooper XXXX@XXXXX.COM
Tabdee Ltd www.tabdee.ltd.uk
TurboSync - Connecting Delphi to your Palm
__________________________________________
 
 

Re: Why no language improvements?

Quote
Colin Wilson in <XXXX@XXXXX.COM>writes:
BTW, XanaNews uses the following algorithm when deciding which
character set to use to post.

1. If it is a new thread, XanaNews uses what ever character set you've
specified in 'Posting Settings'

2. If it is a reply and the message you're replying to is in US-ASCII,
XanaNews uses what ever character set you've specified in 'Posting
Settings'.

3. If it is a reply and the message you're replying to is *not* in
US-ASCII, XanaNews uses this character set too. That way, quoted text
will work - even if it is in Japanese.

Judging by Mikes posts, Thunderbird does much the same sort of thing.

Colin is there some equivalent for the Utf8ToAnsi function for UTF7?
 

Re: Why no language improvements?

"Wayne Niddery [TeamB]" <XXXX@XXXXX.COM>writes:
Quote
The question that continues to come up for me is, if it is benefits
outweight potential problems, why have both Java and C#, relatively
new languages, chosen to only support single inheritance? Surely the
people at that level - language design - have a better handle on the
pros and cons beyond the hype and thus have some legitimate reasons
for their choice.
Without trying to stoke flames, I think that Java and C# were designed
to be easier to use at the expense of not being as powerful as C++.
It's no admission that MI is useless, but that those languages are not
designed to solve the problems that you solve using MI.
They filled that gap with interfaces. In both Java and C#, I think,
allow multiple implementation of interfaces. that is a subset of MI,
and confirms my belief that MI is not useless. It just is more
powerful in C++ than the common use requires, for when you get into a
special situation. In languages without MI, when you need that extra
capability that isn't there, you must create an inferior design to
work around the langauge limitations.
--
Chris (TeamB);
 

Re: Why no language improvements?

"Craig Stuntz [TeamB]" <XXXX@XXXXX.COM [a.k.a. acm.org]>writes:
Quote
Chris Uzdavinis (TeamB) writes:

>I could not think of any other straight-forward way to accomplish this
>behavior with anything other than MI.

You could do this in Delphi with an interface (IOW: multiple interface
inheritance, but not multiple implementation inheritance). I won't try
to suggest a "better" way for C++. :)
Just to clairify, in C++, multiple inheritance is how you implement
multiple interfaces. There simply is no language distinction between
a normal base class and an "interface."
--
Chris (TeamB);
 

Re: Why no language improvements?

Jim Cooper writes:
Quote
Once you have proper reflection, you can do stuff like go and look
for a method of a particular name and signature and invoke it. I
assumed that was what was happening here but it is an assumption only.
This is kinda pedantic, but the method isn't invoked via reflection.
It's called directly, as the compiler generates the call at compile
time.
--
Craig Stuntz [TeamB] ?Vertex Systems Corp. ?Columbus, OH
Delphi/InterBase Weblog : blogs.teamb.com/craigstuntz
 

Re: Why no language improvements?

Quote
I wouldn't necessarily have a problem with that, but it would be a
kinda interesting situation where the compiler *required* the interface
but didn't *use* it. :)
Yes :-)
Cheers,
Jim Cooper
__________________________________________
Jim Cooper XXXX@XXXXX.COM
Tabdee Ltd www.tabdee.ltd.uk
TurboSync - Connecting Delphi to your Palm
__________________________________________
 

Re: Why no language improvements?

Quote
This is kinda pedantic
No, it is cool. it is something I didn't know :-)
Cheers,
Jim Cooper
__________________________________________
Jim Cooper XXXX@XXXXX.COM
Tabdee Ltd www.tabdee.ltd.uk
TurboSync - Connecting Delphi to your Palm
__________________________________________
 

Re: Why no language improvements?

Chris Uzdavinis (TeamB) writes:
Quote
Just to clairify, in C++, multiple inheritance is how you implement
multiple interfaces. There simply is no language distinction between
a normal base class and an "interface."
Right. So it is a good example of how to use the feature in C++, but
not a good argument for adding it to Delphi*, as what you are doing is
already supported in Delphi via interfaces.
-Craig
* And I don't think Chris intended it that way, either.
--
Craig Stuntz [TeamB] . Vertex Systems Corp. . Columbus, OH
Delphi/InterBase Weblog : blogs.teamb.com/craigstuntz
Everything You Need to Know About InterBase Character Sets:
blogs.teamb.com/craigstuntz/articles/403.aspx
 

Re: Why no language improvements?

Chris Uzdavinis (TeamB) writes:
Quote


In both Java and C#, I think,
allow multiple implementation of interfaces. that is a subset of MI,
and confirms my belief that MI is not useless. It just is more
powerful in C++ than the common use requires, for when you get into a
special situation. In languages without MI, when you need that extra
capability that isn't there, you must create an inferior design to
work around the langauge limitations.
We could probably argue on various aspects of MI / interfaces all day, but
I'm curious on one aspect...
In Delphi I can have a class implementing multiple interfaces, e.g.
TClassAB = class(TObject, InterfaceA, InterfaceB)
...
I can have methods that accept one or the other of those interfaces:
procedure TSomeClass.MethodA(A: InterfaceA);
...
procedure TSomeClass.MethodB(B: InterfaceB);
...
I can pass an instance of TClassAB to either of these methods and the
methods will see only what is part of that interface. It also does not
matter what class TClassAB descends from, it could be TObject, TEdit,
TStringList, or anything else - the methods are not tied to any *class*, the
class just has to implement that interface to be compatible.
How is that done in C++? With TClassAB descending from both TClassA and
TClassB, and the equivalent methods above accepting instances of TClassA and
TClassB respectively, I assume you can pass an instance of TClassAB to them
since TClassAB is a legitimate descendant of both classes? However, inside
those methods, what can be seen in the passed instance? Does it "see" only
a TClassA or a TClassB or does it see a TClassAB (i.e. can it see members
from both ancestor classes and/or descendant-based members)?
The one thing I know is that, unless an object is, or decends from, TClassA,
it cannot be passed to MethodA. To me that gives interfaces an *advantage* -
it is *more* powerful in this respect.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: www.logicfundamentals.com/RADBooks.html
Bandwagons are like streetcars, there'll be another along in a few
minutes.
 

Re: Why no language improvements?

Jim Cooper writes:
Quote
There's the IEnumerable thing too. Either implement IEnumerable, or
just put in a function with the right name and signature (like
implementing an interface without having an interface <g>)
Heh! Encountered something similar today when using C# to target the
Compact Framework
using (Pen myPen = new Pen(myColor)) .. nice
using (SolidBrush myBrush = new SolidBrush(myColor)) .. not so nice
The latter complains that SolidBrush can't be implicitly converted to
System.IDisposable. WTF! It has a Dispose method doesn't it? Why on
earth would this *not* be an implementation of the IDisposable
interface? After all, that this is indeed how the full .NET Framework
implements the Brush class.
--
Cheers,
David Clegg
XXXX@XXXXX.COM
Vote 1 cc.borland.com/codecentral/ccweb.exe/listing :-)
Now supports Google Groups searching with Dyna-extend(tm) technology!
QualityCentral. The best way to bug Borland about bugs.
qc.borland.com
"No, no, no, Lisa. If {*word*62}s don't like their jobs, they don't go on
strike. They just go in every day and do it really half-assed. That's
the American Way." - Homer Simpson
 

Re: Why no language improvements?

There's another one with data binding. If you bind an object's property
to a control like this
MyControl.DataBindings.Add("Text",MyObject,"MyProperty");
then if in the MyObject class you have a MyPropertyChanged event
handler, it'll get added to, so you can call the event handler and
update MyControl automatically. There is code that looks for the event
handler by name (it also looks for a property called MyPropertyIsNull
and another event handler called Validating, but I can not get them to do
anything)
Cheers,
Jim Cooper
__________________________________________
Jim Cooper XXXX@XXXXX.COM
Tabdee Ltd www.tabdee.ltd.uk
TurboSync - Connecting Delphi to your Palm
__________________________________________
 

Re: Why no language improvements?

On Wed, 9 Mar 2005 08:31:59 -0600, "Captain Jake"
<jake[nospam]@jsnewsreader.com>writes:
Quote
XXXX@XXXXX.COM writes
<XXXX@XXXXX.COM>
>Totally incorrect. The semantics are different (try sizeof('A') for
>a an example of an seemingly innocuous difference that can break
>things). One cannot dispute the a valid C program using identifiers
>such as "new" and "class", for example, will fail to compile under
>a C++ compiler. That neatly disproves your statement of one being
>a subset of the other. C++ certainly has some heritage from C, as
>you point out, but that is it.

Your spinning off into the void. Using the term C/C++ is something that has
been done for ages. I have got several books on my bookshelves that have C/C++
in the title. Getting all overe{*word*277}d because someone used the term "C/C++"
is just totally ridiculous.

If you had said I was spinning off into the void * it would have at
least been a good pun. Interesting dodge/lack of acknowledgement of
your inaccurate statement about on being a subset of the either...
par for the course.
The titles of books on your shelves proves exactly ziltch about
the correctness of the term. Show me an ISO "C/C++" standard
and then you would have a point. The term is merely a sloppy term
for (probably) a family of languages that have some intersection
of constructs. Doesn't make it correct though.
For the record, I am not e{*word*277}d or even breathing hard.
Please don't project.
Oz
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
 

Re: Why no language improvements?

On 9 Mar 2005 05:36:13 -0800, "Craig Stuntz [TeamB]"
<XXXX@XXXXX.COM [a.k.a. acm.org]>writes:
Quote
Will DeWitt Jr. writes:

>After Craig's post I think I am fairly certain that generics
>(parameterized types) will be enough for me.

Ya know, I suggested parameterized types as a more precise term, since
people misuse the term "generics," but I think I got it backwards. C++
templates are arguably parameterized types, at least moreso than they
are generic.

So maybe we're stuck with "generics -- no, really, I mean generics,
not templates" or something.
This thread has at least been illimunating on the distinction(s)
between templates and generics. It would be handy for a boiled
down version for inclusion into a Delphi FAQ.
Oz
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
 

Re: Why no language improvements?

Billb writes:
Quote
Colin is there some equivalent for the Utf8ToAnsi function for UTF7?
You can use MultiByteToWideChar with CP_UTF7 to do the conversion.
But in general when dealing with iso codepages etc. I use the
IMultiLanguage/IMultiLanguage2/etc interfaces. You can download a
Delphi version of these interfaces from my website. Go for the 'Low
Level Utilities' package there. The package also contains my
'unitCharsetMap' unit which contains a bunch of handy routines for this
sort of thing.
* XanaNews stores all messages as they are received from the Internet.
* When it displays them it converts them to Unicode. The microsoft
rich edit control and Mike Lischke's virtual tree view both handle
Unicode natively.
* If it needs to display something on a non-unicode control (eg. the
header panel) - it sets the panels font charset to a charset that
supports the codepage, and sets it is 'Text' property to the multi-byte
characters.
--
Colin - Author of XanaNews
 

Re: Why no language improvements?

"ozbear" <XXXX@XXXXX.COM>writes
Quote
If you had said I was spinning off into the void * it would have at
least been a good pun. Interesting dodge/lack of acknowledgement of
your inaccurate statement about on being a subset of the either...
par for the course.
No need to dodge anything. it is simply a fact that C++ is an improvement on
C, rather than the two languages being "wildly different" as you put it. But
you don't need to take my word for it. You can go right to the inventor of
the language:
www.research.att.com/~bs/C++.html
"C++ is a general purpose programming language with a bias towards systems
programming that
a.. is a better C
b.. supports data abstraction
c.. supports object-oriented programming
d.. supports generic programming. "
Also, note this site where Bjarne addresses the very questiono we are now
discussing: www.research.att.com/~bs/bs_faq.html#C-is-subset
"C++ is a direct descendant of C that retains almost all of C as a
subset."
Quote
For the record, I am not e{*word*277}d or even breathing hard.
Indeed, we are not exactly pursuing the most interesting topic here, and it
is one you in which obviously were not even interested enough to get your
facts straight. Your statement that C and C++ are two entirely different
unrelated languages was pure hooey, as I illustrated above with direct
quotes from the inventor of C++.