Consistency, Templates, Constructors, and D3

[Era Scarecrow]

On Tuesday, 28 August 2012 at 21:01:52 UTC, David Piepgrass wrote:
>>>> this this(this){} //postblitz?
>
> This is not an appropriate syntax, not just because it looks 
> silly, but because a postblit constructor is not really a 
> constructor, it's is a postprocessing function that is called 
> after an already-constructed value is copied. So I don't think 
> there's any fundamental need for postblit constructors to look 
> like normal constructors.

>>> I'm sure this case has an easy solution. How about:
>>>
>>>   struct Foo {
>>>       this new() { ... } // constructor
>>>       this() { ... } // postblit
>>>   }
>>
>> But now you're breaking consistency by not including a return 
>> type. maybe 'this this()' but that looks like a mistake or 
>> typo.

>> I don't see how "this this()" is any worse than "this(this)"; 
>> IMO neither name really expresses the idea "function that is 
>> called on a struct after its value is copied". But a postblit 
>> constructor doesn't work like normal constructors, so keeping 
>> the "this(this)" syntax makes sense to me even though it is 
>> not consistent with normal constructors. "this()" has the 
>> virtual of simplicity, but it's even less googlable than 
>> "this(this)".

  As long as it's an established standard it won't matter.

  With his insistence that constructors have a return type, then 
the postblit should too. Although keep in mind most likely you 
won't 'return' anything in constructors and it's assumed that 
'return this;' is entered at the very last line (although that 
becomes a special case, and that makes it okay right?).

>>> And for overload distinction (new vs load), which is an issue 
>>> beyond Memory Pools and effects and even larger codebase. 
>>> There needs to be a consistent way to distinguish (by name) a 
>>> constructor that loads from a file, and one that creates the 
>>> object "manually".
>>
>> Isn't that more an API issue?
>
> Sorry, I don't follow.

  Having a named constructor compared to a default one. If there's 
only one type of constructor (although different ways to call it) 
then there shouldn't be an issue; Not really. But the problem was 
down to 'is this a struct or a class' problem. Could do Hungarian 
notation/prefixes; Then you're forced to know each time you use 
it (unless you use auto everywhere).

  struct MyStruct
becomes
  struct Struct_MyStruct
or
  struct S_MyStruct

>> Same problem, how do you tell it ahead of time without 
>> completely rewriting the rules? leaving it as 'this' and 
>> '~this' are simple to remember and work with, and factory 
>> functions should be used to do a bulk of work when you don't 
>> want the basic/bare minimum.
>
> Sorry, I don't understand what you're getting it. I suspect 
> that you're interpreting his proposal in a completely different 
> way than I am, and then trying to expose the flaws in your 
> interpretation of the proposal, and then I can't follow it 
> because my interpretation doesn't have those flaws :)

  But our own opinions never have flaws :)

  Being able to name the constructor whatever you want although 
may sound nice likely is more a hassle than it's worth. Like 
namespace issues. I agree being able to override new could be 
useful for types of allocation, but the way he presented it 
suggested new was the constructor & allocator, meaning you'd have 
to have in depth detail of both steps in order to override it 
later. Abstraction then is thrown away and the black box method 
becomes a white/clear box method, encapsulation goes out the 
window.

  Make everything as simple as possible, but not simpler. -- 
Albert Einstein