Simon Urbanek wrote:
> Seth,
>
> thanks for the suggestions.
>
> On Oct 18, 2006, at 11:23 AM, Seth Falcon wrote:
>
>> Simon Urbanek <[EMAIL PROTECTED]> writes:
>>> thanks, but this is not what I want (the symbols in the environment
>>> are invisible outside) and it has nothing to do with the question I
>>> posed: as I was saying in the previous e-mail the point is to have
>>> exported variables in a namespace, but their value is known only
>>> after the namespace was attached (to be precise I'm talking about
>>> rJava here and many variables are valid only after the VM was
>>> initialized - using them before is an error).
>> We have a similar use case and here is one workaround:
>>
>> Define an environment in your name space and use it to store the
>> information that you get after VM-init.
>>
>> There are a number of ways to expose this:
>>
>> * Export the env and use vmEnv$foo
>>
>> * Provide accessor functions, getVmFooInfo()
>>
>> * Or you can take the accessor function approach a bit further to make
>> things look like a regular variable by using active bindings. I can
>> give more details if you want. We are using this in the BSgenome
>> package in BioC.
>>
>
> I'm aware of all three solutions and I've tested all three of them
> (there is in fact a fourth one I'm actually using, but I won't go
> into detail on that one ;)). Active bindings are the closest you can
> get, but then the value is retrieved each time which I would like to
> avoid.
>
> The solution with promises is very elegant, because it guarantees
> that on success the final value will be locked. It also makes sense
> semantically, because the value is determined by code bound to the
> variable and premature evaluation is an error - just perfect.
>
> Probably I should have been more clear in my original e-mail - the
> question was not to find a work-around, I have plenty of them ;), the
> question was whether the behavior of promises under error conditions
> is desirable or not (see subject ;)). For the internal use of
> promises it is irrelevant, because promises as function arguments are
> discarded when an error condition arises. However, if used in the
> "wild", the behavior as described would be IMHO more useful.
>
Promises were never intended for use at the user level, and I don't
think that they can easily be made useful at that level without exposing
a lot of stuff that cannot easily be explained/made bullet proof. As
Brian said, you have not told us what you want, and I am pretty sure
that there are good solutions available at the R level for most problems.
Although the discussion has not really started, things like dispatch
in the S4 system are likely to make lazy evaluation a thing of the past
since it is pretty hard to dispatch on class without knowing what the
class is. That means, that as we move to more S4 methods/dispatch we
will be doing more evaluation of arguments.
best wishes
Robert
> Cheers,
> Simon
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Robert Gentleman, PhD
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
PO Box 19024
Seattle, Washington 98109-1024
206-667-7700
[EMAIL PROTECTED]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
