Hey, Dave1,
----- Original Message -----
> On 07/09/2014 06:46 PM, Nathan Scott wrote:
> >
> > I got the impression earlier that you were expecting more parameters to
> > be needed down the track, and that strings would not be ideal...? (like
> > the "interrupted" parameter). If that's not the case and we can get
> > rid of that extra parameter, lets keep it simple and go back to strings
> > as you suggest.
> My fault for being unclear, in that case. I just meant that I expected
> new features to be added to the API. I don't see a way to get rid of the
> 'interrupted' parameter other than to make it a byte in one of the
> stings (yuck, and did I mention Yuck?). It needs to exist somewhere in
> the caller's address space.
Hmmm, OK. The only other suggestion then would be to make it a more
general, and call it "flags" (where flags can go in/out of the API).
But thats a pretty ordinary approach too, really.
Oh, or could interrupted-ness be indicated via the return code?
Anyway, you make a decision - it seems nothing here is particularly
attractive, and you're in the best position to consider all of the
approaches - go ahead, pick one and run with it.
> > That name is still really un-helpful though. :( Please use something,
> > anything, other than a number (inconsistent with the rest of the PMAPI
> > and it says to the API user "I could not find words to describe this
> > thing").
> >
> > In fact, double-underscore prefix is looking a really good option here
> > given the lack of certainty - please seriously consider that - we can
> > always add the PMAPI-level symbol later, once we've had more time to
> > consider and see what else comes up.
> >
> > So, pick one of the above two approaches please, and if not settled on
> > a direction you're happy with by weeks end, lets yank this code and try
> > again next release?
> I think that the double underscore prefix is a reasonable buffer against
> invasive change and will probably go with that.
Sounds good.
cheers.
--
Nathan
|