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

"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
the
> base types).

Would be too bloatsome, IMO.

> > 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.

"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?

>
> What big advantages are in creating objects on stack, anyhow?
>
IMHO: Because you know exactly when destructors are
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

"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?
> >
> IMHO: Because you know exactly when destructors are
> 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

"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.

"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.
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.

It's not at all easy to create user-defined types with overloaded operators in C++.

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
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.
>
> It's not at all easy to create user-defined types with overloaded
operators
> in C++.

"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
> operators
> > in C++.
>
> 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.

   :) 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