20 Aug
2012
20 Aug
'12
3:05 p.m.
You have spotted a nice bug.
Curiously, it always worked. This is now fixed in Roassal 1.98
I have added a method removeShape: aShapeClass previousShape: aShape that does the thing.
Thanks Ben! Keep going your review!
Cheers,
Alexandre
On Aug 20, 2012, at 6:59 AM, Ben Coman <btc(a)openInWorld.com> wrote:
Based on what you say, from this amended code...
b := ROBox new.
c := ROCircle new.
b addLast: c.
(b removeShape: ROCircle) inspect
I would expect to get a chain: aROBox --> aROChildrenShape
but instead I get only: aROChildrenShape
Can you confirm that result? I had played around a bit with the code, but Monticello
does currently say Roassal.274 has "no changes"
Alexandre Bergel wrote:
But without a lot of documentation so far, looking at and understanding the internals
does help the external use it (but with the danger of the boundary becoming a bit grey)
Yes, understood, Thanks.
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Just recording a bit of my learning the internals
of Roassal, since it helps me flesh out my understanding.
[ROShape>>removeShape:] does not have a test to reference for my understanding of
this, but it appears to not work as expected. For example in workspace...
b := ROBox new.
c := ROCircle new.
b addLast: c.
b removeShape: ROCircle.
b inspect
removeShape: works as expected I believe. I guess the problem is a matter of naming.
The method ROShape>>removeShape: is actually an helper method and it is not meant
to be directly called. Look at the method:
-=-=-=-=-=-=-=-=-=-=-=-=
ROElement>>removeShape: aShapeClass
"Remove a shape of the element"
shape := shape removeShape: aShapeClass
-=-=-=-=-=-=-=-=-=-=-=-=
Again, I use the Null Object design pattern. I wanted to loop here on the list of shape
and doing a if-statement.
Actually, ROShape>>removeShape: aShape does not remove a shape, it simply return a
collection of shapes without aShape. What a better method name could be? #shapesWithout:
or #shapeChainWithout: ?
Perhaps ROShape>>withoutShape:
results
in a linked list of: aROBoxShape --> aROCircleShape --> aROChildrenShape. Actually
the semantics of [removeShape:] seem problematic. What should be the result of...
b := ROBox new.
b removeShape: ROBox.
b inspect.
The method #removeShape: has indeed a very bad name. It suggests a side effect, but none
is actually realized.
I would guess that 'b' should hold
aROChildrenShape, except you can't change the value of 'b' from inside the
[removeShape:] method. (In my limited knowledge of 'slots', I wonder if this is
something they might help with.) I am relying on the guess that you could have
aROChildrenShape as the only shape on an element, for subviews without a border, but could
you clarify this.
Naively I thought to just try... removeShape: aShapeClass
^ (self isKindOf: aShapeClass)
ifTrue: [ next become: next next ]
ifFalse: [ next removeShape: aShapeClass ]
but the danger of #become hit me and locked my image.
btw, something else just while I am feeling evil, what should happen with the
following...
b := ROBox new.
b removeShape: ROChildrenShape.
b inspect.
I guess my answer given above should clear up the things...
Alexandre
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev