Perhaps this is something we could discuss next week in Catania 2009/2/25 Ceriel Jacobs <ceriel@cs.vu.nl>:
Andre Merzky wrote:
Quoting [Ceriel Jacobs] (Feb 25 2009):
Andre Merzky wrote:
Quoting [Ceriel Jacobs] (Feb 20 2009):
(who quoted Steve Fisher)
The user can also create a context with a type known to him and to the implementation. He may need to set attributes of this context before it can be used. The implementation must not modify any attributes - though the constructor may set attributes to sensible defaults which can then be modified by the user.
The set_defaults call should *not* be in the spec - it is purely an implementation thing.
I think I agree with that. It is a pity that the Context constructor has a default value "" for the context type. IMHO, the Type attribute should only have read access and be set by the Context constructor, which should then also call set_defaults, which then does not have to be in the API.
Calling set_defaults() in the c'tor breaks. That was actually in the spec at some point, but:
saga::context c ("globus"); c.set_attribute ("UserProxy", "/tmp/non-default-proxy.x509"); c.set_defaults ();
Well, calling set_defaults in the constructor IS in the specs, at least it is in the 1.0 version, which is still the official version, is it not? There, it sais in the Notes: if a type is given, then the CONSTRUCTOR internally calls set_defaults().
Right - the errata remove that call.
The c'tor would throw NoSuccess if no default globus proxy exists. Then, how would you create a globus context which points to a non-default proxy location, like above?
I don't know that the c'tor would throw NoSuccess. Maybe a default UserProxy file does not exist, but is set_defaults() the right time to check?
When else can you check? On setting the attribute would be an option - but throwing there would confuse: the exceptions defined on set_attribute are attribute related, not related to the semantics of the context. One could also check internally at the first time the context is being used, but then it is hard to predict on API level when that exception will come, and again it is probably in a context unrelated to the, uhm, context (pun unintented). So, set_defaults provides a good opportnity to flag any inconsistencies.
I would indeed check the first time the context is being used. I don't think it is hard to predict on API level when an exception will come, because virtually all methods can throw a corresponding exception. Also, set_defaults may possibly detect SOME inconsistencies, but certainly not all.
Yes, one could argue if an empty type on context creation makes sense, or if one should mandate a valid string. Given that an empty string is a 'valid' string in most languages, that is not much different from other invalid strings like 'klopus'. We have defined error conditions for calling set_defaults() on invalid context attributes. I don't think that this is a big problem at the moment?
I guess there is a difference between "" and "klopus" in that "" is IMHO supposed to mean that the Type is not yet specified, whereas "klopus" specifies a Type, on which the constructor will call set_defaults(), which will probably cause an exception.
Again, set_defaults() in the c'tor cannot work - you could never create a context with a non-default location for the globus proxy file.
Indeed, not if you want set_defaults to do all the things you describe. But I don't think set_defaults is the right place. If you set some attributes explicitly, like "UserProxy", or "UserId", or "UserPass", there is no check either. In general, the first time you notice that something is wrong is when you try to actually use the context. I don't see why this should be any different if you use set_defaults. For instance, you could create an ftp context with perfectly reasonable default values for UserId and UserPass, but if you then connect to an ftp server that does not allow anonymous access, you still have a problem. So, I think a cleaner design would be to not have set_defaults, and to have the context constructor set some reasonable default values (if a Type is specified). It would then be up to the user to make sure that the default values actually work.
Cheers, Ceriel