deferring the 'decision' of what an attribute's type is going to be

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

deferring the 'decision' of what an attribute's type is going to be

hutch
Hi,

Warnings:
1) I'm new at Scala
2) I'm not sure I'm using the right words to ask this question.

Is there a way to define a class/abstract class/trait where:
1) multiple attributes are 'named'
2) the type of each attribute is not specified when named
3) some subclass may decide the types of some subset of the attributes
4) if no subclass does decide that some default is used (for the sake  
of argument a 'String')

So in pseudo-scala:

abstract class Base {
type T_a1
type T_a2

var _a1: T_a1 = _
var _a2: T_a2 = _

def a1 = _a1
def a1_=(v: T_a1) = _a1 = v

def a2 = _a2
def a2_=(v: T_a2) = _a2 = v
}

...

I've tried five or six different approaches, with three generic  
outcomes:
1) miserable failure, not even close
2) inability to override a 'type = String'
3) using imports, I can get it to compile, until I try to use it: the  
methods a1/a1_= etc. are not defined for the types used.

Any help would be appreciated, or different ways to think about it,  
even a 'you can't do that' will put me out of my misery :-)

What I really don't want to do is require the poor programmer (me) to  
specify all the types, I really want that default.

Thanks,
Bob

dpp
Reply | Threaded
Open this post in threaded view
|

Re: deferring the 'decision' of what an attribute's type is going to be

dpp
Hmmm... starting with your base example... things worked like a charm for me.  Does the enclosed code help?

On 1/11/08, Bob Hutchison <[hidden email]> wrote:
Hi,

Warnings:
1) I'm new at Scala
2) I'm not sure I'm using the right words to ask this question.

Is there a way to define a class/abstract class/trait where:
1) multiple attributes are 'named'
2) the type of each attribute is not specified when named
3) some subclass may decide the types of some subset of the attributes
4) if no subclass does decide that some default is used (for the sake
of argument a 'String')

So in pseudo-scala:

abstract class Base {
type T_a1
type T_a2

var _a1: T_a1 = _
var _a2: T_a2 = _

def a1 = _a1
def a1_=(v: T_a1) = _a1 = v

def a2 = _a2
def a2_=(v: T_a2) = _a2 = v
}

...

I've tried five or six different approaches, with three generic
outcomes:
1) miserable failure, not even close
2) inability to override a 'type = String'
3) using imports, I can get it to compile, until I try to use it: the
methods a1/a1_= etc. are not defined for the types used.

Any help would be appreciated, or different ways to think about it,
even a 'you can't do that' will put me out of my misery :-)

What I really don't want to do is require the poor programmer (me) to
specify all the types, I really want that default.

Thanks,
Bob



--
lift, the secure, simple, powerful web framework http://liftweb.net
Collaborative Task Management http://much4.us

Typist.scala (734 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: deferring the 'decision' of what an attribute's type is going to be

hutch
Hi David,

Thanks for the response.

On 11-Jan-08, at 7:33 PM, David Pollak wrote:

> Hmmm... starting with your base example... things worked like a  
> charm for
> me.  Does the enclosed code help?


That isn't quite what I had in mind. I've appended an edited version  
that is closer.

The trick is with the specification of T_a1

In my situation Base will be generated code, not hand written. I can  
have as many generated classes/traits/objects as necessary but I  
*really* don't want the user of the generated code to have to specify  
or even have to know all of the possible attributes. This is partly  
due to the numbers involved but also because new attributes can appear  
later that are irrelevant to the code written.

I know how to do this if the user defines the interesting types in  
some kind of configuration file, but now there's two separate things  
that have to be maintained. I know from experience that this is  
confusing and error prone.

Cheers,
Bob

abstract class Base {
  type T_a1
  type T_a2

  var _a1: T_a1 = _
  var _a2: T_a2 = _

  def a1 = _a1
  def a1_=(v: T_a1) = _a1 = v

  def a2 = _a2
  def a2_=(v: T_a2) = _a2 = v

  override def toString = "a1: "+a1+" a2: "+a2
}

class Dude extends Base {
  //type T_a1 = String -- I wanted this to 'default' to String
  type T_a2 = Int
}

val dude = new Dude
dude.a1 = "Hello"
dude.a2 = 783

println("Dude is "+dude)

println("Done")
Reply | Threaded
Open this post in threaded view
|

Re: deferring the 'decision' of what an attribute's type is going to be

Stanislas Klimoff-2
Hi Bob,

type T_a1 = String in Base works for me:

arisu:work graven$ scala App
Dude is a1: Hello a2: 783
Done

Am I missing something?

 
Stan

On 1/12/08, Bob Hutchison <[hidden email]> wrote:
Hi David,

Thanks for the response.

On 11-Jan-08, at 7:33 PM, David Pollak wrote:

> Hmmm... starting with your base example... things worked like a
> charm for
> me.  Does the enclosed code help?


That isn't quite what I had in mind. I've appended an edited version
that is closer.

The trick is with the specification of T_a1

In my situation Base will be generated code, not hand written. I can
have as many generated classes/traits/objects as necessary but I
*really* don't want the user of the generated code to have to specify
or even have to know all of the possible attributes. This is partly
due to the numbers involved but also because new attributes can appear
later that are irrelevant to the code written.

I know how to do this if the user defines the interesting types in
some kind of configuration file, but now there's two separate things
that have to be maintained. I know from experience that this is
confusing and error prone.

Cheers,
Bob

abstract class Base {
  type T_a1
  type T_a2

  var _a1: T_a1 = _
  var _a2: T_a2 = _

  def a1 = _a1
  def a1_=(v: T_a1) = _a1 = v

  def a2 = _a2
  def a2_=(v: T_a2) = _a2 = v

  override def toString = "a1: "+a1+" a2: "+a2
}

class Dude extends Base {
  //type T_a1 = String -- I wanted this to 'default' to String
  type T_a2 = Int
}

val dude = new Dude
dude.a1 = "Hello"
dude.a2 = 783

println("Dude is "+dude)

println("Done")



--
Best wishes,
  Stan Klimoff
  Grid Dynamics Consulting
dpp
Reply | Threaded
Open this post in threaded view
|

Re: deferring the 'decision' of what an attribute's type is going to be

dpp
In reply to this post by hutch
Once defined, you cannot change (override) a type.

I think you may also want to look at traits and compose your classes by composing traits.  You can have machine generated (gakk... this gives me the chills, but that aside) base trait and default implementation,  but if a developer needs to change the type, they can use the base:

trait FooBase[T] {
  ...
}

trait StringFoo extends FooBase[String]

class MyClass extends StringFoo with BarBase[Int] {
}

Thanks,

David

On 1/12/08, Bob Hutchison <[hidden email]> wrote:
Hi David,

Thanks for the response.

On 11-Jan-08, at 7:33 PM, David Pollak wrote:

> Hmmm... starting with your base example... things worked like a
> charm for
> me.  Does the enclosed code help?


That isn't quite what I had in mind. I've appended an edited version
that is closer.

The trick is with the specification of T_a1

In my situation Base will be generated code, not hand written. I can
have as many generated classes/traits/objects as necessary but I
*really* don't want the user of the generated code to have to specify
or even have to know all of the possible attributes. This is partly
due to the numbers involved but also because new attributes can appear
later that are irrelevant to the code written.

I know how to do this if the user defines the interesting types in
some kind of configuration file, but now there's two separate things
that have to be maintained. I know from experience that this is
confusing and error prone.

Cheers,
Bob

abstract class Base {
  type T_a1
  type T_a2

  var _a1: T_a1 = _
  var _a2: T_a2 = _

  def a1 = _a1
  def a1_=(v: T_a1) = _a1 = v

  def a2 = _a2
  def a2_=(v: T_a2) = _a2 = v

  override def toString = "a1: "+a1+" a2: "+a2
}

class Dude extends Base {
  //type T_a1 = String -- I wanted this to 'default' to String
  type T_a2 = Int
}

val dude = new Dude
dude.a1 = "Hello"
dude.a2 = 783

println("Dude is "+dude)

println("Done")



--
lift, the secure, simple, powerful web framework http://liftweb.net
Collaborative Task Management http://much4.us
Reply | Threaded
Open this post in threaded view
|

Re: deferring the 'decision' of what an attribute's type is going to be

hutch
In reply to this post by Stanislas Klimoff-2
Hi Stan,

On 12-Jan-08, at 9:41 AM, Stanislas Klimoff wrote:

> Hi Bob,
>
> type T_a1 = String in Base works for me:
> arisu:work graven$ scala App
> Dude is a1: Hello a2: 783
> Done
>
> Am I missing something?

I hope I am :-) I get an error:

  error: error overriding type T_a2 in class Base, which equals String;
  type T_a2 has incompatible type Int
   override type T_a2 = Int

You don't get a problem with T_a2 being set to String in the base  
class then overridden?

Cheers,
Bob

>
>
>
> Stan
>
> On 1/12/08, Bob Hutchison <[hidden email]> wrote:
>>
>> Hi David,
>>
>> Thanks for the response.
>>
>> On 11-Jan-08, at 7:33 PM, David Pollak wrote:
>>
>>> Hmmm... starting with your base example... things worked like a
>>> charm for
>>> me.  Does the enclosed code help?
>>
>>
>> That isn't quite what I had in mind. I've appended an edited version
>> that is closer.
>>
>> The trick is with the specification of T_a1
>>
>> In my situation Base will be generated code, not hand written. I can
>> have as many generated classes/traits/objects as necessary but I
>> *really* don't want the user of the generated code to have to specify
>> or even have to know all of the possible attributes. This is partly
>> due to the numbers involved but also because new attributes can  
>> appear
>> later that are irrelevant to the code written.
>>
>> I know how to do this if the user defines the interesting types in
>> some kind of configuration file, but now there's two separate things
>> that have to be maintained. I know from experience that this is
>> confusing and error prone.
>>
>> Cheers,
>> Bob
>>
>> abstract class Base {
>>  type T_a1
>>  type T_a2
>>
>>  var _a1: T_a1 = _
>>  var _a2: T_a2 = _
>>
>>  def a1 = _a1
>>  def a1_=(v: T_a1) = _a1 = v
>>
>>  def a2 = _a2
>>  def a2_=(v: T_a2) = _a2 = v
>>
>>  override def toString = "a1: "+a1+" a2: "+a2
>> }
>>
>> class Dude extends Base {
>>  //type T_a1 = String -- I wanted this to 'default' to String
>>  type T_a2 = Int
>> }
>>
>> val dude = new Dude
>> dude.a1 = "Hello"
>> dude.a2 = 783
>>
>> println("Dude is "+dude)
>>
>> println("Done")
>>
>
>
>
> --
> Best wishes,
>  Stan Klimoff
>  Grid Dynamics Consulting
Reply | Threaded
Open this post in threaded view
|

Re: deferring the 'decision' of what an attribute's type is going to be

hutch
In reply to this post by dpp
Hi,

On 12-Jan-08, at 9:47 AM, David Pollak wrote:

> Once defined, you cannot change (override) a type.

So it seems. I don't suppose there's any way of deferring that  
decision and then defaulting to something?

>
>
> I think you may also want to look at traits and compose your classes  
> by
> composing traits.  You can have machine generated (gakk... this  
> gives me the
> chills, but that aside)

Bad chills? or good? :-)

> base trait and default implementation,  but if a
> developer needs to change the type, they can use the base:
>
> trait FooBase[T] {
>  ...
> }
>
> trait StringFoo extends FooBase[String]
>
> class MyClass extends StringFoo with BarBase[Int] {
> }
>

That looks a bit awkward.

Cheers,
Bob

> Thanks,
>
> David
>
> On 1/12/08, Bob Hutchison <[hidden email]> wrote:
>>
>> Hi David,
>>
>> Thanks for the response.
>>
>> On 11-Jan-08, at 7:33 PM, David Pollak wrote:
>>
>>> Hmmm... starting with your base example... things worked like a
>>> charm for
>>> me.  Does the enclosed code help?
>>
>>
>> That isn't quite what I had in mind. I've appended an edited version
>> that is closer.
>>
>> The trick is with the specification of T_a1
>>
>> In my situation Base will be generated code, not hand written. I can
>> have as many generated classes/traits/objects as necessary but I
>> *really* don't want the user of the generated code to have to specify
>> or even have to know all of the possible attributes. This is partly
>> due to the numbers involved but also because new attributes can  
>> appear
>> later that are irrelevant to the code written.
>>
>> I know how to do this if the user defines the interesting types in
>> some kind of configuration file, but now there's two separate things
>> that have to be maintained. I know from experience that this is
>> confusing and error prone.
>>
>> Cheers,
>> Bob
>>
>> abstract class Base {
>>  type T_a1
>>  type T_a2
>>
>>  var _a1: T_a1 = _
>>  var _a2: T_a2 = _
>>
>>  def a1 = _a1
>>  def a1_=(v: T_a1) = _a1 = v
>>
>>  def a2 = _a2
>>  def a2_=(v: T_a2) = _a2 = v
>>
>>  override def toString = "a1: "+a1+" a2: "+a2
>> }
>>
>> class Dude extends Base {
>>  //type T_a1 = String -- I wanted this to 'default' to String
>>  type T_a2 = Int
>> }
>>
>> val dude = new Dude
>> dude.a1 = "Hello"
>> dude.a2 = 783
>>
>> println("Dude is "+dude)
>>
>> println("Done")
>>
>
>
>
> --
> lift, the secure, simple, powerful web framework http://liftweb.net
> Collaborative Task Management http://much4.us
Reply | Threaded
Open this post in threaded view
|

Re: deferring the 'decision' of what an attribute's type is going to be

David Pollak


Bob Hutchison wrote:

> Hi,
>
> On 12-Jan-08, at 9:47 AM, David Pollak wrote:
>
>> Once defined, you cannot change (override) a type.
>
> So it seems. I don't suppose there's any way of deferring that
> decision and then defaulting to something?
>
>>
>>
>> I think you may also want to look at traits and compose your classes by
>> composing traits.  You can have machine generated (gakk... this gives
>> me the
>> chills, but that aside)
>
> Bad chills? or good? :-)
Horrible bone chilling kinda chills.

I've written a few OR mappers in my life.  Most of them have relied on
machine generated code.

With Scala, I've been able to compose well typed traits together to form
my classes without the need for machine generation.

I don't know what your use case is, but spending some time with Scala
and working with the kind of idioms that you'll find floating around on
the Scala wiki, I think you'll find more scalable, maintainable ways of
doing things.

Put another way, more than 50% of the reported defects in lift come from
the "new project" generated templates because they are a bunch of text
files that are not type safe/compiler checked.

>
>> base trait and default implementation,  but if a
>> developer needs to change the type, they can use the base:
>>
>> trait FooBase[T] {
>>  ...
>> }
>>
>> trait StringFoo extends FooBase[String]
>>
>> class MyClass extends StringFoo with BarBase[Int] {
>> }
>>
>
> That looks a bit awkward.
You can compose units for your developers to use, but the composed
traits work just like one is supposed to compose classes (and like the
Smalltalk classes are actually composed.)  But it works with traits.

Thanks.

David

>
> Cheers,
> Bob
>
>> Thanks,
>>
>> David
>>
>> On 1/12/08, Bob Hutchison <[hidden email]> wrote:
>>>
>>> Hi David,
>>>
>>> Thanks for the response.
>>>
>>> On 11-Jan-08, at 7:33 PM, David Pollak wrote:
>>>
>>>> Hmmm... starting with your base example... things worked like a
>>>> charm for
>>>> me.  Does the enclosed code help?
>>>
>>>
>>> That isn't quite what I had in mind. I've appended an edited version
>>> that is closer.
>>>
>>> The trick is with the specification of T_a1
>>>
>>> In my situation Base will be generated code, not hand written. I can
>>> have as many generated classes/traits/objects as necessary but I
>>> *really* don't want the user of the generated code to have to specify
>>> or even have to know all of the possible attributes. This is partly
>>> due to the numbers involved but also because new attributes can appear
>>> later that are irrelevant to the code written.
>>>
>>> I know how to do this if the user defines the interesting types in
>>> some kind of configuration file, but now there's two separate things
>>> that have to be maintained. I know from experience that this is
>>> confusing and error prone.
>>>
>>> Cheers,
>>> Bob
>>>
>>> abstract class Base {
>>>  type T_a1
>>>  type T_a2
>>>
>>>  var _a1: T_a1 = _
>>>  var _a2: T_a2 = _
>>>
>>>  def a1 = _a1
>>>  def a1_=(v: T_a1) = _a1 = v
>>>
>>>  def a2 = _a2
>>>  def a2_=(v: T_a2) = _a2 = v
>>>
>>>  override def toString = "a1: "+a1+" a2: "+a2
>>> }
>>>
>>> class Dude extends Base {
>>>  //type T_a1 = String -- I wanted this to 'default' to String
>>>  type T_a2 = Int
>>> }
>>>
>>> val dude = new Dude
>>> dude.a1 = "Hello"
>>> dude.a2 = 783
>>>
>>> println("Dude is "+dude)
>>>
>>> println("Done")
>>>
>>
>>
>>
>> --
>> lift, the secure, simple, powerful web framework http://liftweb.net
>> Collaborative Task Management http://much4.us

Reply | Threaded
Open this post in threaded view
|

Re: deferring the 'decision' of what an attribute's type is going to be

Jamie Webb-2
In reply to this post by hutch
On 2008-01-11 17:27:51 Bob Hutchison wrote:

> Hi,
>
> Warnings:
> 1) I'm new at Scala
> 2) I'm not sure I'm using the right words to ask this question.
>
> Is there a way to define a class/abstract class/trait where:
> 1) multiple attributes are 'named'
> 2) the type of each attribute is not specified when named
> 3) some subclass may decide the types of some subset of the attributes
> 4) if no subclass does decide that some default is used (for the
> sake of argument a 'String')

I'm pretty sure you're not going to be able to make this work. It might
help if you explained why you are trying to do this; it all sounds
rather horrible and you may be better off taking a different tack
entirely.

/J
Reply | Threaded
Open this post in threaded view
|

Re: deferring the 'decision' of what an attribute's type is going to be

hutch
In reply to this post by David Pollak
Hi,

On 12-Jan-08, at 10:03 AM, David Pollak wrote:

>
>
> Bob Hutchison wrote:
>> Hi,
>>
>> On 12-Jan-08, at 9:47 AM, David Pollak wrote:
>>
>>> Once defined, you cannot change (override) a type.
>>
>> So it seems. I don't suppose there's any way of deferring that  
>> decision and then defaulting to something?
>>
>>>
>>>
>>> I think you may also want to look at traits and compose your  
>>> classes by
>>> composing traits.  You can have machine generated (gakk... this  
>>> gives me the
>>> chills, but that aside)
>>
>> Bad chills? or good? :-)
> Horrible bone chilling kinda chills.

That's what I figured :-)

>
>
> I've written a few OR mappers in my life.  Most of them have relied  
> on machine generated code.

I have to agree with you on this one. On the other hand, based on what  
I've been able to do with code generation for other purposes, I think  
one day some really bright and suitably lazy programmer is going to  
solve that problem. But until then...

>
>
> With Scala, I've been able to compose well typed traits together to  
> form my classes without the need for machine generation.
>
> I don't know what your use case is, but spending some time with  
> Scala and working with the kind of idioms that you'll find floating  
> around on the Scala wiki, I think you'll find more scalable,  
> maintainable ways of doing things.

This is why I'm interested in Scala... so I can generate useful code.  
Your project, Lift, is necessary to my happiness too. It fact it is  
really appealing because every webapp I've written since 1994, I  
think, has been statefull.

I'll describe what I'm trying to do in a separate post.

>
>
> Put another way, more than 50% of the reported defects in lift come  
> from the "new project" generated templates because they are a bunch  
> of text files that are not type safe/compiler checked.

I've been using Rails for the last couple of years. I don't use the  
scaffolding and I don't use ActiveRecord. And I *still* like Rails :-)

Cheers,
Bob

>
>>
>>> base trait and default implementation,  but if a
>>> developer needs to change the type, they can use the base:
>>>
>>> trait FooBase[T] {
>>> ...
>>> }
>>>
>>> trait StringFoo extends FooBase[String]
>>>
>>> class MyClass extends StringFoo with BarBase[Int] {
>>> }
>>>
>>
>> That looks a bit awkward.
> You can compose units for your developers to use, but the composed  
> traits work just like one is supposed to compose classes (and like  
> the Smalltalk classes are actually composed.)  But it works with  
> traits.
>
> Thanks.
>
> David
>>
>> Cheers,
>> Bob
>>
>>> Thanks,
>>>
>>> David
>>>
>>> On 1/12/08, Bob Hutchison <[hidden email]> wrote:
>>>>
>>>> Hi David,
>>>>
>>>> Thanks for the response.
>>>>
>>>> On 11-Jan-08, at 7:33 PM, David Pollak wrote:
>>>>
>>>>> Hmmm... starting with your base example... things worked like a
>>>>> charm for
>>>>> me.  Does the enclosed code help?
>>>>
>>>>
>>>> That isn't quite what I had in mind. I've appended an edited  
>>>> version
>>>> that is closer.
>>>>
>>>> The trick is with the specification of T_a1
>>>>
>>>> In my situation Base will be generated code, not hand written. I  
>>>> can
>>>> have as many generated classes/traits/objects as necessary but I
>>>> *really* don't want the user of the generated code to have to  
>>>> specify
>>>> or even have to know all of the possible attributes. This is partly
>>>> due to the numbers involved but also because new attributes can  
>>>> appear
>>>> later that are irrelevant to the code written.
>>>>
>>>> I know how to do this if the user defines the interesting types in
>>>> some kind of configuration file, but now there's two separate  
>>>> things
>>>> that have to be maintained. I know from experience that this is
>>>> confusing and error prone.
>>>>
>>>> Cheers,
>>>> Bob
>>>>
>>>> abstract class Base {
>>>> type T_a1
>>>> type T_a2
>>>>
>>>> var _a1: T_a1 = _
>>>> var _a2: T_a2 = _
>>>>
>>>> def a1 = _a1
>>>> def a1_=(v: T_a1) = _a1 = v
>>>>
>>>> def a2 = _a2
>>>> def a2_=(v: T_a2) = _a2 = v
>>>>
>>>> override def toString = "a1: "+a1+" a2: "+a2
>>>> }
>>>>
>>>> class Dude extends Base {
>>>> //type T_a1 = String -- I wanted this to 'default' to String
>>>> type T_a2 = Int
>>>> }
>>>>
>>>> val dude = new Dude
>>>> dude.a1 = "Hello"
>>>> dude.a2 = 783
>>>>
>>>> println("Dude is "+dude)
>>>>
>>>> println("Done")
>>>>
>>>
>>>
>>>
>>> --
>>> lift, the secure, simple, powerful web framework http://liftweb.net
>>> Collaborative Task Management http://much4.us
>
Reply | Threaded
Open this post in threaded view
|

Re: deferring the 'decision' of what an attribute's type is going to be

Stanislas Klimoff-2
In reply to this post by hutch
Ahh. I dumbly copied the example provided, but didn't override the type. So the problem was to override it, not just to provide the default.

Stan

On 1/12/08, Bob Hutchison <[hidden email]> wrote:
Hi Stan,

On 12-Jan-08, at 9:41 AM, Stanislas Klimoff wrote:

> Hi Bob,
>
> type T_a1 = String in Base works for me:
> arisu:work graven$ scala App
> Dude is a1: Hello a2: 783
> Done
>
> Am I missing something?

I hope I am :-) I get an error:

  error: error overriding type T_a2 in class Base, which equals String;
  type T_a2 has incompatible type Int
   override type T_a2 = Int

You don't get a problem with T_a2 being set to String in the base
class then overridden?

Cheers,
Bob

>
>
>
> Stan
>
> On 1/12/08, Bob Hutchison <[hidden email]> wrote:
>>
>> Hi David,
>>
>> Thanks for the response.
>>
>> On 11-Jan-08, at 7:33 PM, David Pollak wrote:
>>
>>> Hmmm... starting with your base example... things worked like a
>>> charm for
>>> me.  Does the enclosed code help?
>>
>>
>> That isn't quite what I had in mind. I've appended an edited version
>> that is closer.
>>

>> The trick is with the specification of T_a1
>>
>> In my situation Base will be generated code, not hand written. I can
>> have as many generated classes/traits/objects as necessary but I
>> *really* don't want the user of the generated code to have to specify
>> or even have to know all of the possible attributes. This is partly
>> due to the numbers involved but also because new attributes can
>> appear
>> later that are irrelevant to the code written.
>>
>> I know how to do this if the user defines the interesting types in
>> some kind of configuration file, but now there's two separate things
>> that have to be maintained. I know from experience that this is
>> confusing and error prone.
>>
>> Cheers,
>> Bob
>>
>> abstract class Base {
>>  type T_a1
>>  type T_a2
>>
>>  var _a1: T_a1 = _
>>  var _a2: T_a2 = _
>>
>>  def a1 = _a1
>>  def a1_=(v: T_a1) = _a1 = v
>>
>>  def a2 = _a2
>>  def a2_=(v: T_a2) = _a2 = v
>>
>>  override def toString = "a1: "+a1+" a2: "+a2
>> }
>>
>> class Dude extends Base {
>>  //type T_a1 = String -- I wanted this to 'default' to String
>>  type T_a2 = Int
>> }
>>
>> val dude = new Dude
>> dude.a1 = "Hello"
>> dude.a2 = 783
>>
>> println("Dude is "+dude)
>>
>> println("Done")
>>
>
>
>
> --
> Best wishes,
>  Stan Klimoff
>  Grid Dynamics Consulting



--
Best wishes,
  Stan Klimoff
  Grid Dynamics Consulting
Reply | Threaded
Open this post in threaded view
|

Re: deferring the 'decision' of what an attribute's type is going to be

hutch
In reply to this post by Jamie Webb-2
Hi,

On 12-Jan-08, at 10:17 AM, Jamie Webb wrote:

> On 2008-01-11 17:27:51 Bob Hutchison wrote:
>> Hi,
>>
>> Warnings:
>> 1) I'm new at Scala
>> 2) I'm not sure I'm using the right words to ask this question.
>>
>> Is there a way to define a class/abstract class/trait where:
>> 1) multiple attributes are 'named'
>> 2) the type of each attribute is not specified when named
>> 3) some subclass may decide the types of some subset of the  
>> attributes
>> 4) if no subclass does decide that some default is used (for the
>> sake of argument a 'String')
>
> I'm pretty sure you're not going to be able to make this work. It  
> might
> help if you explained why you are trying to do this; it all sounds
> rather horrible and you may be better off taking a different tack
> entirely.
>
> /J

I had pretty much convinced myself that this approach wasn't going to  
work before posting, but thought that maybe there was some part of  
Scala's type system that I didn't know about or use properly. It is  
also very possible that there's a better way of thinking about the  
problem -- I'm 'spinning' on this and that's usually a sure sign that  
I should step back a bit and take another look.

Now, for the rest of this post, please suspend your disbelief :-)

I've been working on this thing I call xampl since 1997 when James  
Clark published his SAX parser.

I've written versions of xampl in Java (5 different implementations),  
Ruby, and CLOS (Common Lisp).

It is very difficult to explain to someone what xampl does, I can show  
a programmer in about 10 minutes. About 60 programmers have used it  
seriously over the years, none of them can explain it, all of them can  
show another programmer in about 10 minutes.

So instead of trying to explain why I'll say part of the what... this  
is where I need you to keep an open mind :-)

Briefly then... Let's say I had a collection of XML documents that I  
wanted to map to Scala. This sounds like a XML binding thing, and  
maybe you can think of it that way, but it has a very specific  
interpretation of the XML and isn't meant to be a general purpose XML  
binding tool. Xampl interprets that collection of XML documents and  
maps elements and attributes to objects and from there to classes, and  
maps element containment to composition of objects. This is a greatly  
simplified explanation.

The generated code has all kinds of functionality, but for the  
purposes of this discussion, it can read an XML document and build a  
hierarchy of Scala objects.

And here is the issue. When xampl reads the XML document and looks at  
an element's attributes all it sees are strings. There is no issue if  
the attributes of the Scala object are, in fact, all Strings.  
Sometimes it would be convenient to have the types more directly  
useful to the programmer (e.g. numeric types, and especially dates).  
But xampl has no idea what those more appropriate types might be. So  
what I was hoping to do was have xampl generate Scala classes that  
left that decision open yet not require the decision to be made  
explicitly for all attributes because in that case String is what is  
needed (as I described in those four points quoted above).

The programmer using xampl *never* touches anything xampl generates --  
this rule will not be broken or stretched. I've found that  
configuration files are error prone (though Scala's type system might  
help *a lot* here, but I don't know yet -- Java's type system was just  
a pain (but I don't know if that was anything special added by  
xampl :-)) and I really don't like having to use two files to define  
something that is conceptually a single thing.

So I have a few options at least:
1) make this idea work (not looking good, it seems that you can't  
override a type once it is established)
2) configuration files
3) let the programmer convert (i.e. don't do anything beyond a nice  
collection of implicit conversions)
4) try to get some kind of reference type to work (but that looks to  
be as bad as #1, same issue so far)

Any additional ideas are more than welcome.

BTW, I am not complaining about Scala here. I'm trying to understand  
how to maximally exploit what it offers.

I hope that makes some sense.

Cheers,
Bob
dpp
Reply | Threaded
Open this post in threaded view
|

Re: deferring the 'decision' of what an attribute's type is going to be

dpp
I've got a solution for you... given me a little time to code it up.

On 1/12/08, Bob Hutchison <[hidden email]> wrote:
Hi,

On 12-Jan-08, at 10:17 AM, Jamie Webb wrote:

> On 2008-01-11 17:27:51 Bob Hutchison wrote:
>> Hi,
>>
>> Warnings:
>> 1) I'm new at Scala
>> 2) I'm not sure I'm using the right words to ask this question.
>>
>> Is there a way to define a class/abstract class/trait where:
>> 1) multiple attributes are 'named'
>> 2) the type of each attribute is not specified when named
>> 3) some subclass may decide the types of some subset of the
>> attributes
>> 4) if no subclass does decide that some default is used (for the
>> sake of argument a 'String')
>
> I'm pretty sure you're not going to be able to make this work. It
> might
> help if you explained why you are trying to do this; it all sounds
> rather horrible and you may be better off taking a different tack
> entirely.
>
> /J

I had pretty much convinced myself that this approach wasn't going to
work before posting, but thought that maybe there was some part of
Scala's type system that I didn't know about or use properly. It is
also very possible that there's a better way of thinking about the
problem -- I'm 'spinning' on this and that's usually a sure sign that
I should step back a bit and take another look.

Now, for the rest of this post, please suspend your disbelief :-)

I've been working on this thing I call xampl since 1997 when James
Clark published his SAX parser.

I've written versions of xampl in Java (5 different implementations),
Ruby, and CLOS (Common Lisp).

It is very difficult to explain to someone what xampl does, I can show
a programmer in about 10 minutes. About 60 programmers have used it
seriously over the years, none of them can explain it, all of them can
show another programmer in about 10 minutes.

So instead of trying to explain why I'll say part of the what... this
is where I need you to keep an open mind :-)

Briefly then... Let's say I had a collection of XML documents that I
wanted to map to Scala. This sounds like a XML binding thing, and
maybe you can think of it that way, but it has a very specific
interpretation of the XML and isn't meant to be a general purpose XML
binding tool. Xampl interprets that collection of XML documents and
maps elements and attributes to objects and from there to classes, and
maps element containment to composition of objects. This is a greatly
simplified explanation.

The generated code has all kinds of functionality, but for the
purposes of this discussion, it can read an XML document and build a
hierarchy of Scala objects.

And here is the issue. When xampl reads the XML document and looks at
an element's attributes all it sees are strings. There is no issue if
the attributes of the Scala object are, in fact, all Strings.
Sometimes it would be convenient to have the types more directly
useful to the programmer (e.g. numeric types, and especially dates).
But xampl has no idea what those more appropriate types might be. So
what I was hoping to do was have xampl generate Scala classes that
left that decision open yet not require the decision to be made
explicitly for all attributes because in that case String is what is
needed (as I described in those four points quoted above).

The programmer using xampl *never* touches anything xampl generates --
this rule will not be broken or stretched. I've found that
configuration files are error prone (though Scala's type system might
help *a lot* here, but I don't know yet -- Java's type system was just
a pain (but I don't know if that was anything special added by
xampl :-)) and I really don't like having to use two files to define
something that is conceptually a single thing.

So I have a few options at least:
1) make this idea work (not looking good, it seems that you can't
override a type once it is established)
2) configuration files
3) let the programmer convert (i.e. don't do anything beyond a nice
collection of implicit conversions)
4) try to get some kind of reference type to work (but that looks to
be as bad as #1, same issue so far)

Any additional ideas are more than welcome.

BTW, I am not complaining about Scala here. I'm trying to understand
how to maximally exploit what it offers.

I hope that makes some sense.

Cheers,
Bob



--
lift, the secure, simple, powerful web framework http://liftweb.net
Collaborative Task Management http://much4.us
Reply | Threaded
Open this post in threaded view
|

Re: deferring the 'decision' of what an attribute's type is going to be

hutch

On 12-Jan-08, at 12:09 PM, David Pollak wrote:

> I've got a solution for you... given me a little time to code it up.

Looking forward to it. Thanks!

Cheers,
Bob
dpp
Reply | Threaded
Open this post in threaded view
|

Re: deferring the 'decision' of what an attribute's type is going to be

dpp
I was wrong...  there is no way around the issue.  At its heart, the issues is:

class Foo {
  def bar: String = "Hello"
}

class SubFoo extends Foo {
  def bar: Int = 43
}

This just isn't legal because:

val f: Foo = new SubFoo // this is legal
val s: String = f.bar // we're expecting a String here, but if we get an Int, we're hosed

So... that's the crux of the problem... sorry.

Thanks,

David


On 1/12/08, Bob Hutchison <[hidden email]> wrote:

On 12-Jan-08, at 12:09 PM, David Pollak wrote:

> I've got a solution for you... given me a little time to code it up.

Looking forward to it. Thanks!

Cheers,
Bob



--
lift, the secure, simple, powerful web framework http://liftweb.net
Collaborative Task Management http://much4.us
Reply | Threaded
Open this post in threaded view
|

Re: deferring the 'decision' of what an attribute's type is going to be

hutch
Hi David,

Thanks for trying. I appreciate it.

Cheers,
Bob

On 12-Jan-08, at 4:42 PM, David Pollak wrote:

> I was wrong...  there is no way around the issue.  At its heart, the  
> issues
> is:
>
> class Foo {
> def bar: String = "Hello"
> }
>
> class SubFoo extends Foo {
> def bar: Int = 43
> }
>
> This just isn't legal because:
>
> val f: Foo = new SubFoo // this is legal
> val s: String = f.bar // we're expecting a String here, but if we  
> get an
> Int, we're hosed
>
> So... that's the crux of the problem... sorry.
>
> Thanks,
>
> David
>
>
> On 1/12/08, Bob Hutchison <[hidden email]> wrote:
>>
>>
>> On 12-Jan-08, at 12:09 PM, David Pollak wrote:
>>
>>> I've got a solution for you... given me a little time to code it up.
>>
>> Looking forward to it. Thanks!
>>
>> Cheers,
>> Bob
>>
>
>
>
> --
> lift, the secure, simple, powerful web framework http://liftweb.net
> Collaborative Task Management http://much4.us