View mode: basic / threaded / horizontal-split · Log in · Help
May 13, 2012
Getting the const-correctness of Object sorted once and for all
http://d.puremagic.com/issues/show_bug.cgi?id=1824

This has gone on for too long.

Object.toString, .toHash, .opCmp and .opEquals should all be const.  (It's also been 
stated somewhere that they should be pure and nothrow, or something like that, but I 
forget where.)

This makes it a nightmare to use const objects in data structures, among other things, at 
best forcing the use of ugly workarounds.  There are probably other, more serious effects 
of this that can't easily be worked around.

It seems that the main obstacle is rewriting the relevant methods in std.stream.  The 
current implementation doesn't make sense anyway - reading the entire contents of a file 
is certainly not the way to generate a hash or string representation of the stream.  I'm 
thinking the hash should probably be the stream handle, and the string representation 
could perhaps be the full pathname of the file.  Of course, what it should be for non-file 
streams is another matter.  (This would be a change at the API level, but when the API's 
as fundamentally flawed as this....)

Are there any other bits of druntime/Phobos that need to be sorted out before these 
methods can be declared const/pure/nothrow once and for all?

Stewart.
May 13, 2012
Re: Getting the const-correctness of Object sorted once and for all
On 13-05-2012 18:39, Stewart Gordon wrote:
> http://d.puremagic.com/issues/show_bug.cgi?id=1824
>
> This has gone on for too long.
>
> Object.toString, .toHash, .opCmp and .opEquals should all be const.
> (It's also been stated somewhere that they should be pure and nothrow,
> or something like that, but I forget where.)
>
> This makes it a nightmare to use const objects in data structures, among
> other things, at best forcing the use of ugly workarounds. There are
> probably other, more serious effects of this that can't easily be worked
> around.
>
> It seems that the main obstacle is rewriting the relevant methods in
> std.stream. The current implementation doesn't make sense anyway -
> reading the entire contents of a file is certainly not the way to
> generate a hash or string representation of the stream. I'm thinking the
> hash should probably be the stream handle, and the string representation
> could perhaps be the full pathname of the file. Of course, what it
> should be for non-file streams is another matter. (This would be a
> change at the API level, but when the API's as fundamentally flawed as
> this....)
>
> Are there any other bits of druntime/Phobos that need to be sorted out
> before these methods can be declared const/pure/nothrow once and for all?
>
> Stewart.

I agree with everything but toString(). I'm afraid that forcing 
toString() to be const will have harm flexibility severely. Can't we do 
better, somehow?

-- 
- Alex
May 13, 2012
Re: Getting the const-correctness of Object sorted once and for all
On 13/05/2012 17:41, Alex Rønne Petersen wrote:
<snip>
> I agree with everything but toString(). I'm afraid that forcing toString() to be const
> will have harm flexibility severely. Can't we do better, somehow?

How exactly?

If you're talking about memoization, it ought to be possible to make use of 
std.functional.memoize to implement it.

Otherwise, using toString to change the state of an object is bending semantics.  If you 
want a method to generate a string representation of an object in a way that might do 
this, then create your own method to do it.

Stewart.
May 13, 2012
Re: Getting the const-correctness of Object sorted once and for all
On 13-05-2012 19:02, Stewart Gordon wrote:
> On 13/05/2012 17:41, Alex Rønne Petersen wrote:
> <snip>
>> I agree with everything but toString(). I'm afraid that forcing
>> toString() to be const
>> will have harm flexibility severely. Can't we do better, somehow?
>
> How exactly?
>
> If you're talking about memoization, it ought to be possible to make use
> of std.functional.memoize to implement it.
>
> Otherwise, using toString to change the state of an object is bending
> semantics. If you want a method to generate a string representation of
> an object in a way that might do this, then create your own method to do
> it.
>
> Stewart.

But how would you memoize the value in the instance of the object if 
it's const?

-- 
- Alex
May 13, 2012
Re: Getting the const-correctness of Object sorted once and for all
On 13/05/2012 18:04, Alex Rønne Petersen wrote:
<snip>
> But how would you memoize the value in the instance of the object if it's const?

By storing the memoized value outside of the object.  Read the code of 
std.functional.memoize - you'll see that it holds the values in a static AA.

Stewart.
May 13, 2012
Re: Getting the const-correctness of Object sorted once and for all
On 13-05-2012 19:27, Stewart Gordon wrote:
> On 13/05/2012 18:04, Alex Rønne Petersen wrote:
> <snip>
>> But how would you memoize the value in the instance of the object if
>> it's const?
>
> By storing the memoized value outside of the object. Read the code of
> std.functional.memoize - you'll see that it holds the values in a static
> AA.
>
> Stewart.

Which forces you to:

1) use an AA lookup
2) use the GC

Not an optimal solution IMHO.

-- 
- Alex
May 13, 2012
Re: Getting the const-correctness of Object sorted once and for all
On 13/05/2012 18:53, Alex Rønne Petersen wrote:
<snip>
> Which forces you to:
>
> 1) use an AA lookup
> 2) use the GC
>
> Not an optimal solution IMHO.

But you're going to need to use the GC anyway.  How else are you going to store the string?

Memoization is a form of laziness.  This concept applies to the allocation of memory to 
hold the result as much as to the actual calculation of the result.

Stewart.
May 13, 2012
Re: Getting the const-correctness of Object sorted once and for all
On 13-05-2012 21:11, Stewart Gordon wrote:
> On 13/05/2012 18:53, Alex Rønne Petersen wrote:
> <snip>
>> Which forces you to:
>>
>> 1) use an AA lookup
>> 2) use the GC
>>
>> Not an optimal solution IMHO.
>
> But you're going to need to use the GC anyway. How else are you going to
> store the string?

malloc? (And free it in the destructor or whatever - depends on your 
manual memory management approach.)

>
> Memoization is a form of laziness. This concept applies to the
> allocation of memory to hold the result as much as to the actual
> calculation of the result.
>
> Stewart.

-- 
- Alex
May 13, 2012
Re: Getting the const-correctness of Object sorted once and for all
On 5/13/2012 9:39 AM, Stewart Gordon wrote:
> It seems that the main obstacle is rewriting the relevant methods in std.stream.
> The current implementation doesn't make sense anyway - reading the entire
> contents of a file is certainly not the way to generate a hash or string
> representation of the stream. I'm thinking the hash should probably be the
> stream handle, and the string representation could perhaps be the full pathname
> of the file. Of course, what it should be for non-file streams is another
> matter. (This would be a change at the API level, but when the API's as
> fundamentally flawed as this....)

I'd like to see std.stream dumped. I don't see any reason for it to exist that 
std.stdio doesn't do (or should do).

The only reason it's there at the moment is for backwards compatibility.
May 13, 2012
Re: Getting the const-correctness of Object sorted once and for all
On Sunday, 13 May 2012 at 19:43:19 UTC, Walter Bright wrote:
> On 5/13/2012 9:39 AM, Stewart Gordon wrote:
>> It seems that the main obstacle is rewriting the relevant 
>> methods in std.stream. The current implementation doesn't make 
>> sense anyway - reading the entire contents of a file is 
>> certainly not the way to generate a hash or string 
>> representation of the stream. I'm thinking the hash should 
>> probably be the stream handle, and the string representation 
>> could perhaps be the full pathname of the file. Of course, 
>> what it should be for non-file streams is another matter. 
>> (This would be a change at the API level, but when the API's 
>> as fundamentally flawed as this....)
>
> I'd like to see std.stream dumped. I don't see any reason for 
> it to exist that std.stdio doesn't do (or should do).
>
> The only reason it's there at the moment is for backwards 
> compatibility.

 Recently in my own code I've started making use of std.stream, 
mostly creating temporary string streams to test IO in functions 
that would otherwise need actual files for unittests.

 Glancing over std.stdio, I only see specific file access 
functions and routines. If I'm doing the wrong approach please 
correct me now.

---
import std.stream;

struct Header {
  char[4] name;
  int size;

  int read(InputStream is_in) {
    is_in.readExact(name.ptr, name.sizeof);
    is_in.read(size);
    return this.sizeof;
  }

  int write(OutputStream os_out) {
    os_out.writeExact(name.ptr, name.sizeof);
    os_out.write(size);
    return this.sizeof;
  }

  unittest {
    ubyte[Header.sizeof] buffer;
    auto buff_stream = new TArrayStream!(ubyte[])(buffer);

    Header x = Header("abcd", 1024);
    x.write(buff_stream);
    assert(buffer == [97, 98, 99, 100, 0, 4, 0, 0]);

    buff_stream.seekSet(0);
    x = Header();

    assert(x.size == 0);
    x.read(buff_stream);
    assert(x.name == "abcd");
    assert(x.size == 1024);
  }
}
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home