E
Eivind Eklund
Please keep me in the Cc: list - I'm not subscribed to the mailing
list.
I noticed some of you were saying you used StrongTyping extensively;
you might consider the following useful:
http://people.freebsd.org/~eivind/ruby/types/
It is a much more flexible typesystem for Ruby, and predates
StrongTyping. The system allows mixed types (Type::Or, Type::And),
handles respond_to (Type::Respond), classes, regular expressions,
pure code as invariant, varying types of some parameters depending
on what the other parameters are, etc. Basically it is a language
for specifying precondtions to methods, and one that is more compact
for this purpose than normal Ruby.
The code also does automatic normalization of types, so if an
equivalent type is specified several times, only one instance is
kept in memory.
The reason I didn't do any particularly public release of it was
that I found that adding type checks to ruby programs were worse
than useless for me - it got in the way of my refactoring, without
catching many bugs.
If people find this useful in practice, I have a couple of improvements
I remember wanting to make (and still might hack up):
- Introspection. There is presently no API for accessing the
information once applied.
- The type system should support co-variant or parameterized types.
Presently, it would be limited to using typeless containers or
manually parallelly typed containers, due to contravariant types.
- Extending this to implement a complete design-by-contract system.
This is the only way I know of to make the type system likely to
work really well. I'd like to do the following:
- Use modules as interfaces (similar to what has been suggested
in another thread earlier today), but using full
preconditions/postconditions on the methods implemented to
specify types.
- Implement 'pre' for postconditions to access previous values
in the context of postconditions.
This can be done using a mod to the core ruby interpreter/parser
to allow me to add keywords dynamically (which might also allow
a better syntax for the typing itself - the typesigs used
presently are somewhat ugly, and including the type in the
parameter list would be better).
It can also be done by extracting the parser code from irb, and
passing the postcondition as a string instead of block.
Eivind.
list.
I noticed some of you were saying you used StrongTyping extensively;
you might consider the following useful:
http://people.freebsd.org/~eivind/ruby/types/
It is a much more flexible typesystem for Ruby, and predates
StrongTyping. The system allows mixed types (Type::Or, Type::And),
handles respond_to (Type::Respond), classes, regular expressions,
pure code as invariant, varying types of some parameters depending
on what the other parameters are, etc. Basically it is a language
for specifying precondtions to methods, and one that is more compact
for this purpose than normal Ruby.
The code also does automatic normalization of types, so if an
equivalent type is specified several times, only one instance is
kept in memory.
The reason I didn't do any particularly public release of it was
that I found that adding type checks to ruby programs were worse
than useless for me - it got in the way of my refactoring, without
catching many bugs.
If people find this useful in practice, I have a couple of improvements
I remember wanting to make (and still might hack up):
- Introspection. There is presently no API for accessing the
information once applied.
- The type system should support co-variant or parameterized types.
Presently, it would be limited to using typeless containers or
manually parallelly typed containers, due to contravariant types.
- Extending this to implement a complete design-by-contract system.
This is the only way I know of to make the type system likely to
work really well. I'd like to do the following:
- Use modules as interfaces (similar to what has been suggested
in another thread earlier today), but using full
preconditions/postconditions on the methods implemented to
specify types.
- Implement 'pre' for postconditions to access previous values
in the context of postconditions.
This can be done using a mod to the core ruby interpreter/parser
to allow me to add keywords dynamically (which might also allow
a better syntax for the typing itself - the typesigs used
presently are somewhat ugly, and including the type in the
parameter list would be better).
It can also be done by extracting the parser code from irb, and
passing the postcondition as a string instead of block.
Eivind.