As my first foray into Dynamic Scala land, I thought that I'd try
accessing bean properties via applyDynamic.

My first very rough cut is

trait BeanProperties extends Dynamic {
 def applyDynamic(name: String)(args: Any*) = {
   if (args.length == 0)
     PropertyUtils.getProperty(this, name)
   else
     null
 }
}

so that

val bean = new JTextField("text") with BeanProperties
bean.getText should equal("text")
bean.text should equal("text")

so far so good! But when I try

bean.background should equal(bean.getBackground)

the compiler complains, trying instead to give access to the field
named background rather than synthesizing a method.

variable background in class Component cannot be accessed in
javax.swing.JTextField with BeanPropertiesTest.this.BeanProperties

Is this by design, an oversight, or something that is planned to be
fixed.

Thanks

Duncan McGregor

And I get same behavior under both 2.9.0 and 2.9.0-1. It's on github
as an sbt project if it helps: https://github.com/alanpog/Circularity
.
Tks,
Alan

On May 31, 6:30 pm, AlanP <alan... <at> gmail.com> wrote:
> I'm getting a behavior with implicits that does not seem consistent to
> me. It is easier if I show it with code.
>
> The following code in Exhibit 1(below) gets no compiler error, but
> does trigger a NullPointerException at runtime. It can be fixed making
> 'val a' lazy, in object I. So it seems like an order of initialization
> issue, except that it is between different objects that refer to each
> other.
>
> Then the code in Exhibit 2 is the same as Exhibit 1, except that
> object A is being held directly in 'val a', instead of being inside a
> List. In this case I get no runtime error, even without making 'a'
> lazy, it runs as intended.
>
> It seems to me that: 1) I should get the same behavior with Lists or
> direct objects or, 2) I should be able to get a compile-time error on
> Exhibit 1.
>
> If this is the expected behavior, can someone explain me what's the
> reasoning involved?
>
> Thanks,
>
> Alan
>
> ------ Exhibit 1 -------
> trait C {val a: List[D]}
>
> class D(implicit val c: C)
>
> object ImplicitHolder {
>         implicit object I extends C {
>                 val a = List(A)  // can fix runtime error by making it lazy
>         }
>
> }
>
> import ImplicitHolder._
>
> object A extends D {
>         val b = c.a.head
>         val s = "hello"
>
> }
>
> object Circularity extends App {
>         println(I.a.head.s)}
>
> --------------------------------
>
> ------ Exhibit 2 -----------
> trait C {val a: D}
>
> class D(implicit val c: C)
>
> object ImplicitHolder {
>         implicit object I extends C {
>                 val a = A
>         }
>
> }
>
> import ImplicitHolder._
>
> object A extends D {
>         val b = c.a
>         val s = "hello"
>
> }
>
> object Circularity extends App {
>         println(I.a.s)}
>
> --------------------------

Right, Traversable is covariant, pow is contravariant, but what is Set? Is it, hmm, a functor? Seems like it is not.
Thanks,
-Vlad

On Tue, May 31, 2011 at 12:12 AM, Luc Duponcheel <luc.duponcheel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Hi,

is the original question (replacing inheritance with implicits)
not somehow circumventing this variance issue in the first place?

scala> implicit def toPow[X](set: Set[X]): Function[X, Boolean] = new Function[X, Boolean] {
     |  def apply(x: X) = set.contains(x)
     | }
toPow: [X](set: Set[X])(X) => Boolean

scala> implicit def toTrav[X](set: Set[X]): Traversable[X] = new Traversable[X] {
     |  def foreach[U](f: X => U): Unit = set.foreach(f)
     | }
toTrav: [X](set: Set[X])Traversable[X]


maybe I'm plain wrong here

I mean: variance issues will eventually pop up anyway
(and, if yes, then, maybe, it makes sense that type inference would be less strict when implicits are involved than when inheritance is involved (?))

... just a wild thought ...

Luc

On Mon, May 30, 2011 at 9:40 AM, Vlad Patryshev <vpatryshev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

While it is easy to turn an obviously invariant Set[A] to contravariant [A->Boolean], it might make sense to have something covariant... something like Iterable[+A].

What's interesting is how we can casually disambiguate (between) these two functors. And whether it is feasible to disambiguate in current programming practice. What we call "sets" in Scala are not sets in any scientific sense anyway, are they? What Set[A] means is a "powertype", right?

Thanks,
-Vlad

On Sat, May 28, 2011 at 3:29 PM, Meredith Gregory <lgreg.meredith-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Dear Scalarazzi,

i was surprised by the following.

Best wishes,

--greg

Welcome to Scala version 2.8.1.final (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_24).

Type in expressions to have them evaluated.

Type :help for more information.

scala> trait GCG[+A] { def left : List[Either[A,GCG[A]]]; def right : List[Either[A,GCG[A]]] }

defined trait GCG

scala> trait GCG2[+A] { def left : Set[Either[A,GCG[A]]]; def right : Set[Either[A,GCG[A]]] }

<console>:6: error: covariant type A occurs in invariant position in type => Set[Either[A,GCG[A]]] of method left

       trait GCG2[+A] { def left : Set[Either[A,GCG[A]]]; def right : Set[Either[A,GCG[A]]] }

                            ^

<console>:6: error: covariant type A occurs in invariant position in type => Set[Either[A,GCG[A]]] of method right

       trait GCG2[+A] { def left : Set[Either[A,GCG[A]]]; def right : Set[Either[A,GCG[A]]] }

                                                              ^

scala> 

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SW

Seattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com

--
   __~O
  -\ <,
(*)/ (*)

reality goes far beyond imagination