Re: Scala Object Notation ( SCON? )

Check out: http://code.google.com/p/punk/wiki/SCON

Carsten Saager gmail.com> writes:

>
>
> 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.
> CarstenPS: 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
>
> On Dec 28, 2007 10:47 PM, Ian Clarke gmail.com> wrote:
> I think I agree.  A language requires a clear vision and consistentaesthetic,
exactly the two things that collective decision making isbad at, remember the
old joke about how a camel is a horse designed bycommittee?
> 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 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 gmail.com> wrote:> > On Dec 23, 2007 3:44 AM, David
Bernard 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 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 gmail.com
> Cell: +1 512 422 3588AIM: ian.clarke mac.comSkype: sanity
>
>