Planet Smalltalk

July 22, 2014

Smalltalk Jobs - Smalltalk Jobs – 7/22/2014

Smalltalk position in Tours France with a contract company, Neo-Soft.

For this Smalltalk position they look for someone on Unix to make changes in Smalltalk and Java. In addition you need to understand COBOL and MVS.

More information in French here.


Filed under: Employment

Smalltalk Jobs - Smalltalk Jobs – 7/21/14

  • Atlanta, GASmalltalk Developer through Evolutyz
    • Required Skills:
      • 5+ years of Smalltalk Development experience
      • IBM Visual Age version 5.0+
      • Version Control using VisualAge – ENVY
      • SQL Server 2008
      • SDLC LifeCycle
      • Familiar with consuming Webservices from Smalltalk
    • Additional listings: VDart, VDart
  • Fremont, CASoftware Engineer 1 at Lam Research
    • Required Skills:
      • MS/BS in EE/CS or related fields
      • Working knowledge of object-oriented design methods and languages
      • Working knowledge of multi-threaded software
      • Basic knowledge of real-time operating system, hardware and software interface, real-time control, motion control
      • Basic knowledge of at least 1 communication protocol
    • Wanted Skills:
      • Smalltalk
      • Working knowledge of Visual Studio
      • Working knowledge of relational database (SQL server preferred)
  • Fremont, CASoftware Engineer 2 at Lam Research
    • Required Skills:
      • Must be proficient in C, C++, and Java
      • Must have used any of the following tools in academic projects tools: ClearQuest, ClearCase, SVN, CVS, GIT, Eclipse
      • Unix
      • Must be familiar with Multi Threading, Inter Process Communications, Memory Management
      • Code analysis using profilers and debuggers etc
    • Wanted Skills:
      • QNX or VxWorks
      • ControlWorks and/or Smalltalk
Good luck with your job hunting,
James T. Savidge

View James T. Savidge's profile on LinkedIn

This blog’s RSS Feed


Filed under: Employment

July 21, 2014

Cincom Smalltalk - Smalltalk Digest: July Edition

The July edition of The Cincom Smalltalk Digest is available now.

Cincom Smalltalk - Contributed Components

A new feature of our website is the Contributed Components Directory.

Pharo Weekly - SciSmalltalk new version

Dear all,

we are to happy to announce SciSmalltalk v0.12

SciSmalltalk is a new Smalltalk project, similar to existing
scientific libraries like NumPy, SciPy for Python or SciRuby for Ruby.
SciSmalltalk already provide the following basic functionalities:

- complex and quaternions extensions,
- random number generators,
- fuzzy algorithms,
- LAPACK linear algebra package,
- Didier Besset's numerical methods,
- Ordinary Differential Equation (ODE) Solver).

Everything is available here: https://github.com/SergeStinckwich/SciSmalltalk
All the code is available under the MIT licence.

We have more than 424 green unit tests and we run a CI job here:
https://ci.inria.fr/pharo-contribution/job/SciSmalltalk/

This version should work on Pharo 2.0/3.0/4.0 and also Squeak 4.5 (to
be confirmed).

We are a small community, we are looking for more volunteers to
contribute code and documentation. Please join us at :
https://groups.google.com/forum/#!forum/scismalltalk

Regards,

July 20, 2014

Pharo Weekly - Another week of changes

Another great list of changes and improvements in Pharo.

40104
13605 Slider can use setValueSelector instead of accessor everywhere
https://pharo.fogbugz.com/f/cases/13605

13603 remove extensions classOrMetaClass and messageName form Context
https://pharo.fogbugz.com/f/cases/13603

40103
13598 MorphicModel ivar open: not used
https://pharo.fogbugz.com/f/cases/13598

13602 SmalltalkImage >> #openLog dependent on Tools
https://pharo.fogbugz.com/f/cases/13602

13601 Add in group DNU
https://pharo.fogbugz.com/f/cases/13601

13600 DiffereratorSettings –> move to TextDiffBuilder
https://pharo.fogbugz.com/f/cases/13600

40102
13594 Reduce references to CodeHolder
https://pharo.fogbugz.com/f/cases/13594

13597 Implement #readsSlot and #writesSlot on CompiledMethod (and tests)
https://pharo.fogbugz.com/f/cases/13597

13595 PluggableSystemWindow is dead code
https://pharo.fogbugz.com/f/cases/13595

13596 remove package TT.cs
https://pharo.fogbugz.com/f/cases/13596

40101
13592 Small RB Tests cleanup
https://pharo.fogbugz.com/f/cases/13592

13589 deprecated TimeStamp
https://pharo.fogbugz.com/f/cases/13589

13590 TimeStamp has still instances
https://pharo.fogbugz.com/f/cases/13590

13591 unload tests Metacello-TestsTutorial
https://pharo.fogbugz.com/f/cases/13591

 

40099
13576 Small code critique cleanup Graphics-Primitives
https://pharo.fogbugz.com/f/cases/13576

13587 add tests to make sure globals and class vars use the right bindings
https://pharo.fogbugz.com/f/cases/13587

13580 move UnixEnvironment and Win32Environment to NativeBoost
https://pharo.fogbugz.com/f/cases/13580

40098

13574 ModelOrNil has only one sender so we should rewrite it and remove it.
https://pharo.fogbugz.com/f/cases/13574

13578 safer RPackageOrganizer>>systemMethodRemovedActionFrom:
https://pharo.fogbugz.com/f/cases/13578

13585 use term Class Variable, not Shared Variablem in ClassModification
https://pharo.fogbugz.com/f/cases/13585

40097
13584 Forward code generation for Globals and Class Vars to meta object
https://pharo.fogbugz.com/f/cases/13584

13586 Class Variables should be ClassVariables, not Globals
https://pharo.fogbugz.com/f/cases/13586

40096
13581 move ThreadSafeTranscriptPluggableTextMorph to own package named Tool-Transcript
https://pharo.fogbugz.com/f/cases/13581

13583 #senders and #implementors on Symbol
https://pharo.fogbugz.com/f/cases/13583

13579 MCPatchOperation >> #patchWrapper should be moved to package Polymorph-Tools-Diff
https://pharo.fogbugz.com/f/cases/13579

13582 Deprecated #classSymbol
https://pharo.fogbugz.com/f/cases/13582

40095
13552 First Class Variables: improve reflective API, ClassBuilder use objects, not string for Globals
https://pharo.fogbugz.com/f/cases/13552

40094
13275 RBSmalllintChecker checks classes not defined in environment
https://pharo.fogbugz.com/f/cases/13275

13577 UIManager should not use WorldState for defer:
https://pharo.fogbugz.com/f/cases/13577

13575 TreeModel in checklist mode gives unchecked items hardcoded color
https://pharo.fogbugz.com/f/cases/13575

13571 Something is completely broken regarding Slice submission
https://pharo.fogbugz.com/f/cases/13571

40093
13558 PluggableTextFieldMorph should be packaged in PluggableTextMorph
https://pharo.fogbugz.com/f/cases/13558

12879 Rename and Recategorize RPackage>>#correspondingMcPackage
https://pharo.fogbugz.com/f/cases/12879

13572 little clean of SimpleSwitchMorph and comment
https://pharo.fogbugz.com/f/cases/13572

40092
13515 GrafPort and EllipseMidpointTracer should not be in Morphic package
https://pharo.fogbugz.com/f/cases/13515

13563 Fix sender of deprecated RPackageOrganizer>>#renamePackage:in: method
https://pharo.fogbugz.com/f/cases/13563

40091
6765 Refactoring Extract into Temporary should modify all duplicates
https://pharo.fogbugz.com/f/cases/6765

13565 extensions of Polymorph on Polymorph class should be folded in these classes
https://pharo.fogbugz.com/f/cases/13565

5618 Refactoring: Cannot permutate arguments
https://pharo.fogbugz.com/f/cases/5618

13540 Debugger: method refactoring option
https://pharo.fogbugz.com/f/cases/13540

40090
13569 Small Code critique cleanup of MonticelloGUI
https://pharo.fogbugz.com/f/cases/13569

13567 Small code critique clean Polymorph
https://pharo.fogbugz.com/f/cases/13567

12205 Cleanup gofer>>#directory:
https://pharo.fogbugz.com/f/cases/12205

13125 The Find&Replace dialog does not honor the Appearance font size setting
https://pharo.fogbugz.com/f/cases/13125

40089
11287 Form class>>fromUserWithExtent: freezes because Rectangle class>>originFromUser:grid: is broken.
https://pharo.fogbugz.com/f/cases/11287

13550 Should remove the 30 inbox from pharo 40alpha
https://pharo.fogbugz.com/f/cases/13550

40088
13564 Fix all users of TimeStamp: remove Tests, change two remaining clients
https://pharo.fogbugz.com/f/cases/13564

13562 remove UUIDGeneration seed generation from sound input
https://pharo.fogbugz.com/f/cases/13562

13561 remove some unload class methods
https://pharo.fogbugz.com/f/cases/13561

40087
13560 remove DSA seed generation from sound input
https://pharo.fogbugz.com/f/cases/13560

13555 IconicListItem should be packaged in Widgets-Basic
https://pharo.fogbugz.com/f/cases/13555

13556 ImagePreviewMorph could be packaged close to AlphaImageMorph
https://pharo.fogbugz.com/f/cases/13556

13559 ControlButtonMorph and PluggableButtonMorph could be moved to Widgets-Base
https://pharo.fogbugz.com/f/cases/13559

13557 Github zip download does not check for the existence of file with the same name
https://pharo.fogbugz.com/f/cases/13557

40086
13551 Not all SmartSugs works in Debugger
https://pharo.fogbugz.com/f/cases/13551

40085
12790 AthensSurfaceExamples class side examples do not work due to subclassResponsibility
https://pharo.fogbugz.com/f/cases/12790

13538 RowScrollerMorph us unused and undocumented
https://pharo.fogbugz.com/f/cases/13538

 


Essence# - Appe’s New ‘Playgrounds’: Back To The Future, One More Time

So Wired thinks Apple’s Playgrounds development paradigm is revolutionary?

Not so much: Smalltalk programmers have been coding with analogous capabilities since before Steve Jobs ever saw his now famous demo at Xerox PARC.

The Smalltalk development environment now has close to 40 years of maturity and experience behind it. And its cool features from 1979 still haven’t all been added to the IDEs of other languages, to say nothing of the ones added since then.

Ref: http://www.wired.com/2014/07/apple-swift/


July 18, 2014

Nicolas Petton - Farewell RMoD!

Today is my last day at RMoD.

The last two years have been an incredibly rich experience, and I’m profoundly sad to leave my colleagues. I have in the past two years met and worked with a lot of very smart people and many of them became very close friends. I’m still saying goodbye to people, so I’ll make this post short. :)

The first thing that comes to my mind when I think about the last two years is that I’m very proud of having been part of RMoD. It hasn’t always been easy, but it has been all in all a very joyful experience.

I will of course stay around, and come back to visit the team around February next year.

In two weeks I’ll be packing my stuff to go to Stockholm, where I will be working in another development team. It’s a totally new adventure that will begin, so stay tuned!

Comments

Torsten Bergmann - Fun with Pharo (when writing books)

Beside the Pharo by Example, Deep into Pharo and the Pharo Enterprise book (available on CI, GitHub and as PDF) there is now also the idea of a book about "funny" things like implementing games in Pharo.

Therefore a new clone of the Pharo by Example book was created with the name "Fun with Pharo". The book is built on CI, the books source is hosted on GitHub and currently it includes already infos on how to build a digital Tamagotchi with Smalltalk or how the PhlappyBird game works.

The PDF for "Fun with Pharo" is already available.

If you want to contribute you should have a look and learn about Pillar and I would recommend to use either Online PillarHub or the new one-click image for PillarHub that you can run locally to write an own chapter.


Essence# - Static Typing And Interoperability

Static typing inhibits interoperability. It does so between class libraries and their clients, and also between programming languages.

The reason is simply because static typing violates encapsulation in general, and improperly propagates constraints that aren’t justifiable as architectural, design or implementation requirements in particular. It does so either by binding too early, or by binding (requiring) more than it should.

The reason that static typing violates encapsulation is because it fails to permit the object itself from being the sole arbiter of its own behavior, and the sole arbiter of the semantics of any operations that may be applied to it. It does that by forcing the programmer to break the veil of encapsulation of the object by directly referencing its class or type as the static type constraint of variables that will be permitted to contain objects of that type, instead of respecting the privacy of that information, which should remain hidden behind the wall of encapsulation that objects are supposed to provide. And then that information is used by the compiler to force the behavior of objects based on the static type constraint of the variables that reference them, as well as the semantics of the operations applied to them, thus violating encapsulation even more profoundly.

As usually implemented by widely-used programming languages, and therefore as typically used by program developers, static typing confuses the distinction between a class and the type that the class implements. And even in an ideal implementation in some language that almost no one will ever actually use in anger, it violates encapsulation by confusing the variables or parameters that reference a value with the class of the referenced value, the type of the referenced value, or (usually) both.

A class is not a type. It’s an implementation of a type.  Therefore, any system built on that false assumption is intrinsically broken at a very deep level. If you write code based on the idea that classes are types, you need to transform your thinking.

And a variable is not the value it references. Therefore, any system built on that false assumption is intrinsically broken at a very deep level.  The semantics of a variable is the architectural role(s) it plays in the algorithm that uses it. It is not the class of the value of the variable that the variable may be referencing at any particular time, nor the type that that class may be implementing at that particular time (the type that a class implements is not necessarily a static property of the class.)

As a concrete example, consider the usage of an array object in a statically-typed language which must hold objects of different types (or different classes, it makes no difference in this case,) and therefore must use Object as the static type constraint for the array’s element type (assuming there is no less-general common superclass.) Putting elements into such an array is easy, and raises no issues.  However, although it is equally easy to fetch elements from such an array, using the retrieved values for other than the most trivial purposes typically requires the programmer to over-constrain the retrieved value: The programmer is forced to constrain such values to being instances of some predefined type (which often also means constraining them to be instances of some predefined class,) before such values can be used in application-specific or domain-specific ways. The programmer must impose such constraints by casting the value to a specific type or class–which will fail if the programmer misjudges the type of the object, even though there would have been no failure had the programmer been allowed to use the value in the operations that were needed without having to cast the value to some specific type (because those operations would be valid for all the elements of the array, regardless of their type or class.)

Typically, one only needs to send one or two messages to values retrieved from a variable or from a collection. One usually does not need to send every message (or apply every operation) defined by a particular type or class. Therefore, requiring that a value must be an instance of a particular type or class is almost always requiring more than is necessary–and usually, far more. Imposing such unnecessary constraints inhibits interoperability because it reduces the generality of the code, reduces the generality of the entities the code defines, and reduces the generality of the the entities that the code can make use of.

And the violation of encapsulation bubbles up to higher-level entities: Classes, modules, packages, assemblies, class libraries and entire frameworks–which is how it inhibits interoperability, not only between class libraries or application frameworks and their clients, but even between different programming languages.

Static typing dramatically increases the coupling between components, because it not only exposes the specific entities that define and/or implement all the behavior of a value, it also requires that clients use precisely and only those specific defining or implementing entities, and typically prohibits the use of functionally/semantically equivalent alternatives that would have worked as desired. This is true even when interfaces are pervasively used as static type constraints (which is rarely the case in practice, and so should in all fairness be dismissed as a moot point,) and because clients must in any case use only the specific interfaces used and/or defined by the component providing the service they’d like to use.

Pervasively using interfaces as static type constraints, although it definitely helps, nevertheless remains a problem a) because interfaces typically require behavior that just is not needed every time one of their instances is used (which is almost always the case,) b) because interfaces defined by third parties–and the classes and methods that use them–generally cannot be changed in any way by their clients, and c) because it is possible (and even likely) that the various providers of “reusable” (ahem) components will separately define what are conceptually “the same” interfaces for the same purposes, which nevertheless won’t be type-compatible even if they have exactly the same names and require precisely all the same operations (messages, operators, etc.)

Why? Because “reusable” components from independent sources that use what are conceptually “the same” interfaces nevertheless cannot easily interoperate with each other, since two (or more!) interfaces that aren’t defined in the same namespace will be classified by the static type system as different, incompatible types, no matter how identical they are otherwise. That means that, for example, the function provided by class library A from source Alpha that transforms a video stream by applying a user-supplied function to the color of each pixel cannot be used with the function that performs the desired color transformation provided by class library B from source Beta, because the two class libraries each use their own “Color” interface, which is not type compatible in spite of having the exact same name and defining the exact same set of required operations with the exact same semantics.

And that’s a short–and incomplete–example of why and how static typing substantially reduces a programmer’s degree of freedom in combining and reusing code components from different, independent sources, relative to what it could be if programming languages used the open-world assumption instead of the closed-world assumption regarding which operations are valid. Operations should be assumed valid until that assumption is proven false, for reasons that are analogous to those that justify the assumption that a person accused of a crime is innocent until proven guilty, or those that motivate the assumption that the null hypothesis is true until proven false by actual experimental observation.

Most of human progress over the past few centuries is directly attributable to discarding the prior obsession with being able to present absolute proofs, and replacing that paradigm with what we now know and love as the scientific method, which is based on falsifiability instead of being based on provability. Our modern technology only exists because we gave up the idea that our models of the world must be provably correct, and instead started using the paradigm of falsifiability, as embodied by the scientific method.

The programming world is in severe need of a Copernican Revolution so that we can discard the ever-more complicated epicycles and contortions that the static typists go through to try to match the generality, reusability and productivity of dynamic programming languages.

Note: You can vote on this essay on Reddit


July 17, 2014

Ricardo Moran - Proximamente SLAM

Hola a todos, hace mucho que no escribo algo para el blog. Durante el último tiempo tuve que dedicarme a cerrar ciertos pendientes que tenia en otros proyectos, disminuyendo el tiempo que le pude dedicar a la robótica.

Durante los próximos meses comenzaremos a trabajar en SLAM (Simultaneous Localization And Mapping), que describe la capacidad de un dispositivo móvil de reconocer su entorno, crear un mapa, ubicarse a si mismo y poder navegar utilizando dicho mapa.

Recientemente me postulé para una beca doctoral y en algún punto de los próximos meses me enteraré si califique para la misma. El proyecto de tesis que presenté es sobre el uso de sensores infrarrojas de profundidad en SLAM .

SLAM-Photo

Ejemplo de Mapa

Para esto planeamos utilizar un Kinect de microsoft, y honestamente creemos que podemos ahorrarnos muchos problemas inherentes al campo de aplicación gracias a la información provista por este sensor.

Lograr que un robot pueda ver y comprender el mundo como para ubicarse es sumamente difícil, y será un largo camino antes de que podamos tener algo funcional pero voy a tratar de mantenerlos al tanto a medida que existan avances al respecto.

Pharo Weekly - First Iteration of Pharo 40 Report

- Modularisation is under way

  • - Tools 
  • - Morphic
  • - Polymorph 

package structure is slowly getting cleaner

- Infrastructure

  • - Android (Missing management events and graphics)
  • - Raspberry (FFI works, vm works, OS process)

- Spur
should be finished this week

  • - found a bug in Spur related to weak structure (already fixed by Eliot)
  • - release each image we produce to Spur format
  • - nativeBoost is not working
  • - large integer plugin is not working

- Host window integration

  • - OSWindow common interface
  • - Multiple back-ends (VM, SDL2, plugin)
  • - Ready to be integrated.
  • - Need some class comments!

- New bytecode set

  • - integrated this morning
  • - needs a new vm for the bytecodeset

- Spur 64 bits

  • - starting to work on it in September

- Removing old compiler

  • - reloadable
  • - needed for VM
  • - Spur

- System Localization

  • - usman should open a bug issue

- Leading Char Removal

  • - probably we will not do it.

- Guille Core

  • - bootstrap
  • - next friday…
  • - Unloading Reloading tools 
  • - JB will help

- Athens

  • - roadmap
  • - missing txText

- TxText

  • - Widget is there and working
  • - Morph is working
  • - Spec integration
  • - Not all tool use Spec
  • - Clean version
  • - Igor MUST release a version and not try to make the complete system working with it.

- Remove the old browser

  • - kill the filePackage browser
  • - We should get Nautilus or OndoBrowser browsing Ring

- Spec

  • - Should do a pass
  • - Check the design (in particular link between adapter and morph)
  • - Examples-driven are needed

- GitSupport

  • - filetree integration is working but not good enough
  • - small progress.
  • - Martin should check with Max the status of libgit2
  • - Need to build on top of that.

- Morph and theme

  • - we will see if we have the time
  • - brainstorming on a solution

- Make sure that we do not overuse Ring

- Font with FreeType

- Glamour

  • - esteban roadmap
  • - first bootstrap
  • - second only a stripped down version
  • - development outside the image

- Ombu/Epicea

  • - call for more users

- ZnUrl should be used in place of URI URL

- Keychain Removal

- Morph class side announcer

  • - we should look at the announcer plague

- Intersect:

  • - should be finished

- Image-level resources

  • - brainstorming prototyping

- Opal

  • there is progress!
  • - slots <-> OPAL 
  • - subclassing and adding instance compiled 
  • - specific slots are on the way

- ClassBuilder

  • - should be revisited.

 

 


Pierce Ng - Committed ROE with NBSQLite3 to STH

I’ve committed my integration of ROE with NBSQLite3 to SmalltalkHub.

Tested on Pharo 3 on OSX Mountain Lion and Linux Mint 17 based on Ubuntu 14.04. All 23 tests of RATestSQLiteSemantics pass.

July 16, 2014

Torsten Bergmann - Ephestos

A small demonstration of Ephestos , a communication bridge between Pharo and Blender.
Code is on SmalltalkHub - but actually it is only a simple methodn on the Pharo side:

sendMessage: aString
   |stream|
   stream := SocketStream openConnectionToHostNamed: '127.0.0.1'  port: 4000 .
   stream sendCommand: aString.
   stream close.



Torsten Bergmann - Pharo Consortium 2014 Annual Report

Pharo Weekly - Pharo consortium meeting report

The Pharo consortium issued its first annual meeting report 2014-06-report. The report is public and contains all the information exchanged during the meeting. Figures are interesting to look at .

 


Pharo Weekly - Ephestos – Using and Coding Blender from inside Pharo

Kilon announced Ephetos: a bridge to Blender. Here is its announce.

Its far from production ready but I am too excited to keep to myself. I present to you Ephestos. 

Ephestos is a socket bridge that communicates with Blender the most popular and most powerful open source 3d application. 
http://www.blender.org/
The goal is to expose Blender coders to the power of Pharo and Pharo to the power of Blender. As you can imagine the potential is huge but I rather talk what Ephestos can do already. 
 
Even though Ephestos is in total less than 200 lines of code it can already communicate with blender and affect blender properties. Blender properties are basically instance variables for any kind of blender object, 3d object, material, textures etc So already you can affect a huge deal of blender .
 
Unfortunately Blender operators seem to crash Blender , probably I am doing something stupid that I will fix. Blender operators are for performing blender actions so they are very important.
 
I have made a simple video demo of it that can be watched here
https://www.youtube.com/watch?v=8igk9DoY6PU&feature=youtu.be
To use it you need first the Blender addon which can be found here
 
https://github.com/kilon/pyEphestos
The code should be inside a folder named “pyEphestos” and placed in Blender addons directory which is located for Macos in Application Support/Blender/VersionsOfBlender/scripts/addons and in Windows should be in App Data/Roaming/….. or you can place it inside the blender folder in similar sub directory
 
You also need the Pharo code which can be found here
http://www.smalltalkhub.com/#!/~kilon/Ephestos/
As I said it is far from production ready , but it works. 
The good news is that the socket communication is blazing fast, at least compared to what I expected. I was able to perform 1000 connections under a second. And each connection carries a 1024 bytes messages , thats a lot of code. Should be possible to pass thousands of lines of code under a second to Blender. 
 
My only worry is blender itself since it tends to be very crashy in the areas I am pushing. 
 
By the way Always press esc after you enable Ephestos in Blender to close the socket or else it wont free it and next time you wont be able to open the socket and you will have to restart your OS. And do not make an error with the string passed . I need to add an exception for it so it wont crash blender.

July 15, 2014

Cincom Smalltalk - Cincom Smalltalk Resolutions – June 2014

Click the title above to see June’s Resolutions for Cincom Smalltalk.

Torsten Bergmann - PillarHub

A one click image for PillarHub is available now on CI. You can now run it locally very easy.

Just download (for instance using PharoLauncher), run and check http://localhost:8080

If you still do not know what PillarHub is all about then read this.

Essence# - How To Develop Code For Essence# Using Your Favorite Smalltalk’s Development Tools

Essence# currently provides no support for any sort of GUI. Nor does it provide any code editing or code browsing tools. You might think that that means that the only way to develop code in Essence# is to use generic text editors, but such is not the case.

You could develop–and debug–your code using, for example, Squeak, Pharo or VisualWorks. That can be done because, unless your development environment’s Smalltalk compiler accepts (or worse, requires) non-standard syntax, the Essence# compiler can and will compile it. It will also accept/compile many of the common non-standard syntax extensions, such as qualified (“dotted”) names (VisualWorks, Smalltalk-X,) dynamic array literals (Squeak, Pharo) or even dynamic dictionary literals (Amber.)

So the heart of the issue is the differences in the standard libraries supported by other Smalltalk implementations. But that issue can be addressed by adding Essence# compatibility classes and methods to the environment where you develop your code, and by adding foreign-environment compatibility classes and methods to your suite of Essence# libraries/namespaces when you port your code to Essence#.

I expect a large body of such inter-Smalltalk compatibility code to be developed over time–some by me, and some of it contributed by others. In Essence# such special-purpose code modules don’t have to be installed by default. They can be partitioned into separate libraries that are only loaded when and as needed. So if you don’t need either the VASmalltalk or the Dolphin compatibility library, just don’t load them.

However, there is one obstacle in the path of this strategy: The file-out formats of other Smalltalk development environments are not at all the same as the Essence# class library format. Given that, it would actually be a lot of work to port code from VisualWorks, Squeak or Pharo to Essence#.

Or more correctly, it used to be a lot of work, because I’m using this post to publish and explain a solution to the problem: Code that will file out a class or class category from VisualWorks, Pharo or Squeak into Essence# class library format. The code can be obtained from the Essence# Tools Repository on GitHub. Although at present only those three development platforms are supported, it should not be too hard to figure out how to port one of them to another Smalltalk development platform. If you do so, please contribute it to the community.

The version of the code export tool for each of the three development environments is named EssenceClassLibraryExporter, and each has the same external API–which will be explained below. The one for Squeak is located here, the one for Pharo is located here, and the one for VisualWorks is located here. Warning: Don’t export code that you do not own, or that is not open source, unless you have the appropriate permission(s.) The VisualWorks class libraries published by Cincom are not open source, although the “Contributed” code may be (don’t assume; verify.)

After you’ve filed in EssenceClassLibraryExporter.st into Pharo, VisualWorks or Squeak, you use it by writing code in a workspace and executing it as a “do It.” Here’s what you need to know in order to do it correctly:

There are two key issues: 1) What code should be exported, and 2) what Essence# class library and namespace should it be exported to.

Because of the way the EssenceClassLibraryExporter works, it’s best to answer the second question first.

Selecting the target Essence# namespace

When exporting from VisualWorks, you probably should use the same namespace name in Essence# that you use in VisualWorks. But when exporting from a Smalltalk development environment that doesn’t have (or doesn’t typically use) namespaces, you’re faced with an architectural decision that you didn’t have to make until such time as you needed to export your code to Essence#. You can, of course, simply export your code to the Smalltalk namespace. But best practice would be to define and use a namespace in Essence# that’s specific to your project (unless you are deliberately extending a namespace authored by someone else.)

Namespaces in Smalltalk have always been controversial. There is a vocal and influential subset of the Smalltalk community that opposes them. So I am going to address that issue upfront:

First, I must point out that all ST80-compliant Smaltalk implementations that support “shared pools” actually do have and use namespaces. That’s precisely what a “shared pool” is: a namespace. Shared pools could be used to do all the things that namespaces do, but for the fact that the ST80-style compilers and code browsers generally used (with the notable exceptions of VisualWorks and Smalltalk-X, and soon Essence#) haven’t been designed to make such usage elegant and easy. But they could be.

And Smalltalk classes also act as namespaces, in that they can define “class variables” that can be used to change the meaning of references to variables defined in the SystemDictionary. And “shared pools” can have the same effect. Consequently, having formal support for modern, first-class namespaces adds no code comprehension or interpretation issues that were not already present even in Smalltalk-80 ca. 1983, as distributed by XSIS.

But the bottom line is that computer science long ago learned that different name binding scopes are necessary–and become ever more necessary as the size of the code base increases, and as the number on independent contributors increases. That’s why objects provide their own “namespaces” for their instance variables, so as to keep each object’s set of named instance variables separate and distinct from that of all other objects, even when the names of the variables are the same. It’s why each method defines and uses its own “namespace” of parameters and local variables–and why blocks do the same. The bottom line is that Essence# (and VisualWorks, and Smalltalk-X, and .Net, and most modern languages) provide namespaces that localize and encapsulate references to non-local variables for analogous reasons, to solve problems that are essentially the same, using a very similar solution, justified by issues and logic that are also largely analogous.

To the extent that multiple name binding scopes cause problems of comprehension or interpretation with respect to the meaning of named variable references, they do so universally for named variable references of all types and in all contexts: Block and method parameters, block and method local variables, function parameters and local variables, the fields of records/structs, the named instance variables of objects, the class variables and shared pools of ST80, the static variables of C++, C# and Java, and modules/assemblies/programs that contain multiple classes and/or functions.

If, on balance, programmers and the code bases they write get more benefit than harm from having separate name binding scopes for class variables, instance variables, parameters and local variables, why would that not also be the case for classes?  Is that not one of the key benefits provided by having separate program files in the case of file-based languages, and separate images in the case of image-based Smalltalk systems? If separate name binding scopes are bad when provided by formal, first-class namespaces, why are they not also bad when implemented by having different images, or by having different program files?

For those reasons, opposition to formal namespaces as first-class objects has always seemed to me to be the equivalent of opposition to compilers by old-school assembly-language coders, opposition to structured-programming by old-school FORTRAN and COBOL coders, opposition to OO by old-school procedural programmers and opposition to dynamic typing by those who think a variable is semantically equivalent to the object it references, and/or that a class is semantically equivalent to the type (concept) it implements.

I’ve used VisualWorks with namespaces for a decade and a half, and have never encountered the issues that opponents of namespaces say they fear.  Not once, not ever. That’s one reason it reminds me so much of opposition to dynamic typing.

Get over it. Move on: Formal namespaces as first class objects solve more problems than they cause. The proof is in the experience of those who’ve been using them for one or more decades now, and in the ever-increasing adoption of them in modern programming systems and languages.

Selecting the target Essence# class library

Conceptually, an Essence# class library is an independently-loadable code module. It roughly corresponds to what other languages/platforms call a “package,” “module,” “parcel” or “assembly” (and these, too, were historically opposed by some; thankfully, they “got over it.”)

It’s important to note that an Essence# class library can contain one or more Essence# namespaces, that the same Essence# namespace can occur (be defined and/or modified by) more than one Essence# class library, that namespaces are an essential and foundational aspect of the .Net platform, and that Essence# namespaces were designed to deal with the fact that namespaces are so central to the way that the .Net framework operates.

You partition your code base into one or more class libraries so that your code modules can be loaded when and as needed as logically-consistent and cohesive units of functionality. You partition your code into one or more namespaces in order to isolate the named entities in your code base from unwanted name clashes with other parts of your own code base, or from unwanted name clashes with code from third parties (of which you may have no knowledge or even interest.) That’s two separate concerns solved by two separate mechanisms (“objects,”) which is proper OO design.

Key point:  You probably should not export your code to the Essence# Standard Library, for the reasons explained in the Essence# documentation section on CodePlex, under the heading Handling multiple releases of Essence#. For one thing, it puts your work at risk of being overwritten when you merge with a new release of Essence# using the Essence# installation program. Using your own private Essence# class library avoids all risk of that happening, and provides several other important benefits that I won’t go into here.

Using the EssenceClassLibraryExporter

The following code snippet will export the class named MyClass to the Essence# class library MyClassLibrary in the Essence# namespace MyNamespace, assuming that MyClass is locally defined in the namespace Smalltalk (i.e., that’s the namespace in which the class is defined in the Pharo, Squeak or VisualWorks image you’re using):

EssenceClassLibraryExporter libraryPath: #('MyClassLibrary').
(EssenceClassLibraryExporter 
        exportingTo: 'MyNamespace' 
        from: Smalltalk)
                exportClass: MyClass

By default, the exported code will be placed in the current working directory of your Smalltalk image. So in the case of the example above, the folder representing/implementing the target Essence# class library would therefore be the current working directory of your Smalltalk image, and the target namespace would be implemented/represented by the folder MyNamespace, which would be created as a direct subfolder in the image’s current working directory.

To use a different folder as the target Essence# class library, send the message #libraryPathPrefix: aPathnameString to the class EssenceClassLibraryExporter before exporting your code, as in the following example:

EssenceClassLibraryExporter libraryPathPrefix: 
        '/Users/myUserName/Documents/Developer/EssenceSharp/Source/Libraries/'.

To export to a nested Essence# namespace, use a qualified named (“dotted notation”) for the target Essence# namespace name, as in the following example, which would export to the nested namespace MyRootNamespace.MyNestedNamesapce, at the absolute path ‘/Users/myUserName/Documents/Developer/EssenceSharp/Source/Libraries/MyClassLibrary/MyNamespace/MyNestedNamespace/’:

EssenceClassLibraryExporter libraryPathPrefix: 
        '/Users/myUserName/Documents/Developer/EssenceSharp/Source/Libraries/'.
EssenceClassLibraryExporter libraryPath: #('MyClassLibrary').
(EssenceClassLibraryExporter 
        exportingTo: 'MyNamespace.MyNestedNamespace' 
        from: Smalltalk)
                exportClass: MyClass

To export all the classes in a class category, replace the message #exportClass: aClass as in the examples above with the message #exportClassCategory: aSymbolNamingAClassCategory, as in the following example:

EssenceClassLibraryExporter libraryPathPrefix: 
        '/Users/myUserName/Documents/Developer/EssenceSharp/Source/Libraries/'.
EssenceClassLibraryExporter libraryPath: #('DevelopmentTools').
(EssenceClassLibraryExporter 
        exportingTo: 'SystemTesting.SUnit' 
        from: Smalltalk)
                exportClassCategory: #'SUnit-Core-Kernel'

If you use the Pharo version of EssenceClassLibraryExporter (in a Pharo image, of course,) then Traits will be handled correctly.


Torsten Bergmann - PhlappyBird

A Morphic based Flappy Bird clone written in Pharo.

Code is on SmalltalkHub: http://smalltalkhub.com/#!/~zeroflag/PhlappyBird


Pharo Weekly - Phlappy: Flappy bird in Pharo

Zeroflag is sharing his fun with us!

 

flappy_shot

Gofer it
       url: 'http://smalltalkhub.com/mc/zeroflag/PhlappyBird/main' username: ''  password: ''; 
       package: 'PhlappyBird';
       load.
PhlappyBirdGame play

Use the SPACE key to “flap” with the bird.

 


Pharo Weekly - Another busy week in PharoLand

Thank you for your contributions.

40084
13548 Move LabelMorph, FuzzyLabelMorph and MultistateLabelMorph to the Package of StringMorph
https://pharo.fogbugz.com/f/cases/13548

13531 RBMissingSubclassResponsibilityRule missing test cases
https://pharo.fogbugz.com/f/cases/13531

13549 Move incrementalSliderMorph to the package of SliderMorph
https://pharo.fogbugz.com/f/cases/13549

13547 Move LabelClicked close to its only user: CheckBoxMorph
https://pharo.fogbugz.com/f/cases/13547

40083
13527 Moving class with overridden method and green override icon gives MNU “methodClass” is nil when clicked
https://pharo.fogbugz.com/f/cases/13527

13542 Better #printOn: method for RPackageTag
https://pharo.fogbugz.com/f/cases/13542

13543 use UserManager default instead of Smalltalk tools userManager
https://pharo.fogbugz.com/f/cases/13543

40082
13546 Move EdgeGripMorph and WindowEdgeGripMorph to Morphic-Widgets-Window
https://pharo.fogbugz.com/f/cases/13546

13544 Move ThreadSafeTranscriptPluggableTextMorph close to Transcript
https://pharo.fogbugz.com/f/cases/13544

13545 Move extension methods from Polymorph-Tools-Diff into MCMergeBrowser
https://pharo.fogbugz.com/f/cases/13545

40081
13537 Merging some polymorph and spec to PluggableListMorph
https://pharo.fogbugz.com/f/cases/13537

13495 deprecate #ifLocked: in PluggableTextMoprh
https://pharo.fogbugz.com/f/cases/13495/

13522 Add Back SimpleSwicthMorph
https://pharo.fogbugz.com/f/cases/13522

40080
13530 Add api to remove selection of text model
https://pharo.fogbugz.com/f/cases/13530

13533 Smart Suggestions for more tools
https://pharo.fogbugz.com/f/cases/13533

13534 Remove some unused “to be removed as soon as possible” methods from Ring
https://pharo.fogbugz.com/f/cases/13534

40079
13529 Move PluggableSlider and subclasses to the same package as Slider
https://pharo.fogbugz.com/f/cases/13529

13375 Should create a package Morphic-Widgest-ColorSelector
https://pharo.fogbugz.com/f/cases/13375

40078
13502 basic UserManager cleanup
https://pharo.fogbugz.com/f/cases/13502

13520 remove all but one direct reference to Compiler
https://pharo.fogbugz.com/f/cases/13520

40077
13508 CachingMorph is unused
https://pharo.fogbugz.com/f/cases/13508

13451 For Pharo4: 13422 Image crashes because an open Nautilus browser hangs onto many objects
https://pharo.fogbugz.com/f/cases/13451

40076
13501 EyeInspector has a slow refresh time (part 1)
https://pharo.fogbugz.com/f/cases/13501

13510 MatrixTransformMorph is not used
https://pharo.fogbugz.com/f/cases/13510

13514 delete empty packages KeyChain and Settings-Compiler
https://pharo.fogbugz.com/f/cases/13514

40075
13509 PSMCSystemSettings –> move to class
https://pharo.fogbugz.com/f/cases/13509

13511 Move CompilerSettings to OpalCompiler package
https://pharo.fogbugz.com/f/cases/13511

13507 ExtendedTabPanelBorder is dead code
https://pharo.fogbugz.com/f/cases/13507

13512 Move BalloonCanvas to Balllon Package
https://pharo.fogbugz.com/f/cases/13512

40074
13506 Move some Settings-Polymorph to the class
https://pharo.fogbugz.com/f/cases/13506

13505 Small Morph clean: SimpleSwitch is not used, move Lazy*List to the sole user: PluggableList
https://pharo.fogbugz.com/f/cases/13505

13504 MorphListItemWrapper is dead code
https://pharo.fogbugz.com/f/cases/13504

40072
13494 Merge Settings-Display and FreeType into the packages
https://pharo.fogbugz.com/f/cases/13494

13496 failing test: testClassRespectsPolymorphismWithTrait
https://pharo.fogbugz.com/f/cases/13496

13487 Bytecode set settings
https://pharo.fogbugz.com/f/cases/13487

40071
13488 Small recategorization of Classes in Kernel
https://pharo.fogbugz.com/f/cases/13488

13485 Move RPackageOrganizer>>#renamePackage:in: to Deprecated40
https://pharo.fogbugz.com/f/cases/13485

13477 Small critique cleanup RPackage
https://pharo.fogbugz.com/f/cases/13477

40070
Merging Opal branch with the trunk.

40069
13483 Preference to always show experimental slot class template
https://pharo.fogbugz.com/f/cases/13483

12373 Class>>name: should be deprecated
https://pharo.fogbugz.com/f/cases/12373

40068
13471 Refactoring in contextual menu in Message Browser
https://pharo.fogbugz.com/f/cases/13471

13458 Rendering text with Athens and StrikeFonts
https://pharo.fogbugz.com/f/cases/13458

13478 The History Package has two classes that are support for tools –> move to Tools-Base
https://pharo.fogbugz.com/f/cases/13478

40067
13482 (Untitled)fix failing opal tests
https://pharo.fogbugz.com/f/cases/13482

13338 FileDirectoryWrapper should be moved to the package containing FileList
https://pharo.fogbugz.com/f/cases/13338

13476 Move TSortable to Collections-Abstract
https://pharo.fogbugz.com/f/cases/13476

40066
12786 Review SmalltalkImageTest>>testImageName
https://pharo.fogbugz.com/f/cases/12786

13475 ClassOrganizer: commentRemoteStr –> commentRemoteStrig
https://pharo.fogbugz.com/f/cases/13475

12767 FontTest has extension from Font package
https://pharo.fogbugz.com/f/cases/12767

5685 offImage is private but used and it is exactly the same as offIcon
https://pharo.fogbugz.com/f/cases/5685

13481 Unload tests for the old Compiler
https://pharo.fogbugz.com/f/cases/13481

40065
13357 ScriptLoader should automatically reassign repository
https://pharo.fogbugz.com/f/cases/13357

13370 Polymorph-Tools-Diff extensions should be moved to their class.
https://pharo.fogbugz.com/f/cases/13370

13474 Small cleanup for RecentMessageList
https://pharo.fogbugz.com/f/cases/13474


July 14, 2014

Essence# - New Release of Essence#: Trumpet-3 (Alpha Build 15)

The Trumpet-3 release fixes some significant bugs. There are no changes to the Essence# Standard Library, and no new features.

The Trumpet-3 release can be downloaded from the Essence# site on CodePlex (which gets you the installer.) Alternatively, the code for the run time system (written in C#) can be obtained from theEssence# CodePlex site using Git, and the code for the Essence# Standard Library can be obtained from GitHub. And the example scripts can also be downloaded from the Scripts repository on GitHub.

The next release will introduce support for native CLR threads, tasks,  monitors and mutexes.


Torsten Bergmann - Toronto Smalltalk User Group

The Toronto Smalltalk User Group patio night is Monday, July 14 at Pauper's Pub, on the street level patio. See http://www.smalltalk.ca

Torsten Bergmann - Essence#’s Predecessor: Iron Smalltalk

Some more insights into Essence# - another Smalltalk for the .NET environment.

Torsten Bergmann - Package Dependencies Analyzer

A new tool for Pharo to check dependencies. Read more.

Pierce Ng - World Cup 2014 with ROE

football.db is a “free open public domain football (soccer) database”. Instructions to construct an SQLite data file from the data are on the website. The database consists of 40 tables; its schema looks normalized. With the World Cup 2014 and dependent data, the file weighs in at ~1MB.

Let’s see what we can do with the data using ROE.

Each league/tournament is given an event ID; the World Cup’s event_id is 8.

| conn groups teams wcTeams |
conn := NBSQLite3BaseConnection on: ('/home/pierce/data/openfootball/sport.db').
conn open.
groups := (((RASQLiteRelation name: 'groups' connection: conn)
    where: #event_id equals: 8) 
    projectAll: #(id title)) 
    renameAll: #(id title) to: #(gid gTitle).
teams := (RASQLiteRelation name: 'teams' connection: conn) 
    renameAll: #(id title) to: #(tid tTitle).
wcTeams := ((RASQLiteRelation name: 'groups_teams' connection: conn) * groups
    whereEqual: #(group_id gid)).
((wcTeams * teams whereEqual: #(team_id tid)) 
    projectAll: #(gTitle tTitle)) explore.

The above code snippet results in a RAProjection instance. We can see its content by the following (pretty-printed by hand):

(self collect: [ :ea | ea values asArray ]) asArray 
#(#('Group A' 'Brazil') 
  #('Group A' 'Croatia') 
  #('Group A' 'Mexico') 
  #('Group A' 'Cameroon') 
  #('Group B' 'Spain') 
  #('Group B' 'Netherlands') 
  #('Group B' 'Chile') 
  #('Group B' 'Australia') 
  #('Group C' 'Colombia') 
  #('Group C' 'Greece') 
  #('Group C' 'Côte d''Ivoire') 
  #('Group C' 'Japan') 
  #('Group D' 'Uruguay') 
  #('Group D' 'Costa Rica') 
  #('Group D' 'England') 
  #('Group D' 'Italy') 
  #('Group E' 'Switzerland') 
  #('Group E' 'Ecuador') 
  #('Group E' 'France') 
  #('Group E' 'Honduras') 
  #('Group F' 'Argentina') 
  #('Group F' 'Bosnia-Herzegovina') 
  #('Group F' 'Iran') 
  #('Group F' 'Nigeria') 
  #('Group G' 'Germany') 
  #('Group G' 'Portugal') 
  #('Group G' 'Ghana') 
  #('Group G' 'United States') 
  #('Group H' 'Belgium') 
  #('Group H' 'Algeria') 
  #('Group H' 'Russia') 
  #('Group H' 'South Korea'))

(Ivory Coast’s proper name in the output doesn’t look right in Pharo. The SQLite database is correct though.)

Yoshiki Ohshima - [仕事] 出張

2週間にわたってドイツとイギリスに出張してきました。ドイツはStuttgartとTübingenに近いGäufeldenという街というか村で、共同開発者とハイキングをしながら設計会議をみっちりと。イギリスの方はAPL系配列言語の開発者達が密かに集まってこれまたみっちりとAPLについて語ったり実装をしたりするというCambridgeのTrinity HallでもたれたIverson Collegeなる集まりでした。 Iverson Collegeのほうはさすがにとっても濃い感 ...

July 13, 2014

Essence# - Essence#’s Predecessor: Iron Smalltalk

Before Essence#, there was IronSmalltalk.

When I started work on Essence#, on or around 9 Jan 2014, I had never heard of Iron Smalltalk.  That name, of course, would be a rather obvious choice, given names such as “Iron Python,” “Iron Ruby” and “Iron Scheme” for other DLR-hosted languages. And yes, I not only considered using “IronSmalltalk” as the language’s name, I actually did use it initially.

Nor do I believe that either of my two advisers/consultants on the project (Craig Latta and Peter Lount) had ever heard of an actual ‘IronSmalltalk’ either (as a real implementation of the language, and not as a concept.) If they had, they certainly didn’t mention it. And Craig Latta was in the middle of a multi-week visit here with me where I live during the time I started the Essence# project, and I was speaking by phone with Peter Lount on a daily basis about the project (and we’re still doing that.) So both of them would have had plenty of chances to tell me about the “other” IronSmalltalk while I was still using that name for what will now always be known as Essence#.

In any case, by mid February (2014,) I changed the name–not because I had discovered that there already was an IronSmalltalk,  but because I didn’t want to have the word “Smalltalk” in the language’s name (but this post isn’t about that, so I’ll explain why I came to that view some other time.)

Fast forward to late May 2014: That’s when I discovered that there was an actual Smalltalk implementation based on the DLR other than mine, and that it was named IronSmalltalk.

Even now, I don’t know all that much about it. I haven’t browsed the code other than to have looked at the folders and file names using the CodePlex source code browsing applet.

Why not? Partly because I’m just too busy implementing Essence#, partly because it’s almost certainly way too late to make any significant architectural changes to Essence# based on whatever I might learn by reading Todor Todorov’s code (he’s the author,) and partly because I just don’t want to plagiarize it (even though it’s open source.)

Most of what I know about IronSmalltalk’s design and implementation I learned just by watching the video of Todor Todorov’s ESUG 2011 presentation on IronSmalltalk. From that, I can tell that the author of IronSmalltalk a) knows what he’s talking about, b) made some of the same architectural decisions I did, but c) did some things rather differently.

For example, IronSmalltalk uses CLR Strings as the direct implementation of Smalltalk Strings, but Essence# does not. The reason is because CLR Strings are intrinsically immutable. Yes, the ANSI Smalltalk Standard requires that String literals be immutable–but that’s not a problem for Essence#, because any Essence# object can be made immutable. And Strings have traditionally been mutable in Smalltalk. Interestingly, IronSmalltalk and IronPython both decided to adopt CLR Strings as their native String objects, while IronRuby and Essence# both decided to implement their own Strings. Although Essence# can and does use CLR Strings also (and I assume IronRuby does the same.)

Just so you know: The primary reason that Essence# doesn’t use CLR Strings and doesn’t use CLR arrays as its “native” implementation of Strings or of Arrays is because the #become: primitive is intrinsically not implementable on the CLR. By implementing both Strings and Arrays as a wrapper over native CLR arrays, much of the pain of not having a #become: primitive is eliminated: The double indirection makes it possible to resize Strings and Arrays “in place” without needing to use #become:. The fact that Smalltalk Strings have traditionally been mutable was a secondary consideration.

Another example involves the DLR’s dynamic binding protocol: IronSmalltalk does it the way the DLR documentation strongly recommends, and Essence# does not. So what’s the recommended way, and why doesn’t Essence# do it that way?  Glad you asked:

The Canonical DLR DynamicMetaObject Protocol For Binding Abstract Operations To Concrete Behavior

The officially recommended (“canonical”) protocol for dynamic binding using the DLR’s DynamicMetaObject Protocol can be expressed as follows:

1. Each operand of an operation (e.g., a message send, although in other languages there are many other possibilities, because most languages do so many things using special syntax) is asked to provide a DynamicMetaObject to act as its agent for participating in the DLR’s meta-object protocol for dynamic binding. If the object is unable to do so, a default DynamicMetaObject is created for it (sort of like a court-appointed public defender.)

2. The DynamicMetaObject that is the agent for the object that is responsible for dynamically (at run time) determining the semantics of the operation is asked to bind the abstract operation (whatever that may be) to a specific physical implementation. Note that identifying which object that is–or perhaps which set of objects–is the responsibility of each DLR-based language’s dynamic binding subsystem.

For example, in the case of most OO languages, the DynamicMetaObject that is the agent for the object that is the receiver of a message would be asked to provide a binding for that message–in other words, an invocable function and associated “binding restriction.” A “binding restriction” is a predicate that can be evaluated to discover whether the binding (the invocable function) is still valid, given the current set of operands. Typically, if the “type” or “class” of the “receiver” isn’t the same as it was when the binding was computed, then the binding is no longer valid and must be recomputed.

3. If the DynamicMetaObject is able to provide a binding, then that binding will be used as the physical implementation of the abstract (logical) operation, for as long as the binding restriction predicate says that the binding is still valid.

4. However, if the DynamicMetaObject of the object nominally responsible for defining the semantics of an operation is not able to provide a binding (e.g, what’s the semantics of the DLR-standard “DeleteMember” abstract operation when the receiver is a Smalltalk object, or of the DLR-standard “Invoke” abstract operation when the receiver is null?), then the responsibility for providing a binding is redirected to the dynamic binding subsystem of the language that compiled the code that’s undergoing dynamic binding. This “host language” (to use the term the DLR uses) may be able to provide a binding, or it too may fail.

5. If the host language can provide a reasonable binding based on its own rules and semantics, it will do so. Otherwise, as a last resort, the binding that will be used would typically report or raise an error (although the DLR imposes no such requirement.) Note that different host languages may bind the exact same abstract operation on the exact same object differently: For example, one language might bind any operation applied to null by providing an invocable function that raises the NullReferenceException, whereas another language might instead provide a method it finds in the method dictionary of its UndefinedObject class, and yet another language might provide a function that’s just a no-op.

So that’s the standard binding protocol, and that’s what IronSmalltalk, IronPython and IronRuby do. And it’s what most languages do when they use the DLR’s DynamicMetaObject Protocol.

Of course, the point of that canonical (“officially recommended”) protocol is to ensure that objects have the right of first refusal in determining the concrete semantics of the abstract operations applied to them. And that’s a commendable and worthy goal of any programming language and/or execution environment.

But it’s not what Essence# does.

The Essence# Dynamic Binding Protocol

1. The first step of the Essence# dynamic binding protocol is identical to that of the canonical protocol. It pretty much has to be: The code that implements it is part of the DLR itself. Although it would be possible to circumvent it but still use the DLR’s DynamicMetaObject Protocol for dynamic binding, it would be a lot more work, and would be much more likely to break if the DLR’s API is ever changed.

2. If the receiver of the message is a native Essence# object, then the object’s class will be asked for the method whose selector matches the message that was sent. If the class has such a method (either in its own local method dictionary, in the method dictionary of the trait or composite trait it’s using, or if its superclass can provide a matching method,) then that method will be used as the binding’s invocable function, and the receiver’s CLR type and Essence# class will be used as the binding restriction (actually, the version ID of the class will be used, because the method might be removed from the class at some time in the future.) If no matching method can be provided by the receiver’s class, then the binding subsystem will ask the class for its #doesNotUnderstand: method. If it can provide such a method, then that will be used. Otherwise, it will provide a function for the binding that directly raises the MessageNotUnderstood exception (so defining the #doesNotUnderstand: message is entirely optional.)

3. If the receiver of the message is not a native Essence# object (i.e., it’s an instance of some non-Essence# CLR type,) then the Essence# Object Space for that execution context will be asked to find or dynamically construct the Essence# class that represents instances of that CLR type. That operation cannot fail–a new Essence# class will always be defined, if it does not already exist. And there can be only one such class for each CLR type in any particular Essence# Object Space. The object’s class will then be asked for a method that matches the message selector, which happens in the same way as it would for a native Essence# object. The only difference is what happens if the class cannot provide a matching method:

4. In cases where the Essence# class for a foreign object does not have a method that matches the message selector, the DynamicMetaObject of the receiver will then be asked to provide a binding.  If it is able to do so, then that binding will be used.

5. Otherwise, if the receiver’s DynamicMetaObject fails to provide a binding, the Essence# dynamic binding subystem takes over the responsibility for doing so. And that’s where much of the magic happens which enables Essence# to interoperate so smoothly and effectively with languages that aren’t primarily based on the DLR (i.e, C#, F#, VisualBasic, etc.) That’s also where you’ll find the bulk of the code that implements the Essence# run time system.

So that’s what Essence# does to implement dynamic binding. The remaining question is why it does it that way, even though it’s not what the authors of the DLR strongly recommend.

The reason is both quite simple, and quite profound: The difference between the standard naming conventions of different programming languages in general, and the very stark differences between the naming conventions of Smalltalk-like languages and every other programming language in existence.

You see, the DLR’s protocol is based on the fallacy that the names of operations are the same in different languages, and based on the false assumption that what one language does by using a syntactical construct other languages also do by using some syntactical construct. Neither of those assumptions hold universally even between languages that use the same operation naming syntax, such as identifier + ["(" + {argument} + ")"] + “;”. But of course, Smalltalk-based languages don’t even share that meta-syntax with other languages, let alone the names themselves. And Smalltalk-based languages do almost everything by sending messages, and almost nothing by using special syntax, such as appending “()” to indicate “invoke a function” or prepending “(typeName)” to convert a value from one type to another.

So that’s why the first step Essence# takes in finding a binding when a Smalltalk message is sent to a foreign object is to ask the object’s Essence# class to interpret the message: It’s an Essence# (Smalltalk) message, not a message whose name or syntactical form is highly likely to mean anything to the objects of any other language.

What could or should the objects of any other language do when asked to find a binding for messages such as #displayOn:at:, #~~, or even just #value? Who could reasonably expect a CLR delegate with no arguments to know that it should respond to that message by invoking itself?

Worse, message (method) names such as #~~ and #displayOn:at: aren’t even legal in other languages. Even if they were, they aren’t likely to have the same semantics, because different languages usually have different standard libraries which use different names for the same thing.

Yes, Microsoft’s standard languages for .Net all use the same standard library-but that’s a special case. The DLR was intended to be used by dynamic languages with pre-existing standard libraries that are quite different than .Net’s BCL, and was not intended to be used by languages designed and implemented by Microsoft as native residents of the .Net framework. It therefore was a mistake to design the CLR’s dynamic binding protocol based on that false assumption. And that’s true without even considering the difference between Smalltalk’s keyword message names and the naming conventions used by all other languages.

The bottom line is that the Essence# dynamic binding protocol handles both the difference between Smalltalk’s message name syntax and also the difference between Smalltalk’s traditional and canonical message name semantics and that of the .Net BCL, and does so in a way that minimizes the risk that a message name will be misinterpreted just because it accidentally matches the name of a foreign function.

Essence# also provides a solution to the inverse problem of Essence# (Smalltalk) objects going on excursions to the homelands of foreign programming languages, and having foreign operations applied to them. And I admittedly haven’t documented that yet. Nevertheless, this post is already too long, so I’ll leave that topic to another time.