On Tue, 19 Oct 2010, Igor Stasenko wrote:
On 19 October 2010 02:51, Levente Uzonyi <[email protected]> wrote:
On Tue, 19 Oct 2010, Igor Stasenko wrote:
On 19 October 2010 00:25, Levente Uzonyi <[email protected]> wrote:
On Mon, 18 Oct 2010, Igor Stasenko wrote:
Stephane, i could say more:
- i don't like how LinkedList implemented.
I don't see why it should mimic things like #at: #at:put: at all..
It's not mimicing those methods. A list usually support things like this,
but the user should know the consequences.
The consequences of such approach is much more far-reaching: leads to
bad design practices, crappy application performance,
and then tons of bugs and workarounds.
Are programmers idiots? If not, then we shouldn't treat them like idiots.
No, of course not.
And that's why as non-idiot (i hope), i was wondering, what things
like #at: #at:put: doing in classes like Stack,
or LikedList.
Okay, it's not nice if a Stack allows indexing, but most linked list
implementations support it.
You know, its like you driving the car and along the road you see a
beatiful park with pool and attractions for the kids to play to the
right side, and a toxic waste dump to the left side of road.. And you
keep driving, thinking about a diner and wife, which waits you at
home, but at some moment your attention gets back to that place and
you have a gut feeling that there was something wrong with a picture
you just seen, and then you got it: they are close to each other, just
across the road!
IMO this protocol should be pruned from it, to not provoke uses which
completely do not fit for given data structure.
I'm not sure if it's okay to remove features, because users lacking
really
basic CS knowledge may use them the wrong way.
Imo, we should prohibit this from the beginning. Standard, core
classes should not contain an API, which could lead to
careless, abusive programming techniques.
So we should get rid of SortedCollection, remove #includes: #indexOf: from
ArrayedCollections, get rid of OrderedCollection >> #remove:, etc. Am I
right?
Roughly speaking, yes. But they are inherited.. this is a little another story.
And should be handled in a way like Array>>add: does.
Array >> #add: is different, because Arrays are not resizable. You could
say that one could use #become: to grow the array, but then I'd say that
following your suggestions we have to remove #become: from the system,
because it's slow and people may use it to write slow code.
IMO, a kernel APIs should serve not only as an implementation of basic
system funcionality, it also must serve as guide,
how to best use these facilities, so people will learn what is the
right way to use it.
That's right, but there's no need to remove useful features to achieve this.
you should convince me first, that things like LinkedList>>at: is userful.
Ok. Here's an example:
What happens if you remove OrderedCollection >> #remove: from the system?
People will write code like this (or worse):
gotIt := false.
1 to: o size do: [ :index |
gotIt
ifTrue: [ o at: index - 1 put: (o at: index) ]
ifFalse: [
(o at: index) = myObject ifTrue: [ gotIt := true ] ].
gotIt ifTrue: [ o removeLast ].
This kind of code is a lot worse than using #remove:, because it's harder
to understand, harder to debug, really easy to mess up. And it will be
reimplemented several times.
Levente
We should teach users to use right tools for things they need.
Removing/inserting into the middle of list is quite ineffective
operation (O(n)),
As long as you don't give away the link objects, it's O(n), otherwise it
can
be O(1).
giving away link objects... oh, that's the worst thing, which could
possibly happen :)
No. It's the user's responsibility to use it wisely. If you don't need to
access a internal nodes, just adding/removing elements to/from the list,
then you probably shouldn't use a list at all.
I prefer making own lists and own classes for list items, because
implementation of
LinkedList raising many questions starting from being optimal, and up
to concerns i presented above.
while inserting at the begginning/end of list is O(1).
Lists are sequenceable.. but sequenceable ~~ indexable. Period.
Sequenceable is indexable, but good performance is not guaranteed.
Unless you representing an infinite collection(s).
Streams are good example of sequenceable, however non-indexable
containers.
Streams are more like external iterators, than containers IMHO. But you can
get/set the position of most streams.
Levente
Levente
--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
