once methods currently cache their result, but accept no parameters.

memo methods have a hashtable, where the key is the arguments to that method, and the value is the result.

the suggestion is to enhance once methods to that mechanism, and remove the restriction of zero passed arguments.

Those methods are not supposed to be affected from state changes. they should be purely functional, and only depend on the arguments.

The developer will be responsible for that part, if there are no mechanisms to validate "purity".

so fib 41 will be quick to return if fib 40 and fib 39 will return the cached result.

I've seen this in the factor programming language, I guess there are other languages that implement it.

http://docs.factorcode.org/content/article-memoize.html

It occured to me that the syntax of once before a class, may make it a singleton class. What do you think?

I think that singleton classes are an abomination in good design and should be ruthlessly and mercilessly mocked, not supported actively by syntax. ;)

ooh, such strong feelings! ;-)

I actually found the singleton pattern very helpful in numerous occasions. Sometimes you just want one "manager" object, that is easy to access from anywhere.

And you may need it in runtime, instead of a static, because it may need to initialize or connect to a database, or do something that happens with live objects.

I saw a language (nemerle) where they have attribute macros that expanded to such patterns. Nemerle as a language was too alien for me, it even has list comprehensions -- that must be a symptom for non-human intervention, hehe. while I'm more of the human 1-indexed arrays :)

In any case, expandable macros like that was a nice feature. I especially liked the Proxy pattern, the inner objects implement the behaviour but it looks like the behaviour originates in the encompassing class. So it looks like multiple inheritance but done cleanly.

(more or less. it has its own issues, i think, wrt syncing)

Sometimes you just want one "manager" object, that is easy to access from anywhere.

sys::Service#find?

I like that idea, but seems a little too "functional" for Fantom since we have so many methods with side effects. I think that would work better when most or all functions were pure with no side-effects.

What if the function were const?

What if the function were const?

We don't really have const functions. Originally I was going to allow const functions to be compile time checked for purity sort of like D does. But I felt it wasn't quite right for Fantom and would lead to "const correctness" mess that can happen in languages like C++.

the suggestion is to enhance once methods to that mechanism, and remove the restriction of zero passed arguments.

Perhaps we could require that the parameters to once methods be const types?