www.digitalmars.com         C & C++   DMDScript  

D - Properties

reply "Martin York" <Martin.York veritas.com> writes:
I was looking at the properties part of the syntax and thinking this was a
great idea.
But this really looks like static methods and the syntax should reflect
this.

int::size()        /*Access the static member size() for the class int.
returns the size of an int*/
(4).size()        /* This again access the static member of the object 4.
where 4 is an instance of the int class.*/

Which leads me onto everything as objects (including what are considered the
base types).
Whatever happens don't do what Java did and have (int and Integer [basic and
class types]).

just my 0.02p

Has this topic been discussed before?

Martin
Jan 14 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Martin York" <Martin.York veritas.com> wrote in message
news:a1v6s4$1fvn$1 digitaldaemon.com...

 I was looking at the properties part of the syntax and thinking this was a
 great idea.
 But this really looks like static methods and the syntax should reflect
 this.

 int::size()        /*Access the static member size() for the class int.
 returns the size of an int*/
 (4).size()        /* This again access the static member of the object 4.
 where 4 is an instance of the int class.*/

In D, there is not :: nor -> You always use dot, and the compiler determines what you've meant by the context.
 Which leads me onto everything as objects (including what are considered

 base types).

Would be too bloatsome, IMO.
Jan 14 2002
parent reply "Martin York" <Martin.York veritas.com> writes:
 int::size()        /*static member size() for the class int.*/
 (4).size()        /* static member of the object 4.*/
                      /*where 4 is an instance of the int class.*/

In D, there is not :: nor -> You always use dot, and the compiler determines what you've meant by the context.

OK. I have re-read the section that mentions that all objects are created on the heap using the new operator (like Java). Do you have any references that I could read that persuaded you to use this java like style, rather than following the C++ style that allows you to have local objects that are created on stack and automatically destroyed at the end of the scope.
 Which leads me onto everything as objects (including what are
 considered the base types).

Would be too bloatsome, IMO.

Yes. If all instances of a class are implemented as pointers to the object I would agree. Martin.
Jan 14 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Martin York" <Martin.York veritas.com> wrote in message
news:a1vc3b$1j9d$1 digitaldaemon.com...

 I have re-read the section that mentions that all objects are created on
 the heap using the new operator (like Java). Do you have any references
 that I could read that persuaded you to use this java like style, rather
 than
 following the C++ style that allows you to have local objects that are
 created on stack and automatically destroyed at the end of the scope.

I don't know why Walter did so, but I guess it adds too much complexity, while giving too little. Because of the ability of objects to exist on stack and be passed by value, C++ employs things like references, copy constructors (with a whole bunch of associated rules), assignment ops etc... most other languages deal with this simply by disallowing "object" variables at all - you always work with references. This is not only the Java way, the same can be seen in Object Pascal (btw for those who remember, it first had stack objects in BP5-7, but in Delphi they were replaced by references), VB... What big advantages are in creating objects on stack, anyhow?
Jan 14 2002
parent reply "Martin York" <Martin.York veritas.com> writes:
 What big advantages are in creating objects on stack, anyhow?

being called, resource management (memory but mainly other) is excellent when using stack based objects. I would loke to know bad points (apart from the obvious complexity issues). Martin
Jan 14 2002
next sibling parent reply "Juan Carlos Arevalo Baeza" <jcab roningames.com> writes:
"Martin York" <Martin.York veritas.com> wrote in message
news:a1vpav$1rgj$1 digitaldaemon.com...
 What big advantages are in creating objects on stack, anyhow?

being called, resource management (memory but mainly other) is excellent when using stack based objects.

That's one reason. It's been argued a lot with Java. Java doesn't allow destructors. The justification for this is that they are not needed, as memory will be recalled as appropriate. The problem is that destructors are useful not only to release memory, but to release other kinds of resources (mutex locks, file handles, sockets, etc...). Thus, having destructors is a good thing. Now comes the million-dollar question: when does an object's destructor get called, when the object is never explicitly destroyed? The answer: maybe never. Thus rendering them useless when all objects are alllocated on the heap and garbage collected. In short, this memory model makes the lifes of the compiler makers and the language users easier, as long as they don't need the kind of automatic resource management that has become ubiquitous in C++. I wouldn't want to live without stack-based objects, precisely for this reason. The other reason is that this memory model widens the gap between predefined types and user-defined types. And that's, IMHO, going in the wrong direction. Instead of adding complex numbers and whatnot to the language (for performance reasons and to avoid user-defined overloaded operators), the language should allow those complex numbers (and vectors, and matrices, etc...) to be easily created and integrated as libraries. Keep the core language simple, and allow libraries to add the complex bits. That's my opinion. It's one of the strengths of C++, even if it's somewhat incomplete and with rough corners there. Salutaciones, JCAB
Jan 14 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Juan Carlos Arevalo Baeza" <jcab roningames.com> wrote in message
news:a20eab$28mc$1 digitaldaemon.com...
    The other reason is that this memory model widens the gap between
 predefined types and user-defined types. And that's, IMHO, going in the
 wrong direction. Instead of adding complex numbers and whatnot to the
 language (for performance reasons and to avoid user-defined overloaded
 operators), the language should allow those complex numbers (and vectors,
 and matrices, etc...) to be easily created and integrated as libraries.

 the core language simple, and allow libraries to add the complex bits.
 That's my opinion. It's one of the strengths of C++, even if it's somewhat
 incomplete and with rough corners there.

It's not at all easy to create user-defined types with overloaded operators in C++.
Jan 16 2002
next sibling parent reply "Sean L. Palmer" <spalmer iname.com> writes:
Luckily those few brave souls who actually know how can just make a library
for use by the masses that can't figure it out.

With D, *nobody* can make types with overloaded operators except you,
Walter.

Sean

"Walter" <walter digitalmars.com> wrote in message
news:a24id1$1uqg$1 digitaldaemon.com...
 "Juan Carlos Arevalo Baeza" <jcab roningames.com> wrote in message
 news:a20eab$28mc$1 digitaldaemon.com...
    The other reason is that this memory model widens the gap between
 predefined types and user-defined types. And that's, IMHO, going in the
 wrong direction. Instead of adding complex numbers and whatnot to the
 language (for performance reasons and to avoid user-defined overloaded
 operators), the language should allow those complex numbers (and


 and matrices, etc...) to be easily created and integrated as libraries.

 the core language simple, and allow libraries to add the complex bits.
 That's my opinion. It's one of the strengths of C++, even if it's


 incomplete and with rough corners there.

It's not at all easy to create user-defined types with overloaded

 in C++.

Jan 16 2002
parent reply "Juan Carlos Arevalo Baeza" <jcab roningames.com> writes:
"Sean L. Palmer" <spalmer iname.com> wrote in message
news:a24ln6$20tb$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:a24id1$1uqg$1 digitaldaemon.com...
 It's not at all easy to create user-defined types with overloaded

 in C++.

Luckily those few brave souls who actually know how can just make a

 for use by the masses that can't figure it out.

 With D, *nobody* can make types with overloaded operators except you,
 Walter.

:) I guess you and I agree that D is not for us, Sean. It does make for some very interesting discussions, though. And the whole DBC thing is very cool indeed. Salutaciones, JCAB
Jan 16 2002
parent "Sean L. Palmer" <spalmer iname.com> writes:
It has a lot of interesting things, things I'd want C++ to have, but yeah
probably C++ will remain my main tool for a while.  I could get some use out
of D for making tools perhaps.  Stuff like Perl and Ruby are just too wierd
for me.  C++ is kind of a pain for little tools.

I can only hope the new C++ standard committee maybe learns a few things
from D and C# and other more modern languages.

Sean

"Juan Carlos Arevalo Baeza" <jcab roningames.com> wrote in message
news:a24nq2$2211$1 digitaldaemon.com...
 "Sean L. Palmer" <spalmer iname.com> wrote in message
 news:a24ln6$20tb$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:a24id1$1uqg$1 digitaldaemon.com...
 It's not at all easy to create user-defined types with overloaded

 in C++.

Luckily those few brave souls who actually know how can just make a

 for use by the masses that can't figure it out.

 With D, *nobody* can make types with overloaded operators except you,
 Walter.

:) I guess you and I agree that D is not for us, Sean. It does make for some very interesting discussions, though. And the whole DBC thing is very cool indeed. Salutaciones, JCAB

Jan 17 2002
prev sibling parent reply "Juan Carlos Arevalo Baeza" <jcab roningames.com> writes:
"Walter" <walter digitalmars.com> wrote in message
news:a24id1$1uqg$1 digitaldaemon.com...
 "Juan Carlos Arevalo Baeza" <jcab roningames.com> wrote in message
 news:a20eab$28mc$1 digitaldaemon.com...
 Instead of adding complex numbers and whatnot to the
 language (for performance reasons and to avoid user-defined overloaded
 operators), the language should allow those complex numbers (and


 and matrices, etc...) to be easily created and integrated as libraries.

 the core language simple, and allow libraries to add the complex bits.
 That's my opinion. It's one of the strengths of C++, even if it's


 incomplete and with rough corners there.

It's not at all easy to create user-defined types with overloaded

 in C++.

Well... no. Generally speaking, no simple task is easy in C++. The main problem with that language (and its main strength, too) is that it's more like an untidy and quite full bag of tools. Many of those tools need "qualified experts" to handle them, though. This means that you can do A LOT of different things with the language, but it also means that the result is never optimal. Salutaciones, JCAB
Jan 16 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Juan Carlos Arevalo Baeza" <jcab roningames.com> wrote in message
news:a24nrc$2217$1 digitaldaemon.com...
    Well... no. Generally speaking, no simple task is easy in C++. The main
 problem with that language (and its main strength, too) is that it's more
 like
 an untidy and quite full bag of tools. Many of those tools need "qualified
 experts" to handle them, though. This means that you can do A LOT of
 different things with the language, but it also means that the result is
 never optimal.

 Salutaciones,
                          JCAB

C++ does have a lot of tools in it. But it's missing important features like: 1) garbage collection 2) design by contract 3) support for unit testing It certainly is possible to use garbage collection with C++, and I do so myself. But two words that describe using gc with C++ are do it "very carefully". Garbage collectors for C++ have not caught on likely for that reason. You can emulate DBC in C++ with a collection of ungainly macros and virtual functions. The result is not too attractive. Ditto for unit testing. Of course, everything you can do in C++ can also be done in C, as cfront proves <g>.
Jan 16 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:a24t94$25gp$1 digitaldaemon.com...

 C++ does have a lot of tools in it. But it's missing important features
 like:
 1) garbage collection
 2) design by contract
 3) support for unit testing

Well, D also has a lot of tools in it (GC, DBC, unittests). But it's missing important features like: 1) operator overloading 2) templates 3) adequate support for strings =)
Jan 17 2002
next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
oops, forgot default values for function parameters! =)
Jan 17 2002
prev sibling parent reply Russell Borogove <kaleja estarcion.com> writes:
Pavel Minayev wrote:

 Well, D also has a lot of tools in it (GC, DBC, unittests). But it's missing
 important features like:
 
     1) operator overloading
     2) templates

Come on, lay off of Walter. He's expressed the intent to support some form of generic programming at some point in the future. And he _will_ come around on operator overloading or I'll break his thumbs.
     3) adequate support for strings

Adequate meaning "having a dedicated comparison operator?" -RB
Jan 17 2002
parent "Pavel Minayev" <evilone omen.ru> writes:
"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3C4706DD.7070306 estarcion.com...

     3) adequate support for strings

Adequate meaning "having a dedicated comparison operator?"

Heh, yes!
Jan 17 2002
prev sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"Martin York" <Martin.York veritas.com> wrote in message
news:a1vpav$1rgj$1 digitaldaemon.com...

 IMHO: Because you know exactly when destructors are
 being called, resource management (memory but mainly other)
 is excellent when using stack based objects.

Just don't write code in destructors that relies on order of destruction... Alternatively, the delete operator can be used - AFAIK it calls the destructor immediately.
Jan 15 2002