Hi all, during a discussion with Hartmut today, we stumbled over the question of copy behavious for the SAGA objects. Consider following code: ---------------------------------------------------------------------- 0 saga::job_description jd_1; 1 2 jd_1.set_attribute ("SAGA_Host", "host_1"); 3 4 cout << jd_1.get_attribute ("SAGA_Host")) << endl; 5 6 7 saga::job_description jd_2 = jd_1; 8 9 cout << jd_2.get_attribute ("SAGA_Host")) << endl; 10 11 jd_2.set_attribute ("SAGA_Host", "host_2"); 12 13 cout << jd_1.get_attribute ("SAGA_Hoset")) << endl; 13 cout << jd_2.get_attribute ("SAGA_Hoset")) << endl; ---------------------------------------------------------------------- What would that print? If the copy in line 4 is a deep copy, it would print: host_1 // jd_1 orig host_1 // jd_2 as copy from jd_1 host_1 // jd_1 orig still host_2 // jd_2 newly set if it is a shallow copy, it would be: host_1 // jd_1 orig <not defined> // jd_2 not defined yet host_1 // jd_1 orig still host_2 // jd_2 newly set if SAGA objects are only handled as references, it would be: host_1 // jd_1 orig host_1 // jd_2 as reference to jd_1 host_2 // jd_1 newly set (via jd_1 ref) host_2 // jd_2 just the same as jd_1 As the SAGA implementation should obviously show the same behaviour (either one for now), the spec needs to define that obviously. We think, that a default shallow copy is the most useful one. If for some objects a deep copy makes sense, a clone() method could be defined, which has the explicit semantics of a deep copy. If a reference is needed for some object, the native language can usually be used to obtain such one. So, if shallow copy as default, all three of the above cases seem easily implementable if needed. If there are no opinions against that, I'll add the respective note to the spec. Many thanks, Andre. -- +-----------------------------------------------------------------+ | Andre Merzky | phon: +31 - 20 - 598 - 7759 | | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 | | Dept. of Computer Science | mail: merzky@cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+
Hi Andre and all, regarding copy semanctics of SAGA calls: (shallow vs. deep vs. references)
As the SAGA implementation should obviously show the same behaviour (either one for now), the spec needs to define that obviously.
Not quite. These issues are certainly beyond SAGA functionality. Rather, this should be addressed by the respective language bindings. For each language, the SAGA spec might "prescribe" to stick with the conventions of each language. IMHO, this would contribute to the "simple" attribute of SAGA: it would be simple as would do in any language what programmers are used to. In your case, the C++ binding could prescribe shallow copies (and maybe explicit "clone"), as this is what C++ does usually... My two cents, Thilo -- Thilo Kielmann http://www.cs.vu.nl/~kielmann/
Hi Thilo, Quoting [Thilo Kielmann] (Sep 11 2005):
Hi Andre and all,
regarding copy semanctics of SAGA calls: (shallow vs. deep vs. references)
As the SAGA implementation should obviously show the
Ah, typo: implemention_S_
same behaviour (either one for now), the spec needs to define that obviously.
Not quite. These issues are certainly beyond SAGA functionality. Rather, this should be addressed by the respective language bindings. For each language, the SAGA spec might "prescribe" to stick with the conventions of each language. IMHO, this would contribute to the "simple" attribute of SAGA: it would be simple as would do in any language what programmers are used to.
In your case, the C++ binding could prescribe shallow copies (and maybe explicit "clone"), as this is what C++ does usually...
I think I disagree here. For one thing, as far as I understood there is no convention which holds for C++ in general, or for C in general etc. Second, that would lead to semantical differences in the different languages. I guess we don't want that. E.g., the following code would then possibly behave differently in C++/Java: +-----------------------------------------------------------------+ saga::job_description jd_1 = my_job.get_job_description (); saga::job_description jd_2 = jd_1; jd_2.set_attribute ("SAGA_Host", "localhost"); +-----------------------------------------------------------------+ The state of jd_2 would differ in C++ and Java then, and I'd think we would like to avoid that, don't we? If we allow that, you basically have to re-learn (small parts of) the semantics for SAGA for each language... Cheers, Andre.
My two cents,
Thilo
-- +-----------------------------------------------------------------+ | Andre Merzky | phon: +31 - 20 - 598 - 7759 | | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 | | Dept. of Computer Science | mail: merzky@cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+
On Sun, Sep 11, 2005 at 01:47:02PM +0200, Andre Merzky wrote:
I think I disagree here. For one thing, as far as I understood there is no convention which holds for C++ in general, or for C in general etc.
Bad enough for C++...
Second, that would lead to semantical differences in the different languages. I guess we don't want that. E.g., the following code would then possibly behave differently in C++/Java:
+-----------------------------------------------------------------+ saga::job_description jd_1 = my_job.get_job_description (); saga::job_description jd_2 = jd_1;
jd_2.set_attribute ("SAGA_Host", "localhost"); +-----------------------------------------------------------------+
The state of jd_2 would differ in C++ and Java then, and I'd think we would like to avoid that, don't we? If we allow that, you basically have to re-learn (small parts of) the semantics for SAGA for each language...
Who cares? Again, this is a language detail, NOT SAGA. It is more important that SAGA doesn't prescibe deviations from "the usual things" in a language. BTW: if you write a program in which this difference is important, your program is badly written. If you are the kind of programmer who makes use of these details, you know that you have to read the docs of your language binding (or even implementation) to find out... I don't care, I don't write (such ;-) programs... Thilo -- Thilo Kielmann http://www.cs.vu.nl/~kielmann/
Quoting [Thilo Kielmann] (Sep 11 2005):
On Sun, Sep 11, 2005 at 01:47:02PM +0200, Andre Merzky wrote:
I think I disagree here. For one thing, as far as I understood there is no convention which holds for C++ in general, or for C in general etc.
Bad enough for C++...
Well, what is the convention in Java? Is there any?
Second, that would lead to semantical differences in the different languages. I guess we don't want that. E.g., the following code would then possibly behave differently in C++/Java:
+-----------------------------------------------------------------+ saga::job_description jd_1 = my_job.get_job_description (); saga::job_description jd_2 = jd_1;
jd_2.set_attribute ("SAGA_Host", "localhost"); +-----------------------------------------------------------------+
The state of jd_2 would differ in C++ and Java then, and I'd think we would like to avoid that, don't we? If we allow that, you basically have to re-learn (small parts of) the semantics for SAGA for each language...
Who cares? Again, this is a language detail, NOT SAGA.
That is what I disagree with :-)
It is more important that SAGA doesn't prescibe deviations from "the usual things" in a language.
BTW: if you write a program in which this difference is important, your program is badly written. If you are the kind of programmer who makes use of these details, you know that you have to read the docs of your language binding (or even implementation) to find out...
The code snippet above is not badly written, but does depend on the semantics of the copy operator. Any assignement operation (so any '=' with SAGA objects involved) will expose the problem. But you cannot argue that a programmer using '=' is writing bad code ;-) Cheers, Andre. -- +-----------------------------------------------------------------+ | Andre Merzky | phon: +31 - 20 - 598 - 7759 | | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 | | Dept. of Computer Science | mail: merzky@cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+
On Sun, Sep 11, 2005 at 02:10:28PM +0200, Andre Merzky wrote:
The code snippet above is not badly written, but does depend on the semantics of the copy operator. Any assignement operation (so any '=' with SAGA objects involved) will expose the problem. But you cannot argue that a programmer using '=' is writing bad code ;-)
Using '=' isn't bad. But creating an alias is (which, in fact, you do here ;-) Thilo -- Thilo Kielmann http://www.cs.vu.nl/~kielmann/
At 05:15 AM 9/11/2005, Thilo Kielmann wrote:
On Sun, Sep 11, 2005 at 02:10:28PM +0200, Andre Merzky wrote:
The code snippet above is not badly written, but does depend on the semantics of the copy operator. Any assignement operation (so any '=' with SAGA objects involved) will expose the problem. But you cannot argue that a programmer using '=' is writing bad code ;-)
Using '=' isn't bad. But creating an alias is (which, in fact, you do here ;-)
But that's the issue here: depending on the copy/assignment semantics, you are either (1) creating a copy, or (2) creating an alias. This means that a SAGA programmer (to avoid "bad" programming) would constantly have to be aware of the language binding context, since each binding context could have different copy semantics. But, one could argue that when programming in a given language, the copy/assignment operator will be used for both SAGA and non-SAGA objects. That is to say, the programmer should be/will be aware of the copy/assignment semantics throughout the program. I agree that differing copy/assignment semantics could cause problems for a programmer, but I don't see how a SAGA binding could dictate copy/assignment semantics that are different from a language's "native" semantics. Besides being difficult or impossible to implement, this means that different objects within a single program could have different copy/assignment behavior, depending on whether they were SAGA or non-SAGA objects. This, too, could cause problems. I think this should be left as a language binding issue. Nonetheless, the SAGA API doc could have a prominent "Advice to Practitioners" section that identifies and discusses these binding pitfalls. my $0.02, --Craig
Thilo -- Thilo Kielmann http://www.cs.vu.nl/~kielmann/
Craig Lee wrote:
At 05:15 AM 9/11/2005, Thilo Kielmann wrote:
On Sun, Sep 11, 2005 at 02:10:28PM +0200, Andre Merzky wrote:
The code snippet above is not badly written, but does depend on the semantics of the copy operator. Any assignement operation (so any '=' with SAGA objects involved) will expose the problem. But you cannot argue that a programmer using '=' is writing bad code ;-)
Using '=' isn't bad. But creating an alias is (which, in fact, you do here ;-)
But that's the issue here: depending on the copy/assignment semantics, you are either (1) creating a copy, or (2) creating an alias.
This means that a SAGA programmer (to avoid "bad" programming) would constantly have to be aware of the language binding context, since each binding context could have different copy semantics.
But, one could argue that when programming in a given language, the copy/assignment operator will be used for both SAGA and non-SAGA objects. That is to say, the programmer should be/will be aware of the copy/assignment semantics throughout the program.
I agree that differing copy/assignment semantics could cause problems for a programmer, but I don't see how a SAGA binding could dictate copy/assignment semantics that are different from a language's "native" semantics. Besides being difficult or impossible to implement, this means that different objects within a single program could have different copy/assignment behavior, depending on whether they were SAGA or non-SAGA objects. This, too, could cause problems.
I think this should be left as a language binding issue. Nonetheless, the SAGA API doc could have a prominent "Advice to Practitioners" section that identifies and discusses these binding pitfalls.
C++ allows both semantics (Java doesn't?) so you still need to make a choice, otherwise different C++ implementations will have different semantics. I personally like the Java style and also use it in C++ but not having a garbage collector makes it a bit tricky, you cannot have circular references. Or maybe somebody knows a good garbage collector for C++ that should be integrated in the SAGA engine(s) so we don't even have that issue. Andrei
participants (4)
-
Andre Merzky -
Andrei Hutanu -
Craig Lee -
Thilo Kielmann