Just clarifying one thing: >> As currently written, I think its intent is to return true for types that >> have a singleton value associated with them (where imaginary is noted as >> being future work in the implementation), so a name reflecting that would >> be better. E.g., chpl_isSingletonType() potentially or >> chpl_typeRepresentsSingleValue() or ...? > > I like where you're pointed here, but chpl_typeRepresentsSingleValue() > doesn't seem a good choice because of the potential for confusion with > single vars, the siblings of sync vars. Maybe chpl_isSingleton(), and > make it applicable to both types and non-types? Or perhaps instead > provide chpl_isStructured(), the opposite? I suppose that depends on > what programmers most often write when they use this. Or maybe having > both is useful.
Whatever the name is here (if this routine doesn't go away), I think the intention is that this be an intended-for-developers symbol (which is what the chpl_ implies to me), which suggests that the name need not be absolutely precise and user-foolproof. At the same time, I clearly don't believe that statement to the extent of being OK with the vagueness of "certain" (as Tom wasn't). And I'm not particularly wed to my names either... was just looking for something that had the possibility of being self-defining for a developer, without knowing exactly what that should be. -Brad ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
