Old-style tuple slot accessors are still defined for all tuples. I will be porting code over the next few months to use the new accessors. All new code should use the new accessors. The old accessors will be removed at the end of May.
Next up in the language change department:
- Implementation inheritance for tuple classes.
- Removing delegation from the core and replacing it by Daniel Ehrenberg's
extra/delegation
library. - New tuple syntax with named slots.
- Moving Doug Coleman's singletons to the core.
- Moving
extra/multi-methods
into the core and removing the current generic word system; I have blogged about the multi-methods library in the past. - Declarative sequence construction using Eduardo's
extra/bake
library should be merged into the core. It can replace a whole slew of utility words and make Factor easier to learn.
Each one of these changes will be accompanied by refactorings of Factor's codebase to use the new features where appropriate.
I will spend the next few days dealing with the fallout from the new-slots merge; I also have a few minor features I want to get out of the way. Once that is done I will return to working on the web framework while continuing to ponder the implementation details of inheritance in my head. Once those are worked out I will dive back into the core.
These language changes are coming rather late in the evolution of Factor, however their utility, along with the recently merged
new-slots
, only became apparent after we wrote a lot of code, and so the justification for incorporating these features and removing the ones they replace is based on real experience and not just theoretical concerns.Once these features are done I will be happy with the state of Factor's language and my focus will shift to performance, documentation, and peripheral libraries. Then, Factor 1.0 will be released and heads will roll.
5 comments:
Hi,
singletons are evil.
They are in the way of proper unit testing.
Just like global functions.
For instance I can not mock up System.currentTimeMillis() in Java which prevents LOTS of unit testing.
Any chance a new language could do better?
Factor singletons don't have state, they're just symbols which can be dispatched on. They don't hinder unit testing at all.
> Factor singletons don't have state,
> they're just symbols which can be dispatched on.
> They don't hinder unit testing at all.
Slava, thanks for you reply!
Good to hear this.
Getting deeper into Factor to find out myself what's good and what can be bettered is still no my looongish TODO list. However today I'd decided to write down my long waiting ideas on language modularization and unit testability.
The text may not be worth anybody's attention but since I feel it may be relevant, here's the link
http://atagunov.blogspot.com/2008/03/singleton-free-jre.html
definitely got a problem with links. here's a better link my post on the desired programming language support for modularization and unit-testing
Post a Comment