April 29, 2005
Ben Hinkle wrote:
>>>MATLAB uses "." independent of value/reference semantics and it works fine. The difference between value/reference only shows up in assignment behavior (which is the definition of value/reference anyway). But then MATLAB also doesn't have pointers.
>>
>>IMHO, getting rid of -> and just using . was a good idea, but that is a different question.
>>
>>I, like the others (it's nice to know I'm not alone) don't like the current syntax.  I've stated before my beefs with it:
>>
>>1) Makes it hard to write a template that handles both struct pointers and object references correctly.
> 
> I'm not sure what you are referring to. Can you give a pointer to a post or examples?

Say that you want to store a pointer to a type in a template struct.  Do you do this?
	struct RefTo(T) {
	  T reference;
	}
which works for classes, or this
	struct RefTo(T) {
	  T *pointer;
	}
which works for structs?  Sure, you can do specialized templates, but that's a kludge to work around the problem, IMHO.

>>2) Leads to a very common newbie error: segfault because he used an uninitialized class reference.  (If we had used C++ syntax, then Java programmers would have had a learning curve...but their error would be caught at build time, not as a runtime error, which, IMHO, is far superior)
> 
> IMO better segv than slicing objects passed by value. Any non-trivial class hierarchy is destined to be manipulated by reference.

I half agree and half disagree.  I think that Walter made a very good point when he said that copy constructors are trouble; you are making a similar point by saying that we don't want to pass objects by value.

So why not just ban passing classes by value?  That is, the following code would be illegal:
	class Foo {};
	int myFunc(Foo pass_by_value) {...}
it would give an error:
	ERROR: Class objects cannot be passed by value.
	They must be passed by pointer instead.

Likewise, any code that required copying a class by value would be illegal.  Offhand, I can think of:
* Class values as function parameters
* Class values as function return values
* Direct object assignments

>>3) Made it so that class objects can't be on the stack.  Let's be honest, here, the whole reason that we have 'auto' is a kludge to get around the syntax problem.
> 
> I'm with Walter (and Java/C#) that class objects on the stack should be rare. If there are issues with structs that require lots of auto classes then structs need attention. Actually auto classes don't have anything to do with being on the stack - they just force the dtor to be called on scope exit. IMO I haven't seen a D class that should be auto (I've seen good uses auto variables but declaring a class as auto forces all uses to be auto).

I agree that the vast majority of class objects should be on the heap. But why require it?

BTW, similar to this is the problem that you can't have a global class object without having to initialize it in an init() function.

>>4) Invited confusion over === and ==
> 
> Agreed - though the current design isn't unreasonable in the big picture. 

:)
April 29, 2005
>> I've read a couple of things recently that've indicated that D's not taken seriously by the C++ world.
>
>I'm not in the C++ plus world, nor are my professional colleagues, but I'm wondering if D's target audience is not the current C/C++/C#/Java crowd. Instead, might it be found in the Perl, Python, Ruby, Euphoria, and total-newbie groups that have not been exposed to the foibles of the 'C' legacy, and are looking for speed, power, and simplicity?

A Python programmer looking for simplicity should switch to D? Have you ever looked at Python?


April 29, 2005
"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:d4tgj7$usv$1@digitaldaemon.com...
> Ben Hinkle wrote:
>>>>MATLAB uses "." independent of value/reference semantics and it works fine. The difference between value/reference only shows up in assignment behavior (which is the definition of value/reference anyway). But then MATLAB also doesn't have pointers.
>>>
>>>IMHO, getting rid of -> and just using . was a good idea, but that is a different question.
>>>
>>>I, like the others (it's nice to know I'm not alone) don't like the current syntax.  I've stated before my beefs with it:
>>>
>>>1) Makes it hard to write a template that handles both struct pointers and object references correctly.
>>
>> I'm not sure what you are referring to. Can you give a pointer to a post or examples?
>
> Say that you want to store a pointer to a type in a template struct.  Do
> you do this?
> struct RefTo(T) {
>   T reference;
> }
> which works for classes, or this
> struct RefTo(T) {
>   T *pointer;
> }
> which works for structs?  Sure, you can do specialized templates, but
> that's a kludge to work around the problem, IMHO.

When you said "template that handles struct pointer and objects refs" I
thought you meant
  struct RefTo(T) {
   T bar;
  }
  RefTo!(Object) blah;
  RefTo!(MyStruct*) blah2;
The same template RefTo should be usable by anything with reference
semantics (which both struct ptrs and object refs have). I agree sometimes
you have to write two templates if you want to use it both with a type with
value semantics and with a type with reference semantics. But that's only
logical. For the particular case of "RefTo" I'm not sure what the point is
but I'd say leave it as one template and make users explicitly take a
reference to the structs since that's how structs in D behave - trying to
make D structs act like they have reference semantics will result in
confusing and clunky code IMO.

>>>2) Leads to a very common newbie error: segfault because he used an uninitialized class reference.  (If we had used C++ syntax, then Java programmers would have had a learning curve...but their error would be caught at build time, not as a runtime error, which, IMHO, is far superior)
>>
>> IMO better segv than slicing objects passed by value. Any non-trivial class hierarchy is destined to be manipulated by reference.
>
> I half agree and half disagree.  I think that Walter made a very good point when he said that copy constructors are trouble; you are making a similar point by saying that we don't want to pass objects by value.
>
> So why not just ban passing classes by value?  That is, the following code
> would be illegal:
> class Foo {};
> int myFunc(Foo pass_by_value) {...}
> it would give an error:
> ERROR: Class objects cannot be passed by value.
> They must be passed by pointer instead.
>
> Likewise, any code that required copying a class by value would be
> illegal.  Offhand, I can think of:
> * Class values as function parameters
> * Class values as function return values
> * Direct object assignments

That is an option but I think it would be one of last resort. A type should
be usable by itself - if taking pointers to something is required in order
to make it useful then that should be built into the type. Also by building
reference semantics into object you avoid silly typedefs like
typedef Window_t* Window;
I dislike C/C++ code that hides pointers behind typedefs. The typedef only
becomes usable when it has some obvious naming convention like WindowRef and
at that point WindowRef is pretty much the same as Window_t* so why bother.

>>>3) Made it so that class objects can't be on the stack.  Let's be honest, here, the whole reason that we have 'auto' is a kludge to get around the syntax problem.
>>
>> I'm with Walter (and Java/C#) that class objects on the stack should be rare. If there are issues with structs that require lots of auto classes then structs need attention. Actually auto classes don't have anything to do with being on the stack - they just force the dtor to be called on scope exit. IMO I haven't seen a D class that should be auto (I've seen good uses auto variables but declaring a class as auto forces all uses to be auto).
>
> I agree that the vast majority of class objects should be on the heap. But why require it?

Make the most common use cases easy and the rest reasonable and you'll have happy users. Conceptual baggage from other languages is a concern but it can be handled through documentation and examples comparing one to the other.

> BTW, similar to this is the problem that you can't have a global class object without having to initialize it in an init() function.
>
>>>4) Invited confusion over === and ==
>>
>> Agreed - though the current design isn't unreasonable in the big picture.
>
> :)


April 29, 2005
> Say that you want to store a pointer to a type in a template struct.  Do you do this?
> 	struct RefTo(T) {
> 	  T reference;
> 	}
> which works for classes, or this
> 	struct RefTo(T) {
> 	  T *pointer;
> 	}
> which works for structs?  Sure, you can do specialized templates, but that's a kludge to work around the problem, IMHO.

You declare this:

/// @brief Struct with reference.
///
/// Dear user. Please use only reference types
/// (objects or pointers) for T. Thank you.
///
struct RefTo(T)
{
  T reference;
}

And then this:

class Klasse { ... }
struct Struktur { ... }

RefTo!(Klasse) klasseRef;
RefTo!(Struktur*) strukturRef;

Does even have the same semantics:

klasseRef.store(new Klasse);
strukturRef.store(new Struktur);


Ciao
uwe
April 29, 2005
Ben Hinkle wrote:

> 
> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:d4tgj7$usv$1@digitaldaemon.com...
>> Ben Hinkle wrote:
>>>>>MATLAB uses "." independent of value/reference semantics and it works fine. The difference between value/reference only shows up in assignment behavior (which is the definition of value/reference anyway). But then MATLAB also doesn't have pointers.
>>>>
>>>>IMHO, getting rid of -> and just using . was a good idea, but that is a different question.
>>>>
>>>>I, like the others (it's nice to know I'm not alone) don't like the current syntax.  I've stated before my beefs with it:
>>>>
>>>>1) Makes it hard to write a template that handles both struct pointers and object references correctly.
>>>
>>> I'm not sure what you are referring to. Can you give a pointer to a post or examples?
>>
>> Say that you want to store a pointer to a type in a template struct.  Do
>> you do this?
>> struct RefTo(T) {
>>   T reference;
>> }
>> which works for classes, or this
>> struct RefTo(T) {
>>   T *pointer;
>> }
>> which works for structs?  Sure, you can do specialized templates, but
>> that's a kludge to work around the problem, IMHO.
> 
> When you said "template that handles struct pointer and objects refs" I
> thought you meant
>   struct RefTo(T) {
>    T bar;
>   }
>   RefTo!(Object) blah;
>   RefTo!(MyStruct*) blah2;
> The same template RefTo should be usable by anything with reference
> semantics (which both struct ptrs and object refs have). I agree sometimes
> you have to write two templates if you want to use it both with a type
> with value semantics and with a type with reference semantics. But that's
> only logical. For the particular case of "RefTo" I'm not sure what the
> point is but I'd say leave it as one template and make users explicitly
> take a reference to the structs since that's how structs in D behave -
> trying to make D structs act like they have reference semantics will
> result in confusing and clunky code IMO.
> 
>>>>2) Leads to a very common newbie error: segfault because he used an uninitialized class reference.  (If we had used C++ syntax, then Java programmers would have had a learning curve...but their error would be caught at build time, not as a runtime error, which, IMHO, is far superior)
>>>
>>> IMO better segv than slicing objects passed by value. Any non-trivial class hierarchy is destined to be manipulated by reference.
>>
>> I half agree and half disagree.  I think that Walter made a very good point when he said that copy constructors are trouble; you are making a similar point by saying that we don't want to pass objects by value.
>>
>> So why not just ban passing classes by value?  That is, the following
>> code would be illegal:
>> class Foo {};
>> int myFunc(Foo pass_by_value) {...}
>> it would give an error:
>> ERROR: Class objects cannot be passed by value.
>> They must be passed by pointer instead.
>>
>> Likewise, any code that required copying a class by value would be
>> illegal.  Offhand, I can think of:
>> * Class values as function parameters
>> * Class values as function return values
>> * Direct object assignments
> 
> That is an option but I think it would be one of last resort. A type
> should be usable by itself - if taking pointers to something is required
> in order to make it useful then that should be built into the type. Also
> by building reference semantics into object you avoid silly typedefs like
> typedef Window_t* Window;
> I dislike C/C++ code that hides pointers behind typedefs. The typedef only
> becomes usable when it has some obvious naming convention like WindowRef
> and at that point WindowRef is pretty much the same as Window_t* so why
> bother.
> 
>>>>3) Made it so that class objects can't be on the stack.  Let's be honest, here, the whole reason that we have 'auto' is a kludge to get around the syntax problem.
>>>
>>> I'm with Walter (and Java/C#) that class objects on the stack should be rare. If there are issues with structs that require lots of auto classes then structs need attention. Actually auto classes don't have anything to do with being on the stack - they just force the dtor to be called on scope exit. IMO I haven't seen a D class that should be auto (I've seen good uses auto variables but declaring a class as auto forces all uses to be auto).
>>
>> I agree that the vast majority of class objects should be on the heap. But why require it?
> 
> Make the most common use cases easy and the rest reasonable and you'll have happy users.
Right. But language also must avoid dangerous cases and possibilities to
make hard-to-find bugs. This is why constructions like if(x=y) does not
allowed in D. In my opinion reference/value ambiguous introduces such
cases.
One can use RefTo!(MyStruct) by mistake - compiler will say nothing.
One can try to pass class for template designed for value-types - compiler
will say nothing.
One can forget about COW technology - compiler will say nothing.
(BTW, can one write a transparent COW wrapper for dynamic arrays in D ? In
C++ this is easy).
Just imagine how many work must be done to convert existing struct into
class or vise versa. And compiler will never help here.

> Conceptual baggage from other languages is a concern but
> it can be handled through documentation and examples comparing one to the
> other.
Absolutely agree.

> 
>> BTW, similar to this is the problem that you can't have a global class object without having to initialize it in an init() function.
>>
>>>>4) Invited confusion over === and ==
>>>
>>> Agreed - though the current design isn't unreasonable in the big picture.
>>
>> :)

-- 
          Vladimir
April 29, 2005
>>> I agree that the vast majority of class objects should be on the heap. But why require it?
>>
>> Make the most common use cases easy and the rest reasonable and you'll have happy users.
> Right. But language also must avoid dangerous cases and possibilities to make hard-to-find bugs. This is why constructions like if(x=y) does not allowed in D. In my opinion reference/value ambiguous introduces such cases.

Sure that's legit opinion to have, but one has to weigh the upsides vs the downsides and on Walter's balance the upsides outweigh the downsides. Other people will use different weights and considerations and have different conclusions.

> One can use RefTo!(MyStruct) by mistake - compiler will say nothing.
> One can try to pass class for template designed for value-types - compiler
> will say nothing.

It will say nothing if the template makes sense - it depends on the template. Some would say it's a feature to allow templates to take any type and as long as it compiles it is ok. Restricting template parameters allows more control if the template author wishes.

> One can forget about COW technology - compiler will say nothing.

It's a trade-off, that's true. Sometimes you want COW and sometimes you don't.

> (BTW, can one write a transparent COW wrapper for dynamic arrays in D ? In
> C++ this is easy).

I assume you are referring to the lack of overloadable assignment to keep track of reference counts, corrent? To me that's a slightly different issue than reference/value semantics. Besides with dynamic arrays sometimes one wants to explicitly not use COW (eg filling in a buffer supplied to a function). Will D someday get some sort of overloadable assignment? Who knows - I personally don't have a strong argument against it but then again I don't miss it.

> Just imagine how many work must be done to convert existing struct into class or vise versa. And compiler will never help here.

I'm not sure what you mean here. Do you mean convert an existing C++ struct/class to D? Or do you mean a D struct that later becomes a class? I've found it's very easy to replace things like MyStruct* with MyClass or vice versa. Anything that uses MyStruct with value semantics needs attention when converted to using reference semantics but that's to be expected since that's pretty much the whole points of structs vs classes.


April 29, 2005
"Kyle Furlong" <ky220@umail.ucsb.edu> wrote in message news:d4sr93$1ik8$2@digitaldaemon.com...
> Are you willing to let someone redesign the D website, Walter?

If someone is willing to do a front page, I'm open minded about adopting it. It needs to have the following characteristics, though:

1) no javascript, no flash, no ActiveX, no Java, no scripts, etc. The page
should work for those who have all that stuff turned off for security
reasons.
2) be search engine friendly
3) be accessible to those who use text-to-speech programs (this and (2) are
flip sides of the same coin)
4) not be fixed size - meaning it should work on small screens as well as
large ones
5) not use fixed font sizes. Visually impaired people should be able to make
the fonts bigger.
6) load fast. This means no large graphics files.
7) be hand-edittable.


April 29, 2005
"Uwe Salomon" <post@uwesalomon.de> wrote in message news:op.spz368oi6yjbe6@sandmann.maerchenwald.net...
> You declare this:
>
> /// @brief Struct with reference.
> ///
> /// Dear user. Please use only reference types
> /// (objects or pointers) for T. Thank you.
> ///
> struct RefTo(T)
> {
>    T reference;
> }

You can build that restriction into the template!

struct RefTo(T:Object)
{
    T reference;
}

struct RefTo(T: T*)
{
    T* reference;
}

    RefTo!(int *) X;    // works
    RefTo!(int) Y;    // fails


April 29, 2005
Walter wrote:

> 
> "Vladimir" <kv11111@mail.ru> wrote in message news:d4qvmu$114p$2@digitaldaemon.com...
>> Matthias Becker wrote:
>>
>> > Bad library, not even the basic collections you find everywhere. So D is unusable in any kind of project.
>> >
>> >
>> > A few C++ programmers see things like built in hash-tables and ask why
> the
>> > languages is bloated with stuff like that, which could be done in the library and then don't even give it a try.
>> That was my first feeling after reading intro on digitalmars site.
> Benefits
>> described here seems not convincingly for me.
> 
> The text can always be improved. What would be a convincing intro be for you?


First informative link from front page is a link to comparation table. First look at this table shows that D has more features than others. But more detailed look shows that many of this features are not missing in other languages but raser implemented as libraries. Reasons for doing it in compiler are not described here.

It's not obvious that moving a big part of library into compiler is good. Many people even convinced that this is evil, and have a reasons for it. So, if doing so, *very* *good* description of it's benefits must be written and placed just beside saying thad D has built-in dynamic and assosiative arrays. Without it a lot of C/C++ programmers just stop reading here.

The most confusing section is about arrays. Reading page "D Strings vs C++
Strings" which is linked from here one can agree
that C++ STL library is far from ideal, and some changes to compiler (such
as adding overloadable ~ operator) are also helpful, but there is no reason
to built-in library into compiler.
As for me, more convincing points is possible optimizations, more standard
implementation (no more difference between STL string, QT QString, and many
others), reference semantics, but these all are at the bottom of the page.

Absence of "How Garbage Collection Works" part is also bad. For many C/C++
programmers GC is associated with java/C# and VMs which are slow. Section
"How Garbage Collection Works" is the only chance to be convinces that this
really can be not-so-slow (especially for those who does not belive
advertisements). May be adding this link:
http://www.iecc.com/gclist/GC-faq.html
and even this:
ftp://ftp.cs.utexas.edu/pub/garbage/gcsurvey.ps
would be helpful.


-- 
          Vladimir
April 29, 2005
Vladimir wrote:
> Walter wrote:
...

>>The text can always be improved. What would be a convincing intro be for
>>you?
> 
> 
> 
> First informative link from front page is a link to comparation table. First
> look at this table shows that D has more features than others. But more
> detailed look shows that many of this features are not missing in other
> languages but raser implemented as libraries. Reasons for doing it in
> compiler are not described here.

Listen, he admits in the first paragraph he's counting what's available in each language. Most people expect that the items in such a comparison list are going to be selected to favor the language being endorsed.

Also, if someone has to be told that it might be a lot cooler to have a feature built-in as opposed to hacked-in, they may not be a programmer.

I believe much of this has already been discussed to death back while Walter first released the comparison chart.

...

> The most confusing section is about arrays. Reading page "D Strings vs C++
> Strings" which is linked from here one can agree
> that C++ STL library is far from ideal, and some changes to compiler (such
> as adding overloadable ~ operator) are also helpful, but there is no reason
> to built-in library into compiler.
> As for me, more convincing points is possible optimizations, more standard
> implementation (no more difference between STL string, QT QString, and many
> others), reference semantics, but these all are at the bottom of the page.
> 


> Absence of "How Garbage Collection Works" part is also bad. For many C/C++

Ah, the " To be written..." section on the garbage collection page (http://www.digitalmars.com/d/garbage.html). You're right -- it should either be filled in or dropped. If I had seen that before I forgot about it.

> programmers GC is associated with java/C# and VMs which are slow. Section
> "How Garbage Collection Works" is the only chance to be convinces that this
> really can be not-so-slow (especially for those who does not belive
> advertisements). May be adding this link:
> http://www.iecc.com/gclist/GC-faq.html
> and even this:
> ftp://ftp.cs.utexas.edu/pub/garbage/gcsurvey.ps
> would be helpful.

I think part of the animosity against GC is religious in nature and the only solution for such a problem is prayer by those who are adherents of the "one true religion". At least Microsoft is on our side now with GC. Every time one of their acolytes extols the virtue of "managed code" they're endorsing D. Here's a new slogan for D: "Get the nearly the same memory leak protection without requiring users to download the large .NET  framework." ;)


-- 
jcc7
http://jcc_7.tripod.com/d/