new DIP47: Outlining member functions of aggregates

Ettienne Gilbert ettienne.gilbert at gmail.com
Mon Sep 9 14:45:09 PDT 2013


On Monday, 9 September 2013 at 17:34:23 UTC, Joseph Rushton 
Wakeling wrote:
> On 09/09/13 18:41, Ettienne Gilbert wrote:
>> I would argue that it is actually better this way (that not 
>> all functions need
>> to be in the declarations list) - its way more flexible! This 
>> way you can leave
>> out function declarations that you are not really interested 
>> to see from a
>> "functional overview perspective" of the class.
>
> AFAICS the request is for separation of declaration and 
> definition, so you'd be able to do things like this:
>
>     class Foo
>     {
>         void foo();
>         int bar(double x);
>         void goo(int n);
>         // ... etc.
>     }
>
> ... and then later in the same file:
>
>     void Foo.foo()
>     {
>         /* ... function body ... */
>     }
>
>     int Foo.bar(double x)
>     {
>         /* ... ditto ... */
>     }
>
>     void Foo.goo(int n)
>     {
>         /* ... and so on ... */
>     }
>
> Now, you'd be at liberty to mix declarations and definitions in 
> the _class_ (or struct) declaration, e.g.:
>
>     class Foo
>     {
>         void foo(); // we define this somewhere else
>
>         int bar(double x)
>         {
>             /* ... but we define this here */
>         }
>
>         // ... etc.
>     }
>
> But supposing that a function is declared but not defined 
> inside the class declaration, it should be obligatory that it 
> _is_ defined somewhere else in the file -- and conversely, if a 
> class function is defined somewhere else in the file, it should 
> be obligatory that it's declared in the class declaration.
>
> And on top of that, it should be obligatory that the 
> declaration and definition match perfectly.  (Note that for any 
> function defined in the class declaration, this is 
> automatically and unavoidably true:-)

Ahh, ok. I see where you are coming from - you were evaluating 
the implications of what Jacob Carlborg proposed if "mixed" in 
with Walter's DIP47, right? My points though was specifically on 
the implications of Jacob Carlborg's proposal "in isolation" i.e. 
as an acceptable alternative to DIP47. And, AFAICS, Jacob posed 
the question to Manu this way as well (I think - but maybe Jacob 
can confirm/deny).

If you mix the 2 I agree with you for the most part. But the real 
question for me (and I suspect Jacob) is this:

Is this...

>     class Foo
>     {
>         void foo();
>         int bar(double x);
>         void goo(int n);
>         // ... etc.
>     }
>
>     void Foo.foo()
>     {
>         /* ... function body ... */
>     }
>
>     int Foo.bar(double x)
>     {
>         /* ... ditto ... */
>     }
>
>     void Foo.goo(int n)
>     {
>         /* ... and so on ... */
>     }

...really so much better than this?


>     class Foo
>     {
>         void foo();
>         int bar(double x);
>         void goo(int n);
>         // ... etc.
>         void foo()
>         {
>              /* ... function body ... */
>         }
>
>         int bar(double x)
>         {
>              /* ... ditto ... */
>         }
>
>         void goo(int n)
>         {
>              /* ... and so on ... */
>         }
>     }

Granted, this sacrifices some flexibility from DIP47. But these 
are of such dubious quality/use/potential pitfalls (as discussed 
in this thread), that I hardly think DIP47 is worth implementing 
as a result. Especially since, what we currently have (as shown 
by Carl,) already gives you arguably 90%+ (IMHO) of Manu's 
request for (I quote) "You don't need to see the function bodies 
in the class definition, you want to quickly see what a class has 
and does". Does it really matter that the function definitions 
are also present inside the class definition, as long as you can 
also see "what a class has and does" in the declarations list at 
the top?

Of course fixing the current issues with .di generation is 
important as a separate issue.


More information about the Digitalmars-d mailing list