Sure, you can get around dynamic typing. I'm just giving a few
examples of where it's handy. The point is to reduce all the
excessive code....
What about something like an xml or json based API (without a schema)?
(this won't work with XmlSlurper btw, this is for an example)
def books = new XmlSlurper().parse("http://myservice/myapi";)
books.book.each {
println "Title = ${it.title}, Author: ${it.author.@firstname}
${it.author.@lastname}"
}
On Mon, May 9, 2011 at 8:27 AM, Kevin Wright <[email protected]> wrote:
> You only need dynamic typing because your query is defined as a "dynamic"
> string!
> The database certainly has a schema and knows the types of columns, as
> should your code base with it's own internal DAOs. The problem is the
> marshalling in between, JDBC and string-based queries. This isn't too far
> removed from the dynamic typing issues caused by defining stuff as
> uncompiled raw strings in a Spring context config.
> Compare to something like squeryl:
> val avg =
> from(grades)(g =>
> where(g.subjectId === mathId)
> compute(avg(g.scoreInPercentage))
> )
> The compiler *knows* that avg will be an Option[Float], because it knows the
> types of the columns. It even checks, statically, that subjectId and mathId
> are of the same type; refusing to compile if they aren't.
> LINQ also takes a similar approach.
> So no, you don't need dynamic typing. Though once you've introduced it (via
> SQL query strings) it does tend to get pervasive unless very carefully
> controlled.
>
> On 9 May 2011 15:12, phil swenson <[email protected]> wrote:
>>
>> What if your sql is "select id as id_alias from users where username
>> ='phil'"?
>>
>> Then the code would be
>>
>> id = resultset.id_alias
>>
>>
>> I think you need dynamic typing for this sort of thing.
>>
>>
>>
>> On Mon, May 9, 2011 at 6:31 AM, Josh Berry <[email protected]> wrote:
>> > Couple of questions.
>> >
>> > First, is dynamic typing truly necessary for this level of coding? I
>> > know it is commonly used that way, but I have seen some tricks in
>> > static languages that work just as well. (The Lift folks have a good
>> > api for pulling from a database, and that is ignoring squeryl. Sadly,
>> > I'm ignorant of Haskel libraries for this sort of thing. I'm also
>> > more ignorant than I care to be on LINQ.)
>> >
>> > Secondly, I think this is what was referred to when it was said the
>> > majority of "dynamic" programs are actually quite static. (Or would
>> > this program work correctly if I renamed that column to
>> > "SpecificIdentifier" or some nonsense?) I understand that ResultSet
>> > has its type altered for this section of code, but one could have just
>> > as easily defined a specific subtype of ResultSet for this section,
>> > because it will always require that specific type. Plus side to the
>> > latter approach, mistakes can be found at compile time. :)
>> >
>> >
>> >
>> > On Sun, May 8, 2011 at 2:21 PM, phil swenson <[email protected]>
>> > wrote:
>> >> Lets say you are iterating through database records and one of columns
>> >> is "id"
>> >>
>> >> def id = resultSet.id
>> >>
>> >> Or from the original blog post:
>> >>
>> >> def books = new XmlSlurper().parse("books.xml")
>> >> books.book.each {
>> >> println "Title = ${it.title}, Author: ${it.author.@firstname}
>> >> ${it.author.@lastname}"
>> >> }
>> >>
>> >> import groovy.sql.Sql
>> >> sql = Sql.newInstance("jdbc:mysql://host/db", "username", "password",
>> >> "com.mysql.jdbc.Driver")
>> >> sql.eachRow("select * from tableName", { println it.id + " --
>> >> ${it.firstName} --"} )
>> >>
>> >>
>> >>
>> >> On Sun, May 8, 2011 at 11:25 AM, Josh Berry <[email protected]> wrote:
>> >>> On Sun, May 8, 2011 at 9:30 AM, phil swenson <[email protected]>
>> >>> wrote:
>> >>>> well the article was called "java.next()"
>> >>>>
>> >>>> But why not have the best of both worlds? Static typing/type
>> >>>> inference. Optional dynamic typing where it makes sense.
>> >>>
>> >>> Within a given program, I'm curious of an example where dynamic typing
>> >>> actually "makes sense." Wasn't there a study that showed even in
>> >>> traditional dynamic languages, the majority of the runtime behavior
>> >>> was consistent with a static type model?
>> >>>
>> >>> --
>> >>> You received this message because you are subscribed to the Google
>> >>> Groups "The Java Posse" group.
>> >>> To post to this group, send email to [email protected].
>> >>> To unsubscribe from this group, send email to
>> >>> [email protected].
>> >>> For more options, visit this group at
>> >>> http://groups.google.com/group/javaposse?hl=en.
>> >>>
>> >>>
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups "The Java Posse" group.
>> >> To post to this group, send email to [email protected].
>> >> To unsubscribe from this group, send email to
>> >> [email protected].
>> >> For more options, visit this group at
>> >> http://groups.google.com/group/javaposse?hl=en.
>> >>
>> >>
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "The Java Posse" group.
>> > To post to this group, send email to [email protected].
>> > To unsubscribe from this group, send email to
>> > [email protected].
>> > For more options, visit this group at
>> > http://groups.google.com/group/javaposse?hl=en.
>> >
>> >
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "The Java Posse" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected].
>> For more options, visit this group at
>> http://groups.google.com/group/javaposse?hl=en.
>>
>
>
>
> --
> Kevin Wright
>
> gtalk / msn : [email protected]
> mail: [email protected]
> vibe / skype: kev.lee.wright
> quora: http://www.quora.com/Kevin-Wright
> twitter: @thecoda
>
> "My point today is that, if we wish to count lines of code, we should not
> regard them as "lines produced" but as "lines spent": the current
> conventional wisdom is so foolish as to book that count on the wrong side of
> the ledger" ~ Dijkstra
>
> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
>
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
