Nothing in OOP is obvious

Is nothing in OOP obvious to the neophyte?

Here is comment from a class named Observable declared as follows :


   public abstract shared Observable


The documentation for the class contains the following method comment  :

public add-observer

Add an observer to this object's list of observers to be notified. Typically this is only called from the Observer's observe method.


For this to make sense to a neophyte, wouldn't we need TWO variants of PUBLIC, e.g.,

• MY-PUBLIC-FACE
• YOUR-PUBLIC-VIEW-OF-ME

corresponding to

• obj-public (intended for me to call against myself)
• consumers-public (available as your message sent to me)

??

BTW, that add-observer method is declared as follows :

public  
{Observable.add-observer
    o:Observer,
    error-if-present?:bool = false
}:void


Is the issue the method name ?  Should it be 

   all-ya-all-add-observer-to-me

??

Consider :

   receive-observer

But what in a name prevents a hack ?  One idea : object procedures and functions versus messages.  In such a language, an object never sends itself a message.  If you have a local copy of an object, you can use its public procedures and functions.  If you have a pointer to an object - an object reference - you send only messages.

And what did the documenting author mean by "typically" ?

---

Logtalk 2.42.1

Logtalk 2.42.1 for most Prolog implementations was released on Dec 22, 2010.

To quote from logtalk.org

Logtalk is an object-oriented logic programming language that can use most Prolog implementations as a back-end compiler. As a multi-paradigm language, it includes support for both prototypes and classes, protocols (interfaces), component-based programming through category-based composition, event-driven programming, and high-level multi-threading programming.

The release notes report (among other things)

includes portability updates for B-Prolog, SICStus Prolog, SWI-Prolog, XSB, and YAP

Curl ValueControl

Here's a challenge for class hierarchies without Traits.

The Curl class ValueControl is noted as follows in the docs:

ValueControl (class)

public abstract ValueControl {inherits Control}

Import from: CURL.GUI.STANDARD. Defined in package CURL.GUI.CONTROL-BASE.

Direct Known Subclasses: ValueControl-of

A superclass for any Control that has a value.

Description

All the Controls with values inherit from this class. It provides abstract accessors for the value, as an any, and an accessor for the expected Type of the value.

Overriding

Don't subclass this class. Subclass ValueControl-of instead.

I added emphasis to the advice. My question is, how might such an intent be enforced in a class hierarchy?  What would you call such a modifier or a macro used to create such a class?

The class in question has the 2 abstract methods value-type and value-as-any but it also implements 2 methods: form-value and has-value?.  In addition, it has a class procedure form-string.  The default constructor for the class is noted as

... : Rest arguments are passed up to Control, which passes them to Visual.

The method form-value is documented as intended for use with controls embedded in HttpForm instances.
It is documented as a getter but not as being abstract yet as intended to be overridden by subclasses.

Here is a snippet from those docs;

The value returned by this getter must be one of the following:

 • String

 • array of String

 • null

Notes

Each control overrides this method to return the value that needs to be sent when the HttpForm that contains this control is submitted.

So why is the method not abstract? Well, because it returns a value of type any - but its subclass is parameterized for types of values.  And here is one more thing that makes Curl fascinating: the leaf classes of these hierarchy branches are not themselves declared as parameterized for a type - and in the case of DateField, the value keyword parameter to the default constructor may be of a possibly-null type - a #DateTime type.

What this may show is that multi-inheritance with partially-abstract classes as mixins or otherwise can be very flexible:

public abstract MultiUIValueControlFrame-of {inherits 

   MultiUIControlFrame, 

   {ValueControl-of tValue}}

A default O-O package for Tcl 8.6: TclOO

 
While the link for O-O Tcl looks to be dated, the page for Tcl 8.6 releases is current.

I have a bias for XOTcl, but I will try to be open-minded when 8.6 gets out of beta.

TclOO is intended to offer classes and objects as a Tcl package rather than as an ad hoc extension to Tcl and Tk.  Some "patterns" folks will like the hiding of new in class in favour of create as the class declaration idiom - but instances are created via a command block substitution with the new word as in

set obj [MyClass new]

A google of TclOO and Tcl failed to get me past beta1 links to Tcl8.6b2 links.

But the link to the PDF on the new engine looked interesting.

This link at tcl.tk may be the final URL for core TclOO.

Over at activestate.com Tcl remains at 8.5.8 with a release number of 8.5.8.2 as of today.

Tcl 8.5.9 added the ttk::spinbox command.

A google on "Tcl 8.6" gives some useful links such as that to Mark Roseman's 8.6 page (he is the author of the tutorial for Ttk or Tile/Themed Tk.)

XOTclIDE: the IDE that is almost Smalltalk

I copied XOTclIDE82.kit into my \kits directory for ActiveState Tcl/Tk for Windows.
A double click on the kit ( I already had Tclkit in the PATH for Tcl\bin ) and I was politely asked whether to launch Simple or with Version Control. Simple was fine for now.

The result was a Transcript, a ClassBrowser and I was one click from a WorkSpace.

If you have ever used Smalltalk, this will sound very familiar.

And if you have never used Tcl with the GUI Tk you deserve to take an hour or two and see what simple GUI-driven control of admin tasks can be like.

XOTcl is extended MIT OTcl. There had been a few GUI extensions to Tcl rather as there have been for Python. But these extensions are principled: they do not simply provide a wrapper to a GUI library. The Mozart-Oz system is very much built on principle and exploits Tcl/Tk in its QTk, but lacks an IDE (SICStus Prolog also has a Tcl interface.). Tcl upvar and uplevel are not a replacement for the Mozart implementation of Oz, so my question becomes: does this rich environment impede or foster useful Tcl scripting?

An IDE as rich as that found with most Smalltalk implementations tends to be only as useful as its GUI layout tools and/or GUI specification framework. If it is awkward to tie event handlers and callbacks to widgets and worse to edit or maintain them, then little is gained by having object inspectors and dynamic workspaces. Tcl/Tk itself is marvelously simple (Jython comes to mind by way of comparison - or Rebol or Curl RTE's.)

The XOTcl documentation presents a very flexible, dynamic object framework, but the XOTcl components are file-based Tcl packages which must be registered with Tcl. Tcl is about component integration, but it's own integration of packages is a weak point, which is not to say that packaging and load dependencies cannot also be a headache in Smalltalk.

If I find the learning curve not too steep ( if Curl, the MIT web content language, has a gentle curve then Rebol is like learning to surf: anyone can paddle out ... ) then I will add a header page at eclectic-pencil and see if I can't put up a few useful markers across the terrain.

If you have a favorite language with no non-commercial IDE and are not in love with Eclipse, XOTclIDE does show what a mature IDE can offer a developer in a dynamic language. The only development environment to interest me as much as this was the outline-browser of Strongtalk.

PS Eclipse, of course, evolved from IBM VisualAge Smalltalk ...