What would be the consequence of implementing interfaces as fat pointers ?

Manu turkeyman at gmail.com
Mon Mar 31 22:02:49 PDT 2014


On 31 March 2014 18:16, Walter Bright <newshound2 at digitalmars.com> wrote:

> On 3/31/2014 12:51 AM, Manu wrote:
>
>> Now it's deceptive that it's a pointer, and the pointer semantics are not
>> suppressed. It might be surprising to find that a type that doesn't look
>> like a
>> pointer behaves like a pointer.
>> You lose access to the operators, indexing/slicing etc, etc.
>> I don't see how this is a reasonable comparison to 'class' as a reference
>> type
>> by definition.
>>
>
> Of course it's reasonable - not many classes overload operators.
>

Is there a way to disable indexed dereferencing? Slicing?

The point is, there are numerous solutions available, you aren't stuck with
> one solution for every problem.
>

I just wouldn't go so far as to call these alternatives 'solution's. A
pointer is a pointer.
Calling it a reference type is a stretch. While it can be indexed, sliced,
and operators don't work, I don't think this is a compelling solution in
very many contexts, and certainly not a general solution.

And, you can use 'alias this' as Adam showed to create a type with fully
> customized behavior - you don't have to change the language to prove your
> ideas.
>

I haven't made any suggestion to change the language, I just said that
adam's idea (well, not necessarily his idea, it seems to be an established
pattern) is a rather elaborate hack; in many cases the boilerplate exceeds
the volume of the useful code. The whole pointer-to-Impl + getter property
+ alias this + etc pattern is quite a lot of boilerplate.

It's a really common pattern, it's obviously very useful, but it's
surprising to me that people think that it's like, 'cool'.
I get why it's done, and it's cool that D can do this (I use it a lot in my
code), but I don't feel it's particularly elegant.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140401/23b5f1f9/attachment.html>


More information about the Digitalmars-d mailing list