On Tuesday, June 04, 2013 01:23:52 Walter Bright wrote:
> I think it's a bad idea to 'mangle' the name. First off, if it is private, it is not visible. And even being public, the anti-hijacking language features make it a non-problem. The whole point is to avoid the wretched C problems with a global name space, by not having a global name space.

Not visible? When was that fixed? Last time I checked, access level had zero effect on visibility, just your ability to actually call it. Access level is taken into account after overload resolution. So, if there's another, public symbol with the same name which would be as good a match as this one aside from access level, then you're going to get a compilation error - which is exactly why most of us argue that inaccessible symbols should not be visible. But that requires a language change (which should definitely happen IMHO, but AFAIK, it still hasn't).

- Jonathan M Davis

On Tuesday, June 04, 2013 14:48:34 David wrote:
> (btw. I think I fxed one
> of the bugs a while ago but it is still open and listed as bug on
> dlang.org).

If you're sure that it's fixed, then close it.

- Jonathan M Davis

On 6/4/2013 9:33 AM, John Colvin wrote:
> On Tuesday, 4 June 2013 at 16:09:09 UTC, Walter Bright wrote:
>> On 6/4/2013 6:34 AM, Jacob Carlborg wrote:
>>> I'm wondering if (un)compress can take the compressing algorithm as a template
>>> parameter. Does that make sense?
>>>
>>> Something like:
>>>
>>> auto result = data.compress!(LZW);
>>>
>>> Then we could pass different compressing algorithms to the compress function.
>>
>> I don't see the point. Furthermore, it requires that the compress template
>> know about all the compression algorithms available, which limits future
>> expansion.
>
> Not necessarily. If the compression algorithms were free functions in the module
> you could just be passing an alias to one, which compress would then call.
> (which would also allow people to specify their own algorithms)

What value does a function which just passes an alias to another one add?

On 6/4/2013 9:34 AM, David wrote:
> Am 04.06.2013 18:09, schrieb Walter Bright:
>> On 6/4/2013 6:34 AM, Jacob Carlborg wrote:
>>> I'm wondering if (un)compress can take the compressing algorithm as a
>>> template
>>> parameter. Does that make sense?
>>>
>>> Something like:
>>>
>>> auto result = data.compress!(LZW);
>>>
>>> Then we could pass different compressing algorithms to the compress
>>> function.
>>
>> I don't see the point. Furthermore, it requires that the compress
>> template know about all the compression algorithms available, which
>> limits future expansion.
>>
>
> No the compression type only has to provide a certain api.
>

Again, I'm not seeing the added value with this.

On Tuesday, 4 June 2013 at 17:50:47 UTC, Walter Bright wrote:
> On 6/4/2013 9:33 AM, John Colvin wrote:
>> On Tuesday, 4 June 2013 at 16:09:09 UTC, Walter Bright wrote:
>>> On 6/4/2013 6:34 AM, Jacob Carlborg wrote:
>>>> I'm wondering if (un)compress can take the compressing algorithm as a template
>>>> parameter. Does that make sense?
>>>>
>>>> Something like:
>>>>
>>>> auto result = data.compress!(LZW);
>>>>
>>>> Then we could pass different compressing algorithms to the compress function.
>>>
>>> I don't see the point. Furthermore, it requires that the compress template
>>> know about all the compression algorithms available, which limits future
>>> expansion.
>>
>> Not necessarily. If the compression algorithms were free functions in the module
>> you could just be passing an alias to one, which compress would then call.
>> (which would also allow people to specify their own algorithms)
>
> What value does a function which just passes an alias to another one add?

A unified interface called "compress" that takes a compression function as an alias (with e.g. lzwCompress as a default) seems like a nicer way of working, seeing as people don't necessarily care/know about which algorithm they're using, they just want to compress something a bit.

Also, it would be cool if a range could remember which algorithm it was compressed with (as it's type? I.e. LzwRange), so a generic function "expand" could call the appropriate ***Expand

On 6/4/2013 11:04 AM, John Colvin wrote:
> On Tuesday, 4 June 2013 at 17:50:47 UTC, Walter Bright wrote:
>> What value does a function which just passes an alias to another one add?
>
> A unified interface called "compress" that takes a compression function as an
> alias (with e.g. lzwCompress as a default) seems like a nicer way of working,
> seeing as people don't necessarily care/know about which algorithm they're
> using, they just want to compress something a bit.
>
> Also, it would be cool if a range could remember which algorithm it was
> compressed with (as it's type? I.e. LzwRange), so a generic function "expand"
> could call the appropriate ***Expand

What is the improvement of typing:

   compress(lzw)

over:

   lzwCompress()

?

On Tue, Jun 4, 2013 at 11:37 AM, Walter Bright <newshound2@digitalmars.com>wrote:

> On 6/4/2013 11:04 AM, John Colvin wrote:
>
>> On Tuesday, 4 June 2013 at 17:50:47 UTC, Walter Bright wrote:
>>
>>> What value does a function which just passes an alias to another one add?
>>>
>>
>> A unified interface called "compress" that takes a compression function
>> as an
>> alias (with e.g. lzwCompress as a default) seems like a nicer way of
>> working,
>> seeing as people don't necessarily care/know about which algorithm they're
>> using, they just want to compress something a bit.
>>
>> Also, it would be cool if a range could remember which algorithm it was
>> compressed with (as it's type? I.e. LzwRange), so a generic function
>> "expand"
>> could call the appropriate ***Expand
>>
>
> What is the improvement of typing:
>
>    compress(lzw)
>
> over:
>
>    lzwCompress()
>
> ?
>

writing generic code.
same reason as why we prefer:
auto y=to!double(x) over auto y=to_double(x);

On 6/4/2013 11:43 AM, Timothee Cour wrote:
> writing generic code.
> same reason as why we prefer:
> auto y=to!double(x) over auto y=to_double(x);

The situations aren't comparable. The to!double case is parameterizing with a type, the compress one is not. Secondly, compress(lzw) does ABSOLUTELY NOTHING but turn around and call lzw. It adds nothing.

On Tuesday, June 04, 2013 11:46:48 Walter Bright wrote:
> On 6/4/2013 11:43 AM, Timothee Cour wrote:
> > writing generic code.
> > same reason as why we prefer:
> > auto y=to!double(x) over auto y=to_double(x);
> 
> The situations aren't comparable. The to!double case is parameterizing with a type, the compress one is not. Secondly, compress(lzw) does ABSOLUTELY NOTHING but turn around and call lzw. It adds nothing.

Well, I'd expect it to be compress!lzw(), but in any case, what it buys you is that you can pass the algorithm around without caring what it is so that while code higher up on the stack may have to know that it's lzw, code deeper down doesn't have to care what type of algorithm it's using. Now, whether that flexibility is all that useful in this particular case, I don't know, but it _does_ help with generic code. It's like how a lot of std.algorithm takes its predicate as an alias.

- Jonathan M Davis

On Tuesday, 4 June 2013 at 18:46:49 UTC, Walter Bright wrote:
> On 6/4/2013 11:43 AM, Timothee Cour wrote:
>> writing generic code.
>> same reason as why we prefer:
>> auto y=to!double(x) over auto y=to_double(x);
>
> The situations aren't comparable. The to!double case is parameterizing with a type, the compress one is not. Secondly, compress(lzw) does ABSOLUTELY NOTHING but turn around and call lzw. It adds nothing.


Currently. However, compress could become more feature-rich in the future. Perhaps there's some scope for automatic algorithm/parameter selection based on the type and length(if available) of what gets passed.