package name
Closed this issue · 6 comments
@kmesbah, ideally we'd put CS50's Java library in its "own" namespace, a la edu.harvard.cs50, but since the library itself needs to be in a class, we'd then have edu.harvard.cs50.CS50, which feels messy. We could name the class something else (e.g., Library), but that feels suboptimal, since usage should ideally be CS50.method, not Library.method. We don't envision having any (or many) other classes (maybe one for CS50 ID, in which case we'd have edu.harvard.cs50.ID) either. Any thoughts on package name? Have you seen other how other single-class libraries handle this?
@dmalan well, I don't recall using a class with the same name as its containing package. took a bit of time searching for examples, but afraid couldn't find any.
typically, the fully qualified name of the class won't be used that much throughout the code anyway. wouldn't be the worst thing to keep it as edu.harvard.cs50.CS50.
what about edu.harvard.cs50.CS50Library or edu.harvard.cs50.CS50Lib?
@dmalan I would say there are several options. If you want to go the most Java-y of ways, then I'd do edu.harvard.cs50.util.CS50Scanner and then have your CS50 class be a subclass of java.util.Scanner (since you are just adding extra functionality). Note, edu.harvard.cs50.io.CS50Scannerwould also be a descent package name. Of course, then the methods will no longer be static, etc. so that's likely not an option you'd want to pursue.
That being said, I know the goal is to maximize consistency across the different language ports while at the same time minimizing awkward "abuse" of conventions in a language. From that point of view, you could do one of two things, either you can make Java behave like the rest or make the rest behave more like Java. If you want to make Java look like the others, then going with any of the class named above would be fine. It's a bit awkward, but you're going for consistency for the ease of learning, not for production level code (of course, you may want to put a note in the docs saying why you made it look this way with a pointer to Java conventions). On the other hand, if you were to make the rest of your ports more Java-y and you were to go with edu.harvard.cs50.Utilities as a place to put your utility methods, then you'd simply change your other ports to also have them under cs50.utilities. E.g. in python the module would be be import edu.harvard.cs50.utilities.
Just my rambling 2 cents.
@prschmid I'm not sure sub-classing Scanner would be a good idea for many reasons including allowed instantiation (Scanner even doesn't have an empty constructor, which I imagine would unnecessarily make things more complicated) and Scanner's methods availability (which would mainly increase the inconsistency), etc, particularly that the goal is to simplify while keeping things consistent.
re the Python example, not sure whether a Python version is going to be released anytime soon, and haven't written much Python, but I suppose it could be done the PHP way, since you won't have to wrap your functions with a class as it's the case with Java.
I completely agree regarding the Scanner in the context of CS50, hence my
other suggestions. I merely put that there as the way I would implement
this in everything-is-a-class-Java way if it were being used in a "real"
application.
Yes, regarding the Python example, you could use the same pattern in PHP,
Ruby, C... That and in Python all those functions would just be one liner
wrappers around the built in raw_input function.
Okay, going to stick with edu.harvard.CS50 for now, until we have (if ever) an occasion to have classes besides CS50. Thanks!