Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I wish to copy (in a nested manner) values from one object tree to another. In Java I would have used something like Orika.
My particular use case is building a sequence of message deltas to generate a latest state.
Scala favours immutable values. Don't think in terms of copying - think in terms of creating a new object tree that's a transformation of the previous object tree.
You might like to use Shapeless' generic zipper support, which can apply a transformation anywhere in a nested structure of case classes or similar.
I don't understand your use case in terms of your question - perhaps you should be more specific about what you want to do. If you want to apply a message delta to a message to generate a new message, that's a case for Lenses, which are also available in Shapeless, although the implementation in Monocle is supposed to be better.
It shouldn't be necessary to use something that relies on runtime reflection - Scala is expressive enough to implement these kinds of things in a typesafe way.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
The community is reviewing whether to reopen this question as of 1 year ago.
Improve this question
Edited
Having multiple data sources for an app
What is the best approach to combine all data sources together in one class and add it as one environment object, keeping in mind data might change, therefore objects update the views?
What are the appropriate Bindings to use for:
Services (API fetches): #Published?
Computed variables: Lazy var?
Please refer to the diagram as an example. Thanks.
These questions were good references:
An equivalent to computed properties using #Published in Swift Combine?
https://medium.com/genetec-tech/property-wrappers-in-swift-5-1-the-missing-published-implementation-1a466ebcf660
diagram
So, you should use a layered architecture and you will not have those problems.
service layer, it's the lowest layer reads the data from either web or db, or other services
repository layer gets the data from service and process it, caching, etc
usecase layer combines data from multiple repositories
viewmodel layer gets the data from usecase and sends it to view
each service or repository handles one type of data "Users" for example
now, if you need to combine multiple types of data, like Users and Companies let's say, you need a Usecase layer which will combine all the data
on your viewmodel you only use the usecase layer
One important note, passed objects change between layers, so on service layer you have UserDto (coming from webservice), and UserEntity (coming from DB), the repo will transform those in UserResponse, which you don't know if it's db or webservice and even more the UseCase will transform UserResponse and CompanyReponse into a User object which will be passed to ViewModel and will contain all data required there.
Also, until you get to the viewmodel layer you should not need SwiftUI, if you need it, you are doing something wrong, use Swift Combine to handle data.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
I know there is scala.collection.mutable package which provides mutable data structures. But how is it done?
Can I write my own mutable data structure and pass it to a function to be changed?
Edit: The question aims towards techniques that can be used to implement mutable data types.
Read this wonderful tutorial on implementing custom collections in scala.
It should have all you need to answer the question "how it is done".
If you are just talking about any data structure, not a collection, then something like
class Foo(var bar: String)
will do. But ... don't do it. While, there are rare and isolated cases, where having a mutable structure is unavoidable, chances are, you will not encounter such a case for a long time.
My advice to you is to start with learning to write good, idiomatic scala code, and getting into the functional mindset, where data structures don't mutate under you. Learn to appreciate that.
Sure, you can. There is no limitation, that all immutable data structures should be inside scala.collection.immutable, and all mutable DS should be inside scala.collection.mutable. Standard collection classes are divided into these two packages just for convenience. You can create your classes, where you like to do it.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
Can we implement one concept in terms of other ?
Objects in terms of higher order functions?
Higher order functions in terms of objects?
Yes.
Objects in terms of higher order functions?
If your language has records, then you can implement objects as a record of closures closing over a common environment. In fact, that's exactly how objects are implemented in ECMAScript. (In ECMAScript, records are confusingly called objects, though.)
If you don't have records, or you subscribe to the message-oriented paradigm of OO, you can use a selector function instead, which takes the "message" as a parameter and returns a closure based on the message. This is how pretty much all object systems in Scheme work, for example Oleg Kiselyov's Purely-functional Object-Oriented System.
Higher order functions in terms of objects?
In fact, Scala implements functions using objects.
An object with a single method is isomorphic to a function.
An object with a single method and some instance variables is isomorphic to a closure.
An object with a single method that takes an object with a single method as parameter or returns an object with a single method is isomorphic to a higher-order function.
That's exactly how functions are implemented in Scala (with a method named apply), Ruby (with a method named call), Python (with a method named __call__), and Java (as instances of a so-called SAM interface, an interface with a Single Abstract Method).
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
At first, I thought it was pretty cool that you can add something to an object without it being defined in the model. But now I can't imagine how this is used in a web application like a Ruby on Rails application. What use cases require dynamic fields and how does the UI allow a user to define these dynamic fields? Do you let the user set the key for the dynamic field (with a text box or something)? Do any of you know off the top of your head any demos are applications in general that showcase the real usefulness of dynamic fields? Also, if you plan on reading these dynamic fields, wouldn't you need read_attribute (in the case of RoR) with the name of the "dynamic" field already planned for ahead of time?
I'm asking this question because I have an assignment in school to wrap an application around PostgreSQL and a NoSQL database (I chose MongoDB). I have successfully done this, however, every attribute that I add to any objects that I have defined on the MongoDB side is already defined in the model. I want to show that I'm aware of this capability, but I can't come up with any reason to use dynamic fields and I can't find results on the search, "purpose of dynamic fields in mongodb" or "dynamic fields mongodb demo".
Thanks!
First of all "Dynamic Field" is a Mongoid concept, and Mongoid is just a ODM to map ruby objects into MongoDB documents. MongoDB doesn't have and doesn't need a concept of Dynamic Fields since it is schemaless. Although this theoretically means that every document in a collection can have a different structure, this is never a practical application for a MongoDB.
An ODM such as Mongoid provides a useful mechanism to define a schema at the application level rather than in the database itself. In this context there are two big benefits to Dynamic Fields.
The ability to add sub documents that have varying structures. For example you can have an Animals collection. Each type of Animal could have different body parts. But in MongoDB I don't need a "tusks" column just because some animals have them.
The ability to change the schema without touching the database. It is very common to add functionality to a database through additional "columns". Using Mongoid/MondoDB this can happen in the application code, as easily as changing an application class -- completely transparently with respect to the database.
I think you took wrong aproach to asking/looking for answer to this question,in my opinion best answer will be from the source and here is a post from MongoDB blog, I hope it will help you out.
http://blog.mongodb.org/post/119945109/why-schemaless
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I remember reading (or hearing) somewhere a few years back that classes must have either an operation, an attribute and an operation, or at least an attribute as a mandatory requirement -- not empty. What I'm asking is whether it's a violation of the Software Engineering rules to have an empty class, or a class with either attributes or operations without the other.
I just want to make sure so that my class diagrams are correct for my project.
Thank you.
You can certainly have a class with attributes but no operations and vice versa.
As for a class with no attributes and no operations - Most (all?) OO languages would allow this, but of course such a class wouldn't be terribly useful except perhaps as a base class of some sort.
Engineering is all about breaking the rules and thinking outside the box.
An empty class, without properties (attributes, etc) or methods (operations, etc) is simply that: an abstract datatype which does nothing.
Many if not most type systems provide for such a thing, if one isn't predefined.
If you define your own, you should have a good reason for doing so. In C++ for example a class used as an object or tag in metaprogramming is often completely empty, because it only serves to carry information through the type system or function overloading at compile time, and ideally does not exist at runtime.