[Pharo-project] Stack should be reimplemented with Array

Levente Uzonyi leves at elte.hu
Tue Oct 19 00:03:31 EDT 2010


On Tue, 19 Oct 2010, Igor Stasenko wrote:

> On 19 October 2010 02:51, Levente Uzonyi <leves at elte.hu> wrote:
>> On Tue, 19 Oct 2010, Igor Stasenko wrote:
>>
>>> On 19 October 2010 00:25, Levente Uzonyi <leves at elte.hu> 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
>>>>> Pharo-project at lists.gforge.inria.fr
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> Pharo-project at lists.gforge.inria.fr
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> Pharo-project at lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project at lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> -- 
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>




More information about the Pharo-dev mailing list