search for: getifexists

...> NULL / error() / .. or similar > } > i.e. many exists() calls when returning TRUE are immediately followed by the > corresponding get() call which repeats quite a bit of the lookup that exists() > has done. > Instead, I'd imagine a function, say getifexists(name, ...) that does both at > once in the "exists is TRUE" case but in a way we can easily keep the if(.) .. > else clause above. One already existing approach would use > if(!inherits(tryCatch(xx <- get(name, where, ...), error=function(e)e), "error")...

...t. And yes, as you mention the dromedars aka 2-hump camels: getIfExist is already horrible to my taste (and "_" is not S-like; yes that's all very much a matter of taste and yes I'm from the 20th century). > To avoid this difficulty, perhaps we want both: have Martin's getifexists( ) > return a list with two values: > - a boolean variable 'found' # = value returned by exists( ) > - a variable 'value' > Then implement get( ) as: > get <- function(x,...,value.if.not.found ) { > if( missing(value.if.not.found) ) { > a <...

...give a NULL because either x exists and has value NULL, or because x doesn't exist. If that matters, the user would need to be careful about specifying a value.if.not.found that cannot be confused with a valid value of x. To avoid this difficulty, perhaps we want both: have Martin's getifexists( ) return a list with two values: - a boolean variable 'found' # = value returned by exists( ) - a variable 'value' Then implement get( ) as: get <- function(x,...,value.if.not.found ) { if( missing(value.if.not.found) ) { a <- getifexists(x,... ) if (!a$fo...

...either x exists and > has value NULL, or because x doesn't exist. If that matters, the user > would need to be careful about specifying a value.if.not.found that cannot > be confused with a valid value of x. > > To avoid this difficulty, perhaps we want both: have Martin's getifexists( > ) > return a list with two values: > - a boolean variable 'found' # = value returned by exists( ) > - a variable 'value' > > Then implement get( ) as: > > get <- function(x,...,value.if.not.found ) { > > if( missing(value.if.not.found) ) {...

...either x exists and > has value NULL, or because x doesn't exist. If that matters, the user > would need to be careful about specifying a value.if.not.found that cannot > be confused with a valid value of x. > > To avoid this difficulty, perhaps we want both: have Martin's getifexists( ) > return a list with two values: > - a boolean variable 'found' # = value returned by exists( ) > - a variable 'value' > > Then implement get( ) as: > > get <- function(x,...,value.if.not.found ) { > > if( missing(value.if.not.found) ) { &g...

...r issues that would have to be thought through before going forward, such as what happens if an rm occurs between obtaining a binding object and doing something with it. Serialization would also need thinking through. This doesn't seem like a worthwhile place to spend our efforts to me. Adding getIfExists, or .get, or get0, or whatever seems fine. Adding an argument to get() with missing giving current behavior may be OK too. Rewriting exists and get as .Primitives may be sufficient though. Best, luke > Michael > > > > > On Thu, Jan 8, 2015 at 6:03 AM, John Nolan <jpnolan at...

...expose any internals. We could implement the behavior using SYMSXP, or not. Nor would the binding need to be mutable. The binding would be considered independent of the environment from which it was retrieved. As Pete has mentioned, it could be a useful abstraction to have in general. > Adding getIfExists, or .get, or get0, or whatever seems fine. Adding > an argument to get() with missing giving current behavior may be OK > too. Rewriting exists and get as .Primitives may be sufficient though. > > Best, > > luke > > > Michael >> >> >> >> >>...

...idered independent of the > environment from which it was retrieved. As Pete has mentioned, it could be > a useful abstraction to have in general. It could be, indeed. Luke's advice (above) and my own gut feeling do tell me that this is a much larger step than solving the "getIfExists()" problem. In the R development cycle I'd think that it should go to the next (2015-2016) "3.3" cycle, rather than the current "3.2" one with goal in April. >> Adding getIfExists, or .get, or get0, or whatever seems fine. Adding >> an argument to...

...bound value (like R_UnboundValue). >>>> >>> >>> A null default is fine -- it's a default; if it isn't right for a >>> particular case you can provide something else. >>> [..................] >>> Adding getIfExists, or .get, or get0, or whatever seems fine. Adding >>> an argument to get() with missing giving current behavior may be OK >>> too. Rewriting exists and get as .Primitives may be sufficient though. > Thank you, Luke. Given that, Duncan's and the other inputs,...

Hi LLVM, If I have an llvm value "<16 x float> addrspace(1)* %in", and in the LLVM IR, there is a @llvm.dbg.value like: call void @llvm.dbg.value(metadata <16 x float> addrspace(1)* %in, i64 0, metadata !216, metadata !28), !dbg !217 How I can retrieve this @llvm.dbg.value when I have "%in"? Since Metadata is not a part of the uselist anymore, is there some way