Hi Marc.

In Smalltalk, we rely on naming conventions a lot.

The great thing is that Smalltalk selectors/symbols/method names read like English.

aDictionary at: aKey put: anObject.

aString indexOf: aCharacter  startingAt: start  ifAbsent: aBlock

Seems pretty clear, no?

We also rely on comments.  For instance this is the class comment for IceRepository - an abstraction of a git repo.

I represent an interface to a git repository. 

My main responsibilities are:
- Load/update both baselines and individual packages from the repository.
- Commit changes to the local repository and publish them to a remote repository.
- Browse other versions of the loaded packages.
- Handle branches

For the Collaborators Part: State my main collaborators and one line about how I interact with them. 

Public API and Key Messages
- loadPackage: packageName
- createBranch: newBranchName

Sample usage:

    Git new origin: 'git@github.com:npasserini/pharo-git-test.git'.
    git loadPackage: 'Pharo-Git-Test'. 


Instance Variables
- origin: A string representing the url of a remote git repository (used as origin)
- repository: An IceGitTreeGitRemoteRepository, which provides underlying git operations.
- location: <FileReference> The directory of the local repository.
- commitDictionary: <Dictionary of IceCommitInfo> Cached dictonary from commitId (hex string) to  all commits in the current branch (in the local repo).
- subdirectory: <String> The subdirectory of the local repository which is handled by the underlying GitFileTree
- versionDescriptors: <List of GitFileTreePackageEntry> cached list of all package versions saved in the (currently selected branch) of the (local) repository.
- announcer: <Announcer>
- branch: <IceBranch> currently selected branch. 
- loadedCode:  <IceLoadedCode> Contains information about the loaded code for each package in this repository. (TODO: maybe handle special cases about loading different versions loaded for different packages, see: https://github.com/npasserini/iceberg/issues/139).

I hope this helps.

-Todd Blanchard

On Jun 7, 2017, at 10:17 PM, Marc Hanisch via Pharo-users <pharo-users@lists.pharo.org> wrote:


From: Marc Hanisch <marc.hanisch@googlemail.com>
Subject: About patterns, UML and documentation
Date: June 7, 2017 at 10:17:11 PM PDT
To: Any question about pharo is welcome <pharo-users@lists.pharo.org>


Hello,

I don't know Smalltalk well enough to give myself an answer about the following topic:

When using design patterns, one benefit of writing interfaces and passing objects, that implement this interface, to methods is, that the reader instantly knows: okay, here the method A expects something that implements method B.

Due to the nature of being a dynamically typed language, Smalltalk does not need interfaces. An exception object is thrown when a message is passed to an object that does not implement that method. But this message send could be deep inside the code.

How do you show to the reader of your code your intention, that you are expecting, let's say for example, an iterator or an object that implements method X, Y and Z?

Just with your method comments? Do you use UML? If so, how (without interfaces that point to the required methods)?

Sorry, but I think my understanding of OOP is still to much influenced by C++ and Java based teachings...

Thanks and best regards,
Marc