On Mon, 11 Sep 2006 12:51:12 +0200, Lutger <lutger.blijdestijn@gmail.com> wrote:

>Well said. I needed some time to adjust to the reference semantics of classes in D and it's less (than C++) capable struct type. But now I'm used to it, it really makes sense.

Yeah, I'm still adjusting too. Too used to being able to use inheritance to create extended structs in C++. Less bothered by having references for objects because I've done that before, but I still don't like having a tool taken out of my toolkit ;-)

In code I'm writing at the moment, it's an issue, but a minor one. D has saved probably ten or more units of effort for this one that it has created. So while I made the relevant suggestions and defended them, it's probably not a big deal IMO.

At the moment, I'm having trouble with interfaces. I can't seem to get the right patterns for using them.

This is one of the things with a new language. Picking up the new syntax and semantics may not seem that hard, but putting it to work in a real project can be a pain - you end up in a refactoring loop, chasing your own tail until you find the patterns that work in that language.

Even though I've use C# enough times that I thought I'd have no problems with D, the C# stuff I've done was pretty small stuff really.

-- 
Remove 'wants' and 'nospam' from e-mail.

Sean Kelly wrote:
> Kristian wrote:
> 
>>
>> Hmm, what if structures could have interfaces and constructors/destructors... and what the heck, inheritance too? Hehheh, this way we would have 'physical classes' for local use and 'reference classes' for global use.
> 
> 
> It will never happen :-)  Though ctor support would be nice, at the very least.  That would simplify initialization and eliminate the need for the static opCall trick.
> 
> 
> Sean

There is no technical reason struct (or anything that can produce a delegate) can't do interfaces. Inheritance on the other hand... I hope that never happens.

BCS wrote:
> Sean Kelly wrote:
>> Kristian wrote:
>>
>>>
>>> Hmm, what if structures could have interfaces and constructors/destructors... and what the heck, inheritance too? Hehheh, this way we would have 'physical classes' for local use and 'reference classes' for global use.
>>
>>
>> It will never happen :-)  Though ctor support would be nice, at the very least.  That would simplify initialization and eliminate the need for the static opCall trick.
>>
>>
>> Sean
> 
> There is no technical reason struct (or anything that can produce a delegate) can't do interfaces. Inheritance on the other hand... I hope that never happens.

Wouldn't it add a hidden __vtbl to your struct and thereby increasing its size?

L.

On Mon, 11 Sep 2006 01:23:38 +0300, Steve Horne <stephenwantshornenospam100@aol.com> wrote:
[snip]
>> Really? I mean, a common source of bugs? But isn't it be simple to fix
>> such bugs, just correct the copy methods?
>
> I suspect this is about accidental copying. Parameter passing,
> implicit conversions, unexpected temporaries etc.

Yes, these things could cause harm. I have had a few incidents with unxcepted temporaries (only few fortunately).

[snip]
> Maybe it's something to do with the real world. It's just natural to
> work with existing objects - not duplicates of those objects. When I
> was told to clean my room as a child, I don't think stories about
> duplicating the room, cleaning the duplicate and discarding it would
> have worked ;-)
>
> With 'values' - numbers etc - copy semantics seem more sane. In
> algebra, calculating the unknowns does not alter the known values.
> Outputs are based on inputs, not the other way around. Even feedback
> has a time delay - the calculation of the output doesn't change its
> input, it just provides a new input for the next millisecond or
> whatever.
>
> The trouble is, this is all subjective. The Python one-size-fits-all
> everythings-an-object-with-a-reference approach will probably always
> bug me, but a lot depends on what you're used to.

Well said. Usually (I think/hope) objects are 'unique' with no need to copy them. You just have to adjust your thinking.

However, sometimes 'working objects' are needed in calculations. But, as said, structures are for that. I am just wondering that should structures indeed have constructors and destructors. It would allow one to create more complex data types. Probably interfaces wouldn't hurt either.

And another thing that I have no clear grasp yet is unability to copy/clone class objects. For example:

class Obj;

void func(Obj obj) {
    Obj tmp;

    tmp.clone(obj);
    //modify 'tmp'
    ...
    //use 'tmp' instead of 'obj'
    ...
}

Or you just need to store objects for later use.
These things cannot be done currently. How often that would be necessary, in practice? (Once is enough to give you gray hair...?)

On Sun, 10 Sep 2006 23:48:22 +0300, Reiner Pope <reiner.pope@REMOVE.THIS.gmail.com> wrote:

> Kristian wrote:
>> On Sun, 10 Sep 2006 18:59:34 +0300, Sean Kelly <sean@f4.ca> wrote:
>>> Kristian wrote:
>>>> And, I hope that D will have a 'const' type specifier in the future.
[snip]
>>>
>>> Don't we all.  But wanting it and coming up with a solid proposal for how it should work are entirely different issues, unfortunately.
>>  Well, what's wrong with the way C++ does it?
[snip]
> Do some searching for 'const' and 'readonly' on this NG, and you should get the idea:
>   - C++ const is ugly, so people don't use it enough;
>   - const_cast removes the safety guarantees of const, making const-directed optimizations by the compiler impossible.
>   - overloading by const requires duplication of code.
>   - a trivial const system like C++ is too strict and may require unnecessary clones to avoid a static const violation, thus necessitating the need for const_cast
>   - reference immutability (C++'s 'readonly view') is only one form of const, and can't guarantee other (important) immutability contracts
>   - after such a problems, the merits are not so clear, since the usefulness can only really be attributed to two things:
>      1. Standardising documentation of variable usage.
>      2. Getting the compiler to help catch programmer errors.
>    and some people claim that they have never found any bugs by using const.

There are a lot of talk about const/readonly/immutability in the archives. I have to admit that I don't have the strenght to read them, so I didn't (yet anyway).

C++ const is better than nothing. Hopefully there will be a solution that will suit everybody, more or less.

C++ const has flaws, of course. Sometimes it's necessary to do non-const-casting inside a const member function. But 'const' tells that a function is logically const even if it's not physically (statically?) one. So for a programmer it's only documentation tool that a compiler can use to check for (some) programming errors. And as such it has been working fine, for me at least.

(I don't know what this C++ const ugliness means. 'const' is a wrong word, so I don't use it? ;) )

Lionello Lunesu wrote:
> BCS wrote:
> 
>> Sean Kelly wrote:
>>
>>> Kristian wrote:
>>>
>>>>
>>>> Hmm, what if structures could have interfaces and constructors/destructors... and what the heck, inheritance too? Hehheh, this way we would have 'physical classes' for local use and 'reference classes' for global use.
>>>
>>>
>>>
>>> It will never happen :-)  Though ctor support would be nice, at the very least.  That would simplify initialization and eliminate the need for the static opCall trick.
>>>
>>>
>>> Sean
>>
>>
>> There is no technical reason struct (or anything that can produce a delegate) can't do interfaces. Inheritance on the other hand... I hope that never happens.
> 
> 
> Wouldn't it add a hidden __vtbl to your struct and thereby increasing its size?
> 
> L.
No, because the type of a struct is always known, the required value for the interface's function table can be found at compile time and all that is needed is to attach it to a reference to the struct.

BCS wrote:
> Lionello Lunesu wrote:
>> BCS wrote:
>>
>>> Sean Kelly wrote:
>>>
>>>> Kristian wrote:
>>>>
>>>>>
>>>>> Hmm, what if structures could have interfaces and constructors/destructors... and what the heck, inheritance too? Hehheh, this way we would have 'physical classes' for local use and 'reference classes' for global use.
>>>>
>>>>
>>>>
>>>> It will never happen :-)  Though ctor support would be nice, at the very least.  That would simplify initialization and eliminate the need for the static opCall trick.
>>>>
>>>>
>>>> Sean
>>>
>>>
>>> There is no technical reason struct (or anything that can produce a delegate) can't do interfaces. Inheritance on the other hand... I hope that never happens.
>>
>>
>> Wouldn't it add a hidden __vtbl to your struct and thereby increasing its size?
>>
>> L.
> No, because the type of a struct is always known, the required value for the interface's function table can be found at compile time and all that is needed is to attach it to a reference to the struct.
I don't understand you. How would it work?

Suppose you had this code:

interface Foo
{
	int foo();
}

struct Bar : Foo
{
	int foo() { ... }
	...
}

void calc(Foo f) { ... }

How can calc know the type of every struct it is passed unless a separate version of calc is generated for every type (in which case it is just a template)?

Cheers,

Reiner

Steve Horne wrote:
> The trouble is, this is all subjective. The Python one-size-fits-all
> everythings-an-object-with-a-reference approach will probably always
> bug me, but a lot depends on what you're used to.
> 

Not sure I follow.  Python uses value semantics for numbers and strings.  The reason you get them for strings is that strings are immutable, so Python always creates a copy when a string is about to be changed.

So it works like in D, except for the strings.

On Tue, 12 Sep 2006 23:33:39 +0200, Tydr Schnubbis <fake@address.dude> wrote:

>Steve Horne wrote:
>> The trouble is, this is all subjective. The Python one-size-fits-all everythings-an-object-with-a-reference approach will probably always bug me, but a lot depends on what you're used to.
>> 
>
>Not sure I follow.  Python uses value semantics for numbers and strings.
>  The reason you get them for strings is that strings are immutable, so
>Python always creates a copy when a string is about to be changed.
>
>So it works like in D, except for the strings.

Sorry - I had a specific problem recently and got a bit annoyed and irrational. I've enough Python experience that I shouldn't have got confused this way, but I haven't used Python seriously for long enough that I did anyway :-(

Everything is an object with a reference. Some things are immutable, so it shouldn't matter. But...

>>> a=5
>>> b=lambda :a
>>> b()
5
>>> a=6
>>> b()
6

According to the definition of a closure, the lambda should bind the value of a. It can't bind a link to the variable, since the variable might not exist when the lambda is evaluated. Yet there is clearly some kind of by-reference binding, or else why does assigning a new value to 'a' cause 'b' to give a different result.

So why the above?

Well, maybe a minor bug. Maybe a command-line-only thing. I haven't investigated. I was only using Python as a calculator when I tripped over the problem.

D behaves similarly with anonymous functions and delegates, but that's because D inner functions etc don't support 'true' closures. In fact, D anonymous delegates aren't even valid after you leave the scope where they were defined. But that's not unexpected - a different convenience vs. efficiency trade-off. Python closures are supposed to be true closures.

-- 
Remove 'wants' and 'nospam' from e-mail.

On Tue, 12 Sep 2006 17:49:44 +0300, Kristian <kjkilpi@gmail.com> wrote:

>C++ const is better than nothing. Hopefully there will be a solution that will suit everybody, more or less.

As far as the meaning of 'const' goes, I agree. It represents a specific, restricted meaning of 'const'. Choosing a reasonable word for an intended meaning does not mean that all possible meanings of that word must be valid.

If you're going to fuss about keyword meanings, I'd focus on 'real', 'ireal' and 'creal'. 'Real' cannot handle irrational numbers, and it can't handle rationals properly either. It does not handle all possible meanings of 'real' - not even within a given range and precision, unless you define those terms in a floating-point specific way. And as for 'imaginary real' and 'complex real', the important phrase here is 'contradiction in terms'.

The keywords convey an intended meaning. It's a matter of common sense. Being too literal gets you no-where. Being an Aspie, I have plenty of experience of this :-(

But I have mixed feelings about C++ const. It has caught errors for me, but not often, and quite often those errors wouldn't exist without 'const' anyway. For instance...

class c_Test
{
  private:
    int m_Var;

  public:
//  int  Var () const  {  return m_Var;  }
    int& Var ()        {  return m_Var;  }
};

The point of this is the 'missing' method. You can read the value of m_Var if you have a non-const reference to c_Test. Mark that reference as const, and suddenly you can no longer do the needed read access - you have to go back and add the const overloaded access method.

Of course I understand the efficiency benefits, but it's not very intuitive. And there wouldn't have been any error using simple getter and setter functions instead of this C++ specific pattern.

What's more, you can end up chasing your tail. You start with a few const references. Then more and more things need a const tag or a const variant as a result. Member functions. References. Pointers. Member pointers.

Pointers even need to be told whether it is the pointer that is const or the value pointed to, or both for that matter.

So the dependencies mean you have three options...

1.  Make constness into something you think about all the time.
2.  Don't do constness at all.
3.  Do half-hearted constness and have loads of const-casts,
    defeating the point.

And then, your code has to work with someone elses... Someone who has a very different approach.

Personally, I tend towards case 1 - I can be a perfectionist at times. Trouble is, this can be a distraction from the real logic. And that can cause logical errors that wouldn't have happened if my attention hadn't been split.

D has been a bit of a relief, really.

-- 
Remove 'wants' and 'nospam' from e-mail.