restraining visibility scope to a (set of) methods

Hi all,   I created a collection via composition of collection.immutable.TreeMap:   class Series[T: Ordering, X](txs: Iterable[(T, X)]) {     private val tm: TreeMap[T, X] = TreeMap(txs.toSeq: _*)     def map[S: Ordering, Y](f: ((T, X)) => (S, Y)): Series[S, Y] = Series(tm map f)   ... }   Reason behind is that I won't offer all TreeMap methods to the lib user, other methods I would like to modify or new methods to add. That works fine so far.   Drawback was that I was not able to get series.map(f) working in the sense that resulting collections are determined by the function f someone passed. So reduced functionality to functions in line with my Series (so can't leave that container).   I found a lot of examples how to achieve this with CanBuildFrom pattern in case of collection extending a bunch of interfaces but I wasn't able to figure out how to get it running under composition.   Hopefully the question is not to vague!   Maybe someone could push me into the right direction.   Thanks, Volker.

Doesn't an object with a public apply() and nothing else public look
just like a function to the client? Or is that false?

-Haoyi

On Tue, Feb 14, 2012 at 10:13 AM, Alex Repain <alex [dot] repain [at] gmail [dot] com> wrote:
>
>
> 2012/2/14 Haoyi Li <haoyi [dot] sg [at] gmail [dot] com>
>>
>> Could an inner "singleton" work for this purpose?
>>
>> class A {
>>  object foo{
>>    private var bar = ...
>>    def apply(...) = ...
>>  }
>> }
>>
>>
>
>
> Yes, a lot better ! It's not client-friendly since it complicates the class
> interface, but that's the visibility I wanted. Thanks for the tip !
>
> class A {
>   object foo {
>     private var bar = 0
>     def apply(i: Int) = {bar = bar + i; println(bar)}
>   }
>   def baz = bar
> }
>
> error: not found: value bar
>          def baz = bar
>                    ^
>
> class A {
>   object foo {
>     private var bar = 0
>     def apply(i: Int) = {bar = bar + i; println(bar)}
>   }
> }
>
> defined class A
>
> val a = new A
>
> a: A = A@c4720
>
> a.foo
>
> res0: a.foo.type = A$foo$@26e232
>
> a.foo(3)
>
> 3
>
> a.foo(5)
>
> 8
>
>
>
>>
>> On Tue, Feb 14, 2012 at 9:42 AM, Alex Repain <alex [dot] repain [at] gmail [dot] com>
>> wrote:
>> >
>> >
>> > 2012/2/14 Alec Zorab <aleczorab [at] googlemail [dot] com>
>> >>
>> >> Something like this?
>> >>
>> >> class A[T, U] {
>> >>  val inner : T => U = {
>> >>    var bar = ...
>> >>    (t:T) => ...
>> >> }
>> >>  def foo(t:T) = bar(t:T)
>> >> }
>> >>
>> >>
>> >
>> > Probably, you mean def foo(t: T) = inner(t: T) ?
>> >
>> > It encapsulates foo's computation, which is nice, but doesn't really do
>> > what
>> > I want, because then I can do :
>> >
>> > def baz(t: T) = inner(t: T), which proves that there is no specific
>> > contract
>> > for the access to computations on bar (the link exists from foo to bar,
>> > but
>> > not from bar to foo) ...
>> >
>> >>
>> >> On 14 February 2012 14:33, Alex Repain <alex [dot] repain [at] gmail [dot] com> wrote:
>> >> >
>> >> >
>> >> > 2012/2/14 Francois <fanf42 [at] gmail [dot] com>
>> >> >>
>> >> >> On 14/02/2012 14:15, Alex Repain wrote:
>> >> >>
>> >> >> I know this is syntactically inconsistent, but it defines what I
>> >> >> want
>> >> >> to
>> >> >> achieve :
>> >> >>
>> >> >> class A {
>> >> >>   private[this.foo] val bar = ...
>> >> >>   def foo = ...
>> >> >> }
>> >> >>
>> >> >> Any hack for that visibility problem ?
>> >> >>
>> >> >>
>> >> >> Why not simply defining bar in foo ?
>> >> >>
>> >> >> def foo = {
>> >> >>   val bar = ...
>> >> >>   ....
>> >> >> }
>> >> >
>> >> >
>> >> > Unless I'm missing something big, it means instanciating bar at every
>> >> > foo
>> >> > call, and with no persistence of the object over the foo call
>> >> > lifespan.
>> >> > Well, make it a var instead of a val then. The difference is then
>> >> > more
>> >> > obvious.
>> >> >
>> >> > class A {
>> >> >   private[this.foo] var bar = ...
>> >> >   def foo = { bar = bar + 1; println(bar) }
>> >> > }
>> >> >
>> >> > The problem is really about neat code. It doesn't change anything for
>> >> > a
>> >> > user
>> >> > of A, but for anyone who need to sneak into A code, this states
>> >> > clearly
>> >> > that
>> >> > bar will only be used by foo, and nowhere else in the class.
>> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Francois ARMAND
>> >> >> http://fanf42.blogspot.com
>> >> >> http://www.normation.com
>> >> >
>> >> >
>> >
>> >
>
>

That works too I guess. Does anyone know if there any downside for
using object{}s like this though? I use them like an object's internal
"namespaces" sometimes, but I'm not sure if there are any problems I
haven't considered. I know I haven't seen anyone else use object{}
like this in any tutorials I've read.

-Haoyi

On Tue, Feb 14, 2012 at 10:26 AM, Nils Kilden-Pedersen wrote:
> On Tue, Feb 14, 2012 at 10:13 AM, Alex Repain wrote:
>>
>> 2012/2/14 Haoyi Li
>>>
>>> Could an inner "singleton" work for this purpose?
>>>
>>> class A {
>>>  object foo{
>>>    private var bar = ...
>>>    def apply(...) = ...
>>>  }
>>> }
>>>
>>>
>>
>>
>> Yes, a lot better ! It's not client-friendly since it complicates the
>> class interface, but that's the visibility I wanted.
>
>
> You could do "private object" and expose what's needed through delegate
> methods on A.
>