View mode: basic / threaded / horizontal-split · Log in · Help
May 12, 2012
Memoize and protected functions
Functions you want to memoize have to be visible to 
std.functional.memoize, so it only works with public functions. 
Is this a bug or merely a bugbear?
May 12, 2012
Re: Memoize and protected functions
On Saturday, 12 May 2012 at 09:08:30 UTC, John Chapman wrote:
> Functions you want to memoize have to be visible to 
> std.functional.memoize, so it only works with public functions.

This is an artifact of the way access protection for alias 
parameters is currently implemented – when accessing 
(»resolving«) an alias parameter, protection attributes are 
checked in the same way as if you just wrote the symbol name, 
i.e. in the scope of the module where e.g. memoize is defined.

In my opinion, this is a … uhm … _questionable_ design 
decision, even more so than the fact that private module members 
are not at all private to that module (as they are still taken 
into account for overload resolution). Several other issues, e.g. 
being unable to std.concurrency.spawn() private functions, are 
also caused by this.

David
May 12, 2012
Re: Memoize and protected functions
On Saturday, 12 May 2012 at 11:33:10 UTC, David Nadlinger wrote:
> In my opinion, this is a … uhm … _questionable_ design 
> decision, […]

If it wasn't clear from the context: I'd propose to instead check 
protection for aliases exactly once at the place where it is 
»created«. In my opinion, this is clearly the behavior that one 
would intuitively expect, just like for (e.g. function) pointers, 
where it doesn't matter if the type system would allow you to 
access the entity directly once somebody who is allowed to passed 
you a reference.

The only possible complication I can see right now caused by this 
is with (rarely used) synchronized classes, where a closer look 
might be necessary regarding aliases to private functions (which 
are not automatically protected by the class mutex).

David
Top | Discussion index | About this forum | D home