Quantcast

Map filter vs. filterNot

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Map filter vs. filterNot

Raoul Duke
http://www.scala-lang.org/api/current/scala/collection/immutable/Map.html
"Returns a new map with all key/value pairs for which the predicate p
returns true."
shouldn't that be false?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Map filter vs. filterNot

HamsterofDeath
i was confused at first, too.
i think of it this way: "filter" divides a collection into 2 collections
without an intersection. weither or not you get the first or second
subcollection isn't defined by the name "filter". it could mean "filter
those getgive them to me" or "filter those out of the collection and
return the remaining collection"


Am 29.01.2011 02:44, schrieb Raoul Duke:
> http://www.scala-lang.org/api/current/scala/collection/immutable/Map.html
> "Returns a new map with all key/value pairs for which the predicate p
> returns true."
> shouldn't that be false?
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Map filter vs. filterNot

Litvinov Alexandr
In reply to this post by Raoul Duke
You can look at implementing this functions in TraversableLike and to you will know exactly how this working. See
def filterNot(p: A => Boolean): Repr = filter(!p(_))

29.01.2011, 06:44, "Raoul Duke" <[hidden email]>:
> http://www.scala-lang.org/api/current/scala/collection/immutable/Map.html
> "Returns a new map with all key/value pairs for which the predicate p
> returns true."
> shouldn't that be false?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Map filter vs. filterNot

Jim Balter-2
In reply to this post by Raoul Duke
On Fri, Jan 28, 2011 at 5:44 PM, Raoul Duke <[hidden email]> wrote:
http://www.scala-lang.org/api/current/scala/collection/immutable/Map.html
"Returns a new map with all key/value pairs for which the predicate p
returns true."
shouldn't that be false?

"shouldn't" in what sense? That's what the code does and what it is intended to do, so the documentation says what it should say. OTOH, the method *should* have been called "keep" rather than the misleading and ambiguous "filter", but it wasn't. But that's nothing compared to the fact that toUTF converts *from* UTF and fromUTF converts *to* UTF, and when I mention that here I get no response other than silly nonsense about method signatures determining semantics.

-- Jim
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Map filter vs. filterNot

Jim Balter-2
In reply to this post by Litvinov Alexandr
Indeed, to understand what the Scala libraries do it's often necessary to read the code.

-- Jim


On Fri, Jan 28, 2011 at 11:13 PM, Alexandr Litvinov <[hidden email]> wrote:
You can look at implementing this functions in TraversableLike and to you will know exactly how this working. See
def filterNot(p: A => Boolean): Repr = filter(!p(_))

29.01.2011, 06:44, "Raoul Duke" <[hidden email]>:
> http://www.scala-lang.org/api/current/scala/collection/immutable/Map.html
> "Returns a new map with all key/value pairs for which the predicate p
> returns true."
> shouldn't that be false?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Map filter vs. filterNot

Jason Zaugg
In reply to this post by Jim Balter-2
On Sat, Jan 29, 2011 at 8:48 AM, Jim Balter <[hidden email]> wrote:

> On Fri, Jan 28, 2011 at 5:44 PM, Raoul Duke <[hidden email]> wrote:
>>
>> http://www.scala-lang.org/api/current/scala/collection/immutable/Map.html
>> "Returns a new map with all key/value pairs for which the predicate p
>> returns true."
>> shouldn't that be false?
>
> "shouldn't" in what sense? That's what the code does and what it is intended
> to do, so the documentation says what it should say. OTOH, the method
> *should* have been called "keep" rather than the misleading and ambiguous
> "filter", but it wasn't. But that's nothing compared to the fact that toUTF
> converts *from* UTF and fromUTF converts *to* UTF, and when I mention that
> here I get no response other than silly nonsense about method signatures
> determining semantics.

You can directly contribute to improving the documentation comments by
suggesting changes with Colladoc:

http://scala-webapps.epfl.ch/colladoc/

-jason
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Map filter vs. filterNot

Daniel Kristensen
In reply to this post by Jim Balter-2
Well, the doc for filterNot is correct in TraversableLike, but the doc for the override in MapLike (which Raoul quotes) is clearly wrong. It should indeed say "Returns a new map with all key/value pairs for which the predicate p returns false."

So this is somewhat similar to the toUTF example, except of course it will be much more painful to correct the latter :)

/Daniel

On Sat, Jan 29, 2011 at 8:48 AM, Jim Balter <[hidden email]> wrote:
On Fri, Jan 28, 2011 at 5:44 PM, Raoul Duke <[hidden email]> wrote:
http://www.scala-lang.org/api/current/scala/collection/immutable/Map.html
"Returns a new map with all key/value pairs for which the predicate p
returns true."
shouldn't that be false?

"shouldn't" in what sense? That's what the code does and what it is intended to do, so the documentation says what it should say. OTOH, the method *should* have been called "keep" rather than the misleading and ambiguous "filter", but it wasn't. But that's nothing compared to the fact that toUTF converts *from* UTF and fromUTF converts *to* UTF, and when I mention that here I get no response other than silly nonsense about method signatures determining semantics.

-- Jim

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Map filter vs. filterNot

Seth Tisue
In reply to this post by Jim Balter-2
>>>>> "Jim" == Jim Balter <[hidden email]> writes:

 Jim> toUTF converts *from* UTF and fromUTF converts *to* UTF, and when
 Jim> I mention that here I get no response other than silly nonsense

Open a ticket.

--
Seth Tisue @ Northwestern University | http://tisue.net
lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Map filter vs. filterNot

Jim Balter-2
In reply to this post by Daniel Kristensen
On Sat, Jan 29, 2011 at 5:30 AM, Daniel Kristensen <[hidden email]> wrote:
Well, the doc for filterNot is correct in TraversableLike, but the doc for the override in MapLike (which Raoul quotes) is clearly wrong. It should indeed say "Returns a new map with all key/value pairs for which the predicate p returns false."

Sorry, I thought he was quoting the doc for filter rather than filterNot.

So this is somewhat similar to the toUTF example, except of course it will be much more painful to correct the latter :)

Indeed, and so I think it's quite dissimilar. For filterNot, the implementation is correct, only the Scaladoc is wrong; correcting it is painless, now or later; the only pain is for people who try to use it according to the Scaladoc before it gets corrected. But for toUTF and fromUTF the method signatures and implementation is wrong (as for Scaladoc, there is none) and there are already cases in the library that depend on that and any user code that uses them necessarily depends on it too. So correcting them requires a deprecation annotation and either selection of inferior names or waiting another release cycle to correct them (fortunately code that uses them would no longer compile).

On Sat, Jan 29, 2011 at 7:53 AM, Seth Tisue <[hidden email]> wrote:
Open a ticket.

Aye aye, sir, but I must say ... Whoosh!

-- Jim

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Map filter vs. filterNot

Jim Balter-2
In reply to this post by Jason Zaugg
On Sat, Jan 29, 2011 at 12:11 AM, Jason Zaugg <[hidden email]> wrote:
On Sat, Jan 29, 2011 at 8:48 AM, Jim Balter <[hidden email]> wrote:
> On Fri, Jan 28, 2011 at 5:44 PM, Raoul Duke <[hidden email]> wrote:
>>
>> http://www.scala-lang.org/api/current/scala/collection/immutable/Map.html
>> "Returns a new map with all key/value pairs for which the predicate p
>> returns true."
>> shouldn't that be false?
>
> "shouldn't" in what sense? That's what the code does and what it is intended
> to do, so the documentation says what it should say. OTOH, the method
> *should* have been called "keep" rather than the misleading and ambiguous
> "filter", but it wasn't. But that's nothing compared to the fact that toUTF
> converts *from* UTF and fromUTF converts *to* UTF, and when I mention that
> here I get no response other than silly nonsense about method signatures
> determining semantics.

You can directly contribute to improving the documentation comments by
suggesting changes with Colladoc:

http://scala-webapps.epfl.ch/colladoc/

-jason


Another instance of completely missing the point. Note that it is fromUTF and toUTF (not their nonexistent Scaladoc) that are wrong, and Colladoc cannot correct the sort of process errors that produce such silly but difficult-to-correct errors. And "automatic specification testing" and "intuitionistic reasoning" (which we're told the readers of this list are too thick to comprehend) are also of no help here.

-- Jim
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Map filter vs. filterNot

Ismael Juma
In reply to this post by Jim Balter-2
On Sun, Jan 30, 2011 at 1:00 AM, Jim Balter <[hidden email]> wrote:
> So correcting them requires a deprecation annotation and either selection of
> inferior names or waiting another release cycle to correct them (fortunately
> code that uses them would no longer compile).

Using the @migration annotation is also an option. That would allow
fixing the methods in the next cycle. This annotation was used in a
few cases for 2.8.0, but that release had a lot of breaking changes
(unlike 2.9.0).

Best,
Ismael
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Map filter vs. filterNot

Daniel Kristensen
In reply to this post by Jim Balter-2
On Sun, Jan 30, 2011 at 2:00 AM, Jim Balter <[hidden email]> wrote:
On Sat, Jan 29, 2011 at 5:30 AM, Daniel Kristensen <[hidden email]> wrote:
So this is somewhat similar to the toUTF example, except of course it will be much more painful to correct the latter :)

Indeed, and so I think it's quite dissimilar. For filterNot, the implementation is correct, only the Scaladoc is wrong; correcting it is painless, now or later; the only pain is for people who try to use it according to the Scaladoc before it gets corrected. ...

Yes, I agree. The slight similarity is that the scaladoc of MapLike#filterNot gets it backwards, like the names of the toUTF and fromUTF methods, but obviously there's a big difference between these cases.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Map filter vs. filterNot

Daniel Kristensen
In reply to this post by Jason Zaugg

You can directly contribute to improving the documentation comments by
suggesting changes with Colladoc:

http://scala-webapps.epfl.ch/colladoc/

-jason

Thanks, I just suggested the following change:

Old:

Returns a new map with all key/value pairs for which the predicate p returns true.

Note: This method works by successively removing elements fro which the predicate is false from this set. If removal is slow, or you expect that most elements of the set will be removed, you might consider using filterwith a negated predicate instead.

p A predicate over key-value pairs
returns A new map containing elements not satisfying the predicate.

New (changed words in bold):

Returns a new map with all key/value pairs for which the predicate p returns false

Note: This method works by successively removing elements for which the predicate is true from this set. If removal is slow, or you expect that most elements of the set will be removed, you might consider using filterwith a negated predicate instead.

p A predicate over key-value pairs
returns A new map containing elements not satisfying the predicate.

/Daniel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Map filter vs. filterNot

Jim Balter-2
In reply to this post by Ismael Juma
On Sat, Jan 29, 2011 at 5:42 PM, Ismael Juma <[hidden email]> wrote:
On Sun, Jan 30, 2011 at 1:00 AM, Jim Balter <[hidden email]> wrote:
> So correcting them requires a deprecation annotation and either selection of
> inferior names or waiting another release cycle to correct them (fortunately
> code that uses them would no longer compile).

Using the @migration annotation is also an option. That would allow
fixing the methods in the next cycle. This annotation was used in a
few cases for 2.8.0, but that release had a lot of breaking changes
(unlike 2.9.0).

Yes, of course you are right; I forgot about @migration; sorry, and thanks. Maybe I was too busy thinking about those @deprecation annotations on  UTF8Codec.{en,de}code that tell people to use the wrongly named methods instead.

But I really do think that the devs should think about, and have something to say about, how such an inversion of names did and could come about, and wasn't caught and fixed even when the backwards methods were used in the compiler and scalap sources:

 /** Create a term name from the UTF8 encoded bytes in bs[offset..offset+len-1].
   */
  def newTermName(bs: Array[Byte], offset: Int, len: Int): TermName =
    newTermName(Codec toUTF8 bs.slice(offset, offset + len) mkString)

and

/** read an UTF8 encoded string
   */
  def nextUTF8(len: Int): String = {
    val cs = scala.io.Codec.toUTF8(buf.slice(bp, bp + len)) 
    ...

Some people here like to say "open a ticket" ... shouldn't the people who wrote that code have opened a ticket when committing code that depends upon an obvious error? I don't think I should be opening tickets pointing out problems with your development process -- that's something you need to come to grips with.

-- Jim

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Map filter vs. filterNot

Jason Zaugg
In reply to this post by Jim Balter-2
On Sun, Jan 30, 2011 at 2:05 AM, Jim Balter <[hidden email]> wrote:

>> > "shouldn't" in what sense? That's what the code does and what it is
>> > intended
>> > to do, so the documentation says what it should say. OTOH, the method
>> > *should* have been called "keep" rather than the misleading and
>> > ambiguous
>> > "filter", but it wasn't. But that's nothing compared to the fact that
>> > toUTF
>> > converts *from* UTF and fromUTF converts *to* UTF, and when I mention
>> > that
>> > here I get no response other than silly nonsense about method signatures
>> > determining semantics.
>>
>> You can directly contribute to improving the documentation comments by
>> suggesting changes with Colladoc:
>>
>> http://scala-webapps.epfl.ch/colladoc/
>
> Another instance of completely missing the point. Note that it is fromUTF
> and toUTF (not their nonexistent Scaladoc) that are wrong, and Colladoc
> cannot correct the sort of process errors that produce such silly but
> difficult-to-correct errors.

I was actually referring to gripes with the Scaladoc of
filter/filterNot, although in context that may not have been so clear.

Scala development process has improved in the last 18 months. Many
changes are now put through a code review. Bug fixes are almost always
accompanied with regression tests. Could things be better? Sure. But
IMO a lack of resources, rather than a lack of process, is the
limiting factor.

As the community, we must make the most of these limited resources,
by: submitting clear, minimal, non-duplicated bug reports; searching
mailing list archives before re-asking old questions; answering each
others questions on mailing lists and Stack Overflow; and submitting
well tested patches.

-jason
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Map filter vs. filterNot

Jim Balter

On Jan 30, 2011, at 1:02 AM, Jason Zaugg <[hidden email]> wrote:

> On Sun, Jan 30, 2011 at 2:05 AM, Jim Balter <[hidden email]> wrote:
>>>> "shouldn't" in what sense? That's what the code does and what it is
>>>> intended
>>>> to do, so the documentation says what it should say. OTOH, the method
>>>> *should* have been called "keep" rather than the misleading and
>>>> ambiguous
>>>> "filter", but it wasn't. But that's nothing compared to the fact that
>>>> toUTF
>>>> converts *from* UTF and fromUTF converts *to* UTF, and when I mention
>>>> that
>>>> here I get no response other than silly nonsense about method signatures
>>>> determining semantics.
>>>
>>> You can directly contribute to improving the documentation comments by
>>> suggesting changes with Colladoc:
>>>
>>> http://scala-webapps.epfl.ch/colladoc/
>>
>> Another instance of completely missing the point. Note that it is fromUTF
>> and toUTF (not their nonexistent Scaladoc) that are wrong, and Colladoc
>> cannot correct the sort of process errors that produce such silly but
>> difficult-to-correct errors.
>
> I was actually referring to gripes with the Scaladoc of
> filter/filterNot, although in context that may not have been so clear.
>

Indeed not; that would have been an appropriate response to Raoul's post, not mine.

> Scala development process has improved in the last 18 months. Many
> changes are now put through a code review. Bug fixes are almost always
> accompanied with regression tests.

That's good to know. But I would note that getting documentation right or even present still seems to be considered unimportant, something to be left to the community via Colladoc rather than a primary responsibility of the dev. If it were my project, I wouldn't allow any element of the API to be released without Scaladoc, and that has been suitably reviewed.

-- Jim

> Could things be better? Sure. But
> IMO a lack of resources, rather than a lack of process, is the
> limiting factor.
>
> As the community, we must make the most of these limited resources,
> by: submitting clear, minimal, non-duplicated bug reports; searching
> mailing list archives before re-asking old questions; answering each
> others questions on mailing lists and Stack Overflow; and submitting
> well tested patches.
>
> -jason
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Map filter vs. filterNot

Ismael Juma
On Sun, Jan 30, 2011 at 6:40 PM, Jim Balter <[hidden email]> wrote:
> If it were my project, I wouldn't allow any element of the API to be released without Scaladoc, and that has been suitably reviewed.

Such things are easy to say when the burden doesn't fall on you. The
Scala team is under-resourced and overstretched. Even so, a system of
reviews was introduced last year and if you want to help, there are
plenty of reviews assigned to the community, see:

http://article.gmane.org/gmane.comp.lang.scala.internals/2709/match=community+reviewing

Best,
Ismael
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Map filter vs. filterNot

HamsterofDeath
didn't know about that. i might review something from time to time

Am 30.01.2011 19:56, schrieb Ismael Juma:

> On Sun, Jan 30, 2011 at 6:40 PM, Jim Balter <[hidden email]> wrote:
>> If it were my project, I wouldn't allow any element of the API to be released without Scaladoc, and that has been suitably reviewed.
> Such things are easy to say when the burden doesn't fall on you. The
> Scala team is under-resourced and overstretched. Even so, a system of
> reviews was introduced last year and if you want to help, there are
> plenty of reviews assigned to the community, see:
>
> http://article.gmane.org/gmane.comp.lang.scala.internals/2709/match=community+reviewing
>
> Best,
> Ismael
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Map filter vs. filterNot

Jim Balter
In reply to this post by Ismael Juma
On Sun, Jan 30, 2011 at 10:56 AM, Ismael Juma <[hidden email]> wrote:
On Sun, Jan 30, 2011 at 6:40 PM, Jim Balter <[hidden email]> wrote:
> If it were my project, I wouldn't allow any element of the API to be released without Scaladoc, and that has been suitably reviewed.

Such things are easy to say when the burden doesn't fall on you.

Sigh. Such things are easy to say because they are sensible policy that is common in many organizations, and they are what I *do* when the burden falls on me.

-- Jim

Loading...