Ben Phillips wrote:
> In article <dubpge$u3r$1@digitaldaemon.com>, Johan Granberg says...
>>>> 1. const parameters and member functions
>>>>
>>>> Countless times this saved me. I just can't imagine references being
>>>> passed in and out of functions without something explicitly saying that
>>>> the function is expected or not to modify it.
>> You did not answer the above statement and i have seen this repeated all over this thread along with destructors in structs.
>>
> 
> A method can explicitly say that it will modify a reference by using "out" and
> "inout".
> 
> I've never cared much for const member methods, so I'm confused as to how a lack
> of them can cause such a problem. Can you give an example?
> 
> 
It is not const methods so much as const in parameters.

class A
{
 int bar=1;//bar should bee read only
}

void foo(in i a)//I want a to bee readonly
{
    i.bar=2;//here the value should not be writable but since a is
            //a reference it is
}

A a=new A;//bar is 1
foo(a);
print(a.bar);//prints 2

It is not so very usefull in smal examples but if you have a large program and do that by mistake it could cause a bug. Basicaly it is a message from the writer of a class to it's users of how member are to bee used, and aditionaly it has compiler suport to catch typos and mistakes, if a user realy want to change the data against the orginal authors recomendations he can use a explicit cast.

Johan Granberg wrote:
> Ben Phillips wrote:
> 
>> In article <dubpge$u3r$1@digitaldaemon.com>, Johan Granberg says...
>>
>>>>> 1. const parameters and member functions
>>>>>
>>>>> Countless times this saved me. I just can't imagine references being
>>>>> passed in and out of functions without something explicitly saying that
>>>>> the function is expected or not to modify it.
>>>
>>> You did not answer the above statement and i have seen this repeated all over this thread along with destructors in structs.
>>>
>>
>> A method can explicitly say that it will modify a reference by using "out" and
>> "inout".
>>
>> I've never cared much for const member methods, so I'm confused as to how a lack
>> of them can cause such a problem. Can you give an example?
>>
>>
> It is not const methods so much as const in parameters.
> 
> class A
> {
>  int bar=1;//bar should bee read only
> }

And why exactly should this be read only again? Maybe my primitive brain is completely underdeveloped rendering me incapable of grasping the concept. Nonetheless, it strikes me as only natural that if one wants something to be read only one would simply identify it as such:

class A
{
  const int bar=1; // bar IS read only
}

but maybe I'm missing something here. Reading on!!!

> void foo(in i a)//I want a to bee readonly
> {
>     i.bar=2;//here the value should not be writable but since a is
>             //a reference it is
> }
>
> A a=new A;//bar is 1
> foo(a);
> print(a.bar);//prints 2

Oh, I see, you want the in parameter to treat it as if it were read only. Rightly so. One should not be able to modify an "in" parameter (reference or otherwise). It is the implied behavior when using the in keyword, there it is only reasonable to expected it. I do not think this is a problem with the implementation of const however, but rather a glaring defect in the implementation of "in".

> It is not so very usefull in smal examples but if you have a large program and do that by mistake it could cause a bug. Basicaly it is a message from the writer of a class to it's users of how member are to bee used, and aditionaly it has compiler suport to catch typos and mistakes, if a user realy want to change the data against the orginal authors recomendations he can use a explicit cast.

Andrew

Johan Granberg wrote:
> Derek Parnell wrote:
> 
>>> 2. as far as I know no way of inporting somthing in a parent directory (as C++ #include "../myheader.hpp")
>>
>>
>> You can, only its not coded in the source file. Instead you do this via the compiler's "-I" switch.
>>
> 
> Yes it can bee worked around but it's frustrating to have to add a lot of -I by hand to the compiler. It realy complicates keeping a simple makefile.
> 
> An example.
> 
> foo/bar/ff.d
> foo/gg.d
> rr.d
> 
> gg.d imports ff.d with the command import bar.ff;
> rr.d imports gg.d using import foo.d; but now you cant just compile rr.d because the compiler does not find ff.d.
> 
> I realise that my orgina formulation was not so clear. actualy it is not specificaly import from parent dir I want but import relative to the source files dir instead of the dir where the compiler is invoked.
> 
> consider the diference of thees c++ includes
> 
> #include "foo.h" // includes relative to the sourcefiles dir and if that fails in the current path
> 
> #include <foo.h> //includes from path
> 
> and D's import
> 
> import foo; // imports from the search path with the compiler flag -I. added
> 
> wath I want is somthing like the first c++ statement ie an include relative to the sourcefiles location.


The *correct* way of doing it is naming your modules according to the directory structure.


----- foo/bar/ff.d ----
module foo.bar.ff;
//rest of file

----- foo/gg.d --------
module foo.gg;
//test of file

----- rr.d ------------
module rr;
//rest of file

now if you want to import rr.d from foo.bar.ff

-----foo/bar/ff.d----
module foo.bar.ff;
import rr;
//rest of file

I think this should work!
When you compile, you have to make sure that the working directory is where rr.d resides.

In article <dudpqv$1otp$1@digitaldaemon.com>, Hasan Aljudy says...
>The *correct* way of doing it is naming your modules according to the directory structure.
>
>
>----- foo/bar/ff.d ----
>module foo.bar.ff;
>//rest of file
>
>----- foo/gg.d --------
>module foo.gg;
>//test of file
>
>----- rr.d ------------
>module rr;
>//rest of file
>
>now if you want to import rr.d from foo.bar.ff
>
>-----foo/bar/ff.d----
>module foo.bar.ff;
>import rr;
>//rest of file
>
>I think this should work!
>When you compile, you have to make sure that the working directory is
>where rr.d resides.
>
>
>

I agree. I think there's no compelling reason to allow referencing files according to the relative path of the current module. In fact, I think the current behaviour enforces a more organized development structure.

--
Sebastián.

Dave schrieb am 2006-03-05:
> In article <op.s5wvjbrq6b8z09@ginger.vic.bigpond.net.au>, Derek Parnell says...
>>
>>Walter,
>>I know you are a busy person and this might have been missed, so I repeat
>>the question for you.
>>
>>On Sat, 04 Mar 2006 15:02:35 +1100, Walter Bright
>>  <newshound@digitalmars.com> wrote:
>>
>>> The private/protected stuff works like it does in C++.
>>
>>  I'm not a C++ person so excuse my ignorance please, but are you saying
>>  that fully qualified references in C++ will override private/protected
>>  attributes? It does this in D.
>>
>>  //--- foo.d --
>>  private void Foo() { }
>>
>>  // --------------
>>
>>  //--- test.d --
>>  import foo;
>>  void main()
>>  {
>>      foo.Foo(); // Compiles!
>>      Foo();  // Doesn't compile.
>>  }
>>
>
> Has this been reported as a bug over in D.bugs?

http://dstress.kuehne.cn/www/dstress.html#private_12_B

Thomas

On Sat, 04 Mar 2006 23:18:00 -0500, Tyro <ridimz_at@yahoo.dot.com> wrote:
> Oh, I see, you want the in parameter to treat it as if it were read only. Rightly so. One should not be able to modify an "in" parameter (reference or otherwise). It is the implied behavior when using the in keyword, there it is only reasonable to expected it. I do not think this is a problem with the implementation of const however, but rather a glaring defect in the implementation of "in".

One cannot modify an "in" parameter. All "in" parameters are copied in, in other words the parameter inside the function is always a copy of the variable passed. The 'key' issue here is realising what you're passing. When you pass a 'reference' the variable is the 'reference' itself, _not_ the data to which it refers. Therefore the 'reference' is what is copied in and what is protected by "in". "in" makes no guarantee to protect the data to which that reference refers.

I think we can all agree that having some way to declare a function is not going to perform any sort of write operation using a passed reference and having the compiler protect this accidentally happening would be a good thing. The problem is how to achieve that, see the many previous "const" and "readonly" threads for a detailed discussion of why it's not so simple to solve.

Regan

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:dudept$19qp$1@digitaldaemon.com...
> And in D, f(x) can be visually ambiguous as well - is the parameter in, out, or inout?

At least you know it's a function call, rather than a declaration of x of type f!

On Sat, 4 Mar 2006, Walter Bright wrote:

> "Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:dudept$19qp$1@digitaldaemon.com...
> > And in D, f(x) can be visually ambiguous as well - is the parameter in, out, or inout?
> 
> At least you know it's a function call, rather than a declaration of x of type f!

I've been trying to figure out when to say something on this topic since I fully understand just how difficult a topic const/immutability is and I know it's been thrashed around for years now.  That said, I think it's a seriously important feature for the safety and maintainability of code.

I view constness as one major aspect of contracts.  A function specifying that 'I will not alter the data you send me, and by implication neither will anything below me' give a major boost to the maintainability of a system.  A human writing that in a comment is totally insufficient.  The author could be wrong about a called function or a future change could invalidate the claim.  The language (and by implication the compiler) must support this guarantee.  As an asside, having such guarantees also gives the optimizer a boost in that it now has much more freedom to restructure code by knowing more.

I fully realize that C++'s const are incomplete.  I also don't personally have a full understanding of how to actually implement such protections. For now, let's not get caught up with the implementation specifics but rather defined semantics.

I want to be clear though, I'm not talking about const-ness of an instance, but of the barrier between callee and caller.

Make sense?

Later,
Brad

On Sun, 05 Mar 2006 20:14:06 +1100, Brad Roberts <braddr@puremagic.com> wrote:

> I want to be clear though, I'm not talking about const-ness of an
> instance, but of the barrier between callee and caller.
>
> Make sense?

Yes.


-- 
Derek Parnell
Melbourne, Australia

Thomas Kuehne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Dave schrieb am 2006-03-05:
>> In article <op.s5wvjbrq6b8z09@ginger.vic.bigpond.net.au>, Derek Parnell says...
>>> Walter,
>>> I know you are a busy person and this might have been missed, so I repeat  the question for you.
>>>
>>> On Sat, 04 Mar 2006 15:02:35 +1100, Walter Bright
>>>  <newshound@digitalmars.com> wrote:
>>>
>>>> The private/protected stuff works like it does in C++.
>>>  I'm not a C++ person so excuse my ignorance please, but are you saying
>>>  that fully qualified references in C++ will override private/protected
>>>  attributes? It does this in D.
>>>
>>>  //--- foo.d --
>>>  private void Foo() { }
>>>
>>>  // --------------
>>>
>>>  //--- test.d --
>>>  import foo;
>>>  void main()
>>>  {
>>>      foo.Foo(); // Compiles!
>>>      Foo();  // Doesn't compile.
>>>  }
>>>
>> Has this been reported as a bug over in D.bugs?
> 
> http://dstress.kuehne.cn/www/dstress.html#private_12_B
> 
> Thomas
> 
> 
> -----BEGIN PGP SIGNATURE-----
> 
> iD8DBQFECpUf3w+/yD4P9tIRAsRUAJ9V1GJH/jywtb2qYecacqsJO7zP2QCeJGJ/
> 7qzapVal6/Jdtkbg/siH8og=
> =Ccdp
> -----END PGP SIGNATURE-----

Oops, this means I reported the bug twice. :/ Maybe it is time to look in that bugzilla.
But anyway, does you assigning it a test case make it an officially recognized bug?


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D