Quoting [Thilo Kielmann] (Jun 03 2009):
On Wed, Jun 03, 2009 at 02:09:25PM +0200, Andre Merzky wrote:
I may want to add that also not all languages support more than the last modification time, e.g. Java only has this one...
Thats interesting. Not relevant, but is that because Java meets the smallest common denominator here? Simple file systems such as FAT only support mtime, ususally, AFAIK.
Does Java have a stat call?
AFAIK, Java is considered to be an "application" programming language, as opposed to systems programming languages. You can find this back e.g. in the stream-based file API, where random seeks are "not done" by typical Java applications. (read/write/seek had only been added later, but "real Java programmers" (-tm) don't use it ;-)
To the best of my knowledge, there is no stat either.
Using the attributes for the modification time (while having get_* for file size) seems odd to me.
We should then move size into the attributes, too. I agree that this should be done in a consistent way.
Hmm, I must admit that I am not too familiar with the proper use of attributes in SAGA. I know we have them, but I never got beyond a vague feeling that they could be useful "somewhere"...
Things which are considered 'properties' or 'meta data' (for whatever vague definition you want) of objects, are mostly exposed as attributes. Usually, changing attributes does not directly change object state, nor trigger any remote operation, etc. Mostly, attributes are informational (and thus often read-only). As you see, the above is rather vague, and involves a lot of handwaving. Nevertheless, a good rule of thumb is: If a SAGA object has a significan number of set_xxx/get_xxx methods, which just return simple data types, the attribute interface should be used. An excellent example is the job_description of course, but others are the job class (exposing memory usage, state, walltime etc via attributes) and replicas (user defined meta data are attached to replica entries as attributes).
In SAGA's file (and ns_entry) classes, I can find all commonly used information via get_*() methods. Which information do file's provide via attributes??? What I mean: I cannot see a single attribute in file, so why now start introducing them???
The only getters on ns_entry are get_url(), get_path() and get_name(), the only additional one in file is get_size(). Back then, we did not think this would be enough to justify the use of the attribute interface. Now, if we add get_atime, get_mtime, get_ctime, and get_btime, then it may be worth to reconsider. If we only go for get_mtime (as seems likely), nothing changes really, IMHO.
The use of the templetized accessors is motivated by the fact that we have it on task.get_result <type> () already, which was actually proposed by Ceriel, and back then you liked it a lot ;-)
I never (mentally) mapped task.get_result to typed attributes. Maybe some more background on them would help me getting a deeper understanding?
Well, consider the following two tasks: saga::task t_1 = file.get_name <saga::task::ASync> (); saga::task t_2 = file.get_size <saga::task::ASync> (); get_name would return a URL, get_size returns an int. Thus, you need to mark the get_result() function so that the correct type is used. We do that with templates in C++, and I though you'd do the same in Java? Anyway, flags and different names are also possible, but more difficult to maintain, and, at least in C++, somwhat non-native: // method templates saga::url u = t_1.get_result <saga::url> (); int s = t_2.get_result <int> (); Alternatives: // names saga::url u = t_1.get_url_result (); int s = t_2.get_int_result (); // flags saga::url u = t_1.get_result (saga::type::Url); int s = t_2.get_result (saga::type::Int); So, which is it in Java? As for attributes, that would (again in C++) look very similar. At the moment, we have only strings: std::string bufsize_s = stream.get_attribute ("BufSize"); The typed version we intent to propose would likely look like: int bufsize = stream.get_attribute <int> ("BufSize"); So, would be similar to get_result(). And also similar to task.get_object() btw, the only other templetized/typed method in the SAGA core spec. While we are on that topic: the spec is actually silent on what happens if the types mismatch, e.g. if I try to call: // spec defines BufSize to be of type int! float bufsize = stream.get_attribute <float> ("BufSize"); // throws In particular, we do not define an exception which semantically maps that case, apart from NoSuccess (which can always be used - that is what we do in C++ right now). Would people think that adding a 'IncorrectType' exception for that reason would make sense? It could also be resolved on language binding level, possibly. How does Java handle that? Thanks, Andre. -- Nothing is ever easy.