Wollok v1.2 Buddha - uqbar-project/wollok GitHub Wiki

Language

Named Objects can now inherit from classes

Now first class objects (named objects) can inherit from a class. This allows to create well-known objects that share behaviour with other objects but overrides just part of its behaviour. Like a mix between the two words (objects and classes) for modelling special cases.

Tests

Wollok now has the concept of test cases as one of the major elements in the language. A test is just like an executable function which contains asserts statements. A test file can have as many tests cases as it wants. And it can also define local objects accesible for the tests cases.

There is also a UI support for tests to show the execution report and the famous green/red bar

New Checks

Check Overriding method return compliance

There's a new static check for validating that an method which overrides another one, has a compatible semantic in terms of returning a value. This means that, if the original method was returning a value, the overriding one MUST also return a value. And the opposite.

wollok-checkoverridereturn

Getter method should return a value

Getters should return a value. Sometimes we just forget the "return" statement. This will check it

Quick Fixes

We have added a couple of useful quick fixes for some of our static code checks. Here is the list with screenshots.

Remove unused variables

Add constructors from superclass

Remove duplicated constructor

Add call to super

Remove override keyword

From native methods that cannot override

Replace if with condition

For bad if usage

Create constructor in superclass

For methods marked as overriding but not overriding anything

There are two options:

Remove duplicated methods

Initialize non assigned var/val

Refactorings

Extract Method

We have implemented our first refactoring: the "extract method", which extracts a given selected piece of code into a new method on the current class/ object

This is the wizard

And it has a preview of the changes

UI

Improvements to Debugger Object's Diagram

The "object diagram" view for debugging has been improved a little bit.

  • It now remembers the nodes positions between steps, so they are not being moved everywhere around the screen :)
  • It now shows the names of the references as labels on top of the connections.
  • It also uses a different color and size (smaller) for numbers values to make it easier to differentiate simple values from more complex user objects.
  • Also the List objects are differentiated by using a small rectangle with a different color, instead of a circle
  • References from the list to its elements are also differentiated with a dashed line (instead of solid)

Improvements to Class Diagram

A number of improvements have been made to the class diagram

  • Inheritance arrows now being shown as empty triangles
  • Selection synchronisation between outline view and the diagram (plus the editor)
  • Methods in class boxes show full parameters signature and icons. Something similar for instance variables.
  • Also methods and instance variables are differentiated visually by two separated boxes within the class node.
  • Double-click on a class node will put the editor focus on that class.
  • Classbox size is now automatically adjusted to fit for all of its content (methods and variables). So that all the content is visible.
  • Methods which returns a value are being marked with a right arrow both in the outline view as well as the class diagram.
  • Inheritance connections are now horizontally and vertically only and they follow a single path to the superclass, which makes it appear like a single arrow from several originating subclasses. Like a regular UML arrow.
  • Also the automatic layout now arranges the hierarchy from the TOP to the BOTTOM, down the hierarchy
  • Now the diagram also shows named objects (root objects) along with classes

Debugger Connection timeout as a preference

When you launch a debug instance it actually executes the program in a separated process to be in control of it. The eclipse debugger UI then connects to that remote process. So the whole debugging session requires a remote communication between the IDE and the running wollok instance. So there's a handshake there. Sometimes the wollok program takes too much time to start listening for connections and you'll see a timeout in the UI. Previously we had a fixed wait time then in the UI. This is now configurable in Wollok preferences. So that slow machines can increase this value to be able to debug.

Milestone