I often use copy in default access methods. The motivation is increaed robustness; it can be very risky to modify a collection.
While a read-only accessor may have its place, in *this* case, robustness is decreased, not increased. If you don't want to allow direct access to a Collection, then what do you think about providing various enumerating / adding / removing / finding api from the containing class?
I generally disagree with having code that "cross-checks" potentially incorrect code elsewhere. Besides the aforementioned performance degradation, it can inhibit learning because it allows misuse and then even increases confusion/uncertainty about the necessity of it when you try to remedy it (just like right now, we're all scratching our heads about this!).
submorphs do: [:m | ........ ifTue: [m delete]])
In this case, I think we should let anyone who tries misuse in this way learn. Let those who already know benefit from the increased performance of not copying submorphs every single time we ask for it.
- Chris
Thanks to everyone who has given this consideration. In case people want to try it and don't know what were talking about, here's a changeset that switches to no-copy and includes a comment. Let us know if you find any problems.
Chris Muller wrote:
I often use copy in default access methods. The motivation is increaed robustness; it can be very risky to modify a collection.
While a read-only accessor may have its place, in *this* case, robustness is decreased, not increased. If you don't want to allow direct access to a Collection, then what do you think about providing various enumerating / adding / removing / finding api from the containing class?
I generally disagree with having code that "cross-checks" potentially incorrect code elsewhere. Besides the aforementioned performance degradation, it can inhibit learning because it allows misuse and then even increases confusion/uncertainty about the necessity of it when you try to remedy it (just like right now, we're all scratching our heads about this!).
I agree; there are lots of ways to screw up a Morph, copy or no copy. Also, exporting the actual object reduces the need to make lots of collection lookalike accessor methods to avoid a performance penalty.
Thanks, Eddie
I think that any good fix of morphic is really high on our consideration. Thanks for your time!!!!
Stef On 29 juil. 05, at 4:09, Eddie Cottongim wrote:
Thanks to everyone who has given this consideration. In case people want to try it and don't know what were talking about, here's a changeset that switches to no-copy and includes a comment. Let us know if you find any problems.
Chris Muller wrote:
I often use copy in default access methods. The motivation is increaed robustness; it can be very risky to modify a collection.
While a read-only accessor may have its place, in *this* case, robustness is decreased, not increased. If you don't want to allow direct access to a Collection, then what do you think about providing various enumerating / adding / removing / finding api from the containing class?
I generally disagree with having code that "cross-checks" potentially incorrect code elsewhere. Besides the aforementioned performance degradation, it can inhibit learning because it allows misuse and then even increases confusion/uncertainty about the necessity of it when you try to remedy it (just like right now, we're all scratching our heads about this!).
I agree; there are lots of ways to screw up a Morph, copy or no copy. Also, exporting the actual object reduces the need to make lots of collection lookalike accessor methods to avoid a performance penalty.
Thanks, Eddie
<NoCopySubmorphs-efc.2.cs.gz>
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
Eddie Cottongim -
stéphane ducasse