2006/12/15, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
Oliver Deakin wrote: > Alexey Varlamov wrote: >> 2006/12/14, Oliver Deakin <[EMAIL PROTECTED]>: >>> Geir Magnusson Jr. wrote: >>> > >>> > >>> > Alexey Varlamov wrote: >>> >> 2006/12/14, Geir Magnusson Jr. <[EMAIL PROTECTED]>: >>> >>> >>> >>> >>> >>> Tim Ellison wrote: >>> >>> > Gregory Shimansky wrote: >>> >>> >> Tim Ellison wrote: >>> >>> >>> Gregory Shimansky wrote: >>> >>> >>>> Tim Ellison wrote: >>> >>> >>>>> Maybe we do, i.e. where there is no value "-Dfoobar". So >>> >>> perhaps we >>> >>> >>>>> need to say that GetSystemProperty returns VMI_ERROR_NONE and >>> >>> sets the >>> >>> >>>>> the *valuePtr to NULL if there is no value; and returns a >>> >>> >>>>> VMI_ERROR_NOT_FOUND if the property is undefined. >>> >>> >>>> Now I am confused. What is the difference between a property >>> >>> which has >>> >>> >>>> no value and an undefined property? >>> >>> >>> Sorry, I meant a property whose value is NULL. So the three >>> >>> cases are: >>> >>> >>> >>> >>> >>> 1) key = "foo", value = "bar" >>> >>> >>> 2) key = "foo", value = NULL >>> >>> >>> 3) no key called "foo" >>> >>> >>> >>> >>> >>> If (2) is disallowed then we should document that in >>> >>> SetSystemProperty(). >>> >>> >> I would prefer to have (2) to be illegal. Can we document this >>> >>> please? >>> >>> > >>> >>> > No objection here. So to attempt a new clarification ... >>> >>> > >>> >>> > GetSystemProperty will return VMI_ERROR_NONE and a string value >>> for >>> >>> > existing properties, or NULL value for a non-existent property. >>> >>> > >>> >>> > We then rename VMI_ERROR_NOT_FOUND to VMI_ERROR_ILLEGAL_ARG and >>> >>> > SetSystemProperty will return VMI_ERROR_NONE for setting an >>> existing >>> >>> > property to a string value, or VMI_ILLEGAL_ARG if there is an >>> >>> attempt to >>> >>> > set the property value to NULL. >>> >>> > >>> >>> > How does that sound? >>> >>> >>> >>> Why again do we want 2 to be illegal? (Sorry, was out of pocket >>> for a >>> >>> while there yesterday...) >>> >> >>> >> This is aligned with the API specification for >>> >> j.l.System.[s|g]etProperty(), which explicitly disallowes NULLs for >>> >> both keys and values. >>> > >>> > Why do I care about the Java API here? >>> > >>> >>> I think we need to here since we're talking about properties that are >>> accessible from Java. Do we want to be able to set a property that is >>> accessible from Java to a value that is invalid by the Java API? If >>> someone >>> calls System.getProperty() on a key that has NULL value, what do we >>> return? >>> Do we benefit from allowing NULL values? >>> >>> My personal feeling is that we should follow the Java API here, since >>> we're changing Java properties. >> >> Exactly! I said very same thing in parallel thread (BTW is it a bug of >> some mailer - reply going to a new thread with "Re:" ?). >> > > (Re: mailer bug - possibly, I see them split out of the thread as well, > but with > the correct "Re:" mail subject. Annoying because it breaks up the flow > of the > thread, and responses are easily missed/lost.) > >> So I believe we have true agreement here. > > Great! Geir, does this answer your question? It answers the question above, but didn't answer my earlier question (I think I asked, of why *not* to have (key, NULL)? The impl of System.getProperty() can enforce the API of System.getProperty(), but if we find it useful as a general facility in the VMI, why not?
Well, IMO the equvalent question is: do we really find (key, NULL) so useful that ready to bear inconvenience or ambiguity of mapping such VMI properties to Java?
The only reason I can think of is to avoid the extra NULL check (in Java), but you have to look at the result code anyway when using GetSystemProp(), right? geir > > Regards, > Oliver > >> >> >>> >>> Regards, >>> Oliver >>> >>> > geir >>> > >>> >>> -- >>> Oliver Deakin >>> IBM United Kingdom Limited >>> >>> >> >
