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. 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. >> 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. >> >> 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
