www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - OOP

reply imr1984 <imr1984_member pathlink.com> writes:
is anyone else here using D in a C stlye way, ie billions of globals, almost no
classes etc?

D just appeals to me because of its much cleaner syntax and no header files, not
because of its great OOP capabilities. I especially dont like member protection
because im a bedroom coder so i work on my own, so protecting member variables
doesnt really appeal to me.
May 17 2004
next sibling parent reply Charlie <Charlie_member pathlink.com> writes:
In article <c8ac4b$2kt4$1 digitaldaemon.com>, imr1984 says...

is anyone else here using D in a C stlye way, ie billions of globals, almost no
classes etc?

D just appeals to me because of its much cleaner syntax and no header files, not
because of its great OOP capabilities. I especially dont like member protection
because im a bedroom coder so i work on my own, so protecting member variables
doesnt really appeal to me.



is anyone else here using D in a C stlye way, ie billions of globals, almost no
classes etc?


Probably, Ive seen functional style D , and while I like OO, sometimes it fits
better to have free functions .  In fact Id much prefer if the Phobos was all a
set of free functions , with an optional OO wrappers to all of it.  Right now
its all mixed in all flibbily bibbily stlye , no consistency to speak of.


I especially dont like member protection
because im a bedroom coder so i work on my own, so protecting member variables
doesnt really appeal to me.


I never liked this either, if the getters and setters do nothing more then just
that ( i.e. they might check a value for a condition etc ) , then why not just
make the data public ?  Even this month I read an article in favor of getters
and setters in CUJ, I like python style much better.

Charlie
May 17 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Charlie" <Charlie_member pathlink.com> wrote in message
news:c8aq9o$94k$1 digitaldaemon.com...

 I never liked this either, if the getters and setters do nothing more then


just

 that ( i.e. they might check a value for a condition etc ) , then why not


just

 make the data public ?


I agree. The common get/set for a simple member variable just looks like
clutter to me.
May 17 2004
parent reply Derek <ddparnell bigpond.com> writes:
On Mon, 17 May 2004 15:01:18 -0700, Walter wrote:


 "Charlie" <Charlie_member pathlink.com> wrote in message
 news:c8aq9o$94k$1 digitaldaemon.com...

 I never liked this either, if the getters and setters do nothing more then


 just

 that ( i.e. they might check a value for a condition etc ) , then why not


 just

 make the data public ?


 
 I agree. The common get/set for a simple member variable just looks like
 clutter to me.


Having public data elements tightly binds modules together. That is to say,
if a class's data elements are public it allows code using that class to be
dependant on it, thus making it hard to modify the class without breaking
already written code. 

J. Anderson has mentioned that fortunately, D can help resolve this by
using its property technique. Basically, if a public data element needs to
be changed in some way by the class author, they can rename the public data
element and make it private and create a property with the old name and
datatype argument. Then the class author can handle the case where existing
code is using the old data form.

Example:

 from...
class Foo
{
   public float XX;
   . . .
}

 to ...

class Foo
{
   private int _XX;

   public XX(float x)
   {
     if (x >= 0)
      _XX = cast(int)x;
     else
      _XX = 0;

   }
   public float XX(){ return cast(float)_XX;}
   . . .
}


-- 
Derek
Melbourne, Australia
May 17 2004
parent reply Sean Kelly <sean ffwd.cx> writes:
Derek wrote:

 
 J. Anderson has mentioned that fortunately, D can help resolve this by
 using its property technique.


Not to quibble, but I said this :)

Sean
May 17 2004
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 17 May 2004 16:16:48 -0700, Sean Kelly wrote:


 Derek wrote:

 
 J. Anderson has mentioned that fortunately, D can help resolve this by
 using its property technique.


 
 Not to quibble, but I said this :)
 
 Sean


Sorry, Sean. I was referring to something that J. Anderson wrote in message
id <c7pb5h$1lei$1 digitaldaemon.com> on the 11/May. And I quote ...

"
I used to program that way.

With D because of property methods I've found many cases where exposing 
properties as public is a good thing.  I mean with C++, the convention 
was to have get/set everywhere.  With D you can convert a property into 
a method without affecting the outside user (users being the people 
extending the class or using an instance).

I look at each properties on its own merit and try to decide if an 
external user would have any good use for it.  Of  course there are 
properties that are unsafe, have some quirky rule or ify (undecided) 
which I make private or protected.  They can always be made public 
later. I don't make everything public but I look on things from the 
other prospective.
"

I was replying to a message from Walter (08:01am in Melbourne, Aus) and it
looks as though while I was typing my response, your message came in
(8:33am) and I didn't get to read it before sending mine off.

So it seems that there are at least two great D minds. ;-)

-- 
Derek
18/May/04 9:51:18 AM
May 17 2004
parent Ilya Minkov <minkov cs.tum.edu> writes:
Just to give a little bit more due credit, Matthew Wilson said nearly 
that already long, long ago - long before properties were actually 
implemented. With some (beware a shameless plug) very little assistance 
from myself, steering some deciding arguments in. :) That's what Delphi 
programmers have been doing already ages ago. Now, if D would also try 
to bolt-on some meaning for the compound assignment operators... I admit 
this is questionable.

-eye

Derek Parnell schrieb:

 On Mon, 17 May 2004 16:16:48 -0700, Sean Kelly wrote:
 
 

Derek wrote:


J. Anderson has mentioned that fortunately, D can help resolve this by
using its property technique.


Not to quibble, but I said this :)

Sean


 
 
 Sorry, Sean. I was referring to something that J. Anderson wrote in message
 id <c7pb5h$1lei$1 digitaldaemon.com> on the 11/May. And I quote ...
 
 "
 I used to program that way.
 
 With D because of property methods I've found many cases where exposing 
 properties as public is a good thing.  I mean with C++, the convention 
 was to have get/set everywhere.  With D you can convert a property into 
 a method without affecting the outside user (users being the people 
 extending the class or using an instance).
 
 I look at each properties on its own merit and try to decide if an 
 external user would have any good use for it.  Of  course there are 
 properties that are unsafe, have some quirky rule or ify (undecided) 
 which I make private or protected.  They can always be made public 
 later. I don't make everything public but I look on things from the 
 other prospective.
 "
 
 I was replying to a message from Walter (08:01am in Melbourne, Aus) and it
 looks as though while I was typing my response, your message came in
 (8:33am) and I didn't get to read it before sending mine off.
 
 So it seems that there are at least two great D minds. ;-)
May 27 2004
prev sibling next sibling parent reply Sean Kelly <sean ffwd.cx> writes:
Charlie wrote:

 In article <c8ac4b$2kt4$1 digitaldaemon.com>, imr1984 says...


I especially dont like member protection
because im a bedroom coder so i work on my own, so protecting member variables
doesnt really appeal to me.


 
 I never liked this either, if the getters and setters do nothing more then just
 that ( i.e. they might check a value for a condition etc ) , then why not just
 make the data public ?  Even this month I read an article in favor of getters
 and setters in CUJ, I like python style much better.


While I personally dislike get/set methods I do understand the reasoning 
behind them.  They are a pre-emptive tactic to enable back-end changes 
without requiring user-side code changes.  However, properties in D 
pretty much eliminate the need for this tactic, as there is no semantic 
difference between public variables and property methods.  It's worth 
noting that properties have been proposed as an addition to the next 
version of C++ 
(http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf), 
probably for this exact reason.

Sean
May 17 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Sean Kelly" <sean ffwd.cx> wrote in message
news:c8bej6$181f$1 digitaldaemon.com...

 While I personally dislike get/set methods I do understand the reasoning
 behind them.  They are a pre-emptive tactic to enable back-end changes
 without requiring user-side code changes.  However, properties in D
 pretty much eliminate the need for this tactic, as there is no semantic
 difference between public variables and property methods.  It's worth
 noting that properties have been proposed as an addition to the next
 version of C++
 (http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf),
 probably for this exact reason.


Someday, C++ may catch up with D <g>.
May 17 2004
parent reply "Achilleas Margaritis" <axilmar b-online.gr> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:c8bjdv$1eun$1 digitaldaemon.com...

 "Sean Kelly" <sean ffwd.cx> wrote in message
 news:c8bej6$181f$1 digitaldaemon.com...

 While I personally dislike get/set methods I do understand the reasoning
 behind them.  They are a pre-emptive tactic to enable back-end changes
 without requiring user-side code changes.  However, properties in D
 pretty much eliminate the need for this tactic, as there is no semantic
 difference between public variables and property methods.  It's worth
 noting that properties have been proposed as an addition to the next
 version of C++
 (http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf),
 probably for this exact reason.


 Someday, C++ may catch up with D <g>.


I send an e-mail to Bjarne Stroustrup regarding the future of C++ now that D
is around the corner. He told me to leave him alone and go use D, and that
C++ is not gonna change anytime soon (although he said it very politely).

I guess some people never realize when their time is over.
May 18 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Achilleas Margaritis" <axilmar b-online.gr> wrote in message
news:c8dojk$2048$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message
 news:c8bjdv$1eun$1 digitaldaemon.com...

 Someday, C++ may catch up with D <g>.


 I send an e-mail to Bjarne Stroustrup regarding the future of C++ now that


D

 is around the corner. He told me to leave him alone and go use D, and that
 C++ is not gonna change anytime soon (although he said it very politely).

 I guess some people never realize when their time is over.


D stands on the shoulders of giants, and one of those giants is Bjarne
Stroustrup. Bjarne has made huge contributions to the programming community.
C++ was a great leap forward, and it practically invented generic
metaprogramming.

C++ isn't going away in the forseeable future. I fully expect that future
C++ standards will incorporate some of D's innovations, in an analogous way
that C has adopted some C++ innovations. Bjarne is right, though, in
suggesting that this will not happen anytime soon. The C++ standardization
process is agonizingly slow (and should be, for a mature language).

And, in due course, D will eventually be run over by a new upstart, D++ <g>.
May 18 2004
next sibling parent reply Sean Kelly <sean ffwd.cx> writes:
Walter wrote:

 
 D stands on the shoulders of giants, and one of those giants is Bjarne
 Stroustrup. Bjarne has made huge contributions to the programming community.
 C++ was a great leap forward, and it practically invented generic
 metaprogramming.


And don't forget Alexander Stepanov.  C++ may not have existed without 
Bjarne, but generics may not have existed without Alexander.  For the 
uninitiated, there's a good interview here:

http://www.stlport.org/resources/StepanovUSA.html


 C++ isn't going away in the forseeable future. I fully expect that future
 C++ standards will incorporate some of D's innovations, in an analogous way
 that C has adopted some C++ innovations. Bjarne is right, though, in
 suggesting that this will not happen anytime soon. The C++ standardization
 process is agonizingly slow (and should be, for a mature language).


Of course.  The C++ community would go nuts if the language changed too 
quickly.  But the language's stability is one of the reasons I favor it 
over the latest greatest whatever.  That's both the blessing and the 
curse of backwards compatibility.


 And, in due course, D will eventually be run over by a new upstart, D++ <g>.


Certainly.  But before then I hope that D will have contributed some new 
ideas and techniques to the programming world.  Otherwise, why are we 
here? :)


Sean
May 20 2004
parent "Walter" <newshound digitalmars.com> writes:
"Sean Kelly" <sean ffwd.cx> wrote in message
news:c8iq5m$1au5$1 digitaldaemon.com...

 Walter wrote:

 D stands on the shoulders of giants, and one of those giants is Bjarne
 Stroustrup. Bjarne has made huge contributions to the programming




community.

 C++ was a great leap forward, and it practically invented generic
 metaprogramming.


 And don't forget Alexander Stepanov.  C++ may not have existed without
 Bjarne, but generics may not have existed without Alexander.  For the
 uninitiated, there's a good interview here:

 http://www.stlport.org/resources/StepanovUSA.html


Yes, you're right. And Bjarne deserves the credit for understanding
Stepanov's work and endorsing/incorporating it, when it would have been easy
to ignore it.



 C++ isn't going away in the forseeable future. I fully expect that




future

 C++ standards will incorporate some of D's innovations, in an analogous




way

 that C has adopted some C++ innovations. Bjarne is right, though, in
 suggesting that this will not happen anytime soon. The C++




standardization

 process is agonizingly slow (and should be, for a mature language).


 Of course.  The C++ community would go nuts if the language changed too
 quickly.  But the language's stability is one of the reasons I favor it
 over the latest greatest whatever.  That's both the blessing and the
 curse of backwards compatibility.


 And, in due course, D will eventually be run over by a new upstart, D++




<g>.

 Certainly.  But before then I hope that D will have contributed some new
 ideas and techniques to the programming world.  Otherwise, why are we
 here? :)


Yes, indeed.
May 21 2004
prev sibling parent reply "Achilleas Margaritis" <axilmar b-online.gr> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:c8e2mb$2h8v$1 digitaldaemon.com...

 "Achilleas Margaritis" <axilmar b-online.gr> wrote in message
 news:c8dojk$2048$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message
 news:c8bjdv$1eun$1 digitaldaemon.com...

 Someday, C++ may catch up with D <g>.


 I send an e-mail to Bjarne Stroustrup regarding the future of C++ now




that

 D

 is around the corner. He told me to leave him alone and go use D, and




that

 C++ is not gonna change anytime soon (although he said it very




politely).

 I guess some people never realize when their time is over.


 D stands on the shoulders of giants, and one of those giants is Bjarne
 Stroustrup. Bjarne has made huge contributions to the programming


community.

 C++ was a great leap forward, and it practically invented generic
 metaprogramming.

 C++ isn't going away in the forseeable future. I fully expect that future
 C++ standards will incorporate some of D's innovations, in an analogous


way

 that C has adopted some C++ innovations. Bjarne is right, though, in
 suggesting that this will not happen anytime soon. The C++ standardization
 process is agonizingly slow (and should be, for a mature language).

 And, in due course, D will eventually be run over by a new upstart, D++


<g>.


But why is it such a slow process ? I myself can work for a couple of hours
and produce a better C++ spec...how come these people need years to do so ?

I think some people are overhyped. With all due respect to mr Stroustrup, if
he can't see that C++ has major flaws that need to be fixed *yesterday*,
what can I say ? Let Java dominate, then.



 May 22 2004



 next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org>  writes:


"Achilleas Margaritis" <axilmar b-online.gr> wrote in message
news:c8nmek$u31$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message
 news:c8e2mb$2h8v$1 digitaldaemon.com...

 "Achilleas Margaritis" <axilmar b-online.gr> wrote in message
 news:c8dojk$2048$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message
 news:c8bjdv$1eun$1 digitaldaemon.com...

 Someday, C++ may catch up with D <g>.


 I send an e-mail to Bjarne Stroustrup regarding the future of C++ now




 that

 D

 is around the corner. He told me to leave him alone and go use D, and




 that

 C++ is not gonna change anytime soon (although he said it very




 politely).

 I guess some people never realize when their time is over.


 D stands on the shoulders of giants, and one of those giants is Bjarne
 Stroustrup. Bjarne has made huge contributions to the programming


 community.

 C++ was a great leap forward, and it practically invented generic
 metaprogramming.

 C++ isn't going away in the forseeable future. I fully expect that future
 C++ standards will incorporate some of D's innovations, in an analogous


 way

 that C has adopted some C++ innovations. Bjarne is right, though, in
 suggesting that this will not happen anytime soon. The C++ standardization
 process is agonizingly slow (and should be, for a mature language).

 And, in due course, D will eventually be run over by a new upstart, D++


 <g>.


 But why is it such a slow process ? I myself can work for a couple of hours
 and produce a better C++ spec...how come these people need years to do so ?


Wow!

Arrogance, coupled with  ...


 I think some people are overhyped. With all due respect to mr Stroustrup, if


... ignorance (it's Dr Stroustrup)


 he can't see that C++ has major flaws that need to be fixed *yesterday*,
 what can I say ? Let Java dominate, then.


... and stupidity.

What a package!



 May 22 2004



  parent reply "Phill" <phill pacific.net.au>  writes:


"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c8ns6g$1697$1 digitaldaemon.com...

 "Achilleas Margaritis" <axilmar b-online.gr> wrote in message
 news:c8nmek$u31$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message
 news:c8e2mb$2h8v$1 digitaldaemon.com...

 "Achilleas Margaritis" <axilmar b-online.gr> wrote in message
 news:c8dojk$2048$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message
 news:c8bjdv$1eun$1 digitaldaemon.com...

 Someday, C++ may catch up with D <g>.


 I send an e-mail to Bjarne Stroustrup regarding the future of C++








now

 that

 D

 is around the corner. He told me to leave him alone and go use D,








and

 that

 C++ is not gonna change anytime soon (although he said it very




 politely).

 I guess some people never realize when their time is over.


 D stands on the shoulders of giants, and one of those giants is Bjarne
 Stroustrup. Bjarne has made huge contributions to the programming


 community.

 C++ was a great leap forward, and it practically invented generic
 metaprogramming.

 C++ isn't going away in the forseeable future. I fully expect that






future

 C++ standards will incorporate some of D's innovations, in an






analogous

 way

 that C has adopted some C++ innovations. Bjarne is right, though, in
 suggesting that this will not happen anytime soon. The C++






standardization

 process is agonizingly slow (and should be, for a mature language).

 And, in due course, D will eventually be run over by a new upstart,






D++

 <g>.


 But why is it such a slow process ? I myself can work for a couple of




hours

 and produce a better C++ spec...how come these people need years to do




so ?

 Wow!

 Arrogance, coupled with  ...


 I think some people are overhyped. With all due respect to mr




Stroustrup, if

 ... ignorance (it's Dr Stroustrup)


 he can't see that C++ has major flaws that need to be fixed *yesterday*,
 what can I say ? Let Java dominate, then.


 ... and stupidity.

 What a package!


Mathew I think you forgot to mention the other feature of the package, it
was wrapped in Bull S**t



 May 23 2004



  parent reply "Matthew" <matthew.hat stlsoft.dot.org>  writes:


"Phill" <phill pacific.net.au> wrote in message
news:c8pimj$hve$1 digitaldaemon.com...

 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:c8ns6g$1697$1 digitaldaemon.com...

 "Achilleas Margaritis" <axilmar b-online.gr> wrote in message
 news:c8nmek$u31$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message
 news:c8e2mb$2h8v$1 digitaldaemon.com...

 "Achilleas Margaritis" <axilmar b-online.gr> wrote in message
 news:c8dojk$2048$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message
 news:c8bjdv$1eun$1 digitaldaemon.com...

 Someday, C++ may catch up with D <g>.


 I send an e-mail to Bjarne Stroustrup regarding the future of C++








 now

 that

 D

 is around the corner. He told me to leave him alone and go use D,








 and

 that

 C++ is not gonna change anytime soon (although he said it very




 politely).

 I guess some people never realize when their time is over.


 D stands on the shoulders of giants, and one of those giants is Bjarne
 Stroustrup. Bjarne has made huge contributions to the programming


 community.

 C++ was a great leap forward, and it practically invented generic
 metaprogramming.

 C++ isn't going away in the forseeable future. I fully expect that






 future

 C++ standards will incorporate some of D's innovations, in an






 analogous

 way

 that C has adopted some C++ innovations. Bjarne is right, though, in
 suggesting that this will not happen anytime soon. The C++






 standardization

 process is agonizingly slow (and should be, for a mature language).

 And, in due course, D will eventually be run over by a new upstart,






 D++

 <g>.


 But why is it such a slow process ? I myself can work for a couple of




 hours

 and produce a better C++ spec...how come these people need years to do




 so ?

 Wow!

 Arrogance, coupled with  ...


 I think some people are overhyped. With all due respect to mr




 Stroustrup, if

 ... ignorance (it's Dr Stroustrup)


 he can't see that C++ has major flaws that need to be fixed *yesterday*,
 what can I say ? Let Java dominate, then.


 ... and stupidity.

 What a package!


 Mathew I think you forgot to mention the other feature of the package, it
 was wrapped in Bull S**t


Well, maybe I came off a bit strong, but I fail to see how such disrespect
should
be tolerated.

Technically Bjarne Stroustrup is a very smart man. Moreover, he is an
exceedingly
foresightful man - just check my latest article in this month's CUJ in June,
which describes a new technique for dramatically improving the performance of
string concatenation in any C++ libraries in a thoroughly safe and non-intrusive
manner. This was inspired by some research I was doing for the book on another
matter - user-defined cast operators (Imperfect C++, Chapter 19, if you're
interested) - that caused me to read a certain part of The C++ Programming
Language. That was an unconscious bit of smarts on the part of Dr Stroustrup. As
for a conscious one, he told me that he did indeed foresee the merging of
template and C++ cast syntax, in smart casts.

Furthermore, he's a very responsive man, and invariably helpful (even if he's
necessarily terse). I have had occasion to have information and encouragement
from him throughout the last year or so wrt my preparation of Imperfect C++, and
I can tell you he's a very nice, genuine, fellow. Given that he could
potentially
be receiving emails from the 3-5 million C++ programmers in the world, that's
pretty good work.

A bit more respect for those whose shoulders we stand upon costs nothing, and
shouldn't hurt anyone's ego. Maybe when AM has invented a language that is used
to implement a significant proportion of the worlds operating systems, and the
software that runs on it, I'll pay more credence to his invective.

-- 
Matthew Wilson

Author: "Imperfect C++", Addison-Wesley, 2004
    (www.imperfectcplusplus.com)
Contributing editor, C/C++ Users Journal
    (www.synesis.com.au/articles.html#columns)
STLSoft moderator
    (http://www.stlsoft.org)

-------------------------------------------------------------------------------

"So far, C++ is the best language I've discovered to say what I want to say" -- 
Alex Stepanov

-------------------------------------------------------------------------------



 May 23 2004



 next sibling parent  "Phill" <phill pacific.net.au>  writes:


 A bit more respect for those whose shoulders we stand upon costs nothing,


and

 shouldn't hurt anyone's ego. Maybe when AM has invented a language that is


used

 to implement a significant proportion of the worlds operating systems, and


the

 software that runs on it, I'll pay more credence to his invective.


I agree, and i'd certainly love to see the C++ spec's that he(AM) can come
up with in a "couple of hours" work.



 May 23 2004



prev sibling  parent  Achilleas Margaritis <Achilleas_member pathlink.com>  writes:


In article <c8qa63$1iu5$1 digitaldaemon.com>, Matthew says...

"Phill" <phill pacific.net.au> wrote in message
news:c8pimj$hve$1 digitaldaemon.com...

 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:c8ns6g$1697$1 digitaldaemon.com...

 "Achilleas Margaritis" <axilmar b-online.gr> wrote in message
 news:c8nmek$u31$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message
 news:c8e2mb$2h8v$1 digitaldaemon.com...

 "Achilleas Margaritis" <axilmar b-online.gr> wrote in message
 news:c8dojk$2048$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message
 news:c8bjdv$1eun$1 digitaldaemon.com...

 Someday, C++ may catch up with D <g>.


 I send an e-mail to Bjarne Stroustrup regarding the future of C++








 now

 that

 D

 is around the corner. He told me to leave him alone and go use D,








 and

 that

 C++ is not gonna change anytime soon (although he said it very




 politely).

 I guess some people never realize when their time is over.


 D stands on the shoulders of giants, and one of those giants is Bjarne
 Stroustrup. Bjarne has made huge contributions to the programming


 community.

 C++ was a great leap forward, and it practically invented generic
 metaprogramming.

 C++ isn't going away in the forseeable future. I fully expect that






 future

 C++ standards will incorporate some of D's innovations, in an






 analogous

 way

 that C has adopted some C++ innovations. Bjarne is right, though, in
 suggesting that this will not happen anytime soon. The C++






 standardization

 process is agonizingly slow (and should be, for a mature language).

 And, in due course, D will eventually be run over by a new upstart,






 D++

 <g>.


 But why is it such a slow process ? I myself can work for a couple of




 hours

 and produce a better C++ spec...how come these people need years to do




 so ?

 Wow!

 Arrogance, coupled with  ...


 I think some people are overhyped. With all due respect to mr




 Stroustrup, if

 ... ignorance (it's Dr Stroustrup)


 he can't see that C++ has major flaws that need to be fixed *yesterday*,
 what can I say ? Let Java dominate, then.


 ... and stupidity.

 What a package!


 Mathew I think you forgot to mention the other feature of the package, it
 was wrapped in Bull S**t


Well, maybe I came off a bit strong, but I fail to see how such disrespect
should
be tolerated.

Technically Bjarne Stroustrup is a very smart man. Moreover, he is an
exceedingly
foresightful man - just check my latest article in this month's CUJ in June,
which describes a new technique for dramatically improving the performance of
string concatenation in any C++ libraries in a thoroughly safe and non-intrusive
manner. This was inspired by some research I was doing for the book on another
matter - user-defined cast operators (Imperfect C++, Chapter 19, if you're
interested) - that caused me to read a certain part of The C++ Programming
Language. That was an unconscious bit of smarts on the part of Dr Stroustrup. As
for a conscious one, he told me that he did indeed foresee the merging of
template and C++ cast syntax, in smart casts.

Furthermore, he's a very responsive man, and invariably helpful (even if he's
necessarily terse). I have had occasion to have information and encouragement
from him throughout the last year or so wrt my preparation of Imperfect C++, and
I can tell you he's a very nice, genuine, fellow. Given that he could
potentially
be receiving emails from the 3-5 million C++ programmers in the world, that's
pretty good work.

A bit more respect for those whose shoulders we stand upon costs nothing, and
shouldn't hurt anyone's ego. Maybe when AM has invented a language that is used
to implement a significant proportion of the worlds operating systems, and the
software that runs on it, I'll pay more credence to his invective.

-- 
Matthew Wilson

Author: "Imperfect C++", Addison-Wesley, 2004
    (www.imperfectcplusplus.com)
Contributing editor, C/C++ Users Journal
    (www.synesis.com.au/articles.html#columns)
STLSoft moderator
    (http://www.stlsoft.org)

-------------------------------------------------------------------------------

"So far, C++ is the best language I've discovered to say what I want to say" -- 
Alex Stepanov

-------------------------------------------------------------------------------


I never spoken with bad words for you, Matthew. In fact, I was deeply annoyed by
your attitude (see "clear your mixins out of my aggregates")...it sounded as if
the sole puprose of the D language is to fit your needs, and not to apply to
millions of programmers across the globe.

With my words I wanted to stirr the pot, as well as express my question about
how C++ is developed so slowly. I am not disrespecting anyone, nor I will take a
chance to call you an arrogant moron, no matter how hard I want to do so. 

I could develop a language, If I had the time to. The fact that I work for 8 to
12 hours a day developing real-time defense applications does not leave me any
time to develop my own programming language. But that does not stop me from
expressing what I desire from a good language. 

Mr Stroustrup works for a University and has the time and resources to develop
whatever he wants, and present it as research...Walter makes a living out of it.
On the other hand, I am in a country that only recently has seen great
developments in computers (and until recently, Basic was tought as a the first
programming language in computer science courses!)...I did not have a choice to
develop my own language, I have to work for another man's company.

Do you want to see If I can come up with many C++ improvements, in a blink of an
eye, that would not break backwards compatibility anytime ? ok, here are some of
them:

-strings as primitive types: new data types 'string', 'wstring', 'dstring':

string foo1;
wstring foo2;
dstring foo3;

-class properties: 

class Foo {
public:
//property
property name {
public:
//getter
string operator () () const {
return m_value;
}

//setter
void operator = (string text) {
m_value = text;
}

private:
//value
string m_value;
}
}


-class partioning:


//partitioned class
class Foo {
public:
partition SomePart {
void bar() {
}
}
}


//usage
Foo foo1;
foo1.SomePart.bar() {
}



-reflection: a vtable entry which points to class data: a method table for
accessing all class methods and fields.

used like:

Foo foo = new Foo;
foo.class.method("action1", 10, 20, 30);


-variants:

variant v1;

v1 = 5;
v1 = "foo";
int i = v1;


-safe variable argument lists using the variant type.

-multithreading, synchronized keyword and mutex primitive:


mutex m_mutex;

synchronized (mutex) {
<bla bla>
}


-signals and slots:

//class with signals
class MyDocument {
public:
signal renamed(string name);
}

//class with slots
class Controller {
public:
slot onDocumentRenamed(string name) {
<bla bla>
}
}


//use signals and slots
document1.renamed += controller1.onDocumentRenamed;


-a new type of file extension that would solve the problem of
header/implementation files: when the compiler met such a file, it would treat
as a translation unit, not expecting include files and such. It could be
combined with 'import' statements, as in D, with symbol processing instead of
text processing.


-garbage collection through the 'gc' attribute:

//garbage collected class
gc class Foo {
}


-make the -> and :: operators reduntant.

-add design-by-contract, as in D.

-add a 'foreach' statement.

-make 'switch' able to work on non-primive types, like strings.

-introduce strong typedefs with a new keyword.

-add delegates to object methods and functions.

-improve enums by making them strong typedefs which define a scope (as in D).

-provide versioning.

-make the 'operator' keyword optional. It does not make any difference, from the
parsing point of view, to have it: the symbol tokens should be put within a
known range, and then be recognized by the syntax analyser by a simple 'if token

= TOKEN_OPERATOR_FIRST && token <= TOKEN_OPERATOR_LAST).


-provide 'and', 'or' and 'not' boolean operators, to make the language better
looking.

-make the ';' after class and struct declarations optional.

-provide for registered classes: allow 'new' with class names, instead of types:

MyObject* foo = new "MyClass";

This, coupled with reflection, would make run-time plug-in management a breeze.
As it is right now, the compiler already keeps class info through the
'type_info' structure.

-make cast operators optional. Why one should need 'static_cast' etc ? a simple
casting, if it is between classes, could be worked out at compile time if it is
static or dynamic.

-provide new types of standard length across all platforms.

-provide code splitting between different files, through usage of some keyword
combinations.

-provide optional initialization of data with their default values.

-make null a keyword.

-provide strong types with ranges, like this:

strong typedef int(1..10) Index;

-provide static properties to types.

-provide compound primitives:

struct Vector {
int x;
int y;
int z;
}
s = {10, 20, 30};

-provide sequence lists:

sequence s = [1, 2, 3, 4, 5, "foo", object1];

-provide a new keyword 'function' which could make the language functional:
assignment would not be allowed during 'function' calls, and calling procedures
would not be allowed through functions. A function would make state change not
allowed:

class Foo {
public:
function int action(Bar bar1) {
<bla bla state
}
}

-provide an 'abstract' keyword.

-provide managed state changes! Let the programmer model a variable's states,
the state changes and the actions to be taken in order to change states. Then,
the programmer could not accidentally make unwanted state changes, and many
logical errors could be cought at compile time! and in run-time, throw
exceptions when a state is violated.

-provide for error report customization. For example, instead of 'syntax error',
one could say 'class Foo must not inherit from class Bar' or something like
that.

-provide for data modelling like XML, but inside the language. One could than
write compile-time or run-time models of data, expressing them in the simplest
way possible.

How all these features break backwards compatibility ? they don't. In fact, they
are nice additions which solve many issues amongst developers, improve the
quality of the programs, elevate the status of the language and give it new
life.

After all, D exists and has many of these capabilities, just because C++ just
does not have these. If C++ had all these, D would not exist.

Hey, I've spend a couple of minutes typing this stuff into...if I looked really
hard, I could add a dozen more features. And this stuff is trivially easy to
incorporate into the C++ language (many of them can already be provided in the
form of code), but it will make a hell of a difference to developers. But it
will never be done so, because someone has decided that it should take decades
of years, when in fact it could take a few months for most compiler vendors to
support them. 

Really wise men know how to talk with their ears, i.e. listen to everyone's
opinions, even the lowly ones like me, and then rule things out based on logic
and arguments. You have chosen to insult me first...what else can I say, other
than you are really immature as a person. 



 May 24 2004



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


"Achilleas Margaritis" <axilmar b-online.gr> wrote in message
news:c8nmek$u31$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message
 news:c8e2mb$2h8v$1 digitaldaemon.com...

 The C++ standardization
 process is agonizingly slow (and should be, for a mature language).


 But why is it such a slow process ?


Committees always are. The C++ standards committee is composed of people all
over the world, and there's a formal process to go through to make any
changes. It's set up to try and produce consensus, and that takes time. Lots
of people need to look at it, get to comment, there are public reviews, etc.
It's all there to try and ensure any changes are really needed and won't
break entrenched existing code.


 I myself can work for a couple of hours
 and produce a better C++ spec...how come these people need years to do so


?

Writing specs is pretty hard. It's further complicated by everything in C++
seems to affect everything else :-( When designing a new feature, it's very
difficult to anticipate everything else it will perturb.


 I think some people are overhyped.


I've known Dr. Stroustrup since 1988 or so, and he's the genuine article.


 With all due respect to mr Stroustrup, if
 he can't see that C++ has major flaws that need to be fixed *yesterday*,
 what can I say ? Let Java dominate, then.


I'm sure he's well aware of the flaws in C++. The problem is, the flaws are
due to the desire for backwards compatibility with legacy code. There's
nothing to be done about it, short of making a break with backwards
compatibility like D does.



 May 23 2004



  parent reply Juan C <Juan_member pathlink.com>  writes:


I'm sure he's well aware of the flaws in C++. The problem is, the flaws are
due to the desire for backwards compatibility with legacy code. There's
nothing to be done about it, short of making a break with backwards
compatibility like D does.


D needs to break backward compatibility more (or however to express that in
proper English grammar).



 May 23 2004



  parent  Norbert Nemec <Norbert.Nemec gmx.de>  writes:


Juan C wrote:


I'm sure he's well aware of the flaws in C++. The problem is, the flaws
are due to the desire for backwards compatibility with legacy code.
There's nothing to be done about it, short of making a break with
backwards compatibility like D does.


 
 D needs to break backward compatibility more (or however to express that
 in proper English grammar).


Do you talk about details or fundamental concepts?

As I understand it the idea behind D is to give up compatibility in terms of
code, but not in terms of programming philosophy. A C/C++ programmer will
have to relearn details, but the core concepts (what is a class, what is a
function, etc.) are kept the same.

I think, this is a great goal. No good programmer should have a problem
learning a new syntax or adjusting to new language details, but changing
your way of thinking is extremely hard once you got comfortable in one
language.



 May 23 2004



prev sibling next sibling parent  "Phill" <phill pacific.net.au>  writes:


"Achilleas Margaritis" <axilmar b-online.gr> wrote in message
news:c8dojk$2048$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message
 news:c8bjdv$1eun$1 digitaldaemon.com...

 "Sean Kelly" <sean ffwd.cx> wrote in message
 news:c8bej6$181f$1 digitaldaemon.com...

 While I personally dislike get/set methods I do understand the






reasoning

 behind them.  They are a pre-emptive tactic to enable back-end changes
 without requiring user-side code changes.  However, properties in D
 pretty much eliminate the need for this tactic, as there is no






semantic

 difference between public variables and property methods.  It's worth
 noting that properties have been proposed as an addition to the next
 version of C++
 (http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf),
 probably for this exact reason.


 Someday, C++ may catch up with D <g>.


 I send an e-mail to Bjarne Stroustrup regarding the future of C++ now that


D

 is around the corner. He told me to leave him alone and go use D, and that
 C++ is not gonna change anytime soon (although he said it very politely).

 I guess some people never realize when their time is over.


I think that time is a looooooong way off.



 May 19 2004



prev sibling  parent  "Matthew" <matthew.hat stlsoft.dot.org>  writes:


"Achilleas Margaritis" <axilmar b-online.gr> wrote in message
news:c8dojk$2048$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message
 news:c8bjdv$1eun$1 digitaldaemon.com...

 "Sean Kelly" <sean ffwd.cx> wrote in message
 news:c8bej6$181f$1 digitaldaemon.com...

 While I personally dislike get/set methods I do understand the reasoning
 behind them.  They are a pre-emptive tactic to enable back-end changes
 without requiring user-side code changes.  However, properties in D
 pretty much eliminate the need for this tactic, as there is no semantic
 difference between public variables and property methods.  It's worth
 noting that properties have been proposed as an addition to the next
 version of C++
 (http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf),
 probably for this exact reason.


 Someday, C++ may catch up with D <g>.


 I send an e-mail to Bjarne Stroustrup regarding the future of C++ now that D
 is around the corner. He told me to leave him alone and go use D, and that
 C++ is not gonna change anytime soon (although he said it very politely).

 I guess some people never realize when their time is over.


When will that be, then? 2030?



 May 19 2004



prev sibling  parent reply Mike Swieton <mike swieton.net>  writes:


On Mon, 17 May 2004 16:46:48 +0000, Charlie wrote:

 I never liked this either, if the getters and setters do nothing more then
 just that ( i.e. they might check a value for a condition etc ) , then why
 not just make the data public ?  Even this month I read an article in favor
 of getters and setters in CUJ, I like python style much better.
 
 Charlie


That's why they are generally considered a bad idea. If a class is nothing but
gets/sets, then it probably should have been a struct. Sure, there's proper
uses for them, but when you start writing a lot of them, you should probably
examine your design once, just to double check.

Mike Swieton
__
But who prays for Satan? Who, in eighteen centuries, has had the common
humanity to pray for the one sinner that needed it the most?
	- Mark Twain



 May 17 2004



 next sibling parent  clayasaurus <clayasaurus_member pathlink.com>  writes:


In article <pan.2004.05.17.22.39.51.699006 swieton.net>, Mike Swieton says...

On Mon, 17 May 2004 16:46:48 +0000, Charlie wrote:

 I never liked this either, if the getters and setters do nothing more then
 just that ( i.e. they might check a value for a condition etc ) , then why
 not just make the data public ?  Even this month I read an article in favor
 of getters and setters in CUJ, I like python style much better.
 
 Charlie


That's why they are generally considered a bad idea. If a class is nothing but
gets/sets, then it probably should have been a struct. Sure, there's proper
uses for them, but when you start writing a lot of them, you should probably
examine your design once, just to double check.

Mike Swieton
__
But who prays for Satan? Who, in eighteen centuries, has had the common
humanity to pray for the one sinner that needed it the most?
	- Mark Twain


I'm creating a project that has a heavy OOP design with D. I like OOP so I don't
have to use function(&datastruct) type syntaxes, rather class.function(), and
using lots of globals is a bad design decision IMO. 

i like using get-set methods because it allows me to change the insides of a
class without effecting the outside classes/programs that use that class, like
if for some reason i wanted to change m_data to m_data[]. 



 May 17 2004



prev sibling  parent reply "Phill" <phill pacific.net.au>  writes:


 Mike Swieton
 __
 But who prays for Satan? Who, in eighteen centuries, has had the common
 humanity to pray for the one sinner that needed it the most?
 - Mark Twain


Does that mean that prior to eighteen centuries ago,
there were people praying for Satan?



 May 18 2004



  parent reply Norbert Nemec <Norbert.Nemec gmx.de>  writes:


Phill wrote:


 Mike Swieton
 __
 But who prays for Satan? Who, in eighteen centuries, has had the common
 humanity to pray for the one sinner that needed it the most?
 - Mark Twain


 
 Does that mean that prior to eighteen centuries ago,
 there were people praying for Satan?


I think, that citation is based on the theological thesis that before that
time, there was no point in praying for sinners at all.



 May 18 2004



  parent reply "Phill" <phill pacific.net.au>  writes:


"Norbert Nemec" <Norbert.Nemec gmx.de> wrote in message
news:c8d2ee$nu6$3 digitaldaemon.com...

 Phill wrote:


 Mike Swieton
 __
 But who prays for Satan? Who, in eighteen centuries, has had the common
 humanity to pray for the one sinner that needed it the most?
 - Mark Twain


 Does that mean that prior to eighteen centuries ago,
 there were people praying for Satan?


 I think, that citation is based on the theological thesis that before that
 time, there was no point in praying for sinners at all.


Ah right, because when Jesus was crucified everyone
started on a new slate(except Satan ofcourse) so prior sins were paid for by
Jesus's suffering on the cross.



 May 18 2004



  parent  Mike Swieton <mike swieton.net>  writes:


On Wed, 19 May 2004 09:27:17 +1000, Phill wrote:


 
 "Norbert Nemec" <Norbert.Nemec gmx.de> wrote in message
 news:c8d2ee$nu6$3 digitaldaemon.com...

 Phill wrote:


 Mike Swieton
 __
 But who prays for Satan? Who, in eighteen centuries, has had the common
 humanity to pray for the one sinner that needed it the most?
 - Mark Twain


 Does that mean that prior to eighteen centuries ago,
 there were people praying for Satan?


 I think, that citation is based on the theological thesis that before that
 time, there was no point in praying for sinners at all.


 
 Ah right, because when Jesus was crucified everyone
 started on a new slate(except Satan ofcourse) so prior sins were paid for by
 Jesus's suffering on the cross.


I think you're following the quote a bit much. I've always thought that the
time (18 centuries) was there solely for emphasis, and that the salient was
the "who has prayed for him" part. Perhaps I'm wrong; I don't have the context
for that quote.

Mike Swieton
__
The Lord's Prayer is 66 words, the Gettysburg Address is 286 words, and there
are 1,322 words in the Declaration of Independence. Yet, government
regulations on the sale of cabbage total 26,911 words. 
	- David McIntosh 



 May 18 2004



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


"imr1984" <imr1984_member pathlink.com> wrote in message
news:c8ac4b$2kt4$1 digitaldaemon.com...

 is anyone else here using D in a C stlye way, ie billions of globals,


almost no

 classes etc?


Empire is written that way.



 May 17 2004



prev sibling  parent  J C Calvarese <jcc7 cox.net>  writes:


imr1984 wrote:

 is anyone else here using D in a C stlye way, ie billions of globals, almost no
 classes etc?


Sort of. I don't create many classes. Part of the reason of why I 
program so procedurally is that I'm not used to OOP. I've programmed a 
little in Turbo Pascal and Java, but I've mostly used forms of BASIC. 
Consequently, I think in functions rather than objects. As I become more 
comfortable with D, I seem to create more classes.


 D just appeals to me because of its much cleaner syntax and no header files,
not
 because of its great OOP capabilities. I especially dont like member protection
 because im a bedroom coder so i work on my own, so protecting member variables
 doesnt really appeal to me.


I'm in a similar position here, too. I don't have many people looking 
over my code, so I code how I want to code.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/



 May 17 2004