On Tue, Oct 21, 2014 at 03:07:31AM -0700, Alan Irwin wrote: > On 2014-10-21 09:18+0100 Phil Rosenberg wrote: > > > Hi Alan > > > That option works for me - if that feature might be in use then we can > > retain it. > > > However I disagree with wrapping plfill in a plstream::plfill > method. This is poor object oriented division of responsibility. The > plfill method has nothing really to do with plstream and if we create > that method, then someone somewhere will use it incorrectly and create > a hard to find bug. > > > If you really wanted to go object oriented then > you would create a plfiller class, which would have a fill virtual > method which for the standard class would call plfill. Then you would > pass this into plstream::shade. However, I think all that is > unnecessary. Just using plfill for the callback is simple, effective, > transparent and also conforms to the existing plplot documentation. > > Hi Phil: > > I was basing my idea for the plstream::fill_callback on the > plstream::tr[0-2] callbacks which are C++ wrappers for the C > callbacks, pltr[0-2]. That is, I was just following an existing > pattern without a lot of C++ knowledge to back it up. However, your > arguments for simply using unwrapped C callbacks seems compelling to > me so long as we are consistent about how we apply that idea. > Therefore, I suggest (unless Andrew weighs in with a contrary opinion) > that you go ahead and commit the exact change you proposed for your > option 1 as well as (this is the consistency part I think is > important) officially deprecating plstream::tr[0-2] in README.release > and replacing all uses of those C++ callbacks in our C++ examples with > the C callbacks pltr[0-2].
Well I (re)wrote the current C++ classes in plplot. The original intention was to completely hide the C API from the user. Mixing C and C++ APIs is generally a bad idea (though I can see some argument in this special case Phil, but it is the thin end of the wedge). Hiding the calls to set_stream was an attempt to make plplot more object orientated, but as Phil pointed out, it is not thread safe anyway so we are hiding some of the dangers. Personally I like the idea of removing the function pointer altogether or replacing with a enumeration since it only causes problems with all our language bindings. This however is a pretty major API change since plshade must be one of our more heavily used functions. I really can't see any users writing their own versions of plfill, but you never know.... My other option was to provide a static version of plfill for use as a callback function (without the set_stream call) and a non-static version with the call to set_stream for use elsewhere. This would make the two different usages clear. Andrew ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
