On Saturday, 8 June 2013 at 14:08:59 UTC, Lars T. Kyllingstad wrote:
> On Friday, 7 June 2013 at 17:27:16 UTC, Andrei Alexandrescu wrote:
>>> However, there are times where it is convenient to be able to explode a
>>> path into a structure, where each part is clearly separate from the
>>> next.
>>
>> Tuple!(
>>    string, "drive",
>>    string[], "folders",
>>    string, "basename",
>>    string, "extension"
>> )
>> parsePath(string path);
>>
>> string buildPath(string drive, string[] folders, string basename, string extension);
>
> [...]
>
> But why stop at the parts you have listed there?

The moment I clicked "Send", I realised that offering multiple decompositions would prevent recomposition, because you'd have to choose which parts to combine.

On Saturday, 8 June 2013 at 14:14:33 UTC, Lars T. Kyllingstad wrote:
> On Saturday, 8 June 2013 at 14:08:59 UTC, Lars T. Kyllingstad wrote:
>> On Friday, 7 June 2013 at 17:27:16 UTC, Andrei Alexandrescu wrote:
>>>> However, there are times where it is convenient to be able to explode a
>>>> path into a structure, where each part is clearly separate from the
>>>> next.
>>>
>>> Tuple!(
>>>   string, "drive",
>>>   string[], "folders",
>>>   string, "basename",
>>>   string, "extension"
>>> )
>>> parsePath(string path);
>>>
>>> string buildPath(string drive, string[] folders, string basename, string extension);
>>
>> [...]
>>
>> But why stop at the parts you have listed there?
>
> The moment I clicked "Send", I realised that offering multiple decompositions would prevent recomposition, because you'd have to choose which parts to combine.

Using D's property functions, this should not actually be a problem. The struct could be opaque in regards to which members are actually attributes, and which are functions.

Eg:
Path path = Path(`C:\MyFile.txt`);
path.filename  = "main.cpp";
path.extension = "d";
assert(path.buildPath() == `C:\main.d`));

I don't see any reason for that to not work.

On 6/8/13 10:45 AM, monarch_dodra wrote:
> On Saturday, 8 June 2013 at 14:14:33 UTC, Lars T. Kyllingstad wrote:
>> On Saturday, 8 June 2013 at 14:08:59 UTC, Lars T. Kyllingstad wrote:
>>> On Friday, 7 June 2013 at 17:27:16 UTC, Andrei Alexandrescu wrote:
>>>>> However, there are times where it is convenient to be able to
>>>>> explode a
>>>>> path into a structure, where each part is clearly separate from the
>>>>> next.
>>>>
>>>> Tuple!(
>>>> string, "drive",
>>>> string[], "folders",
>>>> string, "basename",
>>>> string, "extension"
>>>> )
>>>> parsePath(string path);
>>>>
>>>> string buildPath(string drive, string[] folders, string basename,
>>>> string extension);
>>>
>>> [...]
>>>
>>> But why stop at the parts you have listed there?
>>
>> The moment I clicked "Send", I realised that offering multiple
>> decompositions would prevent recomposition, because you'd have to
>> choose which parts to combine.
>
> Using D's property functions, this should not actually be a problem. The
> struct could be opaque in regards to which members are actually
> attributes, and which are functions.
>
> Eg:
> Path path = Path(`C:\MyFile.txt`);
> path.filename = "main.cpp";
> path.extension = "d";
> assert(path.buildPath() == `C:\main.d`));
>
> I don't see any reason for that to not work.

Looks like the proposal may be converted into something liked by all - a small PathComponents struct with the appropriate primitives. A high ratio of usefulness to size would be key to acceptance.

Andrei