Hi, > * I'm not sure that the planned support for the 'void' type would help you > because, at present anyway, I don't think we envision there being any legal > values of the void type, which would suggest you wouldn't have anything to > put into the default argument position where the '0' is now.
I wasn't thinking that void type would help me anyhow; I was just thinking that void type would be semantically correct type to use in such situations. > * Given that files are a type that have an obvious built-in sentinel value > (/dev/null, essentially), would it make sense to have the default value be > that and to test against the value instead of against the type? (this would > also have the benefit of not requiring the class to be generic) > > * Another way that it occurs to me to deal with this would be to store the > 'useBar' bit as a var or const rather than a param and to support two > constructors, one taking zero arguments, one requiring one, and setting > 'useBar' based on which of the two was called. Originally I wanted to be able to disable the timing acquiring support during the compile time to increase the runtime performance. Though more I think about this the more certain I am that this is just unnecessary micro-optimizing... Also the passed argument/field (bar in this case) is usually a class, not a file. Well, I have to think this a bit more. Another question, is it possible to split a module into multiple files? I recall seeing some notes about this implying that this isn't supported yet, but just wanted to make sure. ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Chapel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-users
