Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing the Famous Framework

blog.famous.org

Post reply on HN
Print view View original

91–94 of 94 posts

Re: Introducing the Famous Framework

#91

Post by zackbrown »

JustSomeNobody wrote: post #88
zackbrown wrote: post #77

Earlier quoted context omitted.

> These "Behavior" functions may depend on the data, but that doesn't make this a dependency. Would you mind clarifying this distinction as you see it? As far as I can see, x depends on y if and only if y is a dependency of x. This would make the States that Behaviors depend on a 'dependency,' based on your statement above that 'functions ... depend on the data [States].' These State dependencies (if we can agree on…

Because state is data. You operate on data, not depend on it. My repository depends on a database connection (be it mock or real). It does not depend on what state the tables may be in. If your function operates on data, it's "passing in data" and not "dependency injection". Hell, otherwise, every function call would involve dependency injection!

Would you accept that a Haskell function could depend on the streams that are bound into it? Not an individual datum, but the stream itself. I'd argue 'yes', in the same sense that you could depend on some model or factory in OO land. The leap is in the paradigm, functional vs OO.

Behaviors in BEST are a functional programming construct—they project streams of data into a return value. Note that Behaviors are automatically re-evaluated every time one of their dependent States change, which introduces this 'stream' functionality.

I'd argue that these streams are dependencies and that they're being injected into these functions (hence DI,) but honestly, at this point we're just bike-shedding about terminology :-).

I do want to make sure, though, that this functionality is properly communicated, as the State-Behavior relationship is the crux of our framework's design.

Re: Introducing the Famous Framework

#92

Post by datashovel »

From the blog post it looks like alot of good work is being done here. I think most apps out there probably don't reach the level of complexity that would require a rethinking of MVC, but I have seen it and agree that some web applications have reached the need to think beyond what MVC can provide.

If I had to guess, I think some of the first web-related work (on what post-MVC web will look like) began several years ago when 'reactive' programming started becoming a hot topic.

Since it seems a new JS framework comes out pretty much every week, and some people express frustration in trying to filter through the noise, I would say to them that this one is definitely one to keep an eye on.

Re: Introducing the Famous Framework

#93

Post by couchand »

zackbrown wrote: post #91
JustSomeNobody wrote: post #88

Earlier quoted context omitted.

Because state is data. You operate on data, not depend on it. My repository depends on a database connection (be it mock or real). It does not depend on what state the tables may be in. If your function operates on data, it's "passing in data" and not "dependency injection". Hell, otherwise, every function call would involve dependency injection!

Would you accept that a Haskell function could depend on the streams that are bound into it? Not an individual datum, but the stream itself. I'd argue 'yes', in the same sense that you could depend on some model or factory in OO land. The leap is in the paradigm, functional vs OO. Behaviors in BEST are a functional programming construct—they project streams of data into a return value. Note that Behaviors are automat…

Nope, that's still just passing in data, from the point of view of the function receiving the data. Passing data to a function is just a regular old function call.

However, you could consider that the caller of the function could have had the stream injected, depending on the perspective of the rest of the application.

For instance in pseudocode:

    useData = (data) ->
        munge(data) + calculate(data)

    setupPipeline = (input, output) ->
        input
            .pipe cleanup
            .pipe useData
            .pipe format
            .pipe output

    application = ->
        setupPipeline stdin, stdout

    test = ->
        setupPipeline mockInput, mockOutput
Notice how I've included the test case to illustrate how the dependency injection enables testability, which is critical to understanding the concept. Without DI, the setupPipeline method would take no parameters and explicitly hook to stdin/stdout.

Contrast this example with the standard case of regular-old-data-passing:

    useData = (data) ->
        munge(data) + calculate(data)

    application = ->
        useData stdin.getInt()

    test = ->
        assert.equal -1, useData 42
        assert.equal 0, useData 100
        assert.equal 1, useData 99
Note how inversion of control is not necessary to unit test this function, which is the indication that there is no dependency injection going on there.

If you were using dependency injection for the behaviors, it would imply that the injection is not strictly necessary, and you could instead write the function with a hard dependency. Since the behavior just takes data that whole idea is nonsensical. What would it bind to? Nothing. It's just taking data.

Re: Introducing the Famous Framework

#94

Post by emoji »

cjoun16 wrote: post #35
exacube wrote: post #7

For a UI framework, show me a pretty demo with some example snippet code next to it and I will read on. Otherwise, I'm not motivated -- this is not the way you want people to read about your UI framework.

Checkout http://milk.samsung.com built using famous. Stackoverflow has lots of famous snippets.

spoiler alert: interface unusable on retina macbook pro
Post reply on HN