Hello:
Is it possible to instantiate scala objects in a declarative way like
JSON. I think this would be a solution:
val p = new Person{
name = "Peter"
age = 20
friends = Array(
new Person{
name = "Gary"
}
)
}
But I don't like to create a subclass of Person for a single instance.
> Hello: > Is it possible to instantiate scala objects in a declarative way like > JSON. I think this would be a solution: > > val p = new Person{ > name = "Peter" > age = 20 > friends = Array( > new Person{ > name = "Gary" > } > ) > > } >Sure. That you wrote is legal Scala, assuming you declared Person like this: class Person { var name: String = "" var age: Int = 99 var friends: Array[Person] = Array() } But maybe that's not what you wanted? Cheers -- Martin
Yes, but I don't like the fact of create a subclass of Person. I just
want to instantiate a Person. Suppose you have this Widget class:
class Widget{
val name = new Property("")
val width = new Property(0)
val height = new Property(0)
val children = new Property(Array[Widget]())
}
To populate the Widget properties without Object notation, you need to
write the next code
val w = new Widget
p.name() = "MyWidget"
p.height() = 10
p.children() = Array(
label, panel,button
)
the previous code is not Property-Editor friendly, because the
"programmatic" nature. Then, a declarative syntax is the key. But
creating annonimous class is not declarative but programmatic, because
I would to assign a property 2 times:
new Widget{
name="MyWidget"
name="YourWidget"
}
In the other hand, I don't like to subclass Widget, because I just
want to instantiate Widget.
2007/12/22, martin odersky <martin.odersky <at> epfl.ch>:
> > Hello:
> > Is it possible to instantiate scala objects in a declarative way like
> > JSON. I think this would be a solution:
> >
> > val p = new Person{
> > name = "Peter"
> > age = 20
> > friends = Array(
> > new Person{
> > name = "Gary"
> > }
> > )
> >
> > }
> >
> Sure. That you wrote is legal Scala, assuming you declared Person like this:
>
> class Person {
> var name: String = ""
> var age: Int = 99
> var friends: Array[Person] = Array()
> }
>
> But maybe that's not what you wanted?
>
> Cheers
>
> -- Martin
>
On Sat, 2007-12-22 at 19:09 -0300, Andrés Testi wrote:> Yes, but I don't like the fact of create a subclass of Person. I just > want to instantiate a Person.How about this? class Person(_name : String, _age : Int) { def name = _name def age = _age } object Person { def apply(p : { def name : String def age : Int }) = new Person(p.name,p.age) } val p : Person = Person(new { def name = "Peter" def age = 20 }) Regards, John
Hi John,
And how about this?
type Person = {
def name : String
def age : Int
}
val person = new {
def name = "Peter"
def age = 20
} // this is a Person
So many options, but none of them quite as concise as JSON...
Cheers,
Jon
--
--
Jon Pretty | Sygneca Ltd.
On Mon, 2007-12-24 at 11:47 +0000, Jon Pretty wrote:
> Hi John,
>
> And how about this?
>
> type Person = {
> def name : String
> def age : Int
> }
>
> val person = new {
> def name = "Peter"
> def age = 20
> } // this is a Person
This doesn't fit with the requirement of instantiating a Person (type
Person isn't quite the same is it?) without creating a new subclass per
instance dose it?
> So many options, but none of them quite as concise as JSON...
If you skip the type declaration I'd say it's close enough.
Best Regards,
John
John Nilsson wrote: > This doesn't fit with the requirement of instantiating a Person (type > Person isn't quite the same is it?) without creating a new subclass per > instance dose it? Probably not; I don't think the compiler does this optimisation. And I sometimes forget constraints I don't agree with.>> So many options, but none of them quite as concise as JSON... > > If you skip the type declaration I'd say it's close enough. Probably; I was only suggesting it for the people who like conciseness, thou I'm actually happy to type a few more characters for the benefit of clearer code. Another problem with the code I suggested is that it doesn't allow methods to be inherited from a Person class, so I would have to conclude that there's nothing better, or clearer in the context of Scala, than to write: val person = new Person { def name = "Peter" def age = 20 } Merry Christmas, Jon -- -- Jon Pretty | Sygneca Ltd.
Object Notation would be completed with Groovy Bean Constructors style (take a look at http://groovy.codehaus.org/Groovy+Beans ). Groovy bean constructor accept parameters like JSON objects. For example: class Person{ String name; Integer age; } p = new Person(name: "Andres", age: 29) A pretty feature to add to Scala. 2007/12/24, Jon Pretty <jon.pretty <at> sygneca.com>:> John Nilsson wrote: > > This doesn't fit with the requirement of instantiating a Person (type > > Person isn't quite the same is it?) without creating a new subclass per > > instance dose it? > > Probably not; I don't think the compiler does this optimisation. > > And I sometimes forget constraints I don't agree with.
> > class Person{ > String name; > Integer age; > } > > p = new Person(name: "Andres", age: 29) > > A pretty feature to add to Scala.I (still) don't understand. The above feature already works one by one in Scala: class Person { var name: String = _ var age: Int = _ } val p = new Person{ name = "Andres", age = 29 } Cheers -- Martin
These are my reasons to refuse anonymous subclasses:
1) Subclassing breaks the encapsulation contracts allowing side
effects. For example, the Person class have a protected var:
class Person{
var name: String = _
protected var internalCode: Int = _
}
val p = new Person{
name = "Andres" // Good
internalCode = 123432 // DANGER!!!! I'just want to instantiate a
class with the public vars
}
2) Hiding the owner scope:
class Person{
protected def op(a: Int) = a + 1
}
def op(a: Int) = a - 1
val p = new Person{
age = op(17) // WARNING!!!
}
3) Anonymous class != Person class:
(new Person).getClass != (new Person{name="Andres"}).getClass
4) This is just a function invocation
new Person(name: "Andres", age: 29)
this is a code secuence
new Person{name = "Andres"; age = 29 }
The JSON-style constructor don't breaks client contracts, that just
instantiates a Person and initializes public vars. I can survive
without this, but I prefer more defensive and declarative programming.
2007/12/28, martin odersky <martin.odersky <at> epfl.ch>:
> >
> > class Person{
> > String name;
> > Integer age;
> > }
> >
> > p = new Person(name: "Andres", age: 29)
> >
> > A pretty feature to add to Scala.
>
> I (still) don't understand. The above feature already works one by one in Scala:
>
> class Person {
> var name: String = _
> var age: Int = _
> }
> val p = new Person{ name = "Andres", age = 29 }
>
> Cheers
>
> -- Martin
>
Hi Andrés,
I understand that Scala's syntax isn't always as concise as JSON's (in
exchange for allowing you to do a whole lot more in general), though I
don't really understand your problems with anonymous subclassing.
Having said that, I think Martin's suggestion is a bit of a compromise
for the sake of conciseness, and I would prefer to write:
class Person {
def name : String
def age : Int
def foo = 42
}
val p = new Person {
def name = "Andres"
def age = 29
override def foo = 100
}
as this then guarantees that there's no risk of forgetting to initialize
any variables.
Andrés Testi wrote:
> 1) Subclassing breaks the encapsulation contracts allowing side
> effects. For example, the Person class have a protected var:
>
> class Person{
> var name: String = _
> protected var internalCode: Int = _
> }
>
> val p = new Person{
> name = "Andres" // Good
> internalCode = 123432 // DANGER!!!! I'just want to instantiate a
> class with the public vars
> }
I don't understand. Why is this dangerous? If 'internalCode' is
protected, then you have every right to do this, and no reason to
suspect that this shouldn't happen. Should 'internalCode' be private
instead?
I don't understand what you're saying about side-effects.
> 2) Hiding the owner scope:
>
> class Person{
> protected def op(a: Int) = a + 1
> }
>
> def op(a: Int) = a - 1
>
> val p = new Person{
> age = op(17) // WARNING!!!
> }
Shadowing is a fact of life, and it's certainly not unique to this
situation. In practice, you have to learn to give methods sensible and
unique names. If you practice this, you have to be quite unlucky to
have two different methods with the same name, the same signature, doing
different things occurring in a place where it's not obvious which one
is being referenced.
> 3) Anonymous class != Person class:
> (new Person).getClass != (new Person{name="Andres"}).getClass
This sort of code is a problem in general. If you expect to use
inheritance, you shouldn't be testing classes for equality. Use
(new Person { name = "Andres" }).isInstanceOf[Person]
instead.
> 4) This is just a function invocation
> new Person(name: "Andres", age: 29)
>
> this is a code secuence
> new Person{name = "Andres"; age = 29 }
Is this a problem, or just an observation?
Cheers,
Jon
--
--
Jon Pretty | Sygneca Ltd.
The number one reason that Scala should not become part of Apache is that "concensus" decisions are exactly the 100% wrong way to design a language except in the rare case where the committee consists of language design experts with a common vision. Normally, designing a language by committee gets you...well, a bunch of languages that I won't mention because doing so would hurt some fan's feelings. So let's just say COBOL and move on. Now, perhaps some of the tools, maybe even the compiler, would benefit from living under the Apache umbrella, but that's different from the language itself being there. ---- David Pollak <feeder.of.the.bears <at> gmail.com> wrote:> On Dec 23, 2007 3:44 AM, David Bernard <david.bernard.31 <at> gmail.com> wrote: > > > I thinks that with some change in Property you could support a builder > > approach that support > > val w = new Widget() > > .name("MyWidget") > > .height(10) > > .children(label, panel, button) > > > Which is what you get with lift components. > > But I believe the larger issue is one of mutability and internal type > representation. > > JavaScript has JSON because it is pretty much built on hash tables and the > built in types (numbers, Strings, dates, booleans, arrays and hashs/objects) > are so limited in number that it makes sense to have special syntax for each > of them. > > Scala, too, has some special notation for building object hierarchies: case > classes. One can build complex object hierarchies using case classes. In > my opinion, they are as easy to read as JSON objects. They are a little > more verbose to type, but that's because they're typed (ah hah... a pun.) > > One can also do: > Map('foo -> Array(1,2,3), 'bar -> Array("dog", "cat"), 'baz -> > Date("12-23-07")) > > It's a little more verbose than JSON, but the objects are serializable as > JSON (okay, I made up the Date thing, but it's not hard to implement.) > > If you want the kind of unstructured hash tables you get with JavaScript, > use Maps/Arrays (or Lists). If you want more structured stuff, where are > case classes lacking? > > Thanks, > > David > > > > > > > > my 2 cents. > > > > /davidB > > > > Andrés Testi wrote: > > > Yes, but I don't like the fact of create a subclass of Person. I just > > > want to instantiate a Person. Suppose you have this Widget class: > > > > > > class Widget{ > > > val name = new Property("") > > > val width = new Property(0) > > > val height = new Property(0) > > > val children = new Property(Array[Widget]()) > > > } > > > > > > To populate the Widget properties without Object notation, you need to > > > write the next code > > > > > > val w = new Widget > > > p.name() = "MyWidget" > > > p.height() = 10 > > > p.children() = Array( > > > label, panel,button > > > ) > > > > > > the previous code is not Property-Editor friendly, because the > > > "programmatic" nature. Then, a declarative syntax is the key. But > > > creating annonimous class is not declarative but programmatic, because > > > I would to assign a property 2 times: > > > > > > new Widget{ > > > name="MyWidget" > > > name="YourWidget" > > > } > > > > > > In the other hand, I don't like to subclass Widget, because I just > > > want to instantiate Widget. > > > > > > 2007/12/22, martin odersky <martin.odersky <at> epfl.ch>: > > >>> Hello: > > >>> Is it possible to instantiate scala objects in a declarative way like > > >>> JSON. I think this would be a solution: > > >>> > > >>> val p = new Person{ > > >>> name = "Peter" > > >>> age = 20 > > >>> friends = Array( > > >>> new Person{ > > >>> name = "Gary" > > >>> } > > >>> ) > > >>> > > >>> } > > >>> > > >> Sure. That you wrote is legal Scala, assuming you declared Person like > > this: > > >> > > >> class Person { > > >> var name: String = "" > > >> var age: Int = 99 > > >> var friends: Array[Person] = Array() > > >> } > > >> > > >> But maybe that's not what you wanted? > > >> > > >> Cheers > > >> > > >> -- Martin > > >> > > > > > > > -- > lift, the secure, simple, powerful web framework http://liftweb.net > Collaborative Task Management http://much4.us
I think I agree. A language requires a clear vision and consistent
aesthetic, exactly the two things that collective decision making is
bad at, remember the old joke about how a camel is a horse designed by
committee?
I think probably the best model is the "benevolent dictator" approach,
which I think is roughly what Scala has now so far as I can tell.
Ian.
On Dec 24, 2007 4:37 AM, James Iry <jiry <at> san.rr.com> wrote:
> The number one reason that Scala should not become part of Apache is that "concensus" decisions are
exactly the 100% wrong way to design a language except in the rare case where the committee consists of
language design experts with a common vision. Normally, designing a language by committee gets
you...well, a bunch of languages that I won't mention because doing so would hurt some fan's feelings. So
let's just say COBOL and move on.
>
> Now, perhaps some of the tools, maybe even the compiler, would benefit from living under the Apache
umbrella, but that's different from the language itself being there.
>
>
> ---- David Pollak <feeder.of.the.bears <at> gmail.com> wrote:
> > On Dec 23, 2007 3:44 AM, David Bernard <david.bernard.31 <at> gmail.com> wrote:
> >
> > > I thinks that with some change in Property you could support a builder
> > > approach that support
> > > val w = new Widget()
> > > .name("MyWidget")
> > > .height(10)
> > > .children(label, panel, button)
> >
> >
> > Which is what you get with lift components.
> >
> > But I believe the larger issue is one of mutability and internal type
> > representation.
> >
> > JavaScript has JSON because it is pretty much built on hash tables and the
> > built in types (numbers, Strings, dates, booleans, arrays and hashs/objects)
> > are so limited in number that it makes sense to have special syntax for each
> > of them.
> >
> > Scala, too, has some special notation for building object hierarchies: case
> > classes. One can build complex object hierarchies using case classes. In
> > my opinion, they are as easy to read as JSON objects. They are a little
> > more verbose to type, but that's because they're typed (ah hah... a pun.)
> >
> > One can also do:
> > Map('foo -> Array(1,2,3), 'bar -> Array("dog", "cat"), 'baz ->
> > Date("12-23-07"))
> >
> > It's a little more verbose than JSON, but the objects are serializable as
> > JSON (okay, I made up the Date thing, but it's not hard to implement.)
> >
> > If you want the kind of unstructured hash tables you get with JavaScript,
> > use Maps/Arrays (or Lists). If you want more structured stuff, where are
> > case classes lacking?
> >
> > Thanks,
> >
> > David
> >
> >
> > >
> > >
> > > my 2 cents.
> > >
> > > /davidB
> > >
> > > Andrés Testi wrote:
> > > > Yes, but I don't like the fact of create a subclass of Person. I just
>
> > > > want to instantiate a Person. Suppose you have this Widget class:
> > > >
> > > > class Widget{
> > > > val name = new Property("")
> > > > val width = new Property(0)
> > > > val height = new Property(0)
> > > > val children = new Property(Array[Widget]())
> > > > }
> > > >
> > > > To populate the Widget properties without Object notation, you need to
> > > > write the next code
> > > >
> > > > val w = new Widget
> > > > p.name() = "MyWidget"
> > > > p.height() = 10
> > > > p.children() = Array(
> > > > label, panel,button
> > > > )
> > > >
> > > > the previous code is not Property-Editor friendly, because the
> > > > "programmatic" nature. Then, a declarative syntax is the key. But
> > > > creating annonimous class is not declarative but programmatic, because
> > > > I would to assign a property 2 times:
> > > >
> > > > new Widget{
> > > > name="MyWidget"
> > > > name="YourWidget"
> > > > }
> > > >
> > > > In the other hand, I don't like to subclass Widget, because I just
> > > > want to instantiate Widget.
> > > >
> > > > 2007/12/22, martin odersky <martin.odersky <at> epfl.ch>:
> > > >>> Hello:
> > > >>> Is it possible to instantiate scala objects in a declarative way like
> > > >>> JSON. I think this would be a solution:
> > > >>>
> > > >>> val p = new Person{
> > > >>> name = "Peter"
> > > >>> age = 20
> > > >>> friends = Array(
> > > >>> new Person{
> > > >>> name = "Gary"
> > > >>> }
> > > >>> )
> > > >>>
> > > >>> }
> > > >>>
> > > >> Sure. That you wrote is legal Scala, assuming you declared Person like
> > > this:
> > > >>
> > > >> class Person {
> > > >> var name: String = ""
> > > >> var age: Int = 99
> > > >> var friends: Array[Person] = Array()
> > > >> }
> > > >>
> > > >> But maybe that's not what you wanted?
> > > >>
> > > >> Cheers
> > > >>
> > > >> -- Martin
> > > >>
> > >
> > >
> >
> >
> > --
> > lift, the secure, simple, powerful web framework http://liftweb.net
> > Collaborative Task Management http://much4.us
>
--
--
Email: ian.clarke <at> gmail.com
Cell: +1 512 422 3588
AIM: ian.clarke <at> mac.com
Skype: sanity
This went OT - I think the Apache discussion had been on the "The future of Scala" thread.
I also had been tempted to praise Martin, the benevolent dictator - perhaps partly because the Chaplin movie had been on TV during the holidays.
So far I can't see any reason why someon should complain over the leadership of this language. There had been so many new things flowing in over the last months that came from other researchers that any claim of an egoistic grip on Scala would be ridiculous. Martin personally responds to virtually any topic on this list as well, thus I can't see anypossibility for improvement in a braoder ownership. But I could see the danger in dilluted responsability.
Carsten
PS: I didn't made this comment on the original thread as my enthusiasm for the Apache project (httpd and Tomcat excluded) significantly cooled down in the last two, three years
I think I agree. A language requires a clear vision and consistent
aesthetic, exactly the two things that collective decision making is
bad at, remember the old joke about how a camel is a horse designed by
committee?
I think probably the best model is the "benevolent dictator" approach,
which I think is roughly what Scala has now so far as I can tell.
Ian.--
On Dec 24, 2007 4:37 AM, James Iry < jiry <at> san.rr.com> wrote:
> The number one reason that Scala should not become part of Apache is that "concensus" decisions are exactly the 100% wrong way to design a language except in the rare case where the committee consists of language design experts with a common vision. Normally, designing a language by committee gets you...well, a bunch of languages that I won't mention because doing so would hurt some fan's feelings. So let's just say COBOL and move on.
>
> Now, perhaps some of the tools, maybe even the compiler, would benefit from living under the Apache umbrella, but that's different from the language itself being there.
>
>
> ---- David Pollak < feeder.of.the.bears <at> gmail.com> wrote:
> > On Dec 23, 2007 3:44 AM, David Bernard <david.bernard.31 <at> gmail.com > wrote:
> >
> > > I thinks that with some change in Property you could support a builder
> > > approach that support
> > > val w = new Widget()
> > > .name("MyWidget")
> > > .height(10)
> > > .children(label, panel, button)
> >
> >
> > Which is what you get with lift components.
> >
> > But I believe the larger issue is one of mutability and internal type
> > representation.
> >
> > JavaScript has JSON because it is pretty much built on hash tables and the
> > built in types (numbers, Strings, dates, booleans, arrays and hashs/objects)
> > are so limited in number that it makes sense to have special syntax for each
> > of them.
> >
> > Scala, too, has some special notation for building object hierarchies: case
> > classes. One can build complex object hierarchies using case classes. In
> > my opinion, they are as easy to read as JSON objects. They are a little
> > more verbose to type, but that's because they're typed (ah hah... a pun.)
> >
> > One can also do:
> > Map('foo -> Array(1,2,3), 'bar -> Array("dog", "cat"), 'baz ->
> > Date("12-23-07"))
> >
> > It's a little more verbose than JSON, but the objects are serializable as
> > JSON (okay, I made up the Date thing, but it's not hard to implement.)
> >
> > If you want the kind of unstructured hash tables you get with JavaScript,
> > use Maps/Arrays (or Lists). If you want more structured stuff, where are
> > case classes lacking?
> >
> > Thanks,
> >
> > David
> >
> >
> > >
> > >
> > > my 2 cents.
> > >
> > > /davidB
> > >
> > > Andrés Testi wrote:
> > > > Yes, but I don't like the fact of create a subclass of Person. I just
>
> > > > want to instantiate a Person. Suppose you have this Widget class:
> > > >
> > > > class Widget{
> > > > val name = new Property("")
> > > > val width = new Property(0)
> > > > val height = new Property(0)
> > > > val children = new Property(Array[Widget]())
> > > > }
> > > >
> > > > To populate the Widget properties without Object notation, you need to
> > > > write the next code
> > > >
> > > > val w = new Widget
> > > > p.name() = "MyWidget"
> > > > p.height() = 10
> > > > p.children() = Array(
> > > > label, panel,button
> > > > )
> > > >
> > > > the previous code is not Property-Editor friendly, because the
> > > > "programmatic" nature. Then, a declarative syntax is the key. But
> > > > creating annonimous class is not declarative but programmatic, because
> > > > I would to assign a property 2 times:
> > > >
> > > > new Widget{
> > > > name="MyWidget"
> > > > name="YourWidget"
> > > > }
> > > >
> > > > In the other hand, I don't like to subclass Widget, because I just
> > > > want to instantiate Widget.
> > > >
> > > > 2007/12/22, martin odersky <martin.odersky <at> epfl.ch>:
> > > >>> Hello:
> > > >>> Is it possible to instantiate scala objects in a declarative way like
> > > >>> JSON. I think this would be a solution:
> > > >>>
> > > >>> val p = new Person{
> > > >>> name = "Peter"
> > > >>> age = 20
> > > >>> friends = Array(
> > > >>> new Person{
> > > >>> name = "Gary"
> > > >>> }
> > > >>> )
> > > >>>
> > > >>> }
> > > >>>
> > > >> Sure. That you wrote is legal Scala, assuming you declared Person like
> > > this:
> > > >>
> > > >> class Person {
> > > >> var name: String = ""
> > > >> var age: Int = 99
> > > >> var friends: Array[Person] = Array()
> > > >> }
> > > >>
> > > >> But maybe that's not what you wanted?
> > > >>
> > > >> Cheers
> > > >>
> > > >> -- Martin
> > > >>
> > >
> > >
> >
> >
> > --
> > lift, the secure, simple, powerful web framework http://liftweb.net
> > Collaborative Task Management http://much4.us
>
Email: ian.clarke <at> gmail.com
Cell: +1 512 422 3588
AIM: ian.clarke <at> mac.com
Skype: sanity
I thinks that with some change in Property you could support a builder approach that support
val w = new Widget()
.name("MyWidget")
.height(10)
.children(label, panel, button)
my 2 cents.
/davidB
Andrés Testi wrote:
> Yes, but I don't like the fact of create a subclass of Person. I just
> want to instantiate a Person. Suppose you have this Widget class:
>
> class Widget{
> val name = new Property("")
> val width = new Property(0)
> val height = new Property(0)
> val children = new Property(Array[Widget]())
> }
>
> To populate the Widget properties without Object notation, you need to
> write the next code
>
> val w = new Widget
> p.name() = "MyWidget"
> p.height() = 10
> p.children() = Array(
> label, panel,button
> )
>
> the previous code is not Property-Editor friendly, because the
> "programmatic" nature. Then, a declarative syntax is the key. But
> creating annonimous class is not declarative but programmatic, because
> I would to assign a property 2 times:
>
> new Widget{
> name="MyWidget"
> name="YourWidget"
> }
>
> In the other hand, I don't like to subclass Widget, because I just
> want to instantiate Widget.
>
> 2007/12/22, martin odersky <martin.odersky <at> epfl.ch>:
>>> Hello:
>>> Is it possible to instantiate scala objects in a declarative way like
>>> JSON. I think this would be a solution:
>>>
>>> val p = new Person{
>>> name = "Peter"
>>> age = 20
>>> friends = Array(
>>> new Person{
>>> name = "Gary"
>>> }
>>> )
>>>
>>> }
>>>
>> Sure. That you wrote is legal Scala, assuming you declared Person like this:
>>
>> class Person {
>> var name: String = ""
>> var age: Int = 99
>> var friends: Array[Person] = Array()
>> }
>>
>> But maybe that's not what you wanted?
>>
>> Cheers
>>
>> -- Martin
>>
I thinks that with some change in Property you could support a builder approach that support
val w = new Widget()
.name("MyWidget")
.height(10)
.children(label, panel, button)
my 2 cents.
/davidB
Andrés Testi wrote:
> Yes, but I don't like the fact of create a subclass of Person. I just
> want to instantiate a Person. Suppose you have this Widget class:
>
> class Widget{
> val name = new Property("")
> val width = new Property(0)
> val height = new Property(0)
> val children = new Property(Array[Widget]())
> }
>
> To populate the Widget properties without Object notation, you need to
> write the next code
>
> val w = new Widget
> p.name() = "MyWidget"
> p.height() = 10
> p.children() = Array(
> label, panel,button
> )
>
> the previous code is not Property-Editor friendly, because the
> "programmatic" nature. Then, a declarative syntax is the key. But
> creating annonimous class is not declarative but programmatic, because
> I would to assign a property 2 times:
>
> new Widget{
> name="MyWidget"
> name="YourWidget"
> }
>
> In the other hand, I don't like to subclass Widget, because I just
> want to instantiate Widget.
>
> 2007/12/22, martin odersky < martin.odersky <at> epfl.ch>:
>>> Hello:
>>> Is it possible to instantiate scala objects in a declarative way like
>>> JSON. I think this would be a solution:
>>>
>>> val p = new Person{
>>> name = "Peter"
>>> age = 20
>>> friends = Array(
>>> new Person{
>>> name = "Gary"
>>> }
>>> )
>>>
>>> }
>>>
>> Sure. That you wrote is legal Scala, assuming you declared Person like this:
>>
>> class Person {
>> var name: String = ""
>> var age: Int = 99
>> var friends: Array[Person] = Array()
>> }
>>
>> But maybe that's not what you wanted?
>>
>> Cheers
>>
>> -- Martin
>>
Case class was the first thing I thought when reading the beginning of this tread.
May it can be a partial answer to Rickard question.
case class Person(firstname: String, lastname: String, age: Int)
But, in a small village in France, they are many Roland Dumas that have different ages. Typing over and over Person("Roland", "Dumas", xxx) is boring.
So let's create a Roland Dumas maker.
scala> def rolandDumasMaker = Person("Roland", "Dumas", _: Int)
rolandDumasMaker: (Int) => Person
Now creating many Roland Dumases is becoming fun.
scala> rolandDumasMaker(45)
res5: Person = Person(Roland,Dumas,45)
scala> rolandDumasMaker(85)
res6: Person = Person(Roland,Dumas,85)
Sure, in many languages you can make this kind of factory but I find it more meaningful and fun the way you can define it in scala.
On Dec 23, 2007 3:44 AM, David Bernard <david.bernard.31 <at> gmail.com> wrote:I thinks that with some change in Property you could support a builder approach that support
val w = new Widget()
.name("MyWidget")
.height(10)
.children(label, panel, button)
Which is what you get with lift components.
But I believe the larger issue is one of mutability and internal type representation.
JavaScript has JSON because it is pretty much built on hash tables and the built in types (numbers, Strings, dates, booleans, arrays and hashs/objects) are so limited in number that it makes sense to have special syntax for each of them.
Scala, too, has some special notation for building object hierarchies: case classes. One can build complex object hierarchies using case classes. In my opinion, they are as easy to read as JSON objects. They are a little more verbose to type, but that's because they're typed (ah hah... a pun.)
One can also do:
Map('foo -> Array(1,2,3), 'bar -> Array("dog", "cat"), 'baz -> Date("12-23-07"))
It's a little more verbose than JSON, but the objects are serializable as JSON (okay, I made up the Date thing, but it's not hard to implement.)
If you want the kind of unstructured hash tables you get with JavaScript, use Maps/Arrays (or Lists). If you want more structured stuff, where are case classes lacking?
Thanks,
David
my 2 cents.
/davidB
Andrés Testi wrote:
> Yes, but I don't like the fact of create a subclass of Person. I just
> want to instantiate a Person. Suppose you have this Widget class:
>
> class Widget{
> val name = new Property("")
> val width = new Property(0)
> val height = new Property(0)
> val children = new Property(Array[Widget]())
> }
>
> To populate the Widget properties without Object notation, you need to
> write the next code
>
> val w = new Widget
> p.name() = "MyWidget"
> p.height() = 10
> p.children() = Array(
> label, panel,button
> )
>
> the previous code is not Property-Editor friendly, because the
> "programmatic" nature. Then, a declarative syntax is the key. But
> creating annonimous class is not declarative but programmatic, because
> I would to assign a property 2 times:
>
> new Widget{
> name="MyWidget"
> name="YourWidget"
> }
>
> In the other hand, I don't like to subclass Widget, because I just
> want to instantiate Widget.
>
> 2007/12/22, martin odersky < martin.odersky <at> epfl.ch>:
>>> Hello:
>>> Is it possible to instantiate scala objects in a declarative way like
>>> JSON. I think this would be a solution:
>>>
>>> val p = new Person{
>>> name = "Peter"
>>> age = 20
>>> friends = Array(
>>> new Person{
>>> name = "Gary"
>>> }
>>> )
>>>
>>> }
>>>
>> Sure. That you wrote is legal Scala, assuming you declared Person like this:
>>
>> class Person {
>> var name: String = ""
>> var age: Int = 99
>> var friends: Array[Person] = Array()
>> }
>>
>> But maybe that's not what you wanted?
>>
>> Cheers
>>
>> -- Martin
>>
--
lift, the secure, simple, powerful web framework http://liftweb.net
Collaborative Task Management http://much4.us
I've been pestering the Scala folks for a way to update just one field in case classes and have a new instance spit out with just that one field changed for a very long time.
It would work like this:
val rolandDumas = Person("Roland", "Dumas", 0) // the factory instance
val first= rolandDumas.age(43) // a new instance with age 43
val second = rolandDumas.age(56) // yet another instance with age 56
You'll be able to get that functionality with some of the changes I'm making to lift, but baking it into the language would be nicer.
Case class was the first thing I thought when reading the beginning of this tread.
May it can be a partial answer to Rickard question.
case class Person(firstname: String, lastname: String, age: Int)
But, in a small village in France, they are many Roland Dumas that have different ages. Typing over and over Person("Roland", "Dumas", xxx) is boring.
So let's create a Roland Dumas maker.
scala> def rolandDumasMaker = Person("Roland", "Dumas", _: Int)
rolandDumasMaker: (Int) => Person
Now creating many Roland Dumases is becoming fun.
scala> rolandDumasMaker(45)
res5: Person = Person(Roland,Dumas,45)
scala> rolandDumasMaker(85)
res6: Person = Person(Roland,Dumas,85)
Sure, in many languages you can make this kind of factory but I find it more meaningful and fun the way you can define it in scala.On Dec 23, 2007 9:42 AM, David Pollak <feeder.of.the.bears <at> gmail.com> wrote:On Dec 23, 2007 3:44 AM, David Bernard <david.bernard.31 <at> gmail.com> wrote:I thinks that with some change in Property you could support a builder approach that support
val w = new Widget()
.name("MyWidget")
.height(10)
.children(label, panel, button)
Which is what you get with lift components.
But I believe the larger issue is one of mutability and internal type representation.
JavaScript has JSON because it is pretty much built on hash tables and the built in types (numbers, Strings, dates, booleans, arrays and hashs/objects) are so limited in number that it makes sense to have special syntax for each of them.
Scala, too, has some special notation for building object hierarchies: case classes. One can build complex object hierarchies using case classes. In my opinion, they are as easy to read as JSON objects. They are a little more verbose to type, but that's because they're typed (ah hah... a pun.)
One can also do:
Map('foo -> Array(1,2,3), 'bar -> Array("dog", "cat"), 'baz -> Date("12-23-07"))
It's a little more verbose than JSON, but the objects are serializable as JSON (okay, I made up the Date thing, but it's not hard to implement.)
If you want the kind of unstructured hash tables you get with JavaScript, use Maps/Arrays (or Lists). If you want more structured stuff, where are case classes lacking?
Thanks,
David
my 2 cents.
/davidB
Andrés Testi wrote:
> Yes, but I don't like the fact of create a subclass of Person. I just
> want to instantiate a Person. Suppose you have this Widget class:
>
> class Widget{
> val name = new Property("")
> val width = new Property(0)
> val height = new Property(0)
> val children = new Property(Array[Widget]())
> }
>
> To populate the Widget properties without Object notation, you need to
> write the next code
>
> val w = new Widget
> p.name() = "MyWidget"
> p.height() = 10
> p.children() = Array(
> label, panel,button
> )
>
> the previous code is not Property-Editor friendly, because the
> "programmatic" nature. Then, a declarative syntax is the key. But
> creating annonimous class is not declarative but programmatic, because
> I would to assign a property 2 times:
>
> new Widget{
> name="MyWidget"
> name="YourWidget"
> }
>
> In the other hand, I don't like to subclass Widget, because I just
> want to instantiate Widget.
>
> 2007/12/22, martin odersky < martin.odersky <at> epfl.ch>:
>>> Hello:
>>> Is it possible to instantiate scala objects in a declarative way like
>>> JSON. I think this would be a solution:
>>>
>>> val p = new Person{
>>> name = "Peter"
>>> age = 20
>>> friends = Array(
>>> new Person{
>>> name = "Gary"
>>> }
>>> )
>>>
>>> }
>>>
>> Sure. That you wrote is legal Scala, assuming you declared Person like this:
>>
>> class Person {
>> var name: String = ""
>> var age: Int = 99
>> var friends: Array[Person] = Array()
>> }
>>
>> But maybe that's not what you wanted?
>>
>> Cheers
>>
>> -- Martin
>>
--
lift, the secure, simple, powerful web framework http://liftweb.net
Collaborative Task Management http://much4.us
We could also have?
rolandDumas.firstname("Bertrand").age(33)
I am curious. Where in the lift code are you making these changes?
I've been pestering the Scala folks for a way to update just one field in case classes and have a new instance spit out with just that one field changed for a very long time.
It would work like this:
val rolandDumas = Person("Roland", "Dumas", 0) // the factory instance
val first= rolandDumas.age(43) // a new instance with age 43
val second = rolandDumas.age(56) // yet another instance with age 56
You'll be able to get that functionality with some of the changes I'm making to lift, but baking it into the language would be nicer.On Dec 23, 2007 9:10 AM, Oscar Picasso <oscarpicasso-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:Case class was the first thing I thought when reading the beginning of this tread.
May it can be a partial answer to Rickard question.
case class Person(firstname: String, lastname: String, age: Int)
But, in a small village in France, they are many Roland Dumas that have different ages. Typing over and over Person("Roland", "Dumas", xxx) is boring.
So let's create a Roland Dumas maker.
scala> def rolandDumasMaker = Person("Roland", "Dumas", _: Int)
rolandDumasMaker: (Int) => Person
Now creating many Roland Dumases is becoming fun.
scala> rolandDumasMaker(45)
res5: Person = Person(Roland,Dumas,45)
scala> rolandDumasMaker(85)
res6: Person = Person(Roland,Dumas,85)
Sure, in many languages you can make this kind of factory but I find it more meaningful and fun the way you can define it in scala.On Dec 23, 2007 9:42 AM, David Pollak <feeder.of.the.bears-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:On Dec 23, 2007 3:44 AM, David Bernard <david.bernard.31-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:I thinks that with some change in Property you could support a builder approach that support
val w = new Widget()
.name("MyWidget")
.height(10)
.children(label, panel, button)
Which is what you get with lift components.
But I believe the larger issue is one of mutability and internal type representation.
JavaScript has JSON because it is pretty much built on hash tables and the built in types (numbers, Strings, dates, booleans, arrays and hashs/objects) are so limited in number that it makes sense to have special syntax for each of them.
Scala, too, has some special notation for building object hierarchies: case classes. One can build complex object hierarchies using case classes. In my opinion, they are as easy to read as JSON objects. They are a little more verbose to type, but that's because they're typed (ah hah... a pun.)
One can also do:
Map('foo -> Array(1,2,3), 'bar -> Array("dog", "cat"), 'baz -> Date("12-23-07"))
It's a little more verbose than JSON, but the objects are serializable as JSON (okay, I made up the Date thing, but it's not hard to implement.)
If you want the kind of unstructured hash tables you get with JavaScript, use Maps/Arrays (or Lists). If you want more structured stuff, where are case classes lacking?
Thanks,
David
my 2 cents.
/davidB
Andrés Testi wrote:
> Yes, but I don't like the fact of create a subclass of Person. I just
> want to instantiate a Person. Suppose you have this Widget class:
>
> class Widget{
> val name = new Property("")
> val width = new Property(0)
> val height = new Property(0)
> val children = new Property(Array[Widget]())
> }
>
> To populate the Widget properties without Object notation, you need to
> write the next code
>
> val w = new Widget
> p.name() = "MyWidget"
> p.height() = 10
> p.children() = Array(
> label, panel,button
> )
>
> the previous code is not Property-Editor friendly, because the
> "programmatic" nature. Then, a declarative syntax is the key. But
> creating annonimous class is not declarative but programmatic, because
> I would to assign a property 2 times:
>
> new Widget{
> name="MyWidget"
> name="YourWidget"
> }
>
> In the other hand, I don't like to subclass Widget, because I just
> want to instantiate Widget.
>
> 2007/12/22, martin odersky < martin.odersky-p8DiymsW2f8@public.gmane.org>:
>>> Hello:
>>> Is it possible to instantiate scala objects in a declarative way like
>>> JSON. I think this would be a solution:
>>>
>>> val p = new Person{
>>> name = "Peter"
>>> age = 20
>>> friends = Array(
>>> new Person{
>>> name = "Gary"
>>> }
>>> )
>>>
>>> }
>>>
>> Sure. That you wrote is legal Scala, assuming you declared Person like this:
>>
>> class Person {
>> var name: String = ""
>> var age: Int = 99
>> var friends: Array[Person] = Array()
>> }
>>
>> But maybe that's not what you wanted?
>>
>> Cheers
>>
>> -- Martin
>>
--
lift, the secure, simple, powerful web framework http://liftweb.net
Collaborative Task Management http://much4.us
--
lift, the secure, simple, powerful web framework http://liftweb.net
Collaborative Task Management http://much4.us
On 12/24/07, Oscar Picasso <oscarpicasso@...> wrote: > We could also have? > rolandDumas.firstname("Bertrand").age(33)I think such methods should have "with" prefix: rolandDumas.withFirstname("Bertrand").withAge(33) -- -- Stepan
We could also have?
rolandDumas.firstname("Bertrand").age(33)
I am curious. Where in the lift code are you making these changes?On Dec 23, 2007 5:05 PM, David Pollak < feeder.of.the.bears-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:I've been pestering the Scala folks for a way to update just one field in case classes and have a new instance spit out with just that one field changed for a very long time.
It would work like this:
val rolandDumas = Person("Roland", "Dumas", 0) // the factory instance
val first= rolandDumas.age(43) // a new instance with age 43
val second = rolandDumas.age(56) // yet another instance with age 56
You'll be able to get that functionality with some of the changes I'm making to lift, but baking it into the language would be nicer.On Dec 23, 2007 9:10 AM, Oscar Picasso <oscarpicasso-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:Case class was the first thing I thought when reading the beginning of this tread.
May it can be a partial answer to Rickard question.
case class Person(firstname: String, lastname: String, age: Int)
But, in a small village in France, they are many Roland Dumas that have different ages. Typing over and over Person("Roland", "Dumas", xxx) is boring.
So let's create a Roland Dumas maker.
scala> def rolandDumasMaker = Person("Roland", "Dumas", _: Int)
rolandDumasMaker: (Int) => Person
Now creating many Roland Dumases is becoming fun.
scala> rolandDumasMaker(45)
res5: Person = Person(Roland,Dumas,45)
scala> rolandDumasMaker(85)
res6: Person = Person(Roland,Dumas,85)
Sure, in many languages you can make this kind of factory but I find it more meaningful and fun the way you can define it in scala.On Dec 23, 2007 9:42 AM, David Pollak <feeder.of.the.bears-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:On Dec 23, 2007 3:44 AM, David Bernard <david.bernard.31-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:I thinks that with some change in Property you could support a builder approach that support
val w = new Widget()
.name("MyWidget")
.height(10)
.children(label, panel, button)
Which is what you get with lift components.
But I believe the larger issue is one of mutability and internal type representation.
JavaScript has JSON because it is pretty much built on hash tables and the built in types (numbers, Strings, dates, booleans, arrays and hashs/objects) are so limited in number that it makes sense to have special syntax for each of them.
Scala, too, has some special notation for building object hierarchies: case classes. One can build complex object hierarchies using case classes. In my opinion, they are as easy to read as JSON objects. They are a little more verbose to type, but that's because they're typed (ah hah... a pun.)
One can also do:
Map('foo -> Array(1,2,3), 'bar -> Array("dog", "cat"), 'baz -> Date("12-23-07"))
It's a little more verbose than JSON, but the objects are serializable as JSON (okay, I made up the Date thing, but it's not hard to implement.)
If you want the kind of unstructured hash tables you get with JavaScript, use Maps/Arrays (or Lists). If you want more structured stuff, where are case classes lacking?
Thanks,
David
my 2 cents.
/davidB
Andrés Testi wrote:
> Yes, but I don't like the fact of create a subclass of Person. I just
> want to instantiate a Person. Suppose you have this Widget class:
>
> class Widget{
> val name = new Property("")
> val width = new Property(0)
> val height = new Property(0)
> val children = new Property(Array[Widget]())
> }
>
> To populate the Widget properties without Object notation, you need to
> write the next code
>
> val w = new Widget
> p.name() = "MyWidget"
> p.height() = 10
> p.children() = Array(
> label, panel,button
> )
>
> the previous code is not Property-Editor friendly, because the
> "programmatic" nature. Then, a declarative syntax is the key. But
> creating annonimous class is not declarative but programmatic, because
> I would to assign a property 2 times:
>
> new Widget{
> name="MyWidget"
> name="YourWidget"
> }
>
> In the other hand, I don't like to subclass Widget, because I just
> want to instantiate Widget.
>
> 2007/12/22, martin odersky < martin.odersky-p8DiymsW2f8@public.gmane.org>:
>>> Hello:
>>> Is it possible to instantiate scala objects in a declarative way like
>>> JSON. I think this would be a solution:
>>>
>>> val p = new Person{
>>> name = "Peter"
>>> age = 20
>>> friends = Array(
>>> new Person{
>>> name = "Gary"
>>> }
>>> )
>>>
>>> }
>>>
>> Sure. That you wrote is legal Scala, assuming you declared Person like this:
>>
>> class Person {
>> var name: String = ""
>> var age: Int = 99
>> var friends: Array[Person] = Array()
>> }
>>
>> But maybe that's not what you wanted?
>>
>> Cheers
>>
>> -- Martin
>>
--
lift, the secure, simple, powerful web framework http://liftweb.net
Collaborative Task Management http://much4.us
--
lift, the secure, simple, powerful web framework http://liftweb.net
Collaborative Task Management http://much4.us
This one is a rebel.
On Dec 23, 2007 11:34 PM, Oscar Picasso <oscarpicasso <at> gmail.com> wrote:We could also have?
rolandDumas.firstname("Bertrand").age(33)
It feels instinctively wrong to have the Roland Dumas named Bertrand. :(
This one is a rebel.
On Dec 23, 2007 5:39 PM, Viktor Klang <viktor.klang <at> gmail.com> wrote:On Dec 23, 2007 11:34 PM, Oscar Picasso <oscarpicasso <at> gmail.com> wrote:We could also have?
rolandDumas.firstname("Bertrand").age(33)
It feels instinctively wrong to have the Roland Dumas named Bertrand. :(
Wow, this is the first time that I witness something like this:
* first, in a Scala example, a factory instance named Roland loses its idenity,
* then, the thread in which th example is mentioned, loses its identity
: )
(helplessly trying to punt on-topic)
+1 for object literals that work with immutable data structures.
+1 for (at least optional, e.g. triggered by annotation) generation of "copying-setter-methods" for immutable fields of case classes.
These features do not seem to be super-essential, but I think therein may lie a way to simplify things... our symbol-literals are also still around, aren't they, and they even have special syntax.
In the meantime, the much-disliked xml literals and constructing Maps are the only way to spell out key-value type data with lookup functionality in your source using a visibly distinct, declarative style.
cheers,
Burak
On Dec 23, 2007 11:34 PM, Oscar Picasso <oscarpicasso <at> gmail.com> wrote:We could also have?
rolandDumas.firstname("Bertrand").age(33)
It feels instinctively wrong to have the Roland Dumas named Bertrand. :(
I am curious. Where in the lift code are you making these changes?On Dec 23, 2007 5:05 PM, David Pollak < feeder.of.the.bears <at> gmail.com> wrote:I've been pestering the Scala folks for a way to update just one field in case classes and have a new instance spit out with just that one field changed for a very long time.
It would work like this:
val rolandDumas = Person("Roland", "Dumas", 0) // the factory instance
val first= rolandDumas.age(43) // a new instance with age 43
val second = rolandDumas.age(56) // yet another instance with age 56
You'll be able to get that functionality with some of the changes I'm making to lift, but baking it into the language would be nicer.On Dec 23, 2007 9:10 AM, Oscar Picasso <oscarpicasso <at> gmail.com> wrote:Case class was the first thing I thought when reading the beginning of this tread.
May it can be a partial answer to Rickard question.
case class Person(firstname: String, lastname: String, age: Int)
But, in a small village in France, they are many Roland Dumas that have different ages. Typing over and over Person("Roland", "Dumas", xxx) is boring.
So let's create a Roland Dumas maker.
scala> def rolandDumasMaker = Person("Roland", "Dumas", _: Int)
rolandDumasMaker: (Int) => Person
Now creating many Roland Dumases is becoming fun.
scala> rolandDumasMaker(45)
res5: Person = Person(Roland,Dumas,45)
scala> rolandDumasMaker(85)
res6: Person = Person(Roland,Dumas,85)
Sure, in many languages you can make this kind of factory but I find it more meaningful and fun the way you can define it in scala.On Dec 23, 2007 9:42 AM, David Pollak <feeder.of.the.bears <at> gmail.com> wrote:On Dec 23, 2007 3:44 AM, David Bernard <david.bernard.31 <at> gmail.com> wrote:I thinks that with some change in Property you could support a builder approach that support
val w = new Widget()
.name("MyWidget")
.height(10)
.children(label, panel, button)
Which is what you get with lift components.
But I believe the larger issue is one of mutability and internal type representation.
JavaScript has JSON because it is pretty much built on hash tables and the built in types (numbers, Strings, dates, booleans, arrays and hashs/objects) are so limited in number that it makes sense to have special syntax for each of them.
Scala, too, has some special notation for building object hierarchies: case classes. One can build complex object hierarchies using case classes. In my opinion, they are as easy to read as JSON objects. They are a little more verbose to type, but that's because they're typed (ah hah... a pun.)
One can also do:
Map('foo -> Array(1,2,3), 'bar -> Array("dog", "cat"), 'baz -> Date("12-23-07"))
It's a little more verbose than JSON, but the objects are serializable as JSON (okay, I made up the Date thing, but it's not hard to implement.)
If you want the kind of unstructured hash tables you get with JavaScript, use Maps/Arrays (or Lists). If you want more structured stuff, where are case classes lacking?
Thanks,
David
my 2 cents.
/davidB
Andrés Testi wrote:
> Yes, but I don't like the fact of create a subclass of Person. I just
> want to instantiate a Person. Suppose you have this Widget class:
>
> class Widget{
> val name = new Property("")
> val width = new Property(0)
> val height = new Property(0)
> val children = new Property(Array[Widget]())
> }
>
> To populate the Widget properties without Object notation, you need to
> write the next code
>
> val w = new Widget
> p.name() = "MyWidget"
> p.height() = 10
> p.children() = Array(
> label, panel,button
> )
>
> the previous code is not Property-Editor friendly, because the
> "programmatic" nature. Then, a declarative syntax is the key. But
> creating annonimous class is not declarative but programmatic, because
> I would to assign a property 2 times:
>
> new Widget{
> name="MyWidget"
> name="YourWidget"
> }
>
> In the other hand, I don't like to subclass Widget, because I just
> want to instantiate Widget.
>
> 2007/12/22, martin odersky < martin.odersky <at> epfl.ch>:
>>> Hello:
>>> Is it possible to instantiate scala objects in a declarative way like
>>> JSON. I think this would be a solution:
>>>
>>> val p = new Person{
>>> name = "Peter"
>>> age = 20
>>> friends = Array(
>>> new Person{
>>> name = "Gary"
>>> }
>>> )
>>>
>>> }
>>>
>> Sure. That you wrote is legal Scala, assuming you declared Person like this:
>>
>> class Person {
>> var name: String = ""
>> var age: Int = 99
>> var friends: Array[Person] = Array()
>> }
>>
>> But maybe that's not what you wanted?
>>
>> Cheers
>>
>> -- Martin
>>
--
lift, the secure, simple, powerful web framework http://liftweb.net
Collaborative Task Management http://much4.us
--
lift, the secure, simple, powerful web framework http://liftweb.net
Collaborative Task Management http://much4.us
--
_____________________________________
/ \
/lift/ committer ( www.liftweb.net)
SGS member (Scala Group Sweden)
SEJUG member (Swedish Java User Group)
Coffee drinker (Skånerost)
\_____________________________________/
Luckily, as the code is written its a copy of Roland, not Roland himself. On 12/23/07, Viktor Klang <viktor.klang@...> wrote:> On Dec 23, 2007 11:34 PM, Oscar Picasso <oscarpicasso@...> wrote: > > > We could also have? > > rolandDumas.firstname("Bertrand").age(33) > > > It feels instinctively wrong to have the Roland Dumas named Bertrand. :( > > > > > > > > > I am curious. Where in the lift code are you making these changes? > > > > > > On Dec 23, 2007 5:05 PM, David Pollak < feeder.of.the.bears@...> > > wrote: > > > > > I've been pestering the Scala folks for a way to update just one field > > > in case classes and have a new instance spit out with just that one > field > > > changed for a very long time. > > > > > > It would work like this: > > > val rolandDumas = Person("Roland", "Dumas", 0) // the factory instance > > > val first= rolandDumas.age(43) // a new instance with age 43 > > > val second = rolandDumas.age(56) // yet another instance with age 56 > > > > > > You'll be able to get that functionality with some of the changes I'm > > > making to lift, but baking it into the language would be nicer. > > > > > > > > > On Dec 23, 2007 9:10 AM, Oscar Picasso <oscarpicasso@...> wrote: > > > > > > > Case class was the first thing I thought when reading the beginning of > > > > this tread. > > > > > > > > May it can be a partial answer to Rickard question. > > > > > > > > **case class Person(firstname: String, lastname: String, age: Int) > > > > > > > > But, in a small village in France, they are many Roland Dumas that > > > > have different ages. Typing over and over Person("Roland", "Dumas", > xxx) is > > > > boring. > > > > > > > > So let's create a Roland Dumas maker. > > > > > > > > scala> def rolandDumasMaker = Person("Roland", "Dumas", _: Int) > > > > rolandDumasMaker: (Int) => Person > > > > > > > > Now creating many Roland Dumases is becoming fun. > > > > scala> rolandDumasMaker(45) > > > > res5: Person = Person(Roland,Dumas,45) > > > > > > > > scala> rolandDumasMaker(85) > > > > res6: Person = Person(Roland,Dumas,85) > > > > > > > > Sure, in many languages you can make this kind of factory but I find > > > > it more meaningful and fun the way you can define it in scala. > > > > > > > > > > > > On Dec 23, 2007 9:42 AM, David Pollak <feeder.of.the.bears@...m> > > > > wrote: > > > > > > > > > > > > > > > > > > > On Dec 23, 2007 3:44 AM, David Bernard <david.bernard.31@...m> > > > > > wrote: > > > > > > > > > > > I thinks that with some change in Property you could support a > > > > > > builder approach that support > > > > > > val w = new Widget() > > > > > > .name("MyWidget") > > > > > > .height(10) > > > > > > .children(label, panel, button) > > > > > > > > > > > > > > > Which is what you get with lift components. > > > > > > > > > > But I believe the larger issue is one of mutability and internal > > > > > type representation. > > > > > > > > > > JavaScript has JSON because it is pretty much built on hash tables > > > > > and the built in types (numbers, Strings, dates, booleans, arrays > and > > > > > hashs/objects) are so limited in number that it makes sense to have > special > > > > > syntax for each of them. > > > > > > > > > > Scala, too, has some special notation for building object > > > > > hierarchies: case classes. One can build complex object hierarchies > using > > > > > case classes. In my opinion, they are as easy to read as JSON > objects. > > > > > They are a little more verbose to type, but that's because they're > typed (ah > > > > > hah... a pun.) > > > > > > > > > > One can also do: > > > > > Map('foo -> Array(1,2,3), 'bar -> Array("dog", "cat"), 'baz -> > > > > > Date("12-23-07")) > > > > > > > > > > It's a little more verbose than JSON, but the objects are > > > > > serializable as JSON (okay, I made up the Date thing, but it's not > hard to > > > > > implement.) > > > > > > > > > > If you want the kind of unstructured hash tables you get with > > > > > JavaScript, use Maps/Arrays (or Lists). If you want more structured > stuff, > > > > > where are case classes lacking? > > > > > > > > > > Thanks, > > > > > > > > > > David > > > > > > > > > > > > > > > > > > > > > > > > > > > > my 2 cents. > > > > > > > > > > > > /davidB > > > > > > > > > > > > Andrés Testi wrote: > > > > > > > Yes, but I don't like the fact of create a subclass of Person. I > > > > > > just > > > > > > > want to instantiate a Person. Suppose you have this Widget > > > > > > class: > > > > > > > > > > > > > > class Widget{ > > > > > > > val name = new Property("") > > > > > > > val width = new Property(0) > > > > > > > val height = new Property(0) > > > > > > > val children = new Property(Array[Widget]()) > > > > > > > } > > > > > > > > > > > > > > To populate the Widget properties without Object notation, you > > > > > > need to > > > > > > > write the next code > > > > > > > > > > > > > > val w = new Widget > > > > > > > p.name() = "MyWidget" > > > > > > > p.height() = 10 > > > > > > > p.children() = Array( > > > > > > > label, panel,button > > > > > > > ) > > > > > > > > > > > > > > the previous code is not Property-Editor friendly, because the > > > > > > > "programmatic" nature. Then, a declarative syntax is the key. > > > > > > But > > > > > > > creating annonimous class is not declarative but programmatic, > > > > > > because > > > > > > > I would to assign a property 2 times: > > > > > > > > > > > > > > new Widget{ > > > > > > > name="MyWidget" > > > > > > > name="YourWidget" > > > > > > > } > > > > > > > > > > > > > > In the other hand, I don't like to subclass Widget, because I > > > > > > just > > > > > > > want to instantiate Widget. > > > > > > > > > > > > > > 2007/12/22, martin odersky < martin.odersky@...>: > > > > > > >>> Hello: > > > > > > >>> Is it possible to instantiate scala objects in a declarative > > > > > > way like > > > > > > >>> JSON. I think this would be a solution: > > > > > > >>> > > > > > > >>> val p = new Person{ > > > > > > >>> name = "Peter" > > > > > > >>> age = 20 > > > > > > >>> friends = Array( > > > > > > >>> new Person{ > > > > > > >>> name = "Gary" > > > > > > >>> } > > > > > > >>> ) > > > > > > >>> > > > > > > >>> } > > > > > > >>> > > > > > > >> Sure. That you wrote is legal Scala, assuming you declared > > > > > > Person like this: > > > > > > >> > > > > > > >> class Person { > > > > > > >> var name: String = "" > > > > > > >> var age: Int = 99 > > > > > > >> var friends: Array[Person] = Array() > > > > > > >> } > > > > > > >> > > > > > > >> But maybe that's not what you wanted? > > > > > > >> > > > > > > >> Cheers > > > > > > >> > > > > > > >> -- Martin > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > lift, the secure, simple, powerful web framework http://liftweb.net > > > > > Collaborative Task Management http://much4.us > > > > > > > > > > > > > > > > > > > > > -- > > > lift, the secure, simple, powerful web framework http://liftweb.net > > > Collaborative Task Management http://much4.us > > > > > > > > > > -- > _____________________________________ > / \ > /lift/ committer (www.liftweb.net) > SGS member (Scala Group Sweden) > SEJUG member (Swedish Java User Group) > Coffee drinker (Skånerost) > \_____________________________________/ >
Luckily, as the code is written its a copy of Roland, not Roland himself.
On 12/23/07, Viktor Klang <viktor.klang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Dec 23, 2007 11:34 PM, Oscar Picasso < oscarpicasso-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > We could also have?
> > rolandDumas.firstname("Bertrand").age(33)
>
>
> It feels instinctively wrong to have the Roland Dumas named Bertrand. :(
>
>
>
> >
> >
> > I am curious. Where in the lift code are you making these changes?
> >
> >
> > On Dec 23, 2007 5:05 PM, David Pollak < feeder.of.the.bears-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > wrote:
> >
> > > I've been pestering the Scala folks for a way to update just one field
> > > in case classes and have a new instance spit out with just that one
> field
> > > changed for a very long time.
> > >
> > > It would work like this:
> > > val rolandDumas = Person("Roland", "Dumas", 0) // the factory instance
> > > val first= rolandDumas.age(43) // a new instance with age 43
> > > val second = rolandDumas.age(56) // yet another instance with age 56
> > >
> > > You'll be able to get that functionality with some of the changes I'm
> > > making to lift, but baking it into the language would be nicer.
> > >
> > >
> > > On Dec 23, 2007 9:10 AM, Oscar Picasso <oscarpicasso-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > wrote:
> > >
> > > > Case class was the first thing I thought when reading the beginning of
> > > > this tread.
> > > >
> > > > May it can be a partial answer to Rickard question.
> > > >
> > > > **case class Person(firstname: String, lastname: String, age: Int)
> > > >
> > > > But, in a small village in France, they are many Roland Dumas that
> > > > have different ages. Typing over and over Person("Roland", "Dumas",
> xxx) is
> > > > boring.
> > > >
> > > > So let's create a Roland Dumas maker.
> > > >
> > > > scala> def rolandDumasMaker = Person("Roland", "Dumas", _: Int)
> > > > rolandDumasMaker: (Int) => Person
> > > >
> > > > Now creating many Roland Dumases is becoming fun.
> > > > scala> rolandDumasMaker(45)
> > > > res5: Person = Person(Roland,Dumas,45)
> > > >
> > > > scala> rolandDumasMaker(85)
> > > > res6: Person = Person(Roland,Dumas,85)
> > > >
> > > > Sure, in many languages you can make this kind of factory but I find
> > > > it more meaningful and fun the way you can define it in scala.
> > > >
> > > >
> > > > On Dec 23, 2007 9:42 AM, David Pollak <feeder.of.the.bears-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > > wrote:
> > > >
> > > > >
> > > > >
> > > > > On Dec 23, 2007 3:44 AM, David Bernard <david.bernard.31-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > > > wrote:
> > > > >
> > > > > > I thinks that with some change in Property you could support a
> > > > > > builder approach that support
> > > > > > val w = new Widget()
> > > > > > .name("MyWidget")
> > > > > > .height(10)
> > > > > > .children(label, panel, button)
> > > > >
> > > > >
> > > > > Which is what you get with lift components.
> > > > >
> > > > > But I believe the larger issue is one of mutability and internal
> > > > > type representation.
> > > > >
> > > > > JavaScript has JSON because it is pretty much built on hash tables
> > > > > and the built in types (numbers, Strings, dates, booleans, arrays
> and
> > > > > hashs/objects) are so limited in number that it makes sense to have
> special
> > > > > syntax for each of them.
> > > > >
> > > > > Scala, too, has some special notation for building object
> > > > > hierarchies: case classes. One can build complex object hierarchies
> using
> > > > > case classes. In my opinion, they are as easy to read as JSON
> objects.
> > > > > They are a little more verbose to type, but that's because they're
> typed (ah
> > > > > hah... a pun.)
> > > > >
> > > > > One can also do:
> > > > > Map('foo -> Array(1,2,3), 'bar -> Array("dog", "cat"), 'baz ->
> > > > > Date("12-23-07"))
> > > > >
> > > > > It's a little more verbose than JSON, but the objects are
> > > > > serializable as JSON (okay, I made up the Date thing, but it's not
> hard to
> > > > > implement.)
> > > > >
> > > > > If you want the kind of unstructured hash tables you get with
> > > > > JavaScript, use Maps/Arrays (or Lists). If you want more structured
> stuff,
> > > > > where are case classes lacking?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > David
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > my 2 cents.
> > > > > >
> > > > > > /davidB
> > > > > >
> > > > > > Andrés Testi wrote:
> > > > > > > Yes, but I don't like the fact of create a subclass of Person. I
> > > > > > just
> > > > > > > want to instantiate a Person. Suppose you have this Widget
> > > > > > class:
> > > > > > >
> > > > > > > class Widget{
> > > > > > > val name = new Property("")
> > > > > > > val width = new Property(0)
> > > > > > > val height = new Property(0)
> > > > > > > val children = new Property(Array[Widget]())
> > > > > > > }
> > > > > > >
> > > > > > > To populate the Widget properties without Object notation, you
> > > > > > need to
> > > > > > > write the next code
> > > > > > >
> > > > > > > val w = new Widget
> > > > > > > p.name() = "MyWidget"
> > > > > > > p.height() = 10
> > > > > > > p.children() = Array(
> > > > > > > label, panel,button
> > > > > > > )
> > > > > > >
> > > > > > > the previous code is not Property-Editor friendly, because the
> > > > > > > "programmatic" nature. Then, a declarative syntax is the key.
> > > > > > But
> > > > > > > creating annonimous class is not declarative but programmatic,
> > > > > > because
> > > > > > > I would to assign a property 2 times:
> > > > > > >
> > > > > > > new Widget{
> > > > > > > name="MyWidget"
> > > > > > > name="YourWidget"
> > > > > > > }
> > > > > > >
> > > > > > > In the other hand, I don't like to subclass Widget, because I
> > > > > > just
> > > > > > > want to instantiate Widget.
> > > > > > >
> > > > > > > 2007/12/22, martin odersky < martin.odersky-p8DiymsW2f8@public.gmane.org>:
> > > > > > >>> Hello:
> > > > > > >>> Is it possible to instantiate scala objects in a declarative
> > > > > > way like
> > > > > > >>> JSON. I think this would be a solution:
> > > > > > >>>
> > > > > > >>> val p = new Person{
> > > > > > >>> name = "Peter"
> > > > > > >>> age = 20
> > > > > > >>> friends = Array(
> > > > > > >>> new Person{
> > > > > > >>> name = "Gary"
> > > > > > >>> }
> > > > > > >>> )
> > > > > > >>>
> > > > > > >>> }
> > > > > > >>>
> > > > > > >> Sure. That you wrote is legal Scala, assuming you declared
> > > > > > Person like this:
> > > > > > >>
> > > > > > >> class Person {
> > > > > > >> var name: String = ""
> > > > > > >> var age: Int = 99
> > > > > > >> var friends: Array[Person] = Array()
> > > > > > >> }
> > > > > > >>
> > > > > > >> But maybe that's not what you wanted?
> > > > > > >>
> > > > > > >> Cheers
> > > > > > >>
> > > > > > >> -- Martin
> > > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > lift, the secure, simple, powerful web framework http://liftweb.net
> > > > > Collaborative Task Management http://much4.us
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > lift, the secure, simple, powerful web framework http://liftweb.net
> > > Collaborative Task Management http://much4.us
> > >
> >
> >
>
>
> --
> _____________________________________
> / \
> /lift/ committer (www.liftweb.net)
> SGS member (Scala Group Sweden)
> SEJUG member (Swedish Java User Group)
> Coffee drinker (Skånerost)
> \_____________________________________/
>
IMHO; double assignment seems odd for declarative instantiation.
Yes, but I don't like the fact of create a subclass of Person. I just
want to instantiate a Person. Suppose you have this Widget class:
class Widget{
val name = new Property("")
val width = new Property(0)
val height = new Property(0)
val children = new Property(Array[Widget]())
}
To populate the Widget properties without Object notation, you need to
write the next code
val w = new Widget
p.name() = "MyWidget"
p.height() = 10
p.children() = Array(
label, panel,button
)
the previous code is not Property-Editor friendly, because the
"programmatic" nature. Then, a declarative syntax is the key. But
creating annonimous class is not declarative but programmatic, because
I would to assign a property 2 times:
new Widget{
name="MyWidget"
name="YourWidget"
}
In the other hand, I don't like to subclass Widget, because I just
want to instantiate Widget.
2007/12/22, martin odersky < martin.odersky <at> epfl.ch>:> > Hello:
> > Is it possible to instantiate scala objects in a declarative way like
> > JSON. I think this would be a solution:
> >
> > val p = new Person{
> > name = "Peter"
> > age = 20
> > friends = Array(
> > new Person{
> > name = "Gary"
> > }
> > )
> >
> > }
> >
> Sure. That you wrote is legal Scala, assuming you declared Person like this:
>
> class Person {
> var name: String = ""
> var age: Int = 99
> var friends: Array[Person] = Array()
> }
>
> But maybe that's not what you wanted?
>
> Cheers
>
> -- Martin
>
On 2007-12-22 10:48:53 Andrés Testi wrote: > Hello: > Is it possible to instantiate scala objects in a declarative way like > JSON. I think this would be a solution: > > val p = new Person{ > name = "Peter" > age = 20 > friends = Array( > new Person{ > name = "Gary" > } > ) > > } > > But I don't like to create a subclass of Person for a single instance.I think your concern is unfounded. Java seems to handle very large numbers of classes quite happily. /J
I think your concern is unfounded. Java seems to handle very largeOn 2007-12-22 10:48:53 Andrés Testi wrote:
> Hello:
> Is it possible to instantiate scala objects in a declarative way like
> JSON. I think this would be a solution:
>
> val p = new Person{
> name = "Peter"
> age = 20
> friends = Array(
> new Person{
> name = "Gary"
> }
> )
>
> }
>
> But I don't like to create a subclass of Person for a single instance.
numbers of classes quite happily.
/J
Another related thing I wish for is some lightweight
syntax for using case classes as immutable records,
(in Haskell-style, among others).
So following your example I would like to do:
val p = Person {
name = "Peter"
age = 20
...
}
val q = p { name = "Rickard" }
where p gets all the attributes from p, with the
name updated. I would find this very useful. Any
suggestions for doing something similar without
any new special syntax?
/ Rickard
On Sat, 22 Dec 2007 14:48:53 +0100, Andrés Testi
<andres.a.testi <at> gmail.com> wrote:
> Hello:
> Is it possible to instantiate scala objects in a declarative way like
> JSON. I think this would be a solution:
>
> val p = new Person{
> name = "Peter"
> age = 20
> friends = Array(
> new Person{
> name = "Gary"
> }
> )
>
> }
>
> But I don't like to create a subclass of Person for a single instance.
Rickard Nilsson wrote:> Another related thing I wish for is some lightweight > syntax for using case classes as immutable records, > (in Haskell-style, among others). > > So following your example I would like to do: > > val p = Person { > name = "Peter" > age = 20 > ... > } > > val q = p { name = "Rickard" } > > where p gets all the attributes from p, with the > name updated. I would find this very useful. Any > suggestions for doing something similar without > any new special syntax? > > > / RickardThe Haskell-record syntax (or similar) would be great! In the meantime, I have been writing a function for each field. For your example, I would write name: Person -> String -> Person -- Tony Morris http://tmorris.net/ Hey! We had 40,000 lines of C# here yesterday, but now there are 40 lines of... Dear God, what is a catamorphism?"
On Sat, 22 Dec 2007 22:55:12 +0100, Tony Morris <tmorris <at> tmorris.net> wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Rickard Nilsson wrote: >> Another related thing I wish for is some lightweight >> syntax for using case classes as immutable records, >> (in Haskell-style, among others). >> >> So following your example I would like to do: >> >> val p = Person { >> name = "Peter" >> age = 20 >> ... >> } >> >> val q = p { name = "Rickard" } >> >> where p gets all the attributes from p, with the >> name updated. I would find this very useful. Any >> suggestions for doing something similar without >> any new special syntax? >> >> >> / Rickard > > > The Haskell-record syntax (or similar) would be great! In the meantime, > I have been writing a function for each field. For your example, I would > write name: Person -> String -> PersonYes, that is probably the best I could do for the moment. / Rickard
I'm only voting "yes" if we call it SCONES.
Hello:
Is it possible to instantiate scala objects in a declarative way like
JSON. I think this would be a solution:
val p = new Person{
name = "Peter"
age = 20
friends = Array(
new Person{
name = "Gary"
}
)
}
But I don't like to create a subclass of Person for a single instance.
I'm only voting "yes" if we call it SCONES.
--On Dec 22, 2007 2:48 PM, Andrés Testi <andres.a.testi <at> gmail.com> wrote:Hello:
Is it possible to instantiate scala objects in a declarative way like
JSON. I think this would be a solution:
val p = new Person{
name = "Peter"
age = 20
friends = Array(
new Person{
name = "Gary"
}
)
}
But I don't like to create a subclass of Person for a single instance.
_____________________________________
/ \
/lift/ committer (www.liftweb.net)
SGS member (Scala Group Sweden)
SEJUG member (Swedish Java User Group)
Coffee drinker (Skånerost)
\_____________________________________/
You're right, my example is to show the only way I know to instantiate objects in a declarative way. I hope to see first class object notation in a future release of Scala. Object notation is very useful in UI definition. 2007/12/22, Viktor Klang <viktor.klang <at> gmail.com>:> > > On Dec 22, 2007 2:57 PM, Viktor Klang <viktor.klang <at> gmail.com> wrote: > > I'm only voting "yes" if we call it SCONES. > > > > > > > > On a serious side, your example doesn't specify wether it's a var or val or > def, which wouldn't work out so well.. > > Cheers, > Viktor > > > > > > > > > > > > > On Dec 22, 2007 2:48 PM, Andrés Testi <andres.a.testi <at> gmail.com> wrote: > > > > > Hello: > > > Is it possible to instantiate scala objects in a declarative way like > > > JSON. I think this would be a solution: > > > > > > val p = new Person{ > > > name = "Peter" > > > age = 20 > > > friends = Array( > > > new Person{ > > > name = "Gary" > > > } > > > ) > > > > > > } > > > > > > But I don't like to create a subclass of Person for a single instance. > > > > > > > > > > > -- > > _____________________________________ > > / \ > > /lift/ committer (www.liftweb.net) > > SGS member (Scala Group Sweden) > > SEJUG member (Swedish Java User Group) > > Coffee drinker (Skånerost) > > \_____________________________________/ > > > > -- > _____________________________________ > > / \ > /lift/ committer ( www.liftweb.net) > SGS member (Scala Group Sweden) > SEJUG member (Swedish Java User Group) > Coffee drinker (Skånerost) > \_____________________________________/
RSS Feed