Also, I've heard that Christopher (/cc'd) is also experimenting with
DynamicRef. I think, you guys could discuss and share your ideas.
On Mar 30, 8:05 pm, Chris Hodapp <
clhoda...@gmail.com> wrote:
> Hey, I'm working on building a more solid version. I've managed to check
> out the Scala source from Github and build it, but I could really use a
> good discussion on what capabilities the new reflection API gives or at
> least how I should approach learning it.
>
>
>
> On Wednesday, March 28, 2012 11:38:39 AM UTC-5, Chris Hodapp wrote:
>
> > That sounds great. It is possible that nothing useful would come of it,
> > given the problems with implicits, but I would like to try. As has been
> > pointed out, this should be implemented as a subtrait of the base Dyamic
> > trait (which can have the behavior specified in SIP 17), so there should be
> > plenty of time to get this right if it is possible.
>
> > On Wednesday, March 28, 2012 2:51:51 AM UTC-5, Eugene Burmako wrote:
>
> >> By the way, speaking of the original idea, I think it's great, but
> >> personally I have my hands full with macros.
>
> >> Though if you're interested in turning your prototype into something
> >> solid, I can provide some assistance (starting from how to build Scala
> >> trunk and how to use the new Scala reflection API).
>
> >> On 28 March 2012 09:44, Chris Hodapp <
clhoda...@gmail.com> wrote:
>
> >>> More specifically, you would first need some way to represent a bundle
> >>> of implicits. You would be able to query this bundle for implicits matching
> >>> some signature. Finally, you would need to be able to get one of these
> >>> bundles from the calling scope (i.e. implicits that were in scope when this
> >>> method was called), another from the class of the class of the object, and
> >>> finally one from the class of each parameter and argument type (!). If
> >>> Scala reflection were to support this sort of black magic, maybe something
> >>> could be made to work...
>
> >>> On Wednesday, March 28, 2012 2:30:00 AM UTC-5, Chris Hodapp wrote:
>
> >>>> I can't think of any way to do auto-injecting of implicit conversions
> >>>> without language support and I'm not even sure how *that* would work.
>
> >>>> Implicit parameters just look like regular parameters through Java
> >>>> reflection. Hopefully Scala reflection will fix this. Even if does, we will
> >>>> still have the same problem as we do with conversions.
>
> >>>> Multiple parameter lists look like one long parameter list through Java
> >>>> reflection. Hopefully Scala reflection will fix this too. If it does, it
> >>>> may be possible to handle those properly.
>
> >>>> Maybe there is a solution to the implicits problem that I'm not
> >>>> thinking of...
>
> >>>> On Wednesday, March 28, 2012 1:58:30 AM UTC-5, Eugene Burmako wrote:
>
> >>>>> 1) How would you support auto-injecting implicit conversions where
> >>>>> necessary?
> >>>>> 2) Same question for implicit parameters.
> >>>>> 3) What about multiple parameter lists?
>
> >>>>> On 28 Mar 2012, at 06:59, Chris Hodapp wrote:
>
> >>>>> After reading the SIP 17 proposal, I began to think about whether,
> >>>>> rather than being a marker trait, Dynamic could provide concrete
> >>>>> implementations of applyDynamic, applyDynamicNamed, selectDynamic, and
> >>>>> updateDynamic that used reflection to call through to normally-defined
> >>>>> methods if they exist. I thought that this would make "Dynamic" way more
> >>>>> useful, since methods could accept parameters of type "Dynamic" and use
> >>>>> them properly. After some experimenting, I realized that this does seem to
> >>>>> be possible. See this <
https://gist.github.com/2223633> for the
> >>>>> result of my experimentation. If you paste this into the REPL, you should
> >>>>> be able to define f: Foo and then call f.applyDynamic("bar", 4).as[Int].
>
> >>>>> Note that:
>
> >>>>> - It is extremely rough and doesn't handle a bunch of key cases.
> >>>>> This is just a proof that something like this could work (I was in a hurry
> >>>>> to share).
> >>>>> - I also changed the signature of applyDynamic so that it's return
> >>>>> type is "Dynamic". This allows you to stay in "Dynamic-land" for extended
> >>>>> periods without too much pain. I created a system for boxing non-Dynamic
> >>>>> values.
> >>>>> - It will be necessary to provide implementations of this method
> >>>>> (and of the Dynamic box class) for each parameter list length that we want
> >>>>> to support.
> >>>>> - You do prevent the type checker from detecting some errors this
> >>>>> way, since you can now call any method name with any arguments on a Dynamic
> >>>>> object. The safety that existed before was something of an illusion,
> >>>>> though, since you could easily use a method name not expected by the
> >>>>> applyDynamic author with parameter types they did expect and pass type
> >>>>> checking.
> >>>>> - Crazy thought: rather than having users override this method, it
> >>>>> could act more like Ruby's method_missing and call some user-defined method
> >>>>> only if it can't call a normal method.
>
> >>>>> Thoughts?
>
> >>> On Wednesday, March 28, 2012 2:30:00 AM UTC-5, Chris Hodapp wrote:
>
> >>>> I can't think of any way to do auto-injecting of implicit conversions
> >>>> without language support and I'm not even sure how *that* would work.
>
> >>>> Implicit parameters just look like regular parameters through Java
> >>>> reflection. Hopefully Scala reflection will fix this. Even if does, we will
> >>>> still have the same problem as we do with conversions.
>
> >>>> Multiple parameter lists look like one long parameter list through Java
> >>>> reflection. Hopefully Scala reflection will fix this too. If it does, it
> >>>> may be possible to handle those properly.
>
> >>>> Maybe there is a solution to the implicits problem that I'm not
> >>>> thinking of...
>
> >>>> On Wednesday, March 28, 2012 1:58:30 AM UTC-5, Eugene Burmako wrote:
>
> >>>>> 1) How would you support auto-injecting implicit conversions where
> >>>>> necessary?
> >>>>> 2) Same question for implicit parameters.
> >>>>> 3) What about multiple parameter lists?
>
> >>>>> On 28 Mar 2012, at 06:59, Chris Hodapp wrote:
>
> >>>>> After reading the SIP 17 proposal, I began to think about whether,
> >>>>> rather than being a marker trait, Dynamic could provide concrete
> >>>>> implementations of applyDynamic, applyDynamicNamed, selectDynamic, and
> >>>>> updateDynamic that used reflection to call through to normally-defined
> >>>>> methods if they exist. I thought that this would make "Dynamic" way more
> >>>>> useful, since methods could accept parameters of type "Dynamic" and use
> >>>>> them properly. After some experimenting, I realized that this does seem to
> >>>>> be possible. See this <
https://gist.github.com/2223633> for the
> >>>>> result of my experimentation. If you paste this into the REPL, you should
> >>>>> be able to define f: Foo and then call f.applyDynamic("bar", 4).as[Int].
>
> >>>>> Note that:
>
> >>>>> - It is extremely rough and doesn't handle a bunch of key cases.
> >>>>> This is just a proof that something like this could work (I was in a hurry
> >>>>> to share).
> >>>>> - I also changed the signature of applyDynamic so that it's return
> >>>>> type is "Dynamic". This allows you to stay in "Dynamic-land" for extended
> >>>>> periods without too much pain. I created a system for boxing non-Dynamic
> >>>>> values.
> >>>>> - It will be necessary to provide implementations of this method
> >>>>> (and of the Dynamic box class) for each parameter list length that we want
> >>>>> to support.
> >>>>> - You do prevent the type checker from detecting some errors this
> >>>>> way, since you can now call any method name with any arguments on a Dynamic
> >>>>> object. The safety that existed before was something of an illusion,
> >>>>> though, since you could easily use a method name not expected by the
> >>>>> applyDynamic author with parameter types they did expect and pass type
> >>>>> checking.
> >>>>> - Crazy thought: rather than having users override this method, it