September 20, 2014 Re: Library Typedefs are fundamentally broken | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | Andrei Alexandrescu:
>> Have you used it in your real D code three or more times?
>
> No, but that doesn't mean much.
It means that I have more experience than you in using Typedef, and in my experience their usage is not so good.
Bye,
bearophile
|
September 20, 2014 Re: Library Typedefs are fundamentally broken | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On 9/20/14, 1:52 PM, bearophile wrote: > Andrei Alexandrescu: > >>> Have you used it in your real D code three or more times? >> >> No, but that doesn't mean much. > > It means that I have more experience than you in using Typedef, and in > my experience their usage is not so good. Aye. What I meant was "it doesn't mean Typedef is unusable; I just didn't need for that particular facility". What I'm saying after skimming https://issues.dlang.org/buglist.cgi?f1=short_desc&list_id=106755&o1=casesubstring&query_format=advanced&resolution=---&v1=Typedef is that all or at least most issues are trivial to fix. My perception of this thread is that there's an abundance of that misleading vividness fallacy (http://en.wikipedia.org/wiki/Misleading_vividness). Rhetoric techniques blow the most trivial matters out of proportion and build to the foaming co(ncl|f)usion that "less convenient than a baked-in facility" really means "unusable". I don't care for that kind of argument. Fix that stuff, go your merry way and use Typedef. Andrei |
September 21, 2014 Re: Library Typedefs are fundamentally broken | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | Am Sat, 20 Sep 2014 08:25:17 -0700 schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>: > On 9/19/14, 11:36 PM, Marco Leise wrote: > > Am Fri, 19 Sep 2014 08:02:30 -0700 > > schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>: > > > >> On 9/18/14, 11:45 PM, Marco Leise wrote: > >>> We should probably revert to having real typedefs. > >> > >> Should not. > > > > Ok, but don't ask me to use > > alias ALfloat = std.typecons.Typedef!(float, "yummyCookie23"); > > when it could be > > typedef ALfloat = float; > > ! :) > > I think this is an entirely palatable idiom: > > alias ALfloat = std.typecons.Typedef!(float, "ALfloat"); > > > Andrei Funny that you mention it. I had the exact same thought yesterday and hoped you wouldn't come around with that ... excuse. Actually, that works for me. But it could be DRY and look like typedef ALfloat = float; -- Marco |
September 21, 2014 Re: Library Typedefs are fundamentally broken | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Saturday, 20 September 2014 at 17:20:28 UTC, Andrei Alexandrescu wrote:
> On 9/20/14, 9:32 AM, ketmar via Digitalmars-d wrote:
>> On Sat, 20 Sep 2014 08:25:17 -0700
>> Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com>
>> wrote:
>>
>>> I think this is an entirely palatable idiom:
>>> alias ALfloat = std.typecons.Typedef!(float, "ALfloat");
>> this is ugly.
>
> But not unusable.
Requiring manual tracing of identity = unusable. With my proposed implementation it is at least clear when it is going to fail. This is much worse:
module a;
alias Int1 = Typedef!(int, "MyInt");
module b;
alias Int2 = Typedef!(int, "MyInt");
// oh I didn't know someone else used that cookie too..
static assert (is(Int1 == Int2));
Such solution simply can't be allowed in any project with >1 active programmer unless either type safety is not important or some additional restrictions on adding new typedefs are added process-wise (insane).
|
September 21, 2014 Re: Library Typedefs are fundamentally broken | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | Dicebot: > module a; > > alias Int1 = Typedef!(int, "MyInt"); > > module b; > > alias Int2 = Typedef!(int, "MyInt"); > > // oh I didn't know someone else used that cookie too.. Sooner or later a dirty semantics will bite your ass. It's an important rule of language/library design. > unless either type safety is not important If type safety is not so important in a piece of code, you probably are already not using a typedef/Typedef/newtype. Bye, bearophile |
September 21, 2014 Re: Library Typedefs are fundamentally broken | ||||
---|---|---|---|---|
| ||||
Posted in reply to Marco Leise | On 9/21/14, 1:52 AM, Marco Leise wrote: > Am Sat, 20 Sep 2014 08:25:17 -0700 > schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>: > >> On 9/19/14, 11:36 PM, Marco Leise wrote: >>> Am Fri, 19 Sep 2014 08:02:30 -0700 >>> schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>: >>> >>>> On 9/18/14, 11:45 PM, Marco Leise wrote: >>>>> We should probably revert to having real typedefs. >>>> >>>> Should not. >>> >>> Ok, but don't ask me to use >>> alias ALfloat = std.typecons.Typedef!(float, "yummyCookie23"); >>> when it could be >>> typedef ALfloat = float; >>> ! :) >> >> I think this is an entirely palatable idiom: >> >> alias ALfloat = std.typecons.Typedef!(float, "ALfloat"); >> >> >> Andrei > > Funny that you mention it. I had the exact same thought > yesterday and hoped you wouldn't come around with that ... > excuse. Why would anyone hope a valid idiom were not mentioned? > Actually, that works for me. But it could be DRY and > look like > > typedef ALfloat = float; DRY is DRY. Bloating the language is bloating the language. Andrei |
September 21, 2014 Re: Library Typedefs are fundamentally broken | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | On 9/21/14, 7:22 AM, Dicebot wrote: > On Saturday, 20 September 2014 at 17:20:28 UTC, Andrei Alexandrescu wrote: >> On 9/20/14, 9:32 AM, ketmar via Digitalmars-d wrote: >>> On Sat, 20 Sep 2014 08:25:17 -0700 >>> Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> >>> wrote: >>> >>>> I think this is an entirely palatable idiom: >>>> alias ALfloat = std.typecons.Typedef!(float, "ALfloat"); >>> this is ugly. >> >> But not unusable. > > Requiring manual tracing of identity = unusable. With my proposed > implementation it is at least clear when it is going to fail. This is > much worse: > > module a; > > alias Int1 = Typedef!(int, "MyInt"); alias Int1 = Typedef!(int, "a.Int1"); > module b; > > alias Int2 = Typedef!(int, "MyInt"); alias Int2 = Typedef!(int, "b.Int2"); > // oh I didn't know someone else used that cookie too.. > static assert (is(Int1 == Int2)); > > Such solution simply can't be allowed in any project with >1 active > programmer unless either type safety is not important or some additional > restrictions on adding new typedefs are added process-wise (insane). More hyperbole won't help the weakness of the argument. Andrei |
September 21, 2014 Re: Library Typedefs are fundamentally broken | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On 9/21/14, 7:49 AM, bearophile wrote:
> Dicebot:
>
>> module a;
>>
>> alias Int1 = Typedef!(int, "MyInt");
>>
>> module b;
>>
>> alias Int2 = Typedef!(int, "MyInt");
>>
>> // oh I didn't know someone else used that cookie too..
>
> Sooner or later a dirty semantics will bite your ass.
Mine ain't hurting. -- Andrei
|
September 21, 2014 Re: Library Typedefs are fundamentally broken | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Sunday, 21 September 2014 at 15:15:27 UTC, Andrei Alexandrescu wrote: > alias Int2 = Typedef!(int, "b.Int2"); ..and don't forget to keep those updated when module / aggregate names change via refactoring! Sorry but what you pretend to be a pragmatical solution is just a useless crap I am not going to ever use while I am in sane mind. Especially considering that more reliable alternative can be hacked in few minutes. > More hyperbole won't help the weakness of the argument. Calling daily concerns of others "hyperbole" doesn't help to sell your solution as well-thought and reasonable. |
September 21, 2014 Re: Library Typedefs are fundamentally broken | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu Attachments: | On Sun, 21 Sep 2014 08:15:29 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com>
wrote:
> alias Int1 = Typedef!(int, "a.Int1");
> alias Int2 = Typedef!(int, "b.Int2");
ah, now that's cool. module system? wut? screw it, we have time-proven manual prefixing!
|
Copyright © 1999-2021 by the D Language Foundation