Jump to page: 1 210  
Page
Thread overview
Getting the const-correctness of Object sorted once and for all
May 13, 2012
Stewart Gordon
May 13, 2012
Stewart Gordon
May 13, 2012
Stewart Gordon
May 13, 2012
Stewart Gordon
May 14, 2012
bearophile
May 14, 2012
Jakob Ovrum
May 14, 2012
Jakob Ovrum
May 13, 2012
Walter Bright
May 13, 2012
Era Scarecrow
May 13, 2012
Walter Bright
May 13, 2012
Stewart Gordon
May 13, 2012
Dmitry Olshansky
May 14, 2012
Dmitry Olshansky
May 14, 2012
Andrej Mitrovic
May 14, 2012
Dmitry Olshansky
May 14, 2012
H. S. Teoh
May 13, 2012
Walter Bright
May 13, 2012
H. S. Teoh
May 13, 2012
Jonathan M Davis
May 13, 2012
Mehrdad
May 13, 2012
Timon Gehr
May 13, 2012
Jonathan M Davis
May 13, 2012
Mehrdad
May 14, 2012
deadalnix
May 14, 2012
Mehrdad
May 14, 2012
deadalnix
May 14, 2012
Mehrdad
May 14, 2012
deadalnix
May 15, 2012
Jakob Ovrum
May 14, 2012
Era Scarecrow
May 14, 2012
Jonathan M Davis
May 14, 2012
Mehrdad
May 14, 2012
Era Scarecrow
May 14, 2012
Jonathan M Davis
May 14, 2012
Era Scarecrow
May 14, 2012
Walter Bright
May 14, 2012
Jonathan M Davis
May 14, 2012
Jonathan M Davis
May 14, 2012
Jonathan M Davis
May 14, 2012
Era Scarecrow
May 14, 2012
H. S. Teoh
May 14, 2012
Era Scarecrow
May 14, 2012
Walter Bright
May 14, 2012
Walter Bright
May 14, 2012
Mehrdad
May 14, 2012
John
May 14, 2012
Jonathan M Davis
May 14, 2012
Chris Cain
May 14, 2012
Mehrdad
May 14, 2012
Walter Bright
May 14, 2012
Chris Cain
May 15, 2012
Walter Bright
May 15, 2012
bearophile
May 14, 2012
Mehrdad
May 15, 2012
Walter Bright
May 14, 2012
Timon Gehr
May 14, 2012
Tove
May 14, 2012
deadalnix
May 14, 2012
Era Scarecrow
May 14, 2012
Walter Bright
May 17, 2012
Marco Leise
May 15, 2012
Stewart Gordon
May 14, 2012
deadalnix
May 14, 2012
Jonathan M Davis
May 14, 2012
Timon Gehr
May 14, 2012
Stewart Gordon
May 15, 2012
Chad J
May 15, 2012
Christophe
May 15, 2012
Chad J
May 16, 2012
Christophe
May 16, 2012
Timon Gehr
May 16, 2012
Christophe
May 15, 2012
Chris Cain
May 15, 2012
Chad J
May 15, 2012
Era Scarecrow
May 15, 2012
Chris Cain
May 15, 2012
Chad J
May 16, 2012
Chris Cain
May 16, 2012
Chad J
May 23, 2012
era scarecrow
May 13, 2012
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
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
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
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
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
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
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
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
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
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 6 7 8 9 10