[Pharo-project] Stack should be reimplemented with Array

Igor Stasenko siguctua at gmail.com
Mon Oct 18 23:11:08 EDT 2010


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




More information about the Pharo-dev mailing list