This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Fwd: A few questions...

2 replies
Kevin Wright 2
Joined: 2010-05-30,
User offline. Last seen 26 weeks 4 days ago.
Forwarding... The list somehow got dropped as a recipient.


tabPane.pages.remove(i) sure looks like a modification to me!

On 14 October 2011 12:29, Aishwarya Singhal <asinghal79 [at] gmail [dot] com> wrote:
Hi Kevin

Thanks! I am actually not modifying anything inside the find block, it
only gets me the element that matches my condition and then I do a
"match" on it. Is that still a bad practice? I also like Dennis's
latest suggestion on using foreach over match in this case.

Best regards
Aishwarya

On Oct 14, 3:58 pm, Kevin Wright <kev [dot] lee [dot] wri [dot] [dot] [dot] [at] gmail [dot] com> wrote:
> Performing side effects inside a find block is a bad idea.  Established
> Scala programmers won't expect it, so you're breaking the principle of least
> surprise.
>
> A preferable solution is to first pull out the target index, then remove the
> tab page in an explicit step.
>
> On 14 October 2011 11:50, Aishwarya Singhal <asingha [dot] [dot] [dot] [at] gmail [dot] com> wrote:
>
>
>
>
>
>
>
> > Thanks Kevin, I am just a fairly long time java developer so its
> > taking time to get over the hangover :-)
>
> > The following is what I thought of the code with "find"
>
> > (0 until tabPane.peer.getTabCount).find { i =>
> > (tabPane.peer.getToolTipTextAt(i) == name)} match {
> >          case Some(i) => tabPane.pages.remove(i)
> >          case None =>
> >      }
>
> > I actually wanted to know of a way to avoid iterating over the entire
> > collection if I find a match in between, so "find" seems to be fine...
>
> > Any idea of runtime annotations or byte code compatibility?
>
> > Best regards
> > Aishwarya
>
> > On Oct 14, 3:35 pm, Kevin Wright <kev [dot] lee [dot] wri [dot] [dot] [dot] [at] gmail [dot] com> wrote:
> > > On 14 October 2011 10:53, Aishwarya Singhal <asingha [dot] [dot] [dot] [at] gmail [dot] com>
> > wrote:
>
> > > > Hi All
>
> > > > I see that runtime annotations can not be written in Scala (or atleast
> > > > I haven't found a way yet). In the Java world, I used annotations
> > > > heavily esp for data binding with external streams and hence I find
> > > > this apparent limitation troublesome. My question is - is this an
> > > > actual problem or my ignorance, and if its an actual problem, is it
> > > > being worked upon?
>
> > > > Also, incompatibility of byte code between major releases seems to be
> > > > a major problem. I am doing an open source project and have to publish
> > > > binaries for both 2.8.1 as well as 2.9.1 as either doesn't work with
> > > > the other version.
>
> > > > Also, are there any plans of the building into the compiler an ability
> > > > to warn against unused imports or poor programming practices?
>
> > > > Lastly, I know the first page of the manual warned me of this, but the
> > > > lack of "break" in loops gets troublesome as well at times. I do
> > > > "return" instead of break, but I would have preferred and found the
> > > > code more readable with "break". A simple (rather crude) example is as
> > > > follows:
>
> > > > for (i <- 0 to (tabPane.peer.getTabCount - 1)) {
> > > >        if (tabPane.peer.getToolTipTextAt(i) == name) {
> > > >          tabPane.pages.remove(i)
> > > >          return
> > > >        }
> > > > }
>
> > > > What do you think about "break"?
>
> > > Stop thinking in loops!
> > > Sadly, JTabPage doesn't expose tabs as a collection, but it's easy enough
> > to
> > > fake:
>
> > >     val namedTabs = (0 until tabPane.peer.getTabCount) map {
> > >       i => i -> tabPane.peer.getToolTipTextAt(i)
> > >     }
> > >     val idx = tabs collectFirst { case (i, txt) if txt == name => i }
> > >     tabPane.pages remove idx
>
> > > > Thanks and Best regards
> > > > Aishwarya






Aishwarya Singhal
Joined: 2011-09-09,
User offline. Last seen 42 years 45 weeks ago.
Re: Fwd: A few questions...

Thanks Kevin, my mistake on the group getting dropped.

> tabPane.pages.remove(i) sure looks like a modification to me!

it is but not in find block. i could have broken that into 2
statements one capturing the output of find and the next using the
output with match/ foreach, but i am somehow missing the point how
different that would be to not be the same "bad" practice...

Thanks very much for your feedback!
Best regards
Aishwarya

On Oct 14, 5:41 pm, Kevin Wright wrote:
> Forwarding... The list somehow got dropped as a recipient.
>
> tabPane.pages.remove(i) sure looks like a modification to me!
>
> On 14 October 2011 12:29, Aishwarya Singhal wrote:
>
>
>
>
>
>
>
> > Hi Kevin
>
> > Thanks! I am actually not modifying anything inside the find block, it
> > only gets me the element that matches my condition and then I do a
> > "match" on it. Is that still a bad practice? I also like Dennis's
> > latest suggestion on using foreach over match in this case.
>
> > Best regards
> > Aishwarya
>
> > On Oct 14, 3:58 pm, Kevin Wright wrote:
> > > Performing side effects inside a find block is a bad idea.  Established
> > > Scala programmers won't expect it, so you're breaking the principle of
> > least
> > > surprise.
>
> > > A preferable solution is to first pull out the target index, then remove
> > the
> > > tab page in an explicit step.
>
> > > On 14 October 2011 11:50, Aishwarya Singhal
> > wrote:
>
> > > > Thanks Kevin, I am just a fairly long time java developer so its
> > > > taking time to get over the hangover :-)
>
> > > > The following is what I thought of the code with "find"
>
> > > > (0 until tabPane.peer.getTabCount).find { i =>
> > > > (tabPane.peer.getToolTipTextAt(i) == name)} match {
> > > >          case Some(i) => tabPane.pages.remove(i)
> > > >          case None =>
> > > >      }
>
> > > > I actually wanted to know of a way to avoid iterating over the entire
> > > > collection if I find a match in between, so "find" seems to be fine...
>
> > > > Any idea of runtime annotations or byte code compatibility?
>
> > > > Best regards
> > > > Aishwarya
>
> > > > On Oct 14, 3:35 pm, Kevin Wright wrote:
> > > > > On 14 October 2011 10:53, Aishwarya Singhal
> > > > wrote:
>
> > > > > > Hi All
>
> > > > > > I see that runtime annotations can not be written in Scala (or
> > atleast
> > > > > > I haven't found a way yet). In the Java world, I used annotations
> > > > > > heavily esp for data binding with external streams and hence I find
> > > > > > this apparent limitation troublesome. My question is - is this an
> > > > > > actual problem or my ignorance, and if its an actual problem, is it
> > > > > > being worked upon?
>
> > > > > > Also, incompatibility of byte code between major releases seems to
> > be
> > > > > > a major problem. I am doing an open source project and have to
> > publish
> > > > > > binaries for both 2.8.1 as well as 2.9.1 as either doesn't work
> > with
> > > > > > the other version.
>
> > > > > > Also, are there any plans of the building into the compiler an
> > ability
> > > > > > to warn against unused imports or poor programming practices?
>
> > > > > > Lastly, I know the first page of the manual warned me of this, but
> > the
> > > > > > lack of "break" in loops gets troublesome as well at times. I do
> > > > > > "return" instead of break, but I would have preferred and found the
> > > > > > code more readable with "break". A simple (rather crude) example is
> > as
> > > > > > follows:
>
> > > > > > for (i <- 0 to (tabPane.peer.getTabCount - 1)) {
> > > > > >        if (tabPane.peer.getToolTipTextAt(i) == name) {
> > > > > >          tabPane.pages.remove(i)
> > > > > >          return
> > > > > >        }
> > > > > > }
>
> > > > > > What do you think about "break"?
>
> > > > > Stop thinking in loops!
> > > > > Sadly, JTabPage doesn't expose tabs as a collection, but it's easy
> > enough
> > > > to
> > > > > fake:
>
> > > > >     val namedTabs = (0 until tabPane.peer.getTabCount) map {
> > > > >       i => i -> tabPane.peer.getToolTipTextAt(i)
> > > > >     }
> > > > >     val idx = tabs collectFirst { case (i, txt) if txt == name => i }
> > > > >     tabPane.pages remove idx
>
> > > > > > Thanks and Best regards
> > > > > > Aishwarya

H-star Development
Joined: 2010-04-14,
User offline. Last seen 2 years 26 weeks ago.
Re: Fwd: A few questions...

he got me at first, too
take a closer look. the find doesn't make the modification, the match on the returned option does

-------- Original-Nachricht --------
> Datum: Fri, 14 Oct 2011 13:41:45 +0100
> Von: Kevin Wright
> An: scala-debate
> Betreff: [scala-debate] Fwd: A few questions...

> Forwarding... The list somehow got dropped as a recipient.
>
>
>
> tabPane.pages.remove(i) sure looks like a modification to me!
>
>
> On 14 October 2011 12:29, Aishwarya Singhal wrote:
>
> > Hi Kevin
> >
> > Thanks! I am actually not modifying anything inside the find block, it
> > only gets me the element that matches my condition and then I do a
> > "match" on it. Is that still a bad practice? I also like Dennis's
> > latest suggestion on using foreach over match in this case.
> >
> > Best regards
> > Aishwarya
> >
> > On Oct 14, 3:58 pm, Kevin Wright wrote:
> > > Performing side effects inside a find block is a bad idea.
> Established
> > > Scala programmers won't expect it, so you're breaking the principle of
> > least
> > > surprise.
> > >
> > > A preferable solution is to first pull out the target index, then
> remove
> > the
> > > tab page in an explicit step.
> > >
> > > On 14 October 2011 11:50, Aishwarya Singhal
> > wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > > Thanks Kevin, I am just a fairly long time java developer so its
> > > > taking time to get over the hangover :-)
> > >
> > > > The following is what I thought of the code with "find"
> > >
> > > > (0 until tabPane.peer.getTabCount).find { i =>
> > > > (tabPane.peer.getToolTipTextAt(i) == name)} match {
> > > > case Some(i) => tabPane.pages.remove(i)
> > > > case None =>
> > > > }
> > >
> > > > I actually wanted to know of a way to avoid iterating over the
> entire
> > > > collection if I find a match in between, so "find" seems to be
> fine...
> > >
> > > > Any idea of runtime annotations or byte code compatibility?
> > >
> > > > Best regards
> > > > Aishwarya
> > >
> > > > On Oct 14, 3:35 pm, Kevin Wright wrote:
> > > > > On 14 October 2011 10:53, Aishwarya Singhal
> > > > wrote:
> > >
> > > > > > Hi All
> > >
> > > > > > I see that runtime annotations can not be written in Scala (or
> > atleast
> > > > > > I haven't found a way yet). In the Java world, I used
> annotations
> > > > > > heavily esp for data binding with external streams and hence I
> find
> > > > > > this apparent limitation troublesome. My question is - is this
> an
> > > > > > actual problem or my ignorance, and if its an actual problem, is
> it
> > > > > > being worked upon?
> > >
> > > > > > Also, incompatibility of byte code between major releases seems
> to
> > be
> > > > > > a major problem. I am doing an open source project and have to
> > publish
> > > > > > binaries for both 2.8.1 as well as 2.9.1 as either doesn't work
> > with
> > > > > > the other version.
> > >
> > > > > > Also, are there any plans of the building into the compiler an
> > ability
> > > > > > to warn against unused imports or poor programming practices?
> > >
> > > > > > Lastly, I know the first page of the manual warned me of this,
> but
> > the
> > > > > > lack of "break" in loops gets troublesome as well at times. I do
> > > > > > "return" instead of break, but I would have preferred and found
> the
> > > > > > code more readable with "break". A simple (rather crude) example
> is
> > as
> > > > > > follows:
> > >
> > > > > > for (i <- 0 to (tabPane.peer.getTabCount - 1)) {
> > > > > > if (tabPane.peer.getToolTipTextAt(i) == name) {
> > > > > > tabPane.pages.remove(i)
> > > > > > return
> > > > > > }
> > > > > > }
> > >
> > > > > > What do you think about "break"?
> > >
> > > > > Stop thinking in loops!
> > > > > Sadly, JTabPage doesn't expose tabs as a collection, but it's easy
> > enough
> > > > to
> > > > > fake:
> > >
> > > > > val namedTabs = (0 until tabPane.peer.getTabCount) map {
> > > > > i => i -> tabPane.peer.getToolTipTextAt(i)
> > > > > }
> > > > > val idx = tabs collectFirst { case (i, txt) if txt == name =>
> i }
> > > > > tabPane.pages remove idx
> > >
> > > > > > Thanks and Best regards
> > > > > > Aishwarya
> >

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland