[Pharo-project] Stack should be reimplemented with Array
leves at elte.hu
Mon Oct 18 19:51:48 EDT 2010
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.
>>> 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
> 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
> 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.
>>> 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.
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>> Pharo-project mailing list
>>> Pharo-project at lists.gforge.inria.fr
>> Pharo-project mailing list
>> Pharo-project at lists.gforge.inria.fr
> Best regards,
> Igor Stasenko AKA sig.
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
More information about the Pharo-dev