Oren Eini

CEO of RavenDB

a NoSQL Open Source Document Database

Get in touch with me:

oren@ravendb.net +972 52-548-6969

Posts: 7,583
|
Comments: 51,213
Privacy Policy · Terms
filter by tags archive
time to read 2 min | 213 words

Today I'd twice began writing a question to Boo's mailing list, after fighting with the code for several hours (each time), only to realize that I already know the answer.

To be rather exact, it was to process of formulating the problem so other people could understand it was what mattered, the moment that I did that I suddenly had an insight to the problem at hand.

I spend a log of time lately smacking my forehead because I brute force my way through something only to figure out a much simpler way to do it. I'm currently trying to add inherited ast attributes* to Boo, which would pave the way to implementing desing by contract.

I wrote less than 250 lines of code in nearly two days, but I've got it 90% implemented. The low line count is mainly because I keep finding better and clearer way to do what I need. And because I try to learn as I go the internal of Boo's compiler. It's actually fun to do so and I'm certain that eventually I will get to the point where I can just see the way it's all suppose to happens.

time to read 2 min | 387 words

For the last five days or so I've been working on a Reflector plugin for Boo, so you could view the disassembled code in Boo.

It's not perfect yet. That is a very big subject and I probably made many mistakes in the process, but it is functional and should hopefully make people more open to Boo. The plugin is built against Reflector 4.1.8 and is available here.

Here is a short list of the stuff that need special attention:

  • Pointers and function pointers - declared using C#'s syntax, since there is not equivalent to those in Boo.
  • Ref arguments, out arguments, optional parameters, required parameters - indicated that they are so using comments, since Boo doesn't support them yet.
  • Boo's literals (days, weeks, etc) are not handled.
  • The literal '\v' - vertical tab is not supported in Boo, but is displayed as is instead of the cast(char,11) hack.
  • C's for loops and do - while loops are implemented as while loops.
  • Conditional expression are displayed as iif(condition, trueResult, falseResult)
  • Null coalescing operator is implemented as in C#, since Boo currently doesn't support it.
  • Address dereferencing and sizeof are implemented as in C#, since Boo currently doesn't implement them.
  • Generics - currently implemented as [Of T], but I didn't really test them properly.
time to read 12 min | 2298 words

(This is a suggestion I'm making for the Boo's mailing list, about a proposed syntax for Eiffel's like contracts for Boo)

[This proposal require inherited Ast attributes, which provides some challanges in the implementation. More on this in a moment.]

The idea is to allow to use attribute markup to create pre & post conditions for a method. Here are the sematics or this proposal:

  • Pre conditions apply to the current method and all the method that override it:
    • Considerring that difficulities in checking in compile time that a class accept equal to or wider range of parameters (rather than a narrow range) I don't think that this practical.
    • It's not hard to implement this check in run time where you can ensure that if the base method pre condition has passed then the method must accept it or violate its contract. So this what this proposal does. An exception (with very silly name) is raise if a parent's base condition is satisfied but the child condition has failed.
  • Post conditions apply to the current method and all the methods that override it:
    • Again, statically checking the correctness of the post condition is prohibitive, and much simpler to do on run time.
    • Post conditions are stacked, and a post condition that allows something that the base method wouldn't allow will cause a contract exception

Without further ado, here is the proposed code and the final translation (see more comments about the implementation below):

public class ClassWithContract:     
#post & pre are Inherited AstAttributes
[post(PerformComplexVerification(result))]
virtual def FirstMethod([pre(foo.Property == "object")]foo as someType) as anotherType:
return DoWork(arg)
public class DerivedClassWithNoOverridingContract(ClassWithContract):     
override def FirstMethod(foo as someType) as anotherType:
return DoDerivedWork()
public class DerivedClassOverrideContract(ClassWithContract):     
[post(PerformValidationForDerived(result)]
override def FirstMethod([pre(foo.Property is not null)] foo as someType) as anotherType:
return DoDerivedWork2()

The above would be translated into the following:

public class ClassWithContract:     
protected virtual def post_FirstMethod(result as anotherType) as bool:
return PerformComplexVeriication(result)
    # the syntax for this is pre_<method name>_<arguments>_<arguments this method check>     
# this is done in order to handle overloading
protected virtual def pre_FirstMethod_someType_arg(foo as someType) as bool:
return foo == "object"
    # this attribute is check by the ocmpiler and if found it will invoke the specified     
# attribute on any overloading method and then apply to it the same AST attribute
[InheritorUseAstAttribute("Boo.Lang.Useful.PostAttribute, Boo.Lang.Useful")]
[InheritorUseAstAttribute("Boo.Lang.Useful.PreAttribute, Boo.Lang.Useful")]
virtual def FirstMethod(arg as someType) as anotherType:
raise PreConditionFailedException("arg") if not pre_FirstMethod_someType_arg(arg)
__result = DoWork(arg) raise PostConditionFailedException() if not post_FirstMethod(__result)
return __result
public class DerivedClassWithNoOverridingContract(ClassWithContract): 
    # pre condition of base method is enforced     
# post condition is enforced
# this doesn't have any special pre/post condtions of its own
override def FirstMethod(foo as someType) as anotherType:
raise PreConditionFailedException("arg") if not pre_FirstMethod_someType_arg(arg)
__result = DoDerivedWork()
raise PostConditionFailedException() if not post_FirstMethod(__result)
return __result
public class DerivedClassOverrideContract(ClassWithContract): 
    # override the parent post condition and then call it:     
protected override def post_FirstMethod(result as anotherType) as bool:
currentCondition = PerformComplexVeriication(result)
baseCondition = super(result)
raise ContractViolationChildDontAcceptSuperDoesException() if currntCondition
and not baseCondition

return currentCondition
 protected override def pre_FirstMethod_someType_arg(foo as someType) as bool:     
baseCondition = super(foo)
currentCondition = foo .Property is not null
# need to work on the name of this exception :-)
raise ContractViolationChildDontAcceptSuperDoesException() if baseCondition and not currentCondition
return currentCondition
    [InheritorUseAstAttribute("Boo.Lang.Useful.PostAttribute, Boo.Lang.Useful")]     
[InheritorUseAstAttribute("Boo.Lang.Useful.PreAttribute, Boo.Lang.Useful")]
override def FirstMethod(foo as someType) as anotherType:
raise PreConditionFailedException("arg") if not pre_FirstMethod_someType_arg(arg)
__result = DoDerivedWork2()
raise PostConditionFailedException() if not post_FirstMethod(__result)
return __result

A few comments about the proposal:

  • Adding a class invariant would be a very simple matter if we take this approach
  • Setting a contract for an interface may be problematic, since there is no place to put the methods, in this case I propose that a utility class will be created and used by all the classes that implement the interface.
  • What happen when a post/pre condition raise an exception?
  • I don't like the idea of easing the limitation, or of not implementing the contract exception. The reasoning is very simple, right now a post / pre condition need to takes into account each and every parent's condition. I suggest that we would simply stack them together, and if any fail the Pre/Post condition exception would be raised, without checking for the correctness of the contract.
  • How do you debug this?
  • How do you get the contract from a compiled dll so you would know what it is? Do we rely on documentation or should we live something in the IL to be read later?

What is needed to implement this?

Not much, actually :-) which is very good. I played with my mind a little with this and this is what is needed to create this proposal:

  • An abstract attribute (AbstractInheritedAstAttribute) that inherit from AbstractAstAttribute that will handle inheritance to overriding methods (or derived class, if we wants class invariants as well). This attribute will "tag" any method/class that it is used upon with a normal attribute (in the sample InheritorUseAstAttributeAttribute which will have the full type name of the Ast attribute.
  • Adding a compiler step that will process any method/class that has this attribute in their parentage chain and call the Ast attribute on the current memeber.

[This is a rough draft that was mainly formulate during IRC discussion early this morning.]

time to read 1 min | 95 words

I'm currently investigating a sweet little language call Boo. I've been totally blown away by it's abilities. It's so cool that I just can't belive that I didn't know that such a thing exist. It totally blows away C# in terms of ease-of-use.

There are some cavats currently, mainly due to the fact that the language is still in beta, but already it has some great potential.

The double damn is that I just spent three or four hours coding, and lost it all just as I was about to finish because of #Develop.

Boo!

time to read 1 min | 186 words

I'm interested in learning dynamic languages, but I don't want to leave the CLI, so I decided to investigate IronPython. I started reading about it, then I got (somehow, no idea how) to Boo.

Read the manifest.

After reading this, and considerring that this is the first non C-derived language that I'm planning to learn (VB & Pascal aren't really that different. Different syntax, same way of thinking) it looks way cool.

 

"Stewardesses is the longest word typed with only the left hand." -- Fact of lifes

"Boat: A hole in the water surrounded by wood into which one pours money" -- Definate Facts

"The most beautiful thing we can experience is the mysterious. It is the source of all true art and all science. He to whom this emotion is a stranger, who can no longer pause to wonder and stand rapt in awe, is as good as dead: his eyes are closed." -- Albert Einstein

[Listening to: רגעים - ברי סחרוף - סימנים של חולשה(03:48)]

 

FUTURE POSTS

No future posts left, oh my!

RECENT SERIES

  1. Production postmorterm (2):
    11 Jun 2025 - The rookie server's untimely promotion
  2. Webinar (7):
    05 Jun 2025 - Think inside the database
  3. Recording (16):
    29 May 2025 - RavenDB's Upcoming Optimizations Deep Dive
  4. RavenDB News (2):
    02 May 2025 - May 2025
  5. Production Postmortem (52):
    07 Apr 2025 - The race condition in the interlock
View all series

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats
}