"Ben Hinkle" <Ben_member@pathlink.com> wrote in message news:d80fq2$2gfv$1@digitaldaemon.com...
> [snip]
>>Let's take a look in some code fragments of Phobos:
>>
>>module std.openrj -----------------------------------
>>
>>class Record
>>{
>>    Field[] fields() { return m_fields.dup;  } // just in case?
>>    // probably following is better?
>>    // const Field[] fields() { return m_fields;  }
>>}
>>
>>class Database
>>{
>>    Record[]  records()  {   return m_records.dup;   } // the same
>>    Field[]      fields()      {   return m_fields.dup;  }
>>}
>>
>>std.file----------------------------------------------
>>
>>class FileException : Exception
>>{
>>    this(char[] name, uint errno)
>>    { char* s = strerror(errno);             //  I have no idea
>> this(name, std.string.toString(s).dup); //  what is going on here.
>> this.errno = errno;
>>    }
>>}
>>
>>void listdir(char[] pathname, bool delegate(char[] filename) callback)
>>{
>> ....
>>     int len = std.string.strlen(fdata.d_name);
>>     if (!callback(fdata.d_name[0 .. len].dup)) // is dup really needed
>>here???
>>             // allocation of new string on each entry! Doh!
>>
>> ....
>>}
>>
>>std.loader ----------------------------------------------
>>public class ExeModuleException : Exception
>>{
>>    this(uint errcode)
>>    {
>> super(std.string.toString(strerror(errcode)).dup); // why?
>>    }
>>}
>>
>>std.socket ----------------------------------------------
>>
>>void populate(protoent* proto)
>> {
>>  type = cast(ProtocolType)proto.p_proto;
>>  name = std.string.toString(proto.p_name).dup; // why?
>>....
>>   aliases = new char[][i];
>>   for(i = 0; i != aliases.length; i++)
>>   {
>>    aliases[i] = std.string.toString(proto.p_aliases[i]).dup; // what for?
>>   }
>>....
>>
>>}
>>----------------------------------------
>>etc.
>
> Are the comments in the code above editorial by you or are they actually
> in the
> code? I'd say someone needs to look at phobos to clean up the dups. If
> you've
> already done the sweep then sending Walter the fixes would be helpful.
> Phobos
> can contain non-D programming styles occasionally - each module has a
> strong
> indication of the author's attitudes IMHO.

Yes, comments are mine. I took a look again:

1) std.socket is fine: std.string.toString(proto.p_aliases[i]).dup is really
needed
    as proto.p_aliases[i] is temporary string coming from system (sockets)
2) strerror(errcode)).dup probably make sense, as string there is coming
from
     extern (C) char* strerror(int);
3) For std.openrj I don't really know Matthew intention. Seems like he needs
   such implementation for some reasons or he is following
   .dup advices for library module safe implementation.
   No idea to be short. const will help in such cases.
4) std.file -> void listdir(char[] pathname, bool delegate(char[] filename)
callback)
    the way it is implemented and without const char[] filename seems like
only reliable
    way of how to accomplish this as fdata.d_name coming from system static
buffer.
    Other option would be to create temp buffer on stack, copy string value
there
    and pass this buffer reference. But this is a copy on each iteration.
    With const such string can be passed 'as is'.

>
> ps - for kicks this weekend I've been adding a parameter to the MinTL
> containers
> to indicate read-only vs read-write. For example
> struct List(Value, bit ReadOnly = false) {
> static if (!ReadOnly) {
> void addTail(Value v){...}
> .. other functions that modify the list ...
> }
> .. functions that don't modify the list ...
> }
> You get a read-only view of a container by using the "readonly" property.
> I'll
> be finishing this stuff up soon and post to D.dtl later in the week.
>

(no offence, just wondering)

I really don't know how such static flag would work. Suppose I declared:

   List(int, true /*ReadOnly*/) readOnlyList;

How to fill this list then? You will need some mechanism
allowing to do mutable->immutable conversion, right?
My perception is that just something like const_iterator
needs to be designed. Or ConstList without modification
methods which will have sole ctor ConstList(List data).


Andrew.

>> ps - for kicks this weekend I've been adding a parameter to the MinTL
>> containers
>> to indicate read-only vs read-write. For example
>> struct List(Value, bit ReadOnly = false) {
>> static if (!ReadOnly) {
>> void addTail(Value v){...}
>> .. other functions that modify the list ...
>> }
>> .. functions that don't modify the list ...
>> }
>> You get a read-only view of a container by using the "readonly" property.
>> I'll
>> be finishing this stuff up soon and post to D.dtl later in the week.
>
> (no offence, just wondering)
>
> I really don't know how such static flag would work. Suppose I declared:
>
>   List(int, true /*ReadOnly*/) readOnlyList;
>
> How to fill this list then? You will need some mechanism allowing to do mutable->immutable conversion, right?

That's what the "readonly" property does. For example

  void foo(List!(int,ReadOnly) y) { ... }
  List!(int) x;
  x.add(10,20,30);
  foo(x.readonly);

The 'ReadOnly' in the code above is a constant defined to be true. I think it improves readability of the code. If one wants to "cast away the const" I also added a property x.readwrite.

> My perception is that just something like const_iterator needs to be designed. Or ConstList without modification methods which will have sole ctor ConstList(List data).

Those are equivalent to iterator!(true) where iterator(bit Const = false) and List!(true) where List(bit Const = false). The "constness" becomes part of the type just like the types List/ConstList or iterator/const_iterator.

"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:d81fb2$7el$1@digitaldaemon.com...
>
>>> ps - for kicks this weekend I've been adding a parameter to the MinTL
>>> containers
>>> to indicate read-only vs read-write. For example
>>> struct List(Value, bit ReadOnly = false) {
>>> static if (!ReadOnly) {
>>> void addTail(Value v){...}
>>> .. other functions that modify the list ...
>>> }
>>> .. functions that don't modify the list ...
>>> }
>>> You get a read-only view of a container by using the "readonly"
>>> property. I'll
>>> be finishing this stuff up soon and post to D.dtl later in the week.
>>
>> (no offence, just wondering)
>>
>> I really don't know how such static flag would work. Suppose I declared:
>>
>>   List(int, true /*ReadOnly*/) readOnlyList;
>>
>> How to fill this list then? You will need some mechanism allowing to do mutable->immutable conversion, right?
>
> That's what the "readonly" property does. For example
>
>  void foo(List!(int,ReadOnly) y) { ... }
>  List!(int) x;
>  x.add(10,20,30);
>  foo(x.readonly);
>
> The 'ReadOnly' in the code above is a constant defined to be true. I think it improves readability of the code. If one wants to "cast away the const" I also added a property x.readwrite.
>
>> My perception is that just something like const_iterator needs to be designed. Or ConstList without modification methods which will have sole ctor ConstList(List data).
>
> Those are equivalent to iterator!(true) where iterator(bit Const = false) and List!(true) where List(bit Const = false). The "constness" becomes part of the type just like the types List/ConstList or iterator/const_iterator.
> 

"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:d81fb2$7el$1@digitaldaemon.com...
>
>>> ps - for kicks this weekend I've been adding a parameter to the MinTL
>>> containers
>>> to indicate read-only vs read-write. For example
>>> struct List(Value, bit ReadOnly = false) {
>>> static if (!ReadOnly) {
>>> void addTail(Value v){...}
>>> .. other functions that modify the list ...
>>> }
>>> .. functions that don't modify the list ...
>>> }
>>> You get a read-only view of a container by using the "readonly"
>>> property. I'll
>>> be finishing this stuff up soon and post to D.dtl later in the week.
>>
>> (no offence, just wondering)
>>
>> I really don't know how such static flag would work. Suppose I declared:
>>
>>   List(int, true /*ReadOnly*/) readOnlyList;
>>
>> How to fill this list then? You will need some mechanism allowing to do mutable->immutable conversion, right?
>
> That's what the "readonly" property does. For example
>
>  void foo(List!(int,ReadOnly) y) { ... }
>  List!(int) x;
>  x.add(10,20,30);
>  foo(x.readonly);
>
> The 'ReadOnly' in the code above is a constant defined to be true. I think it improves readability of the code. If one wants to "cast away the const" I also added a property x.readwrite.
>
>> My perception is that just something like const_iterator needs to be designed. Or ConstList without modification methods which will have sole ctor ConstList(List data).
>
> Those are equivalent to iterator!(true) where iterator(bit Const = false) and List!(true) where List(bit Const = false). The "constness" becomes part of the type just like the types List/ConstList or iterator/const_iterator.

Yep. It will work. It will increase size of generated code twice as you
need second instantiation of the template (readonly version).
But such specialized  wrapper is definitely a solution for containers for
places where robustness and modulraity is main requirements.

Wish it will be possible to say something like char[].readonly or so for primary containers and pointers. As in most cases they are pretty sufficient and more effective.

I took a look in compiler code. Seems I can implement constness for array and pointers pretty easily as everything is already there.

Another option would be in implementation of extended/selected typedef
notation:
typedef  char[] cstring:  opSlice, opIndexAssign; // list of operations
derived from
base type.  A bit ugly but would work.

Andrew.