Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Adrian Hope-Bailie
    @adrianhopebailie
    You sent: interledgerjs/btp-toolbox#2
    interledgerjs/btp-toolbox#2
    Adrian Hope-Bailie
    @adrianhopebailie
    Sorry David, I think I cut you off there
    David Fuelling
    @sappenin
    No worries - can't remember what I was going to say, so it must not have been very important.
    ;)
    Btw - here's a link to a quick branch I put together to demonstrate how easy immutables is to use: interledger/java-ilp-core@724bcb3
    To get it working in your IDE, you'll want to follow the directions on the immutables website -- for Intellij, at least, you have to configured the annotation processor in the IDE so it can pickup the immutables annotations. But on the command-line, it should just build.
    See here for IDE config: http://immutables.github.io/apt.html
    Enrique Arizón Benito
    @earizon

    Restarting a old discussion. I'm not convinced that using and Interface for value-objects is a good idea. Providing a POJO with a constructor and private final fields with setters will translate missing parameter errors from runtime ( MyClass myInstance = WhatEver.builder().setParam1().setParam2 ...build() ) to compile time ( MyClass myInstance = new MyClass(param1, param2, ...) ) , following the fail-fast design (https://en.wikipedia.org/wiki/Fail-fast), one the few "absolute true" in software design. The only real scenario where Interfaces are suitable IMHO is that in which the value-object is "big" and so different strategies for storing the data can be applied in different context (embedded, servers, clusters,...).

    First results on Google - https://www.google.com/search?&q=interface++%22value+object%22 - looks to favor NOT to use Interfaces for value objects :
    https://stackoverflow.com/questions/25457028/designing-value-object-by-interface
    https://softwareengineering.stackexchange.com/questions/185636/should-i-create-interfaces-for-data-transfer-objects

    of course interfaces can still be very useful for value-object for the purpose of "tagging" the classes/instances as having some sort of property not directly related to value storage, but to the orthogonal properties like Printable, Serializable, Orderable, Comparable, TaintedInput, UntaintedOutput, ... )

    David Fuelling
    @sappenin
    Interesting points - I agree that compile-time fail-fast is a good goal, but the I think this is a flaw in the way we've constructed our builders, not necessarily in the usage of an interface vs. concrete class. The pattern you're looking for is called a "staged-builder", which is a compile-time safe way to ensure that all required attributes of a builder are set. For example, see here in the Immutables project where you can configure the generated builder to implement the behavior you are seeking: http://immutables.github.io/immutable.html#staged-builder
    Also, another scenario where interfaces are preferred is when we want the implementation to vary. Since java-ilp-core is a library that we want to be widely used, I think it's important to assume that most users of our library will simply use the value objects we provide, but for those users who desire not to use our value objects, we give them the ability to create their own implementations without deviating from the interfaces that we've also defined.
    I think this is particularly painful in java-ilp-core because we have a lot of value objects, and so the library has a lot of boilerplate because of the decision to use interfaces. You can look at my PR above and see how the usage of something like the Immutables project allows us to keep using interfaces, but remove almost 99% of all the boilerplate.
    Enrique Arizón Benito
    @earizon
    (FYI: The Hyperledger STC meeting is at 4:00 pm ECT, to join:
    https://www.gotomeeting.com/join/613310429
    or dial in using your phone: US (toll-free): +1-877-309-2070 US: +1-312-757-3119 Access Code: 613-310-429
    @sappenin : Just in case, Adrian confirmed he can NOT attend the meeting. I'm not sure if someone from Ripple will do.
    Michiel de Jong
    @michielbdejong
    @earizon just to double check, ECT is Ecuador Time?
    Enrique Arizón Benito
    @earizon
    Sorry ECT European (Summer) Central Time
    Michiel de Jong
    @michielbdejong
    Or did you mean CET?
    I'll attend! What does 'STC' stand for?
    Enrique Arizón Benito
    @earizon
    Just to avoid confussions. 14:00 pm UTC (Coordinated Universal Time )
    Michiel de Jong
    @michielbdejong
    ok :)
    and is there an agenda for this meeting? what will be discussed?
    Enrique Arizón Benito
    @earizon
    About Interledger it's possible that somebody ask questions from the shared document: https://docs.google.com/document/d/1KVrakb2JsqgMo2aG-QIYl743VHsU9NWYKxy7n-WeXv4/edit
    Michiel de Jong
    @michielbdejong
    ok! i'll read that doc before the meeting. see/hear you there! :)
    Enrique Arizón Benito
    @earizon
    +1
    Michiel de Jong
    @michielbdejong
    interledger/java-ilp-core#90
    Enrique Arizón Benito
    @earizon
    FYI: I just created a wrapper script around Docker+NodeJS to allow running NodeJS "stuff" inside a Java environment without getting the file system dirty (as well as easily allowing switching the NodeJS version used). In case someone is also interested, it's available at:
    https://github.com/earizon/utility_shell_scripts/blob/master/node_wrapper.sh
    (function "usage" mostly summarizes how to use it)
    Chris Opler
    @controlsurface
    @sappenin Hi This is Chris checking in
    Hope to be of help !
    I have already created a pull request in java-ilp-core for issue #96 -- the javadoc cleanup.
    David Fuelling
    @sappenin
    Yeah, just saw that, thanks for jumping in!
    Chris Opler
    @controlsurface
    You bet :-)
    I saw another getting started ticket
    David Fuelling
    @sappenin
    Github appears to be having trouble today, but I a few small comments (minor nits).
    Chris Opler
    @controlsurface
    Cool, I will clean them up
    David Fuelling
    @sappenin
    cool! Feel free to look through the issues and take anything that's unassigned (if it makes sense how to fix).
    Chris Opler
    @controlsurface
    Great, will do. If you have any priorities, let me know and I can try to look at those first
    David Fuelling
    @sappenin
    Sounds good. Also, there's a bi-weekly Interledger call every other Weds at 8AM PST. https://lists.w3.org/Archives/Public/public-interledger/2017Oct/0005.html
    On the other wednesdays, we hold a Java call to sync-up the community. Send me your email address in a private message, and I can forward the invite if you're interested.
    Chris Opler
    @controlsurface
    @sappenin Awesome. Will definitely participate
    David Fuelling
    @sappenin
    @/all FYI, new version 0.9.0-SNAPSHOT of java-ilp-core published here: https://oss.sonatype.org/#nexus-search;quick~ilp-core
    Enrique Arizón Benito
    @earizon
    @sappenin , thx for sharing
    Enrique Arizón Benito
    @earizon
    @/all interledger/java-ilp-core#103 is a set of common shell scripts that can save some minutes a day while developing locally (pure shell scripts, IDE-agnostic, only gradle as dependency). I guess they can/could also be reused for continuous integration tasks.
    Adrian Hope-Bailie
    @adrianhopebailie
    @earizon you haven't provided input here: interledger/java-ilp-core#88
    Enrique Arizón Benito
    @earizon
    @adrianhopebailie I completely forgot about that issue.
    Rizwan Tanoli
    @rizwantanoli
    I would love to get involved in code development efforts and help out
    anything the team is looking specifically help with?
    Rizwan Tanoli
    @rizwantanoli
    just checked out and ran initial code build