Indeed I found that terrible when we ported moose. So can you propose something and we fix it. I have the impression that subclasses should not override mooseName so we should turn them into mooseNameOn:
Stef
Problems I can see now:
- not all classes seem to override printOn: in a proper way.
- mooseName calls mooseNameOn: in MooseEntity, but some subclasses
override mooseName, and others mooseNameOn: That does not look good.
Take for example
MooseEntity>>mooseName | stream | ^ self privateState at: #mooseName ifAbsentPut: [ stream := (String new: 64) writeStream. self mooseNameOn: stream. ^ stream contents asSymbol ]
MooseEntity>>mooseNameOn: aStream self mooseID isNil ifTrue: [ aStream nextPutAll: 'nil mooseID!!!' ] ifFalse: [ self name ifNil: [ aStream print: self mooseID ] ifNotNil: [ aStream nextPutAll: self name ] ]
There is plenty of ways one can customize mooseName, and amazingly almost all those ways are used:
- you can override mooseName
- you can override mooseNameOn:
- you can override name
- you could also directly set #mooseName in privateState, for
example in the initialize method (something done in MooseGroup>>initialize..... self description: 'Group')
Cheers, Doru
On 5 Nov 2009, at 21:27, Alexandre Bergel wrote:
#printOn: is used by Pharo tools to display objects. For example, a famix class is printed as "a FAMIXClass #'Smalltalk::CRCError'"
Glamour uses description to render items in browsers. It makes sense to have a short description from the moose point of view (instead of the developper tools point of view as with printOn:). A description of a famix class could be 'Smalltalk::CRCError (Class)'
Not really, we kind of mix things there (partly because of my ignorance). Glamour uses the standard Smalltalk way (asString...). I also used mooseName for formatting some entries, but now prefer the standard way, except the standard way is not well defined everywhere. Then MooseGroup uses its description when printing itself.
mooseName returns a description shorter than with #description. It is often used as dictionary keys and unique identifier. For the famix class CRCError we have #'Smalltalk::CRCError'
We could maybe replace #description for #mooseLongName. This will be more explicit and make implementer/serder easily browsable since #description is implemented in Monticello, Fame, Exception
This is a good action task to do in my opinion. Shall I add an entry in the Moose code google? Moreover, I do not see any Moose unit test that test it (but I did a quick check).
Cheers, Alexandre
On 5 Nov 2009, at 10:01, Simon Denier wrote:
This morning, I tried to understand (I thought I understood before) the things about printing Moose entities, either in the finder or in an inspector, or whatever.
Only thing I can say is it's a mess with a lot of yo-yo in the hierarchy.
So there is MooseEntity>>description MooseEntity>>mooseName MooseEntity>>printOn:
also mooseNameOn: etc.
MooseGroup tends to use description. mooseName is likely a unique identifier, however it is also used to print an entity sometimes (in the moose finder) #printOn: is not rationally overridden everywhere...
Maybe someone wants to take a look and proposes a solution, at least some conventions/documentation.
Which selector is used in which context. Which method should I override in a new entity.
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Obvious things are difficult to teach."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev