FAQ
Lets assume that we wanted to modify the Dijkstra code to account for non
unitary weights. Presumably that would mean we need to modify the graph
interface to enable calling of the edge weight (something like Weight(e
Edge) ). There may be some graph classes which have all of the bells and
whistles, and allow things like edge weights. There may be other graph
classes which are designed for efficiency on simple graphs, and so don't
have a weight assigned to their edge. Is there any way to write a single
Dijkstra's code that can run on both of those kinds of graphs? I think this
would be equivalent to having a statement like "If the type has an edge
weight method, then use it, otherwise the edge weight is 1".

Thanks, I'm still trying to get my head around "thinking in Go"


On Monday, September 19, 2011 8:09:33 AM UTC-7, Jeremy Shute wrote:

I have a warm place in my heart for generic programming.

But, it's often the case (outside of STL) template spaghetti is used to
duck-type and you can't (easily) decipher which concrete class a piece of
code is working with. Cross-referencing becomes a real PITA. Boost in C++
uses "contracts" to try to make this better (where a generic block of code
statically asserts its requirements are met), whereas Common Lisp gives you
an interactive environment with (MACROEXPAND-1 ...) to let you see what's
going on.

gofmt follows in the vein of the latter, basically, and in doing so it
skirts the issues of having to compile generic code with variable-sized
objects (something Go has to worry about because its philosophy seems to be
allowing you to control memory layout, as opposed to e.g. boxing EVERYTHING
ala Java).

I don't think it's the Best Solution, rather I think it's worth mentioning
when people come down on the perceived lack of a feature. It's a good tool
in the toolbox, one you can use to get things done right now.

Jeremy



On Sat, Sep 17, 2011 at 1:58 PM, warmfuzzykitten <bobf...@gmail.com<javascript:>
wrote:
It would seem that source rewriting is something the compiler should do
for you, and its existence highlights that deficiency.
--

Search Discussions

  • Tarmigan at Sep 26, 2012 at 12:28 am

    On Tue, Sep 25, 2012 at 9:04 AM, wrote:
    Lets assume that we wanted to modify the Dijkstra code to account for non
    unitary weights. Presumably that would mean we need to modify the graph
    interface to enable calling of the edge weight (something like Weight(e
    Edge) ). There may be some graph classes which have all of the bells and
    whistles, and allow things like edge weights. There may be other graph
    classes which are designed for efficiency on simple graphs, and so don't
    have a weight assigned to their edge. Is there any way to write a single
    Dijkstra's code that can run on both of those kinds of graphs? I think this
    would be equivalent to having a statement like "If the type has an edge
    weight method, then use it, otherwise the edge weight is 1".
    You can test whether a type implements an interface. So you could
    make a new interface that includes a Weight() method, and test against
    that.

    http://play.golang.org/p/Hkt0qQaD3L

    -Tarmigan

    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedSep 25, '12 at 10:42p
activeSep 26, '12 at 12:28a
posts2
users2
websitegolang.org

2 users in discussion

Tarmigan: 1 post Tracey Brendan: 1 post

People

Translate

site design / logo © 2021 Grokbase