[vtk-developers] Hinting proposal

Biddiscombe, John A. biddisco at cscs.ch
Thu Apr 28 03:52:44 EDT 2011


David

+1

I don't care how you implement it, html/mummy(?) or otherwise, but moving the hints into the source gets my vote. Much nicer than having a dodgy hints file for the wrappers.

JB

-----Original Message-----
From: vtk-developers-bounces at vtk.org [mailto:vtk-developers-bounces at vtk.org] On Behalf Of David Gobbi
Sent: 27 April 2011 23:43
To: David Cole
Cc: VTK Developers
Subject: Re: [vtk-developers] Hinting proposal

On Wed, Apr 27, 2011 at 2:31 PM, David Cole <david.cole at kitware.com> wrote:
> I realize this goes directly against what you said in the other thread....
>
> But I strongly prefer inline hints to use actual code attributes if
> possible. For example, this particular hint would be an attribute on the
> return type of the method. You could also envision parameter hinting (as in,
> this parameter is a pointer, but it's really an array of N elements).
>
> Parsing stuff out of comments seems like it would be more error prone
> compared to having an actual C++ compiler-readable attribute attached to a
> C++ entity.
>
> This is just my opinion, though. Let's see who else chimes in.

So in the mummy examples I see code like this:

iwhPropGet double GetMileage() const;

I could get used to it.  It makes the code a bit more confusing to a
casual reader, but not too much.  So, yes, I'd be willing to go along
with this.  I'd much rather use "hint" as the prefix instead of "iwh",
and looking at the implementation, this seems to be doable without
losing compatibility with mummy.

 - David
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.vtk.org/mailman/listinfo/vtk-developers




More information about the vtk-developers mailing list