Git Product home page Git Product logo

Comments (3)

mdom avatar mdom commented on August 15, 2024

Hah! That was a issue on my todo list i also wanted to bring up... I like the indirection with the injectible class and i would definitely add that to make subclassing and composing easier. There will always be cases of code that you can't include and we should make that as easy for users as possible.

But said that, why not just add type to Mojo::Feed? I would even go so far and add all attributes mentioned in the spec. That shouldn't be too much work and have a negligent runtime cost. And even if we worry about that, we could just use a specialised import list to generate a minimal set of accessors or an extended list. I would love to use atoms expired to save updating feeds if they run their course. :)

from mojo-feed.

dotandimet avatar dotandimet commented on August 15, 2024

There are two points here: The one I'm looking at here is how to make Mojo::Feed and Mojo::Feed::Item extensible. feed_type() is just a quick example, doesn't matter if it's a good idea to add that to Mojo::Feed. For extending Mojo::Feed::Item, I'm using your enclosures code - testing how it would look if you had to add that feature without changing the Mojo::Feed::Item code.

The second point (the one you're making) is what are worthwhile additions to Mojo::Feed. The current implementation is a quick-and-dirty, broadest common denominator parser. But if we go past that, it might be worth taking this more seriously and providing full access to everything feeds contain. I'm adding this as a new issue, #14

Regarding extensibility, I made a quick POC in the extend branch with pluggable classes, and I'm not sure I like that approach - it feels over-engineered rather than elegant. In Israel they say "setup for an air conditioner", because the code looks like a wall with a bricked-up hole in it (I think the more common phrase is YAGNI).

A better(?) approach might be to use with_roles to extend the objects themselves, after they are created. This has the advantage of requiring no adaptations in Mojo::Feed (no item_class member, etc), but the user will need to wrap the creation of objects with a function that calls with_roles on the result.

from mojo-feed.

mdom avatar mdom commented on August 15, 2024

Yeah, you're probably right. Maybe we just just with_roles, see how often we need to extend Mojo::Feed and how much pain the manual wrapping is? We can always add more features but it's hard to remove them ... :)

from mojo-feed.

Related Issues (11)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.