I would spect it to return aBag, for example. On 27 October 2011 12:13, Andrea Brühlmann <[email protected]> wrote:
> Hi Clara, > > You don't need to worry about the receivers class, but about the result you > wish to have... There are 2 possibilities what the result will be: either > the same kind as the original collection or something else! If you mind > about the result, you need to tell the system what the result should look > like :-) But I just want to use it! > In your case, it is important that the result is no Set, so this is why you > need to tell the system to collect the grades as an OrderedCollection or > whatever. It doesn't matter if the students are a Set or not then! Indeed. IN THIS CASE it's important that the result is not a Set. But why? Because the receiver is a Set!!! I do not send a asBag message to every collect: result I get, so why should I do that here? What you're saying is that I need to be aware that the receiver is a Set, which sucks. Otherwise, I should send asBag every time I use collect:, just in case the receiver is a Set... That doesn't sound good. > self students collect: #grade as: OrderedCollection > > Do you have another solution in mind? Maybe you expect Set>collect: to > return anOrderedCollection by Default? This would make sense for your > students grades and for many more cases, but then, the implementation would > break the rule "Collections always return results on an new instance of its > own #species". > And why couldn't we break the rule in this case? Again, this works for the others collections and the other messages, and I'm ok with it. But not with collect: :S > > Andrea > > > > > > Clara Allende schrieb: > > Ok, but this means I have to worry of the receiver's class before I send >> collect:, so as I don't fuck it all up.... and I don't want to think about >> that!!! See, if I want the collection of grades of the students, I would >> like to do this: >> >> grades >> ^self students collect: [.aStudent | aStudent grades] >> >> regardless of whatever is the class of students... This does the trick >> for >> all the collections, except for Set. And I don´t know if students is an >> instance of Set, and I really don't want to think if it is or not. If I >> don't want repeated students and I create my collection as an instance of >> Set, an i.e.; I want to calculate the average, then I'm screwed because >> the >> collection I get from the collect: wasn't the want that I wanted. >> So, I have to know previously that my collection is an instance of Set, or >> if it isn't, so as to know if I have to convert it first.... >> >> And if I use collect: as:, as you suggest, this means the collections are >> no >> longer polymorphic for me :( >> Sorry, maybe I'm really stupid, but I don't know how that message solves >> best the problem than redefining collect: for Set. For the particular case >> I >> don't want the repeated objects (which AFAIK is not so common) I could >> send >> asSet. >> >> On 27 October 2011 11:05, Henrik Sperre Johansen < >> [email protected]> wrote: >> >> On 27.10.2011 15:40, Clara Allende wrote: >>> >>> I know, but our students don't :) So they ran into problems because the >>>> message send didn't answer what they were specting.... because it makes >>>> sense that if I want to transform the objects in my collection, I might >>>> get >>>> repeated objects... Maybe I'm not thinking in terms of consistency, I'm >>>> just >>>> putting myself on student's shoes :P >>>> >>>> The consistency rule to remember for #collect:/#select:/#reject: is >>> that >>> they will return a collection of the receiver's species. >>> #collect:as: was added as a general answer to the situation your students >>> ran into :) >>> >>> set := Set withAll: #(1 2 3 4 5 6 7 8). >>> result := set collect: #even as: Bag. >>> >>> Cheers, >>> Henry >>> >>> >>> >>> >>> >> >> > -- > AB | ANDREA BRÜHLMANN · SOFTWARE ENGINEER > | NETSTYLE · TERRASSENWEG 18 · CH-3012 BERN > | TEL +41 31 356 42 54 · FAX +41 31 356 42 51 > | WWW.NETSTYLE.CH · [email protected] > > -- "*Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.*" Linus Torvalds
