restraining visibility scope to a (set of) methods

On 14/02/2012 14:15, Alex Repain wrote:

XWpy_8a9dJupByEvasyhdJiHdJFEVgrAA [at] mail [dot] gmail [dot] com" type="cite">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 = ...
  ....
}

-- 
Francois ARMAND
http://fanf42.blogspot.com
http://www.normation.com

2012/2/14 Francois <fanf42@gmail.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

Something like this?

class A[T, U] {
val inner : T => U = {
var bar = ...
(t:T) => ...
}
def foo(t:T) = bar(t:T)
}

On 14 February 2012 14:33, Alex Repain wrote:
>
>
> 2012/2/14 Francois
>>
>> 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
>
>

2012/2/14 Alex Repain <alex.repain@gmail.com>

2012/2/14 Francois <fanf42@gmail.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.

@FunctionalLobbyists : Don't mistake me, I don't encourage people to think a code can be "neat" while using vars ! The example is just more inspiring with a var.

-- 
Francois ARMAND
http://fanf42.blogspot.com
http://www.normation.com

2012/2/14 Alec Zorab <aleczorab@googlemail.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.repain@gmail.com> wrote:
>
>
> 2012/2/14 Francois <fanf42@gmail.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
>
>

Could an inner "singleton" work for this purpose?

class A {
object foo{
private var bar = ...
def apply(...) = ...
}
}

On Tue, Feb 14, 2012 at 9:42 AM, Alex Repain wrote:
>
>
> 2012/2/14 Alec Zorab
>>
>> 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 wrote:
>> >
>> >
>> > 2012/2/14 Francois
>> >>
>> >> 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
>> >
>> >
>
>

This is what I get for typing code straight into gmail! I meant

def foo(t: T) = inner(t)

I don't see how
def baz(t: T) = inner(t)
is a problem - all this has done is alias the function you were
already offering. I can do this from outside the class anyway, so I
don't see how you;d ever be able to stop it?

On 14 February 2012 14:42, Alex Repain wrote:
>
>
> 2012/2/14 Alec Zorab
>>
>> 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 wrote:
>> >
>> >
>> > 2012/2/14 Francois
>> >>
>> >> 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
>> >
>> >
>
>

2012/2/14 Haoyi Li <haoyi.sg@gmail.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.repain@gmail.com> wrote:
>
>
> 2012/2/14 Alec Zorab <aleczorab@googlemail.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.repain@gmail.com> wrote:
>> >
>> >
>> > 2012/2/14 Francois <fanf42@gmail.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
>> >
>> >
>
>

On Tue, Feb 14, 2012 at 10:13 AM, Alex Repain <alex.repain@gmail.com> wrote:

2012/2/14 Haoyi Li <haoyi.sg@gmail.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.

You could do "private object" and expose what's needed through delegate methods on A. 

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 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. 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
>> wrote:
>> >
>> >
>> > 2012/2/14 Alec Zorab
>> >>
>> >> 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 wrote:
>> >> >
>> >> >
>> >> > 2012/2/14 Francois
>> >> >>
>> >> >> 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.
>

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.

2012/2/14 Haoyi Li <haoyi.sg@gmail.com>

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

it does "look" like a method (not really like a function, which is not the same concept). I was rather thinking of Scala docs, method auto-find in IDEs, and such things ...
 

On Tue, Feb 14, 2012 at 10:13 AM, Alex Repain <alex.repain@gmail.com> wrote:
>
>
> 2012/2/14 Haoyi Li <haoyi.sg@gmail.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.repain@gmail.com>
>> wrote:
>> >
>> >
>> > 2012/2/14 Alec Zorab <aleczorab@googlemail.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.repain@gmail.com> wrote:
>> >> >
>> >> >
>> >> > 2012/2/14 Francois <fanf42@gmail.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
>> >> >
>> >> >
>> >
>> >
>
>

How about having other constructors? So that you would not necessarily have to pass an Iterable of pairs.


Thanks,
-Vlad


On Tue, Feb 14, 2012 at 7:35 AM, Bardenhorst, Volker Dr. <Volker.Bardenhorst@eon.com> wrote:

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.

Hm, you're saying a different constructor (I don't mind to change to another one) will simplify things? But what is the next step to establish CanBuildFrom?   Thanks, Volker.
From: Vlad Patryshev [mailto:vpatryshev@gmail.com]
Sent: 15 February 2012 06:31
To: Bardenhorst, Volker Dr.
Cc: scala-user
Subject: Re: [scala-user] creating collection under composition

How about having other constructors? So that you would not necessarily have to pass an Iterable of pairs.


Thanks,
-Vlad


On Tue, Feb 14, 2012 at 7:35 AM, Bardenhorst, Volker Dr. <Volker.Bardenhorst@eon.com> wrote:

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.

Oh, sorry! I did not pay enough attention.
See, my idea was to have a constructor that would take a map.
But there's a bigger problem - variance. A map is supposed to be at least contravariant in the first argument; in your case it's invariant. Is it the way you want it to be? 
I mean, if it's a map, it's a map; you can build it from a sequence of pairs, but you cannot seriously go back and extract a sequence of pairs to do something with them. I mean, it looks pretty unnatural.
Say, your function f, it consists of two functions, f0 and f1, componentwise. So, f0 takes a pair (key, value) and produces another key. Does it make sense? Will it, say, produce a map?
I understand, it can be all represented as something like "take a map, build its graph in T &times; X, then apply some kind of transformation f, get, err, a graph? How come?
But you may have something in mind; can you elaborate?
Thanks,
-Vlad


On Wed, Feb 15, 2012 at 12:05 AM, Bardenhorst, Volker Dr. <Volker.Bardenhorst@eon.com> wrote:

Hm, you're saying a different constructor (I don't mind to change to another one) will simplify things? But what is the next step to establish CanBuildFrom?   Thanks, Volker.
From: Vlad Patryshev [mailto:vpatryshev@gmail.com]
Sent: 15 February 2012 06:31
To: Bardenhorst, Volker Dr.
Cc: scala-user
Subject: Re: [scala-user] creating collection under composition

How about having other constructors? So that you would not necessarily have to pass an Iterable of pairs.


Thanks,
-Vlad


On Tue, Feb 14, 2012 at 7:35 AM, Bardenhorst, Volker Dr. <Volker.Bardenhorst@eon.com> wrote:

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.

Thanks for reply, Vlad   that Series can be like TreeMap (including variance annotations), but via composition because inheritance from all the interfaces works well but I get more that I want, e.g.   take(n: Int):     a lot of bugs overhere (in the hopefully soon forgetten pure java world), because some coder want to take everything including 20th of May, 2014 (T = Date),     so in his special context he did some counting and ideally he got it right, but someone is picking up in another context and fails   so my lib only should offer takeWhile (personally I think Scala should drop any methods specifing elements via Ints, ok, ok, should think about sliding)   as I said: other methods I would like to modify, new methods to add   maybe we should forget my special use case,   I think it is: "How can I get the CanBuildFrom pattern to work when MyCollection contains a standard lib collection via composition?"   Thanks a lot, Volker.    From: scala-user@googlegroups.com [mailto:scala-user@googlegroups.com] On Behalf Of Vlad Patryshev
Sent: 16 February 2012 08:06
To: Bardenhorst, Volker Dr.
Cc: scala-user
Subject: Re: [scala-user] creating collection under composition

Oh, sorry! I did not pay enough attention.
See, my idea was to have a constructor that would take a map.
But there's a bigger problem - variance. A map is supposed to be at least contravariant in the first argument; in your case it's invariant. Is it the way you want it to be? 
I mean, if it's a map, it's a map; you can build it from a sequence of pairs, but you cannot seriously go back and extract a sequence of pairs to do something with them. I mean, it looks pretty unnatural.
Say, your function f, it consists of two functions, f0 and f1, componentwise. So, f0 takes a pair (key, value) and produces another key. Does it make sense? Will it, say, produce a map?
I understand, it can be all represented as something like "take a map, build its graph in T &times; X, then apply some kind of transformation f, get, err, a graph? How come?
But you may have something in mind; can you elaborate?
Thanks,
-Vlad


On Wed, Feb 15, 2012 at 12:05 AM, Bardenhorst, Volker Dr. <Volker.Bardenhorst@eon.com> wrote:

Hm, you're saying a different constructor (I don't mind to change to another one) will simplify things? But what is the next step to establish CanBuildFrom?   Thanks, Volker.
From: Vlad Patryshev [mailto:vpatryshev@gmail.com]
Sent: 15 February 2012 06:31
To: Bardenhorst, Volker Dr.
Cc: scala-user
Subject: Re: [scala-user] creating collection under composition

How about having other constructors? So that you would not necessarily have to pass an Iterable of pairs.


Thanks,
-Vlad


On Tue, Feb 14, 2012 at 7:35 AM, Bardenhorst, Volker Dr. <Volker.Bardenhorst@eon.com> wrote:

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.

Oh, I believe this line of thinking is too far from my way of thinking. I was asking more or less architectural questions, I believe...
Thanks,
-Vlad


On Thu, Feb 16, 2012 at 1:17 AM, Bardenhorst, Volker Dr. <Volker.Bardenhorst@eon.com> wrote:

Thanks for reply, Vlad   that Series can be like TreeMap (including variance annotations), but via composition because inheritance from all the interfaces works well but I get more that I want, e.g.   take(n: Int):     a lot of bugs overhere (in the hopefully soon forgetten pure java world), because some coder want to take everything including 20th of May, 2014 (T = Date),     so in his special context he did some counting and ideally he got it right, but someone is picking up in another context and fails   so my lib only should offer takeWhile (personally I think Scala should drop any methods specifing elements via Ints, ok, ok, should think about sliding)   as I said: other methods I would like to modify, new methods to add   maybe we should forget my special use case,   I think it is: "How can I get the CanBuildFrom pattern to work when MyCollection contains a standard lib collection via composition?"   Thanks a lot, Volker.    From: scala-user@googlegroups.com [mailto:scala-user@googlegroups.com] On Behalf Of Vlad Patryshev
Sent: 16 February 2012 08:06
To: Bardenhorst, Volker Dr.
Cc: scala-user
Subject: Re: [scala-user] creating collection under composition

Oh, sorry! I did not pay enough attention.
See, my idea was to have a constructor that would take a map.
But there's a bigger problem - variance. A map is supposed to be at least contravariant in the first argument; in your case it's invariant. Is it the way you want it to be? 
I mean, if it's a map, it's a map; you can build it from a sequence of pairs, but you cannot seriously go back and extract a sequence of pairs to do something with them. I mean, it looks pretty unnatural.
Say, your function f, it consists of two functions, f0 and f1, componentwise. So, f0 takes a pair (key, value) and produces another key. Does it make sense? Will it, say, produce a map?
I understand, it can be all represented as something like "take a map, build its graph in T &times; X, then apply some kind of transformation f, get, err, a graph? How come?
But you may have something in mind; can you elaborate?
Thanks,
-Vlad


On Wed, Feb 15, 2012 at 12:05 AM, Bardenhorst, Volker Dr. <Volker.Bardenhorst@eon.com> wrote:

Hm, you're saying a different constructor (I don't mind to change to another one) will simplify things? But what is the next step to establish CanBuildFrom?   Thanks, Volker.
From: Vlad Patryshev [mailto:vpatryshev@gmail.com]
Sent: 15 February 2012 06:31
To: Bardenhorst, Volker Dr.
Cc: scala-user
Subject: Re: [scala-user] creating collection under composition

How about having other constructors? So that you would not necessarily have to pass an Iterable of pairs.


Thanks,
-Vlad


On Tue, Feb 14, 2012 at 7:35 AM, Bardenhorst, Volker Dr. <Volker.Bardenhorst@eon.com> wrote:

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.