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: '[email protected]: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
> <[email protected]> wrote:
>
>
> From: Marc Hanisch <[email protected]>
> Subject: About patterns, UML and documentation
> Date: June 7, 2017 at 10:17:11 PM PDT
> To: Any question about pharo is welcome <[email protected]>
>
>
> 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
>
>
