Coming up on December 3rd and 4th in Zurich, Switzerland, we will be hosting the second Eiffel Design Feast solely focused on the Web solution(s) for Eiffel. The first event back in June was a real success and we hope to achieve the same kind of results.
This time around we will be checking the results of the work since last time.
In Eiffel (to the best of my knowledge), a class B that inherits from a parent class A has access to all features of A. So far this hasn't bothered me at all, to the point that I often change my private functions in C# to protected.
But recently, as I was writing Eiffel programs to practice SCOOP, it occurred to me that I must now write a lot more features than I would before.
A FoxPro colleague shared a factoid about FoxPro that I had not connected the dots about. In FoxPro most class primitives are visual. Text-boxes, combo-boxes, check-boxes, edit-boxes, buttons, pictures, containers and so on are all manipulated from the visual aspect.
I am leading a workshop on Monday 27 June 2011, at TOOLS 49 in Zurich on the idea of developing a worldwide New Eiffel Technology Community. The idea is that languages that survive like Java and Ruby today don't depend on the qualities of the language, but on the qualities of the 'technology stack', i.e.
At the present time, each new day of working with Eiffel shows me both how far I have come and how much further remains to go. A faithful saying is: "Whatever you focus on expands." Working with Eiffel is no exception to this rule.
We are learning and have learned a great deal in the last two and half months of working with our two very fine engineers.
No matter what language used, software is concerned with the states of objects and transitions between them. Within the Visual FoxPro paradigm, I saw the notion of a State Machine as a fantastic solution to a common problem: How do I make my interfaces respond appropriately to user interaction?